GNOME Activity Journal + OpenOffice 3.3

It's been far too long coming, but after some pestering on #zeitgeist(sorry guys :) ), I have gotten the Activity Journal working for our users. Multiple users and documents being on NFS always makes these things more interesting, but I got it working well enough to push to testers.

Right now it's only showing documents created with OpenOffice via .recently-used.xbel; but this is the piece that helps us the most. Because we have a multi-server environment, there is separate instances of this file on different computers. I need to tinker with combining them together either over NFS or with some kind of merging process. That project is on the back burner though.

Here is the journal running from our NAS server. .recently-used.xbel is copied over from the OpenOffice server, loaded into $HOME , daemons started and the GUI launched. I'm sure I'll make improvements to the design as it's tested. So beagle is now bound to Windows+F5, and Journal is bound to Windows+F6. Documents searches have never been easier for our users.




Speaking of OpenOffice, I upgraded us to 3.3 this morning. It was the usual process: Close all running instances, block them from running it in the script, run the upgrade, QA that it worked and then open the one script to our 800 employees. So far no major issues and they are starting to test the new features.



Up next: Two days of debugging and testing Evolution. There are some problems and I want to create proper bug reports.

Beagle Returns

I mentioned that a week ago we installed a new NAS server to hold all of our documents. Now that a few tuning projects are over, I had some time to restore the functionality of having Beagle available for users to search their documents. We continue to use Beagle because it offers the ability to build the databases in a manner suited for multiple users, and multiple departments. You can tell it to create a database of all documents in the IT directory, and then grant permissions for only IT staff to see those files. Each individual user in IT doesn't then have to crawl and find the documents; it's only done once.

Beagle had changed a bit since the old 32bit server was deployed, so I had to check out some new backends and command line arguments. In looking at the old code and clunky UI, I decided to try a new approach to make it easier. This only took a short period of time, it's simply some new bling on top of the old infrastructure.

The old beagle-search UI had their available sources (folders) in a drop down menu along the top that they could toggle on and off. Users rarely found them and didn't know what they were selecting. Since all employees have access to three folders, I made a quick glade/python UI to connect them to the right document databases. The shot below shows the current design for testing. I added this UI to metacity/Windows+F5 so that it can be opened with a simple keystroke. UI pops up and you tell it if you want to search your personal documents, your departmental documents or citywide documents and then beagle-search comes up pointed to that static database. Simple, easy and stable.

Now all I have to do is install our standard MIME document bars on this server and the project is complete.




PS: Looks like Beagle-search really needs some new artwork, pretty fuzzy icon.

OpenOffice/Oracle Help, Firefox, OpenFire

Some experimental work has been done to start checking on how well OpenOffice can connect to the Oracle database. The database is outside of my division, so I'm hoping someone just knows how to solve this issue:

We can connect to Oracle cleanly using the jar file driver and everything works. However, for some reason it's displaying what looks like system tables along with the tables we desire. Has anyone experimented with this connectivity and resolved this issue? It seems odd to me that this is being exposed over ODBC.



New Browser Server

After going live on 64bit Firefox we had a few days with some brownouts and issues that required some changes and tuning. Two things seemed to have corrected the problems and it's running very well now. The original deployment used a NFS directory to be the area to hold temporary files instead of /tmp. This worked fine until a certain number of people and combination of plugins and then the disk io started to bottleneck. With 600 users that can access the Internet, there are thousands of sites they visit each day and it's hard to simulate that during beta testing. I moved the temporary storage back to /tmp and then only copied files to NFS when they were needed by external applications. I stumbled on "iotop" which is a beautiful piece of software. Those of us that used SCO Unix back in the day were always spoiled with "iohog" which performed a similar function.

We also had tuned Firefox with some custom tweaks available on the Internet to increase performance. These too worked in beta testing and under smaller loads, but it looks like when we got over a certain number of concurrent users it flooded the Barracuda, firewalls and eventually the Internet circuit with too many requests at once. When these settings were de-tuned things worked better. Even without them, response time is excellent.

So we have settled in around 80-100 concurrent users in Firefox and here is the load:




The City has "cyber cafes" set up in various places to allow employees to get on the Internet. This was done so that non-work related sites could be visited on breaks and eliminate this being done at their desks. I pointed the thin clients to the new server and have created a point release to our internal build with this feature. I'm testing it this very second and it will go live tomorrow. At that point nearly all services are disabled on the old server and we can begin the process of putting it into retirement.

We use OpenFire for Jabber on our internal instant messenger network. I brought over this software from the old server to discover that it was crashing on 64bit Linux. By default it runs its own included Java, which is only 32bit. All I had to do was modify the openfire rc.d file and add a line to point it to JAVA_HOME. It then ran the 64bit version and is working perfectly. Another item off my list.

Projects on the horizon for me: Upgrading to OpenOffice 3.3 (next week), working with Vincent and Hans on some GNOME issues, getting avant-window-navigator recompiled with all of the latest features, watching for updates to NX 4 to allow us to log into the servers with an iPad.

MIME Helper Interfaces & Opt Outs

A few people commented to me when I blogged about our MIME helper interfaces that this intermediate step would drive them crazy. As those of you know that follow our work, when you double-click on a file a dialog comes up and then offers you several options on what exactly you want to do with the file.

What's interesting is that we just deployed a new Firefox server a week ago, and there were a few file types that were not configured to open these helper interfaces and we got calls from some users that had no idea what to do when a download manager opens and asks them where to save a file. I then added those file types to the mimetypes file and they were content. So, I know that a vast majority of our users have benefited from this module being in place. Instead of having to worry about WHERE, they can focus on WHAT.

But, there are a few advanced users that want a traditional interface on the new desktop. When they double-click on a file, they want the default application to just open. They are perfectly content with moving the files around manually and do not like the additional step in the middle. So after some conversation with my Director, I wrote a quick Glade/Python UI that allows people to opt out of the helper interfaces and to just launch an application.

I broke this down into three different settings. One of them is for the Desktop, which is defined as interaction of files with Nautilus. The second is Evolution, which is defined as the interaction with files that are attached in email. The third is with Firefox, and defines how to handle files that are downloaded from the Internet. This offers a great deal of flexibility and those users that wish a more traditional approach to file management is able to work in this manner.

In the shot below is the opt out UI, along with a view of the current helper interface that opens when you double-click a file. Changing the setting to "No" disables this feature.

We're Hiring

This job opening is not in my division, and I'm not involved with the hiring process. But I wanted to pass it along to anyone interested. The City is hiring a Programmer to write business software. Currently most in-house applications are written with a toolkit called Panther. It doesn't get much simpler than this tool; connect to the database and drop and drag the fields to a screen and then hook up the SQL queries, buttons and logic.

There are pros and cons to working on Government, but it's a very stable work environment and it's fun to be a part of working outside the box with Linux and save lots of money in the process. The job would require living in the area. Largo is located close to Tampa/St Pete Florida.

Here is the job posting, and good luck to anyone that wishes to apply.

64Bit Firefox Deployment Complete

There is always an unknown when you deploy new software to hundreds of people. All of your testing never simulates their techniques and a full load. But yesterday the cutover to 64bit Firefox 4 on the new server went beautifully. We announced the upgrade and at noon I just killall'd their processes on the old 32bit server and moved the binary out of the way to halt it from running. I then tar'd up all of their .mozilla directories, and extracted them on the new 64bit replacement server. I changed the global launch scripts and was done. The total process took about 15 minutes.

The shots below are the 'top' windows with about 65 users with Firefox sessions running. Watching the load split on the threads is a thing of beauty and scrolling is as crisp as it was with just our beta testers. There are a few spikes in the 5-8% busy area, but the bulk of the time it sits under 1-3%. I believe this server could easily get 300-400 users on it concurrently. Very nice. Another item off my list. :)

Here is the link to the server.

Firefox Goes Live + Thanks + Possible Job Opening

As I have mentioned previously, lots of technology has been awaiting the new year when we are fully staffed in order to deploy. Tomorrow we are going live with the new 8 CPU, 6 Core server for deploying Firefox sessions. Everything is all compiled cleanly and natively on 64bit OpenSuse 11.3, stable and fast. Between noon and 1pm when the users are lunch, I'll do a backup of all $HOME/.mozilla directories and push them over to the new server. Then I just change the launch scripts to point to the new server and everybody is live. This technique works out well; if we have an issue that requires a rollback, all we do is change the launch scripts back to the old server. Today I'm giving the new Internet circuit and the plugins a good shakedown. Frame rates are good and sound quality over PULSE is excellent.

I'm expecting an afternoon tomorrow of minor tuning issues and helping people that didn't read the announcement message; but no major problems. In the shot below you can see I'm giving FF a good Flash test with Youtube.



Many thanks for Vincent Untz who has been working with me on getting a few upstream patches merged into OpenSuse 11.3 to fix a few showstoppers on our GNOME desktop upgrade project. A few more patches to GDM, Nautilus/GIO and avant-window-navigator and we will be ready to move the desktop into wider beta testing. Right now I have about 20 people testing and using it fulltime, and feedback is very positive. I've spent a good amount of time squeezing every second of time from our customized Xsession login script. I'm firing some of the code into background processes as appropriate to allow the script to get to the point that gnome-session starts as quickly as possible.

There is a chance that we will be hiring one programming position in the next few weeks. When I have an exact job description and notification, I'll post it here in case anyone is interested.

Finalizing USB Sticks & Cameras

I have blogged about parts of this topic in the past, but the project has developed and I wanted to update the status.

I have been working with management and end users to come up the best way to handle USB sticks around the City. One wants to allow users to upload their photos. However, using USB sticks as a 'sneakernet' needs to be discouraged. The whole point of having a centralized environment and using thin clients is so that the data remains on the server. Some people still fight the concept of centralized files and want to squirrel their data away. This usually ends up with disaster. Drop the USB stick in the parking lot and it's gone! We also want to avoid the situation where someone lassos entire sections of City documents and puts them on a USB stick and walks out the door.

In regards to word processing documents, we are a proponent in keeping them in OpenDocument format to try and ensure that they can always be opened in the future. There also is the issue that when Microsoft file formats are used, it's a downgrade format when used with OpenOffice. If a certain feature is used that has no comparable feature in MS Office, the information is not retained. So we always tell people to use odt,ods,odg formats when not collaborating with people on the outside. And now that OpenDocument is starting to be included in MS Office, the case for using this format is even stronger.

So with all of these things in mind, we have developed our first release of the new design. I'm sure there is a better UI design, but for right now we continue to focus on the work flow. In the shot below the UI on the right side opens for all City employees when they insert a USB stick or camera. It does a quick scan of the device and generates thumbnails of the most recent 36 photos. To insert these into any City applications, all they do is click on the photo; this places it into the clipboard at 1024x768. On the right side you can see Draw, and the right-mouse Paste command has inserted the photo. No file management skills required, no lassos and all they can do is move the pictures upstream to the server. This eliminates the need of having to give USB access to employees that might want to take a few pictures a month for posters or flyers.

If the software detects any Microsoft Office documents, the button [ Convert To OpenDocument ] lights up. If the user clicks on it, their documents are sent to the Linux server in a non-privileged user account and converted to OpenDocument on the command line (pyuno) and then copied back to the stick in a separate folder and without touching the original documents. The red arrow indicates the button was pressed, and then all MS Office docs are converted. Those users with USB stick access can then use Nautilus to bring them over to the server. The original MS Office are hidden from view so no chance of them grabbing the wrong files.

Our Director is going to take this approach to the other Directors and then we will get this code into the hands of end users for testing and feedback.




One last bit of information: All of this is unrelated to the users ability to send and receive MS Office documents via email as part of collaboration and sharing information with outside people. These steps are being done with USB sticks to protect our data; and try and break their habit of working using 1980s and 1990s file handling skills.

Project Updates

The New Year is here and lots of technology was waiting in the wings for our staff levels to be back to normal levels now that the Holidays are complete.

I finished the software module that allows our support group to support remote users. We also can obtain information about their Xserver (depth, dimensions) from this UI too. It's been live for a few days now and they are reporting that's been very helpful and saving us valuable time. The software it replaced took far more steps.

Support staff types in part of the users name into the Filter area and then a search is performed. Once they find the right user, they click on the user and it displays technical information about their session.



If Support clicks on the [ Request Remote Control ] button, the other users receives the dialog below. This allows them to grant permission before the session is viewed. Instead of running VNC on the end device, I'm using x11vnc which is just an excellent approach. We have users logging in with thin clients, NX/Windows and NX/Mac and x11vnc works no matter what end device is used. It's also 100% host based and can be upgraded and altered once instead of having to touch individual devices. If we attempted to put VNC on Linux, Windows and Mac there would be operating system nuances to deal with as well. The other positive thing that I discovered is that x11vnc is much faster on the new 64bit server. Support gets quicker UI responses and repaints; very nice indeed.

Here is what the remote user sees when we send them a remote control request:



The new MIME bars that we have been testing for many months are stable and working well, so I have backported them to some of our production servers and will be integrating them into our technology. In the shot below, opening a PDF from Evolution opens the new UI. Our Firefox upgrade is nearly ready to go live too, and this UI is used there as well. They also will see them when the new GNOME desktop server goes live later this year.



LibreOffice installed cleanly on our production server without disrupting OpenOffice, so I added an icon to the desktop for some beta tester users to "kick the tires". No decision has been made to transition at this time, but it's prudent to monitor this issue with an eye to the future.

Some Project Updates

I wanted to blog one more update before the Holidays. I'll be off the next week enjoying time with friends and family.

We received a patch from Barracuda that allows our web filter to work in a manner better suited for our network design (all users coming from the same IP address). This was the last hurdle before deploying our new 64bit Firefox server. It will be nice to see the 48 hyper-threading CPUs in production. It should be a nice upgrade for our users and make their sessions more responsive. We also got a circuit upgrade and more bandwidth. This should go live the second week in January.

Now that my iPad prototype login is finished, I spent time bringing over more shortcut icons from the production GNOME server and testing them on the new one. Mostly all that remains is Windows apps now, and they are being QA'd as we move from using Citrix to RDP. My coworker has also been experimenting with running them in seamless windows, which would be a nicer user experience.

We had a utility on the old GNOME server to allow people to share their desktops with one another using VNC (x11vnc). What I saw when lingering in the support area is that they spent as much time showing people how to initiate this request as they did actually solving their issue. Users have a hard time finding new icons. So in my new design, the originator sends a vnc request and once accepted their desktop remotely displays. All the users have to do now is wait for a popup window, accept it and then get their support from our staff. I have also experimentally added a few more options to the UI, and having a fun time learning to use Glade and Python. The shot below shows the screen. You perform a search for the user, it matches their name and alerts you that they are online (green button) and then gives you options to take over their screen. It also gives you information about their resolution, color depth and thin client OS release number.



Nomachine released a preview of NX 4 last night, and being that this will be used for several of our projects I took the time today to get it installed and test it. The install process was quick and easy, and I simply typed in the URL and authenticated and the GNOME desktop appears right inside Firefox. I am waiting for some networking to be altered to allow my iPad to connect to the City network so that I can test this from that device using Safari. This technology seems to be working pretty well and promise. I really need to give this all a good shakedown (and maybe read a few manuals ;) ), and will report further as it's deployed. In the shot below, I'm logged into GNOME and then using Firefox opened another session with a different account name.

First Tablet UI And Work Flow Nearly Finished

This week went quickly, along with my various projects I have been improving my python skills so that the language wasn't a hindrance to creating the ideas that were in my head.

When logged into the new GNOME desktop, the MIME bars were updated to offer another selection to Save 'To MobileDocuments'. While this is a simple concept to computer people, moving files around the network is very difficult to regular users. With a single click, the document that is being displayed will now appear on the iPad/Tablet device.



The first iteration of the user interface that displays when you log into the network in portrait mode from an iPad is finished (below). All of the documents in your MobileDocuments folder display on the lower panel as thumbnails. When you click on them once, the drop shadow changes color and the status line displays information about the file. Touching the thumbnail button again or hitting the [ Open ] button opens the document in the appropriate software application. I'm designing with the consideration that users will be holding a stylus pen. I'm not sure how easy a right mouse click will be with a pen, so I'm coding with this limitation in mind. The UI supported PDFs and OpenOffice documents, and I just added photos. There might be circumstances where employees need to take photos with them into the field, and it only took a few minutes to add this feature. Being that everything is running on the server, if the iPad is lost, stolen or fails, no City documents are ever lost.

When I am sure that we are feature complete for the first release, I'll spend some time on the UI. Focus was on work flow, eye candy can come later. Here is a shot of a 768x1024 window, displaying documents and pictures and then opening a photo with eog.



With the coding nearly complete, I'll be at a stand-still now until NX 4 is released. Right now it's impossible to log in from the iPad. With this sub-project nearly finished, I'll focus on delivering the rest of the software packages on the new GNOME desktop and await patches to fix the last of our show stoppers.

Up next: Expanding use on the new desktop/GNOME server, putting the new Firefox server live, testing the new thin client changes and creating a large NFS drive for our documents. December is looking to be very busy.

Already A Good Morning

Yesterday I blogged about some ideas we are experimenting with to reduce printing costs. It was one of those days where you walk out the door knowing that pieces are just about ready to work.

I wrote a few python lines of code for the Glade UI to copy a pdf template from a skel directory into the MobileDocuments folder of the individual user and then fire Xournal against that document. The results are below. I then simulated the stylus pen being used for note taking.



The documents created are 100% on the server and never on the local iPad/tablet (simulated) and immediately show up in the users full GNOME desktop. Double-clicking on the file brings up the PDF MIME bar which shows the document already available on the network.



I just have to learn a little about using the paste clipboard signal in python and that feature should be working here pretty quickly. That will allow Dragon Naturally Speaking documents to be pasted and immediately placed on the City servers.

Then I just need to write some code to create a listing of files in MobileDocuments and generate thumbnails. Not a bad start to my Wednesday.

Tablet Footprint & Cost Savings

Sometimes it's very hard to pack many months of conversations and needs analysis into blogs. My current project is just such an issue; I could type paragraphs describing the specifications but will try and be concise. We have tried to close up a number of open requests with one design.

There is a growing demand for mobile solutions that allow users to move around the building and gain access to their files. Our centralized design makes this easier, and many different concepts were discussed. The first inclination is to move in the direction of getting a laptop footprint device. Those of you that have seen my previous posts know that we already have a mobile laptop thin client that is being tested. The laptop footprint is not the best for meetings. Sitting in a room with 10 screens flipped up is not really ideal, and then you have to consider power needs, cords and batteries. They also are not suited for what people want to do most: annotate over the top of previously created documents. It would be wonderful if regular users worked as we do in the computer field with Wikis and sharing information, but that's not how they work at this time. They still want to annotate over the top of document with their own notes. Currently this is being done pen to paper. Technology changes are sometimes done in baby steps.

So if your IT department is like ours, you are not as staffed as you would like and the hours of the day are filled. So how do you add a new type of technology and still maintain a quality design? Replacing the thin clients at the users desktops with something they can pick up doesn't make sense. Our desktop cost is 600 dollars (400 thin client + 200 monitor) with a projected 10 year duty cycle. Annual costs are minimal. Laptop footprint devices (even thin client laptops) would then have lots of docking and undocking, snapping of wires, cords being moved, monitors plugged in, USB devices plugging and unplugging...all very expensive to support and problematic. Why change one of the most stable parts of your network? It was clear that our efficiency and cost savings should then be obtained from our printing infrastructure. We don't have desktop printers which are very expensive to maintain, but instead run departmental laser printers. Our printing costs and printed page counts are still too high in my view. There are people that print pages during document construction and then hand write notes on the pages; and some people print email messages in order to read them. Nearly every meeting involves pages being printed and handed out to employees. There has got to be better ways of working, and this for sure is the area that needs attention.

So what I am developing now with the IT Director is a way to integrate an iPad footprint device into our design as a way to reduce printing costs. The goal is to give them the power of the devices, but not allow them to store documents locally.

In prototype form I have accomplished the design below. I'm simulating this work flow on a thin client until NX 4.0 is relased. NX/Nomachine 4 will allow you to log into our servers with Safari directly from an iPad. The server will then detect your Xserver is 768x1024 and know that you are on a tablet and then bypass starting GNOME in favor of a UI designed just for this footprint. This will allow you to be logged into the server with a full GNOME desktop and also a tablet device at the same time. The UI opens in a split second, and will offer much faster response time than waiting for a desktop to start. The image below shows Xsession passing you to the two environments based on Xserver size criteria.


The workflow that we have worked out so far is: When users log into GNOME they always have the following icon on their desktop. This opens a Nautilus folder into which they can drop and drag PDF and OpenDocument files. Anything in this folder is staged then for the iPad devices.



The shot below shows the current UI that is displayed in the 768x1024 footprint, exactly what will be seen on iPads. The panel at the bottom appears and thumbnails are generated of everything in $HOME/MobileDocuments sorted in reverse order newest to oldest. Clicking once on the document will display information about the document on the status line. Pressing Open will open it in either Xournal or OpenOffice. Xournal will allow them to use a stylus pen and mark up the meeting notes in their own handwriting. These documents are always on the server, and when they return to their desks they are available for immediate reference and further editing.

The iPad also has Dragon Naturally Speaking, and I have created a small multi-line text widget that will accept a paste from the local device. Once pasted, the button "Save Dragon Document" will become active. When they click this button, the text will be converted into OpenDocument (with perl modules) and a unique date stamped file name auto generated. The document will then display on the left of the panel as a thumbnail and be available for editing.



To answer the questions that I think will be coming :) -- ** Yes other tablets will be reviewed and the market is always monitored. This design is elegant in that it does not lock you into a certain vendor. ** Yes the UI is very basic and will evolve and probably sux. I'm more focused right now on this work flow. ** Yes iPads are $500 a piece, but even buying 10-20 of these would be but a small dent in our printing budget. A 10-20% reduction in printing might pay for the hardware in the first year.

I'm looking forward to testing this workflow and it's proceeding as a back burner project along with my primary projects.

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.

Weather Applet Re-Wrapped

For a number of years we have used a global weather applet which has become very popular. The reason why this application is worth the time to develop is because otherwise you have hundreds of people during the day navigating around the Internet to look for information; this is especially true during inclement weather. Instead just one daemon runs and downloads all of this information ONCE and saves it to a shared directory. Then when users activate this applet, they load in these pictures and get current information. This greatly reduces Internet usage and helps our bandwidth.

I re-wrapped this application with greater flexibility and made it consistent with the new desktop helper MIME bars that I wrote. One of the biggest problems that users have is getting information around the network, "I'm looking at this image, but I have no idea how to get it to email or to print it". So there are now options to take the currently displayed image and save it, copy it to the clipboard for later paste, print it or email it directly from the UI.

I just pushed this live and bound it to the Super-F9 key, let's see what my early beta testers say. :)

Up next: Cleaning up other dialogs and screens from the older desktop, installing patches and poking for bugs and installing more icons with links to our internal software. Still on target for wider beta deployment in November.

Desktop Cleanups Continue

Still working on prepping GNOME 2.30 to replace our very aged GNOME 2.16 server and also on getting Firefox 4 ready. I have been testing different cache lockdowns in gnome-mplayer to find a good middle ground between the clip starting and having enough cache to play without interruptions. Obviously this depends greatly on the remote server, but testing it to find a good sane setting that will work most of the time. I don't want users tinkering with these settings; because they will randomly increase and decrease values and then wonder why things are broken. :)

In testing the workflow of the new Picture Options bar that comes up when you double-click on a picture, I decided to add two very basic features. EOG doesn't have a way to put the image into the clipboard, and it's a shame to have to wait for GIMP to start in order to perform this step. So I added a feature to send the image to the clipboard. It's very common for users to want to rotate pictures they have taken, and having to start EOG to perform this step was clunky. Since EOG doesn't copy to the clipboard, after rotating the photo they then have to save the photo and then double-click on it again. A simple 90 degree clock-wise rotation was added and works great. (seen in screenshot below). The python Image library is awesome and easy to manipulate photos. Did I mention something about clipboards twice? :)

With some help from the avant guys, I was able to get software to better sit under their corresponding launcher icon. This combines the launcher icon with the window list functionality nicely and provides more space on the panel. Next up is pondering the fact that all rdesktop instances come back with a WM_CLASS of "rdesktop". (current panel seen in shot below).

At this point the functionality is mostly in place and it's time to bring over the rest of the software packages and create artwork and icons.

I had to do something clunky to application-browser to get around a bug. In previous versions of GNOME if the user selected this software process again, it would connect to the already running process and reuse it. In the current release there is a bug and it keeps adding another instance to the process list. If a user clicks on this menu system 20 times during the day, they would have 20 processes. :| So the code below resolved that issue. Hopefully a patch is forthcoming; this is some serious nastiness.



Current desktop screenshot:

Panel, Browser Stress Test & Thanks

With some tinkering of lockdowns and gconf settings, I have gotten avant-window-navigator working well enough to push to some early beta testers. Very nice applets and a clean modern look. Let's see what kind of feedback I get back tomorrow. :)

Thanks to Kevin for your help with understanding that xrdb is a g-s-d plugin. Testing Motif applications right now to see how the themes are working.

So with that in place I'm giving mplayer, Firefox/Flash and Pulse Audio a stress test to try and get them to crash. So far sound is strong even running remotely over the network, frame rates are excellent. I think the user community will be pleased with these upgrades.