Review: Flexiglass 5/5

If you are a Mac user that have spent any time on recent desktop Linux, chances are you will be missing Compiz-like window management.

(On a side note: Even Windows converts may be missing some niceties such as double click to maximize, or resize by any corner or window edge that wasn't added until Lion.)

I bought a Flexiglass license a couple of months ago and I love it. Flexiglass offers:

• Move a window using alt + two fingers (think alt-dragging in gnome/kde)
• Resize using alt + three fingers (Mac OS X > 10.7 can't resize a window by dragging any corner/border) 
• Real maximize by right clicking the plus button (Make a window fill the screen, instead of leaving to the window manager to guess how much space it needs. )
• Real close by two finger clicking the cross button. (Actually closes the application instead of closing the window and leaving the application running.)
• Shortcuts for resize/move to specified postitions. Nice for when you want a howto and a terminal side by side.

I have a Divvy-license from before but after I started using Flexiglass I don't need it anymore as Flexiglass offers all I used Divvy for and more.

Below are some screenshots from the settings to show the configurability of Flexiglass:

Basic settings for Move and Resize. The settings are customizable for both mouse and trackpad and Flexiglass automatiaclly changes profile when you attach or remove a mouse. Nice!

The exceptions list: I don't need it but I figure graphical artists might need to be able to use the mouse together with modifier keys in some applications without activating Flexiglass.

I thought I'd use the "Real Zoom" and the "Real Close" features a lot, but as it turns out I end up double clicking in the window title bar to maximize it instead. On the other hand I use the Quick Layout Shortcuts a lot for example to tile up two shells at the right of the screen and the documentation on the left

Autostart? Yes!

Do those stylesheets really need to be in the page body?

I once worked on a medium size enterprise software project that felt very sluggish and slow. I was new to the technology stack, new to anything but small web applications and I figured it just wasn't possible to get that particular stack any faster.

As the project went on features were added, more optimizations were added by expensive consultants,  a few performance regressions were weeded out but the app was still as sluggish as ever until one day the ux designer came and asked if there was any reason the consultants needed the stylesheet in the page body instead of in the head.

There wasn't, and at the next deploy the app was suddenly a whole lot faster and smoother. So much for the cruft of StringBuilder for every string concatenation. So much for higly efficient log statements, each spanning three lines, applied liberally across the whole codebase.

From that day on I became a little more pragmatic, a little less uninformed regarding that particular stack, the expensive consultants that happend to know it and optimizations for web applications.

Disclaimer: Of course, I'm not saying you should ditch StringBuilder and stop checking if debugIsEnabled() in thight loops, but in the average controller code in the average enterprise web project I guess they won't matter much.