LibreOffice, You're On Deck

After many months of prep work, QA and testing we are finally going live with LibreOffice next week.  There were a few bugs and nuances during early testing but with 3.5.2 we are to a milestone that seems ready for use with our 800+ users.  I have a group of beta testers and they have been very helpful in identifying documents and issues that needed attention and review.  Today I installed code to push them a fresh set of "defaults" each time they launch LibreOffice for a suitability test prior to deployment.  This is exactly what everyone will see next week, and this will allow me to push them the latest updates leading up to that date.  They are given a quick dialog which alerts them that settings are being reset

This dialog will go away next week.  The first time that you launch LibreOffice a dialog is presented which displays a quick summary of all things changed since our last upgrade of OpenOffice.  I have used this in the past with OpenOffice and found it to be very helpful.  No one reads the published articles and email messages about upgrades, but here it is again.  We then have acknowledgement that they clicked through.  The dialog gives them the option to receive a PDF of all release notes.  It also gives the users the ability to have a document emailed to their home address with the download links of LibreOffice; or if they want we will burn them a CD with the software already downloaded.  It's proven very helpful to promote people running these same software packages at home on their computers.

And then LibreOffice launches normally and quickly.  While you don't really ever have a "cold start" on a multi-user server, it's about 4 seconds from splash page to the point that Libre is fully rendered and ready for typing.  Certainly acceptable. 

Typing is crisp and responsive over remote display,and users are indicating that it seems to run faster in many places than did OpenOffice.  Being that OOo and Libre are on the same physical server, it certainly is an apples to apples test.  Both have identical resources, fonts and printers.   We have seen some problems with printing tables in comparison to OpenOffice and our support group has discovered some ways to align the tables for better printing.  Many of these documents have been upgraded several times going from WordPerfect 6, 7 and 8 and then OpenOffice 1, 2 and 3 and now LibreOffice.  It's a wonder they open as well as they do. 

Once this is deployed, I will be spending some time in some known problem areas.  We have seen some performance problems when Anti-Aliasing is enabled for graphic objects.  I want to better understand these problems and work with the developers to make improvements. 

Trapping User Crashes And Eliminating False Positives

When I was working on the new GNOME desktop servers, I wrote all of the launch scripts to go through a central set of calls so that we could trap an unprecedented amount of data.  Every click and login is recorded and we can tell when users are having problems.  One of the unexpected issues noted is the number of people that are "stealing" software packages that are running on other workstations.  We have two GNOME servers that you can log into and from there you can launch software applications such as Evolution and Libre/OpenOffice which are running on other "applications servers".  Both of these software packages cannot run on multiple heads at the same time.  This multiple login architecture was designed with the expectation that it would be used just occasionally and in a pinch; you are already logged in and running Evolution and go to a meeting in another building and need to 'steal' Evolution from the second workstation.  But the data was indicating that people were doing this all day as part of normal business practice.  When you steal Evolution it crashes and when you steal Libre/OpenOffice you are 100% assured that you will get a recovery dialog of some type.  In the dialog below, it shows how Libre and Evolution are running on servers which then can be run from the two GNOME desktops...but only to one at a time.

We had a lengthy conversation with our Director about this technique and sadly it cannot be stopped, because there are really times when users need to do this.  And there are 16 hours of the day when IT does not have support staff available to assist users.  So what we settled on was a consistent dialog to be used in places where users make an attempt to 'steal' software from one location to another.  The dialog warns the users of the severity of what they are doing and then they have to enter a six digit code which is their 'signature' that they accept the risks.  This same dialog is used for LibreOffice too and soon will be used for times when users attempt to log into the same GNOME desktop for a second time from another workstation.

The beauty of this design is that now when they terminate software with this technique it simply does an exit 0 and no longer is logged in our software as a crash and we can now make no attempt to grab a backtrace.  They are on their own and any problems they have are their own.  What they are doing is exactly like having a desktop computer with software running and pulling the cord; of course you'll have problems and very probably lose work.  We have had a huge drop in people using this technique once the dialog was installed. 

Now that false positives have been eliminated, it's now possible for the first time to grab a backtrace from software that has deadlocked. We know it's frozen because they are requesting a kill from the same workstation from which it was started the first time.  In the case of Evolution when they try and kill a running Evolution instance, they now get this dialog.  Once they select an option from the UI below, it finds the 'evolution' and 'evolution-data-server' process and grabs a backtrace and then closes them down.  Whereas previously we only had backtraces of a crash, now we have backtraces of deadlocks.  This will allow me to look for locking trends and work with Novell in improving the software. 

And if you are interested, here is the code that runs prior to starting the Evolution process.  When they click on the Evolution icon it always first tries to raise Evolution to the front of the window stack with wmctrl.  It then looks to see if it's already running.  If it's already running, it determines if it's running on their current workstation or another workstation.  If it's the current workstation it gives them the dialog to pick the last thing they did before deadlock; from this dialog they can obviously cancel and leave it alone.  If they terminate Evolution, it finds their two processes and used gdb to non-interactivity dump a backtrace.   If instead it's running on another workstation, it warns them that shutting down software is dangerous and then if they do so shuts it down and makes no attempt to create crash backtraces or deadlock backtraces...they are on their own.

I'm excited about the quality of data that we will be obtaining now, and this same code will be moved fully into LibreOffice once it's deployed next week.  We're getting complete crash and deadlock backtraces from hundreds of users without them having to mess with bug-buddy; everything is fully automated.

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.