The Grumpy Editor encounters the Hardy Heron

Presumably because it tells Nautilus to set the background, and your Nautilus is long dead.

Is that outcome a bug? Yes, perhaps. But it's going to be on the priority scale somewhere
between "GNOME does not show correct free disk space on my 20 Petabyte USB RAID array" and
"GNOME world map is wrong for my planet, Neptune". My guess would be that if you don't write a
really good patch of your own, any bug would be "fixed" by just greying out that entire panel
when Nautilus is disabled.

You have disabled one of the most basic components of Gnome (Nautilus) and can't tolerate any
glitches... ?

I have watched the text edit mode setting for emacs key bindings gradually fade away.  First
the dialog-box checkbox disappeared.  Then the on-line documentation on the setting in gconf
was deleted!  The first could be attributed to streamlining.  The second smacks of malice.

When emacs edit key binding ultimately goes away, as it seems it must, I suppose I will
finally switch to KDE.  I wonder if there will be anything to miss, then.

By the way, the gconf key required appears to be

  desktop/gnome/interface/gtk_key_theme

and the value that still works to fix the key assignments is "Emacs".

> I guess it's inevitable. To caricaturize: if I like a setting, it's almost certainly gone in
the next release, so there's no point to set oneself for disappointment.

For me, it happened only one time — during the switch from Gnome 1.4 to Gnome 2.0. After an
initial shock and an understanding that it's really going to be this way from that point, I've
*so* switched to KDE :) Don't like being tortured this way. They should have renamed the
project to something different, really.

> Would someone at least write a GNOME advanced GUI that will have all the
> settings the devs choose to remove?

That's called gconf-editor. Yes, really -- see above explanation of how to change the settings
for blinking cursor (if you don't use normal configuration in System menu that is). It is not
that hard.

While I agree that the GTK+ file browser could be faster... if Firefox bothered to integrate
with the GNOME platform at all then instead of picking 'gv' from a /usr/bin directory
containing (on my system) 3740 files (a pathological condition if ever I saw one) then you'd
just pick it from a dropdown of other applications capable of opening image files.

*zing*  Yow! :-)  I must put the parent post in my .sig.

I would definitely agree with that comment, especially in my own pet-peeve case: file-selector
widget sorting.  GTK/Gnome has the setting to sort folders separately from files fixed in
stone (well, in the source code, but it might as well be in granite), with a snarky little
comment about how this is the One True Way and it will Always Be That Way.  Fortunately, a
little snip-snip with the editor, and a recompile, and the One True Way disappears into the
ether.  :)  When I say I want things sorted by last-modified date, that's exactly what I mean,
d*** it.  It doesn't matter that the last-modified thing is a folder or not--whatever it is,
put it at the top (or the bottom, if the sort is reversed)!

What can be sure is that you people don't like people but yourselves. Read what you wrote,
insulting fair developers who try to make a desktop environment for the people not you, you,
you. Some project choose a way, a policy, some others, another and so one. So instead of
spreading a hell of FUD just you and you and you there, hidden behind the pillar, just speak
yourself what you are about to frentically write, and notice you are just among GNOME-haters
here. Brain-masturbation isn't it ?
 

Surely you back up your home directory (which contains your Firefox profile on Linux) on
upgrades?  In any case, very few application upgrades would touch anything in your home
directory, so this is something of a non-issue.

I do recommend a home Wiki to track this sort of config change, which is particularly useful
if you do a fresh install or want to do the same change on other machines.

I'd actually say it's more akin to turning on your TV so you can change the time on your VCR.
That's not the primary use of either piece of equipment, but it reuses the existing
relationship among the pieces to great effect.

In the case of Nautilus, since it's expected to be there as part of the overall GNOME
environment and needs to handle root-window events anyway, having it take over the root window
image doesn't seem like too much of a stretch.  (That's roughly how Windows does it--it's the
Explorer shell that handles it, IIRC.)  Just as in my analogy, since a VCR pretty much has to
have a TV attached so you can watch a tape, so reusing the TV for on-screen menu display isn't
too much of a stretch.

Are there VCRs that let you change the time w/out a TV?  Of course!  But that doesn't make the
ones that require a TV for that purpose wrong.  It just makes them different.

Now as for the silent failure to change the background?  That sounds a bug.  That level of
failure shouldn't be silent.  Either a error/warning dialog should come up, or the tab should
be greyed out when Nautilus isn't running.  Also, disabling Nautilus should give a warning
that some functionality will be disabled.

Probably because it is related to handling of keyboard input?

It also happens to be where Windows and MacOS X put it, and there doesn't seem to be many
compelling reasons to be different (save that for places where it matters).

Yes. I agree the gconf approach makes sense.

I do have my own set of gnome-settings I care of and so I do have a short script that sets
those via gconftool-2. Very fast, very predictable.
Only drawback is, that there is no easy option that I'm aware of to check whether a key is
valid/used. So if gnome changes certain keys in newer versions you still have to search for
correct replacement.

It times out. That's part of the reason why this feature was centralised, which in turn lead
to our Grumpy Editor being slightly more Grumpy than usual. Next to the setting to disable it
altogether is one which adjusts the length of time before it stops flashing when idle.

Are you serious?  The possible power draw of painting a cursor has to be so vanishingly small
as to be unmeasurable.

So much for the whole "bring your ancient hardware back to life with Linux" argument. Oh
well... guess it's time to throw out my perfectly function P2/333 then - oh hang on, I can't
because I live in Europe; it costs less to keep it running than it would to dispose of it.

Some of us (including our editor) measure time in human years, and in human years, quite a
reasonable computer comes with just a few hundred megabytes of ram and processors considerably
slower than yours.  And amazingly enough, these computers that worked a few years ago,
actually still work.  And if we avoid running windows or gnome, they continue to work well.
Actually, to be honest, my wife runs gnome on her X22 (PIII 800MHz) which is only a little
faster than my computer.  But she's pretty patient, and her computer runs pretty slowly.  I
always just blamed it on firefox, but if disabling nautilus were to speed things up, that
would be worth trying.

The hardware is an 2.2 GHz Athlon64 laptop with 1 GB RAM.  Hardly ancient, although it is 3.5
years old now.

High memory pressure is caused by running Open Office, Evolution (on really big IMAP folders),
Beagle and many web browser tabs.  It isn't hard at all to get things swapping and laptop disk
is the worst ever for swapping.

CPU speed isn't 2.2GHz most of the time.  Most of the time it's idling at 800 MHz and it takes
a small amount of time to clock up when there's demand.

X window speed would actually be good -- if I were running the Nvidia binary drivers.  Instead
I'm running the "nv" open source driver which is nearly an unaccelerated frame buffer.

> Expose events will be generated for any window.
Yes.  Except for the root window, which gets the "special handling" I was talking about.  The
X server handles it directly.  It isn't quite the same as backing store, and no other window
gets this.

> If you want that behavior, just switch to a compositing window manager.
Use a compositing window manager with a video driver without either XRender or OpenGL
acceleration?  I'd be lucky to get one desktop update every 3 seconds once "modern" programs
start trying to use compositing.

> only the relatively few pages touched by the event-handling code are paged in. And the
little bit of code that wakes up, notes a file alteration, and continues is simply not that
big.

Except that isn't exactly what happens.  Say that a program is writing to a file with periodic
pauses: perhaps a slow network download and Nautilus is open on my Downloads directory with
hundreds of files in it.  There's enough time between file notifications that the code swaps
out again.  It doesn't take much, just a few seconds of inactivity.  Then the event comes in
and it isn't just a few bits of code.  Nautilus actually rescans the file header and compares
it with the mime type database to see if the type has changed so it can update the icon and a
lot more.  The data structure that backs a Nautilus file display is not a small little array
that shares a few 4KB memory pages; its actually all over the map, held together with
pointers. 

The entire swap-in/idle/swap-out dance can cause hundreds of KB/s of random I/O swap activity.

Now, I don't actually mind all this for a Nautilus window I've left open.  Live file updates
are pretty cool.  But Nautilus on the desktop and it doing all this work for something I never
look it is a bad idea which is why I turn it off.