Shallow Thoughts : tags : gnome

Turning off the Gnome Keyring prompt

My mom got a netbook! A ZaReason Terra, in lovely metallic brown. (I know "metallic brown" sounds odd -- I was skeptical before I saw it -- but take it from me, it looks great.) It's cute and lightweight, with a nice keyboard with a clicky IBM-keyboard-style feel, and a meta key with a Tux penguin on it rather than a silly Windows logo. The only criticism so far is that the comma and period keys are narrower than the rest, so all three of us keep hitting slash when we mean period.

It comes preinstalled with Ubuntu (currently 9.04 Jaunty) with a full Gnome desktop. I've never been much of a Gnome fan, but this time we thought we'd try keeping it for a while and see how Mom likes it. We can always switch to something faster, like Openbox, later.

Of course, a lot of things needed configuration, like getting rid of one of the two toolbars. (In this age of cinema-width screens, why is it that the major desktops, like Gnome and even Apple, insist on sucking away vertical space with multiple menubars/toolbars?)

(And don't get me started on Evolution's preferences panes that are too big to fit on a netbook screen, yet have no scrollbars; and although the preference window is resizable, Gnome won't let you drag a window past the top of the screen so you can resize it taller.)

What stymied us, though, was the Gnome keyring and the way it prompts you for a password -- even if you've already typed in a login password -- whenever it tries to connect to the wireless network.

Web searches revealed that we were far from the only people who found this annoying and wanted to turn it off. There are lots of howtos. Unfortunately, every howto is different -- apparently gnome-keyring changes its user interface with every release, but somehow none of these UI changes ever make it easier to find your way to the place where you can turn off the password prompting. So here's one for Jaunty.

Howto turn off the Gnome-keyring master password in Ubuntu Jaunty

The key is a program called "seahorse", which you can get to via Applications->Accessories->Password and Encryption Keys. Click on the Passwords tab: you'll probably see two lines, login password and master password. According to some of the earlier howtos, these two passwords need to be the same in order for the following steps to work.

Right-click on login password and choose Unlock (I'm not sure if that step is necessary, but we did it).

Then from the same right-click menu, choose Change Password and make the new password empty. Of course, it will warn you about this horribly insecure behavior and how you're an idiot to want to do this. Your choice!

Tags: linux, gnome, ui
[ 15:31 Nov 01, 2009    More linux | permalink to this entry | ]

GIMP Drag-n-Drop and Open Location without gvfs

Quite a while ago I noticed that drag-n-drop of images from Firefox had stopped working for me in GIMP's trunk builds (2.6 and 2.7); it failed with a "file not found" error. Opening URIs with Open Location also failed in the same way.

Since I don't run a gnome desktop, I assumed it probably had something to do with requiring gnome-vfs services that I don't have. But yesterday I finally got some time to chase it down with help from various folk on #gimp.

I had libgnomevfs (and its associated dev package) installed on my Ubuntu Hardy machine, but I didn't have gvfs. It was suggested that I install the gfvs-backends package. I tried that, but it didn't help; apparently gvfs requires not just libgvfs and gvfs-backends, but also running a new daemon, gvfsd. Finding an alternative was starting to sound appealing.

Turns out gimp now has three compile-time configure options related to opening URIs:

  --without-gvfs          build without GIO/GVfs support
  --without-gnomevfs      build without gnomevfs support
  --without-libcurl       build without curl support

These correspond to four URI-getting methods in the source, in plug-ins/file-uri:

• uri-backend-gvfs.c
• uri-backend-gnomevfs.c
• uri-backend-libcurl.c
• uri-backend-wget.c

GIMP can degrade from gvfs to gnomevfs to libcurl to wget, but only at compile time, not at runtime: only one of the four is built.

On my desktop machine, --without-gvfs was all I needed. Even without running the gnome desktop, the gnomevfs front-end seems to work fine. But it's good to know about the other options too, in case I need to make a non-gnomevfs version to run on the laptop or other lightweight machines.

Tags: gimp, desktop, performance, gnome
[ 12:09 Oct 31, 2008    More gimp | permalink to this entry | ]

XFCE dukes it out with Gnome; users lose

Looking for a volume control that might me installed on mom's XFCE4-based Xubuntu desktop, I tried running xfce4-mixer.

The mixer came up fine -- but after I exited, I discovered that my xchat had gone all wonky. None of my normal key bindings worked, my cursor was blinking, and the fonts used for tabs was about half its normal size. Over in my Firefox window, key bindings were also affected.

I've seen this sort of thing happen before with Gnome apps, and had found a way to solve it using gconf-editor. That app was not installed, so I installed it and discovered that it didn't help.

I tried killing the running gconfd-2, removing .gconf/ and .gconfd/ from my home directory, then removing the four gnome directories (.gnome/, .gnome2/, .gnome2_private/, and .gnome_private/). Nothing helped xchat (though Firefox did return to normal).

After much flailing and annoying people by restarting xchat repeatedly, it turned out the problem was that xfce-mixer had started a daemon called xfce-mcs-manager, which is like gconf, only different. Like gconf, it mucks with settings of all running gtk programs without asking first. It runs simultaneously with gconf, but overrides gconf, which in turn overrides the values set in ~/.gtkrc-2.0.

Killing xfce-mcs-manager caused my running xchat to revert to its normal settings.

... Well, *almost* revert. A few key bindings didn't get reset, as I discovered when I hit a ctrl-W to erase the last word and found myself disconnected from the channel. Another xchat restart, with xfce-mcs-manager not running, fixed that.

Aside from the ever-present issue of "Where do I look when some unfriendly program decides to change the settings in running applications?" (which begs the question, "What genius thought it would be a good idea to give any random app like a volume control the power to change settings in every other gtk application currently running on the system? And do they have their medications adjusted better now?") there's another reason this is interesting.

See, if an arbitrary app like xfce-mcs-manager can send a message to xchat to change key bindings like ctrl-W ... then maybe I could write a program that could send a similar message telling xchat to cancel those compiled-in bindings like ctrl-F and ctrl-L, ones that it doesn't allow the user to change. If I could get something like that working, I could use a standard xchat -- I'd no longer need to patch the source and build my own.

Tags: linux, gnome
[ 21:12 Dec 14, 2007    More linux | permalink to this entry | ]

Powertop BOF at Linuxworld 2007

The best thing at Linuxworld was the Powertop BOF, despite the fact that it ended up stuck in a room with no projector. The presenter, Arjan van de Ven, coped well with the setback and managed just fine.

The main goal of Powertop is to find applications that are polling or otherwise waking the CPU unnecessarily, draining power when they don't need to. Most of the BOF focused on "stupid stuff": programs that wake up too often for no reason. Some examples he gave (many of these will be fixed in upcoming versions of the software):

• gnome-screensaver checked every 2 sec to see if the mouse moved (rather than using the X notification for mouse move);
• gnome volume checked 10 times a second whether the volume has changed;
• gnome-clock woke up once a second to see if the minute had rolled over, rather than checking once a minute;
• firefox in an ssl layer polled 10 times a second in case there was a notification;
• the gnome file monitor woke up 40 times a second to check a queue even if there was nothing in the queue;
• evolution woke up 10 times a second;
• the fedora desktop checked 10 times a second for a smartcard;
• gksu used a 10000x/sec loop (he figures someone mistook milliseconds/microseconds: this alone used up 45 min on one battery test run)
• Adobe's closed-source flash browser plugin woke up 2.5 times a second, and acroread had similar problems (this has been reported to Adobe but it's not clear if a fix is coming any time soon).

And that's all just the desktop stuff, without getting into other polling culprits like hal and the kernel's USB system. The kernel itself is often a significant culprit: until recently, kernels woke up once a millisecond whether they needed to or not. With the recent "tickless" option that appeared in the most recent kernel, 2.6.22, the CPU won't wake up unless it needs to.

A KDE user asked if the KDE desktop was similarly bad. The answer was yes, with a caveat: Arjan said he gave a presentation a while back to a group of KDE developers, and halfway through, one of the developers interrupted him when he pointed out a problem to say "That's not true any more -- I just checked in a fix while you were talking." It's nice to hear that at least some developers care about this stuff! Arjan said most developers responded very well to patches he'd contributed to fix the polling issues.

(Of course, those of us who use lightweight window managers like openbox or fvwm have already cut out most of these gnome and kde power-suckers. The browser issues were the only ones that applied to me, and I certainly do notice firefox' polling: when the laptop gets slow, firefox is almost always the culprit, and killing it usually brings performance back.)

As for hardware, he mentioned that some linux LCD drivers don't really dim the backlight when you reduce brightness -- they just make all the pixels darker. (I've been making a point of dimming my screen when running off batteries; time to use that Kill-A-Watt and find out if it actually matters!) Wireless cards like the ipw100 use a lot of power even when not transmitting -- sometimes even more than when they're transmitting -- so turning them off can be a big help. Using a USB mouse can cut as much as half an hour off a battery. The 2.6.23 kernel has lots of new USB power saving code, which should help. Many devices have activity every millisecond, so there's lots of room to improve.

Another issue is that even if you get rid of the 10x/sec misbehavers, some applications really do need to wake up every second or so. That's not so bad by itself, but if you have lots of daemons all waking up at different times, you end up with a CPU that never gets to sleep.

The solution is to synchronize them by rounding the wakeup times to the nearest second, so that they all wake up at about the same time, and the CPU can deal with them all then go back to sleep. But there's a trick: each machine has to round to a different value. You don't want every networking application on every machine across the internet all waking up at once -- that's a good way to flood your network servers. Arjan's phrase: "You don't want to round the entire internet" [to the same value].

The solution is a new routine in glib: timeout_add_seconds. It takes a hash of the hostname (and maybe other values) and uses that to decide where to round timeouts for the current machine. If you write programs that wake up on a regular basis, check it out. In the kernel, round_jiffies does something similar.

After all the theory, we were treated to a demo of powertop in action. Not surprisingly, it looks a bit like top. High on the screen is summary information telling you how much time your CPU is spending in the various sleep states. Getting into the deeper sleep states is generally best, but it's not quite that simple: if you're only getting there for short periods, it takes longer and uses more power to get back to a running state than it would from higher sleep states.

Below that is the list of culprits: who is waking your CPU up most often? This updates every few seconds, much like the top program. Some of it's clear (names of programs or library routines); other lines are more obscure if you're not a kernel hacker, but I'm sure they can all be tracked down.

At the bottom of the screen is a geat feature: a short hint telling you how you could eliminate the current top offender (e.g. kill the process that's polling). Not only that, but in many cases powertop will do it for you at the touch of a key. Very nice! You can try disabling things and see right away whether it helped.

Arjan stepped through killing several processes and showing the power saving benefits of each one. (I couldn't help but notice, when he was done, that the remaining top offender, right above nautilus, was gnome-power-manager. Oh, the irony!)

It's all very nifty and I'm looking forward to trying it myself. Unfortunately, I can't do that on the laptop where I really care about battery life. Powertop requires a kernel API that went in with the "tickless" option, meaning it's in 2.6.22 (and I believe it's available as a patch for 2.6.21). My laptop is stuck back on 2.6.18 because of an IRQ handling bug (bug 7264). Powertop also requires ACPI, which I have to disable because of an infinite loop in kacpid (bug 8274, Ubuntu bug 75174). It's frustrating to have great performance tools like powertop available, yet not be able to use them because of kernel regressions. But at least I can experiment with it on my desktop machine.

Tags: linux, conferences, linuxworld, laptop, gnome
[ 14:06 Aug 12, 2007    More linux | permalink to this entry | ]

Turn off gtk cursor blink

It's a small thing, but xchat's blinking text cursor has irritated me for a while. It's not so much the blink itself that bothers me, but that it makes the mouse pointer flicker. (I have no idea why blinking the cursor should make the X mouse pointer flicker, but it was pretty clear that they were in sync.) I've also seen fingers pointed at cursor blink as a laptop battery eater (one more reason the CPU has to wake up every second or so when it might otherwise have been idling) though I've seen no numbers on how significant that might be (probably not very, on most laptops). Anyway, there are reasons enough to look into turning off the blink.

Xchat is a gtk application, of course. There are lots and lots of pages on the web telling developers about gtk's gtk-cursor-blink property (and related properties like gtk-cursor-blink-timeout) and what they do in at a library level, so it's clearly possible. But I found nothing about where a user should set these properties to make gtk find them.

Here's the answer. Add to $HOME/.gtkrc-2.0 (or any other file loaded by $HOME/.gtkrc-2.0):

gtk-cursor-blink = 0

I had to restart X (maybe shutting down all gtk apps would have been enough) before I saw any effect.

While I was searching, I did find a nice page on How to disable blinking cursors in lots of different apps. Its gtk section didn't seem to do anything here (maybe it only works if a gnome desktop is running), but it's a good page nontheless, full of useful advice for turning off cursor blink in other programs.

Tags: linux, gnome
[ 20:50 Jul 28, 2007    More linux | permalink to this entry | ]

Gnome Knows Best

"Would you take a look at this?" my husband asked. I glanced over -- he was on the Gnome desktop on his newly-installed Debian Etch system, viewing some of his system icons with pho. Specifically, an xchat icon, an X with some text across it.

"So?" I shrugged.

He pointed to his panel. "But it's really using that icon." A little yellow happy-face-with-blob thing.

He right-clicked on the panel icon and brought up a dialog. "See, it should be using /usr/share/pixmaps/xchat.png. Now, I run pho /usr/share/pixmaps/xchat.png ..." And sure enough, the image it said it was using wasn't the image it was actually putting in the panel.

That jogged a memory. "That happened to me once back when I used Gnome. Try a locate xchat | grep png. I think it was using an icon from somewhere else -- that might find it for you."

Sure enough, there were several xchat png images on his system. I suggested going one step further, and actually viewing all of them:

pho `locate xchat | grep png`

We stepped through the images, and sure enough, we found the icon he was seeing. It was at /usr/share/icons/gnome/32x32/apps/xchat.png (with a larger sibling at /usr/share/icons/gnome/48x48/apps/xchat.png).

Good of Gnome to pretend let the user customize the icon location, even though it actually doesn't bother to use the icon specified there! At least you get a nice feeling of empowerment from pretending to choose the icon.

Later in the day, continuing to fiddle with the desktop settings, Dave burst out laughing. "You've got to see this. It's so Gnome." When I saw it, I had to laugh too. You may think you know what you want, but Gnome knows better! If you've ever tried to customize Gnome, you'll laugh, too, when you see the short video we took of it: Gnome knows best (764K).

Tags: linux, gnome, humor
[ 19:21 Apr 27, 2007    More linux | permalink to this entry | ]

Linus vs. GNOME, part deux: Linus Sends Patches

Remember a bit over a year ago when Linus Torvalds slapped GNOME for removing all their configuration options and assuming a "users are idiots mentality"?

Here's the latest installment.

Linus, challenged to "start a constructive dialog" by using GNOME for a while then giving a talk on his experiences, went them one better: he sent in patches to fix the usability problems he experienced.

An excerpt from his posting to the Desktop_architects list:

I've sent out patches. The code is actually _cleaner_ after my patches, and the end result is more capable. We'll see what happens.

THAT is constructive.

What I find unconstructive is how the GNOME people always make *excuses*. It took me a few hours to actually do the patches. It wasn't that hard. So why didn't I do it years ago?

I'll tell you why: because gnome apologists don't say "please send us patches". No. They basically make it clear that they aren't even *interested* in fixing things, because their dear old Mum isn't interested in the feature.

Do you think that's "constructive"?

and, later,

Instead, I _still_ (now after I sent out the patch) hear more of your kvetching about how you actually do everything right, and it's somehow *my* fault that I find things limiting.

Here's a damn big clue: the reason I find gnome limiting is BECAUSE IT IS.

Linus is back, and he's pissed. Go Linus!

Read more details in the linux.com story, or in Linus' actual email in the Desktop_architects list, where you can also follow the rest of the thread.

Tags: linux, gnome
[ 21:05 Feb 17, 2007    More linux | permalink to this entry | ]

Linus on Gnome Usability

I spent an entertaining morning reading the thread on Gnome-usability that Linus Torvalds started with his posting beginning, "I personally just encourage people to switch to KDE."

The whole thread is interesting reading for anyone who's been frustrated with the lack of usability and missing features in recent Gnome user interface redesigns.

Linus continues:

This "users are idiots, and are confused by functionality" mentality of Gnome is a disease. If you think your users are idiots, only idiots will use it. I don't use Gnome, because in striving to be simple, it has long since reached the point where it simply doesn't do what I need it to do.

Naturally, various Gnome people speak up to defend Gnome. Linus clarifies his position in a followup posting:

No. I've talked to people, and often your "fixes" are actually removing capabilities that you had, because they were "too confusing to the user".

That's _not_ like any other open source project I know about. Gnome seems to be developed by interface nazis, where consistently the excuse for not doign something is not "it's too complicated to do", but "it would confuse users".

He gives several examples of functionality the Gnome team has removed which every competing project still allows, such as binding mouse buttons to functions in the window manager, and typing a filename in the file selection dialog.

A few messages later, Jeff Waugh defends the file selection dialog, calling it "top stuff". Carl Worth responds to that with a nice summary of long-standing and long-ignored bugs on file selection dialog usability. Several other posters follow up with additional issues not yet fixed.

Somewhere along the line, the spectre of Mac OS is raised (of course). Michael Bernstein posts the obligatory "I gave my mom Mac OS X and she loved it" message, adding the novel but unlikely suggestion that the cure for Linux usability issues is to draft non Linux programmers to develop the UI. (No one points out in the Mac OS subthread that Mac OS X itself includes quite a few of the options which have been dropped by the Gnome usability team, such as readline key bindings in every text field, or a typable text field in the file selection dialog, yet no one seems to be complaining about OS X's lack of usability.)

The thread eventually peters out without a conclusion. It's fairly clear that neither side is convinced by the other. Gnome has chosen their path, and "dumbing down" the UI and removing features needed by users such as Linus is part of that choice. Too bad for the users, though: especially users for whom switching entirely to KDE/Qt apps is not a viable choice.

Tags: linux, gnome
[ 18:40 Dec 13, 2005    More linux | permalink to this entry | ]

When gnome loses all your settings

This has bitten me too many times, and I always forget how to recover. This time I'm saving it here for posterity.

The scene: you wanted to check something, perhaps a window manager theme or a font setting or something, and innocently ran some gnome app even though you aren't running a gnome desktop.

Immediately thereafter, you notice that something has changed disastrously in your gtk apps, even apps that were already running and working fine. Maybe it's your keyboard theme, or maybe fonts or colors.

Now you're screwed: your previous configuration files like ~/.gtkrc-2.0 don't matter any more, because gnome has taken over and Knows What's Best For You. How do you fix it?

Don't bother looking for apps that start with gnome-- or gtk-. That would be too obvious. You might think that gnome-control-center would have something related ... but mwa-ha-ha, you'd be wrong!

The solution, it turns out, is gconf-editor, an app obviously modeled after regedit from everyone's favorite user interface designer, Microsoft.

In the case of key theme, you'll find it in desktop->gnome->interface->gtk_key_theme.

Tags: linux, gnome
[ 17:39 Jul 22, 2005    More linux | permalink to this entry | ]

Idiot gtk designers removing accessibility features

Someone posted on #gimp his review of the new gtk2 file chooser, someone else pointed to the file chooser spec. I spent most of the afternoon angry. The file chooser has no text field to type in or paste a file path! What is it about the idiot gtk2 designers that they continually insist on removing accessibility features, like keyboard access, and moving everyone to a mouse-only form of interaction? Do they want to keep keyboard-only users from using their library? Are they getting kickbacks from doctors treating RSI injuries? Or are they actually Windows developers who want to make sure that linux is even less usable than Windows?

Sometimes I think that just about the time linux is getting usable, I'm going to have to find some other OS to use, because all the linux apps will have purged all accessibility features and it will be too painful to try to get any work done.

Grr.

Tags: linux, gnome
[ 20:00 Jul 12, 2004    More linux | permalink to this entry | ]