I have been testing LibreOffice 3.5.1 on our server with anticipation of a migration from OpenOffice in the next 30 days. The users are going to like the advancements made in the code base since OpenOffice 3.3 and the migration should go pretty painlessly.
This project has given me time to revisit one of the drawbacks of server based computing from the user perspective -- control over recycling power and resetting software. There are many drawbacks to running software at their desk, but one thing it does is allow them to "reboot" the computer. If LibreOffice locks on a file, all children processes thereafter are dead as well and the end user cannot "fix" this issue. On a PC they'd reboot. Doing something with a process killer is beyond the scope of what most people can do. They don't know what to kill, and how to pick and troubleshoot errant processes. When a user requests a document while another document is already open, the server really can't tell if the first process is running correctly. Consideration is also needed to the fact that we are only staffed from 7am until 5pm with people that can assist with these matters. The previous design was to give them a dialog when a second document opened and ask them if they wanted to kill the previous document. Clunky, but required to ensure off hour users the ability to fix their sessions. My mindset since OpenOffice went live was that I needed something like notify-send that had a pushbutton trigger on a timer. With resources allocated to installing LibreOffice, I created my own with Python/Glade. Instead of something intrusive, they get a popup in the lower left corner when they launch a second document. If everything is working fine, they leave the dialog alone and it closes after 5 seconds. If the first process is locked, they can click on [ Terminate All LibreOffice Sessions ] and it does exactly that.
As time allows, I'm going to see if I can file a feature request to make it so that children process of LibreOffice can "poll" the parent and see if he is alive and then reset itself if required. This would solve issues and remove the dialogs completely.
I have been revisiting other dialogs and messages on the servers and have made changes. Many of these changes have been made because we are now tracking a more information regarding how they are reacting to and using our dialogs. I'll blog more about that in the coming days.