Crusty Blaa

Luis commented on old
bugs recently. It certainly feels good to close old bugs. Like this four year old
bug.

People will be glad to know that with very latest glibc (it'll be in
glibc 2.3.4), you'll be able to change the timezone and the clock
applet will actually notice. Yay for us! :-)

Tom
you'll be delighted to know that if turn back time and decide to wait
until FC 3 to switch from RHL 9, the panel won't forget your nicely
configured 10 launchers and 10 applets ...

I can't help with the turning back the time part, though :-)

It saddens me to see people writing applets as notification icons
because I've been there myself and spent a good deal of time trying to
get traction on the problem but ended up dropping the ball.

The Network Monitor started out as a notification icon. But I was
unhappy
with that for a number of reasons:

1. No consensus on what the notification area should be used for. Until
   we have that, I'm worried about serious notification area bloat.
2. No reasonable way of starting standalone notification icons short of
   "start gnome-netstatus and save your session"
3. Other less fundamental problems - no keynav, no decent notification
   icon widget, can't re-arrange icons, problems expanding icons to the
   full panel width ...

I think we got tantalizingly close
to consensus on the first problem, and EggStatusIcon is
an okay start on a widget, but in the end I ran out of time and turned
the Network Monitor into an applet.

Granted, I didn't care whether or not the Network Monitor worked in
KDE. Cross-desktop applets isn't an intractable problem, but just
lumping everything into the notification area is no way to approach
it.

Anyway, what I really wanted to mention was that I don't think problem
(2) above is a session manager
problem. The notification area itself should manage these icons,
not the session manager ... if the panel isn't running or the
notification area isn't on the panel, these icons shouldn't be running,
right?

At some point we discussed the idea that each notification icon should
install a .desktop file describing the icon. In the preferences dialog
you could enable/disable each icon. If the icon is standalone (like
the Network Monitor) it would have an Exec field and the
notification area would spawn it if enabled. If the icon is part of an
application (e.g. the epiphany download icon) the notification area
would only allow the icon to be displayed if its enabled.

All this reminded me that I actually had a good argument
against every application developer's favourite feature - "Minimise to
Notification Area". Don't argue with a butler analogy!

There's lots of talk at the moment about "fixing the session manager",
a sentiment I agree with, but I worry that if we don't step back and
look at the big picture a bit we'll screw things up even more.

To me, "Session Management" is all about providing the ability to take
a snapshot of what you're doing right now, log out and be able to come
back later, log in and continue where you left off. So if I saved
the state of my session I'd expect following to be remembered:

• the applications which are running, and the windows belong to
  those applications which are open
• the size and position of all those windows
• which documents I have open, the position within those
  documents etc.

Alternatively, people seem to set things up just how they'd like it
when they log in every morning and take a snaphot of the session at
that point.

This is the kind of functionality which XSMP was designed for but it
hasn't yet worked out very well because most applications don't do a
good job of implementing it and there's not a lot of clarity on how
session state differs from application state (e.g. when you close your
browser, should it remember the last position of the window or should
it only remember that when you save your session?)

Anyway, lets forget about this feature for the moment. We do our best
to hide it in GNOME because we know its broken and my impression is
that most people don't bother with it because of its brokeness. I'm
not too concerned about fixing it right now.

There's this whole other thing the session manager does, though. It
starts what we think of as the "desktop shell" - the window manager,
panel, nautilus, screensaver daemon, settings daemon etc. etc. I think
most user's mental model of the desktop would be that all these
components make up a single entity in which different applications
run. Whether the panel is running isn't a part of transient session
state in the same way as whether the browser is running, its a fixed
part of the desktop.

Making this distinction gives us the ability to treat the session
shell and transient session state differently. But to what end? Well,
there's a number of thing we can do differently if we treat the
management of the session shell as a different problem:

1. We stop forcing users to understand that in order to have certain
   desktop services started at login they must run them and then
   save the session.
2. We consolidate all the hard-coded hacks for starting desktop
   services into a single mechanism whereby desktop services can
   register themselves with the session manager and asked to be
   started up based on a user preference.
3. We remove the possibility of "losing" important parts of the
   desktop from your session
4. We can start the session in two stages - the desktop shell
   followed by the applications, perhaps hiding the entire screen
   until the desktop has started
5. We can remove obtuse terms like "Metacity Window Manager", "The
   Panel", "Nautilus" from the splash screen and just have "Starting
   GNOME".
6. Since we won't have to worry about managing legacy applications,
   we can think about dumping XSMP and coming up with a solution
   specifically designed for starting the desktop itself

Here's another way to look at it - if you save your session while
you're running GNOME, wouldn't it make sense that when you log in to
KDE the same applications are running? If the answer to that is yes, I
think it shows that the question of activating desktop shell
components is orthogonal to the question of restoring session state on
login.

This bothers me and
I'm not sure why.

Is it the irony in judging someone by the book they're reading, and then claiming
to not pick your books by the point you're making to the world?

Perhaps its the implication that judging someone by the book they're reading is
somehow more intelligent than judging them by the shoes they're wearing?

Or maybe its because I'm reading a lame, trashy, populist book at the moment.

Ah no, I've just figured out why it bothers me ... its that the very fact that
I'm writing this proves that I've managed to completely mislay my sense of
humour somewhere ... Wonder where I put it?