Portrait Feature Merged Into Thin Clients

A conversation that has taken place over the last few months is the idea of adding portrait mode as a supported thin client workstation feature. This is being done for two reasons: 1) to promote electronic document construction and review for those users that do this often as part of their jobs. We still have a good number of employees that use paper as part of the construction process. They print the document, hand write their notes on the paper and then submit it back and someone re-types their changes. (sigh!). One bad thing we have done in the technology arena is widen our screens for beautiful landscape views....and yet continued to design documents in portrait mode for printing on paper. From this perspective we kind of have promoted not working electronically. Hopefully this change will reduce these older techniques. 2) With tablet devices getting more popular this footprint needs to be tested and accounted for in design. Note: I'll be blogging about an offshoot of issue number 2 in the next week or two.

Since I was updating the thin client operating system anyway to make picture management easier (see earlier blogs), I decided to use the short week to just get this feature deployed. After a few mods to our standard xorg.conf file, our ATI cards are working great with xrandr -o and rotating cleanly with no artifacts. Nice.

gdm on GNOME 2.30 plays nicely with rotated screens and I'm happy with the results. Authentication cleanly worked, GNOME started and avant is working well in this mode. In the shot below you can see 1050x1680 in all of its beauty. OpenOffice looks great and for the most part everything is working as anticipated.




One issue that is being discussed is whether or not we will allow users to flip their monitors day to day or if this will be a setting that is locked down. As anyone knows that supports lots of users: anything that moves or can change will have failures and increases support. Something as simple as a power cord popping out produces calls to our help desk.

I made a quick change to our login chooser (below), and will get get this out to a few beta testers in the coming weeks. Initially we will allow the users to flip the screen on their own, and see how it works.



In my next blog (probably week of December 6th), I'll write about some tablet/mobile ideas that are a part of this portrait project. We have some ideas on how to save money in this regard.

Another Week, More Progress

The weeks go very quickly around here, and I have made lots of progress on my projects.

The Firefox 4 sever is basically all done and ready to deploy. There are some policy issues related to content blocking that are being resolved. I'm not really involved in that decision, and it's being handled at an Administrative level. Once that is settled, I'll create a script to backup all of the users $HOME/.mozilla directories and move them over. We have done this before and it's very simple and easy. 800 users moved to a new version of Firefox with just a tarball and script change. :)

I finished writing the first release of our USB stick user interface idea. The beauty of this design is that we will be able to give this to employees and they will be able to insert a USB stick with photos (or camera) and the photos will display and once clicked go into the clipboard. This will allow us to eliminate the need for many users to have full access to the sticks. Those employees that do need full access to read and write USB sticks will use Nautilus to transfer files, just as they did before.

Regardless of the megapixel size used on the camera, the UI converts them to 1024x768 before placing the pictures into the clipboard. Currently we have a lot of people that shoot 10 megapixel and then insert that photo into a document and resize it to 1 inch by 1 inch with the resize handles of OpenOffice and then wonder why their resulting PDFs are so big. For many documents and email messages around here, 1024 is plenty big. The shot below shows the thumbnail screen that comes up when you insert a stick. It loops through the files and summarizes the file types and then sorts the photos into reverse date order and displays thumbnails of the newest pictures. The black lines demonstrate the thumbnail being pressed, and then a control-v in OpenOffice and Evolution and the photo is inserted. I gave the UI a nice icon (green line) which then displays in the lower panel cleanly.



The functionality of the MIME bars is pretty well locked now and finalized so I have been adding the final changes to make them look nicer. I found a nice script that allows you to use convert to dynamically create a drop shadow for any thumbnail. So now all of the bars look like the shot below. I just need to give the UI an icon and do some final spacing changes...but I'm pleased with how they work.



One of my ongoing projects is to try and get as much speed as possible running Microsoft Windows applications over RDP. In the last few months we moved the RDP client off of the server and made it run locally on the thin client. We also have started to trickle in the new HP t5745 thin client to the users that use graphics heavy Windows applications because its Gig networking and faster CPU is yielding about a 20% speed increase. Running RPD locally on the thin client also got us about 20% increase in speed, nice.

One other technique that can be used is to use cache to increase performance. On a computer with a hard drive, this works well and does in fact make things run faster. However, the thin clients have solid state Apacer flash memory in place of a physical hard drive. The write time of these drives was not a fit for trying to use it to hold cache from running software. Also, whenever the thin clients would perform a disk flush (sync) the software would sometimes slow for a few seconds. What I did in the new release of our thin client OS is make a 50MB ram drive, and then mount it to $HOME/.rdesktop of the 'user' account. This will allow cache to be sitting in memory and should yield better performance. I'll be pushing this change to beta testers later today.

The shot below shows the RAM file system which is then mounted into the cache directory.



Got a nice comment concerning the Rdesktop fork called FreeRDP. I'll be doing QA work on that in the coming weeks and see how it works. Very nice to see patches being merged and new releases.

Happy Friday Updates

I have been busy working on various projects and making progress. Our architecture group also had a meeting and have made some decisions about some open design goals.

Compiz No More

At this time we are going to not bring over Compiz to the new GNOME desktop that I am building. This technology will probably be tested in a back burner type project, but is not on the design goals that must be met before we go can go live. There are users that love Compiz and I too used it every day, but a few issues were taken into consideration. 1) In order to have a consistent thin client build on all HP models (5725, 5735, 5745) we upgraded to HPs Debian Lenny build. On our ATI cards, the 3D desktop is crashing the Xserver periodically. For some people it never happens, and for others it happens often. I haven't gotten any updates to my bug report and don't expect that anyone will fix this issue. When HP releases a Squeeze update, I'll review the updates and try again. 2) We wanted to have a consistent desktop now on all devices. If you enabled Compiz here at City Hall it worked great. If you went to a remote site on lower bandwidth the regular GNOME desktop appeared by design. Sometimes people had been on Compiz so long, they didn't remember how the other desktop works. 3) We are anticipating a future where people will be on more and more mobile devices and carrying devices with them; so a simple, fast and consistent interface is desired. You aren't going to be pinching your fingers and turning a cube on an iPad type device right? :)

On a technical note, I compiled Compiz 0.9.0 on the 64bit server and the speed was excellent. With some patches from Debian on the thin clients and more time I am confident it would have worked great. Sadly, time is my biggest enemy sometimes.

Firefox 4 Updates

We have about 15 people using Firefox 4 (64bit) fulltime and all plugins are working and the server looks great. Pages are loading faster than ever and scrolling is crisp and fast. I'm very pleased with the results. Having 48 CPUs kind of helps too. :) I expect this server to run for a good 4-5 years and it's the most cost effective way to deploy browser and video technology to our users and our thin clients. Adobe Acrobat, Flash and Firefox are touched once and the updates go to everyone instantly. This server should go into wider deployment in the coming weeks...almost done.

Desktop MIME UI Status

As I have been adding users to the beta desktop, I have been hearing consistently that they really like MIME UI bars that open when you double-click on files. It's as simple as it can be to move files around the network while sheltering them from the physical processes. I have said many times that a file picker that opens in any application is the kiss of death for productivity. Navigation even in 2010 is one of the hardest concepts for regular users to understand.

We have been working on promoting the usage of the insert link/file:// technique in Evolution to email a link of a document to other employees instead of doing a physical attach. This reduces the instances of duplicated documents and also helps with quota space in the post office. I experimentally added a feature to do this automatically from the GUI and it's working well. When they double-click on a PDF for instance, one of the options is [ Link To Evolution Message ] (below). This builds a small HTML file which is attached to a new email message and contains a bit of href "magic".



Below is the resulting Evolution message generated. This eliminates them having to use the Insert Link feature, and mess around with spelling things correctly and understanding where documents are stored. Feedback was positive on this feature. I think once we have more people using this feature, it will be used often.



The other feature that I added was a checkbox to help resolve one of our improvement areas: users don't understand how big the pictures are that are coming from their cameras. Shooting 10 megapixel is great, right? :)

When [X] Email Friendly Size is pressed the picture is reduced to 800x600 and compressed into JPG.



USB Sticks, Viruses And Functionality

Those users with permissions are able to gain access to USB sticks on our current deskop and it's working well. A ftp daemon is running on the thin client and allows the GNOME server to gain access to the device. FTP is jailed into /media and also certain types of files are disallowed from view. Pictures and OpenDocument files can be moved to/from the sticks. Microsoft Office and PDFs can be moved TO the sticks, but not FROM the sticks. This is because of their virus risk, and also the fact that this work flow is not in our business practice. Documents should not be constructed off network and especially with non-City standard software packages. All of our software writes documents into open document format. If documents are to be received from the outside, they should be emailed whereby they are fully checked for viruses. It also is not a good practice to use USB sticks to house data. The risk of data loss (loss, theft, physical failure) is very high.

A review of the logs indicates that primarily users are using USB sticks to upload pictures, and very often just a few pictures at a time for inclusion into documents and presentations. I have designed a mockup of a dialog that will come up when a USB stick is inserted into the thin client. For many users, this will provide a simple UI to handle their needs with no file managers. The UI will build thumbnails of the last 32 photos taken along with a summary of files contained on the stick. If the user clicks on the image it puts it into their copy buffer at which time it can be pasted into any other application. This also will allow me to shrink the image to 1024x768 prior to putting it into the clipboard and reduce the huge pictures that are being taken on the cameras. The UI also gives them the option of emailing PDF and MS Office documents to their email account.



Of course the users will continue to have access to the full file manager to manually drop and drag files as they did previously. But at least now a simple interface which covers 80% of our needs will open automatically when usb insertion is detected.

Coming up for me next week:
- Begin moving services live on the new Firefox 4 server.
- Continue testing the new GNOME server, and installing updates and patches.
- Await the next avant-window-navigator tarball to fix a few issues.
- Experiment with making the USB process easier
- Begin testing some ideas to speed up rdesktop/xfreerdp with the use of a RAM file system on the thin clients.
- Being engineering the replacement for the server that holds the bulk of our documents and pictures. Use beagle again or try and install Zeitgeist?

Desktop Progress Continues

Problems can be solved, they just need time. :)

I had been kind of putting off a few technical issues while I explored options to see if better solutions existed. Our online friend "Pepp" has been poking at getting Helix/Real Player to compile natively in 64bit. The 32bit version runs, but the problem is that I was having problems getting padsp working to redirect the sound to PULSE. This is because you cannot wrap a 32bit application with 64 bit pulse libraries (padsp). I used cpio to extract the 32bit version of libpulsedsp.so from the i586 RPMs and installed it into /usr/lib and created a padsp & padsp.64 to run both types of applications. Everything is working as it should now. Circled in purple below is real player running seamlessly from 64 bit Firefox. CPU usage is excellent, and sound and video are synced well. Seems like it's going to work just fine. I still would love a native port however! :)

I also was having some problems with the mail-notification popup applet, it apparently is still expecting the icons to be in the layout of older versions of GNOME and certain pieces of art were not displaying (stock_unknown and stock_mail and others). I went into the source code and forced it to read these icons from /usr/share/mail-notification/ as a quick hack and now everything is working. I also wrote a few lines of code to always force working settings into the mailboxes.xml file which houses the email account information to ensure it's working each time users log into the server. The ability to get popups when email arrives has proven very popular with the end users and it was important to bring this over to the new server.

The last major piece of testing is with our Microsoft Windows applications. I mentioned in an earlier blog that on the production desktop we were using three different connection methods to launch Windows, and we are standardizing them all now with RDP/Rdesktop. So some QA and testing days ahead for me.