Improving Window Resolutions

Things have been so busy, I have been getting a lot done and been meaning to blog about what's happening. Perhaps some of what we are doing will give you ideas to solve similar problems. The first chunk that I worked on was the user experience in regards to interacting with MS Windows software from GNOME.

Without a doubt one of the hardest parts of deploying technology to users is monitor resolutions. It's hard to explain and it's hard to explain now it relates to font size and screen appearance. Our environment allows users to roam around all of our buildings and use mobile devices to connect to the same GNOME desktop. I was not satisfied with static or hard coded user settings. I wanted them to be able to truly roam around through the City and have the experience as simple as possible and not require them to keep picking settings or have a dissimilar experience on another workstation.

All of the Linux applications work great and require no customizations. However, Microsoft Windows applications that are integrated into GNOME are a challenge. Largo uses mostly RDP/Rdesktop which works well for us. Many applications will run seamlessly and behave just like standard Linux windows and are not a problem. However many other Windows applications are not well suited to run seamlessly and require a "container" around the UI.

The code for a single monitor on the new GNOME server was already settled for how to handle launching a MS Windows application on a single monitor workstation. It subtracts enough room for the lower avant-window-navigator panel (which we do not allow users to resize or move) and then enough room for the metacity window manager. The window consumes about 90% of the screen as seen below. Users can still switch workspaces and they have the largest possible canvas to run their software. Users tend to always want to maximize windows and this gives them the best possible experience without obscuring anything and confusing those that struggle with window management and movement. This code works for all resolutions and monitors.

So of course when you settle on a design, there is always an exception. We have 1-2 applications on Windows that were developed with the expectation that users would run them in maximized mode and need close to 1024x768. (Why would anyone multi-task and use multiple windows, right? ;) ) We have a good number of users still in 1024x768 so what this means is that the lower few pixels of their software was getting chopped off sitting above the panel. After reviewing options, I decided to develop code that allows us to specify WIN_MINIMUM_RESOLUTION in the GNOME launch script and it performs the following logic:

Is their monitor physically smaller than this value? Disallow the software from running and alert the user that their resolution is too low. (Yup, we have just a few 800x600 devices still in play and home users sometimes configure their PCs in 800x600).

Is their monitor big enough to hold this value, but it's obscured by the panel? If so, enable Intellihide in avant-window-navigator and launch the software. The panel then hides only when it's launched and is active only for that session.

Is their monitor big enough to run this software completely above the panel? Just launch it in 90% mode as it did before.

Intellihide is a feature that is hard to explain to users, so only those few people that need to see it, have it enabled. Everyone else has the same experience. This code was deployed and worked well and now the users can see all of the UI.


As long as I was in this code, I have been wanting to clean up the code for those users on dual screens. Some software applications users want to fill both monitors, and some things they want to fill just 1/3 or 1/2. Previously there was an underdeveloped UI that allowed them to pick the size each time MS Windows was launched on a dual screen monitor. This was very simple and worked, but I hate being asked the same question repeatedly and I am sure they did too. So I made the assumption that each unique application is normally run with the same scaling factor. You might always use an engineering application in full screen, and you might always use Visio in 1/3 size. I added a checkbox on the UI that allowed them to store per application settings of 1/3, 1/2, 2/3 and full screen modes. If this checkbox is enabled, it keeps it and uses it automatically the next time. If they log into dual screens @ 1440x900 or @1024x768 it won't matter, everything is dynamic and opens in the same scaling factor.

If this same user logs into a single screen workstation, this code is not used and it just runs in 90% mode. So the infamous question, what if the user wants to change it after it's set. Old school thinking would be of course to make a UI where the settings are stored and allow them to go in and make the change. I have found that such screens are seldom remembered and we get support calls, or they just suffer and are not happy with the experience. So following in the trend of some recent projects, I present this information on a dialog box similar to notify-send. It's on a timer and pops up in the lower left corner. If you leave it alone, the software uses this setting automatically in five seconds. Very clean, and no "hidden screen" to change settings...it's always right there and easy to change.

Screenshots; I love them and maybe they help show how this all looks to the users:

On a single monitor @ 1440x900 Visio is launched and creates a nice workspace with no prompts.



On a dual monitor @1024x768 user is prompted for desired Visio window, checkbox allows them to make this setting "stick"



The dual screen user has selected 1/3 and opted to remember this setting each time. Container opens as requested.



User launches this same application and GNOME finds setting and alerts the user that it's going to be used. Pseudo-notify-send popup is on a timer and allows them to easily change it later without having to hunt for a hidden UI somewhere.



Feedback has been positive and I think it was time well invested. Support calls concerning resolution problems should drop.

Quick Updates: Acrobat Reader 9.5.1 finally released and installed; Flash 11.2 seems to be working well and is now live. Testing Firefox 12.

Other Projects: Significant advances in improving techniques with shutting down software correctly to avoid recovery dialogs. Finally a way for us to grab backtraces on deadlocked software while dropping false positives....I'll blog about this next week. It's really coming together nicely.