Desktop Linux: Gnome

August 29th, 2007

I had been intending to write an entire series of posts about our corporate switch to Linux on the Desktop. To date, I wrote only one introducing the project and our reasons for switching from Windows. That was back in April.

Today I’d like to start talking about it all some more.

We have standardized on Gnome for our desktops. Given the Windows background of our user base, it was pretty much a given that we would have to use either Gnome or KDE. Something like fvwm or a non-integrated environment just wouldn’t be a good option.

We evaluated both Gnome and KDE. The very “clean” appearance of Gnome was a nice thing for us. KDE seemed to be to “chatty”, talked about entering in audiocd:/ when it shouldn’t have needed to, and generally violated the KISS and principle of least surprise too often. That said, I continue to run KDE for my personal desktop because Gnome just doesn’t have the flexibility that KDE does. It is too bad that Gnome has gone on this remove functionality kick, and KDE hasn’t gotten the KISS religion yet.

Anyway, Gnome worked well for the most part. We have set some defaults in gconf for things like panel icons. We also set a few mandatory defaults. I fixed a couple of bugs in the vfs system related to nfs4 support, which manifested themselves as icons for files newly saved to the desktop never showing up.

We wanted to present a customized menu to people based on what their job function is. That is, we are using a single system image, so all apps will be installed on all machines. But we didn’t want people to have to see a ton of software that they don’t use. That was easily enough accomplished for custom apps by creating desktop files with mode 0640 and setting the group to the set of people that should see the program on their menu. We removed a few stock programs (such as the terminal) from the menu as well, using dpkg-statoverride. That was also quite easily done. However, I will say that the entire Gnome XDG menu thing is woefully under-documented.

We use Firefox for the standard web browser. It is integrated well enough with Gnome and we have no problems there, aside from sites that are IE-only. We solve that with a Windows terminal server, which I’ll discuss later.

Our network printing was already based on Cups. The individual machines are set up as Cups clients only, which works fine. We did find, however, that gnome-cups-manager automatically installs a tray monitor for cups. This monitor puts little printer icons on the tray when printers are in use. Unfortunately, it figures out which printers are in use by polling the server, and it is turned on by default out of the box, with no good way to disable it short of dpkg-statoverriding it to 0000. You can imagine that hundreds of users times dozens of printers times numerous polls per minute created quite the load on the server. This was a really braindead design and the people that wrote it should have known better. It is also quite useless to have icons coming on for all the printers on the network, which on some networks could be thousands, and not even on the same continent as the user.

Printing is generally a bit iffy in Gnome. They seem to be transitioning between about 3 different printing toolkits, all of which have different print dialog boxes with different supported features and different ways of selecting printers. One chief annoyance is that the print box in evince (the document/PDF viewer) does not let people access printer-specific features such as hole punching and stapling. So we installed gtklp and xpdf for people. The people that print heavy PDFs are huge fans of gtklp these days; it’s a nicer solution than we had in Windows. Nobody really likes evince. We also have had some trouble with evince generating PostScript output that some printers can’t grok. It sounds like all this should be much better in newer versions of Gnome, which if true, would be welcome news.

The Gnome screenshot tool makes it easy to save off a screenshot to a file, or to drag it into an email, but it is difficult to print it (you have to save it first). That was a common complaint around here, so I wrote a little wrapper around xwd and gtklp for printing screenshots. People really like that because gtklp gives them lots of options about orientation and size of the image if they want it, or a simple “Print” button to click if they don’t care. We set a gconf default to bind this to Ctrl-PrintScr and it works well. KDE’s screenshot tool is much more capable, and if we were using KDE, we wouldn’t have had any problem with screenshots.

The bottom line on Gnome is that we, and are users, are happy with it after we’ve made these customizations. But we have had to do more customization that we should have. I still think that Gnome has been better for our users than KDE, but I do wonder how long we’ll be able to survive with our “no KDE libraries” policy, as people want ksnapshot, kolour, etc.

Categories: Desktop Linux

Leave a comment

Comments Feed12 Comments

  1. Luis Matos

    I think your work is great…

    the evince problem is correct in newer versions, i think … essentially with the new gtk printing system.

    i hope that your reportbug tool is working ok and you have, at least sent some bugs to BTS, so maintainers can at least drive them upstream.

    Reply

    John Goerzen Reply:

    Indeed I have. Some even accompanied with patches.

    Reply

    Luis Matos Reply:

    hurray!!!

    Reply

  2. Emmanuele Bassi

    personally, and I speak with my gnome-screenshot/gnome-utils maintainer hat firmly on, I don’t think that gnome-screenshot should print anything. it simply adds complexity to something that is never meant to be more than a “point-and-shoot” kind of utility; if I ever implemented printing I would end up replicating much code from eog or from gimp just to get it “right” (orientation, scaling, borders, you name it).

    having said that, gnome-screenshot should be able to launch another application with the screenshot or save it into the clipboard, so you can use eog or gimp to print something the right way. I’m working on this feature – it has been preempted for the 2.19/2.20 cycle but it’ll definitely be available in the 2.21/2.22 cycle.

    Reply

    Luis Matos Reply:

    I agree … maybe it is its KDE user side talking … KDE has some strange features (it is a joke, not a flame start)

    Reply

    John Goerzen Reply:

    That would be a quite reasonable way to go, especially if it remembers the user’s preferred printing application.

    It is possible that the KDE printing system covers more of that setup than Gnome’s does, dunno.

    Reply

  3. Luis Matos

    You said that you changed the menu layout, right? Why? applications misplaced?

    Reply

    John Goerzen Reply:

    Not exactly. We removed some things from the menu that people have no need for (such as gnome-terminal) and added some entries for local applications. I don’t believe that we actually moved anything to a different location, though.

    Reply

  4. Ross

    Did you try using Sabayon to manage the user groups? With this you can define multiple roles, and edit the menus with the standard GNOME tools.

    Reply

    John Goerzen Reply:

    I didn’t know about that tool, but it does indeed look useful.

    Reply

  5. Corsac

    Did you try Xfce?

    Reply

  6. brent saner

    fluxbox for the win!

    i love fluxbox, especially for older machines. it’s just so clean and smooth and it just has such a down-to-business interface and menu layout.

    (i was recommended here by my cousin, Mark Saner. yes, THAT Mark Saner.)

    Reply

Leave a comment

 

Feed

http://changelog.complete.org / Desktop Linux: Gnome