Re: Multi-sessioning for GNOME [revisited]

[Havoc Pennington <hp redhat com>]

jacob helixcode com (Jacob "Ulysses" Berkman) writes:
> Havoc Pennington <hp redhat com> writes:
> 
> > Moving .gnome around is not a solution. 
> > 
> >  - all settings should not be per-session. Some should be per-host, 
> >    some per-display, etc. If we want to be remotely user friendly
> >    GNOME should automatically decide which are which.
> 
> How is GNOME going to decide this?  Seems a hard problem to determine
> the intent of a config variable...
>

 - state of currently open documents, etc. are per-session
 - sizes of things, colors, etc. are generally per-display
   (stuff you might change according to the visual and display 
   size)
 - the majority of things are global settings, not per-session 
   (which is why the env variable and moving .gnome is so lame)

etc. But these are just defaults; users can override them.
 
> Umm, AFAIK GNOME 1.4 will be using it...  is this not the case?

Yes, but I think it's stupid to make future upgrades to the right way
much more painful, when GNOME 2.0 is in the pretty near future. We
shouldn't introduce some feature that we're going to break and change
with confusing results only a few months later.

But even if this goes in 1.4, we still need to be talking about what
to do for 2.0. There are people volunteering here with time to work on
it.

> > Making this usable will involve GConf and gnome-session work, along
> > with fixing applications when required, and probably would be enhanced
> > by multiple display support in GTK.
> 
> Making it pefect may, but usable requires none of this.

I don't agree. The env variable hack will be highly suboptimal. I do
not want my mouse acceleration settings to be per-session. That is
just freaking broken. I will get bugs in the Red Hat bug tracker about
how the session stuff doesn't make any sense, and I'll be embarassed
to close them with "supposed to work that way."
 
Moreover the session hack stuff won't work on Nautilus, the most
visible part of the desktop, since it already uses GConf.

And then after I have to deal with all the "works stupidly" bugs for
1.4, we'll change how it works in 2.0, and I'll get all the "it
doesn't work the way it used to" and "I lost all my sessions" bugs.

> Well we can't fix it properly until GNOME 2.  And some people would
> like to be able to use it before then.

Well, they can apply a patch to their copy. But I don't think we
should introduce this kind of thing in 1.4 only to break it again in
2.0, especially since it won't even work properly in 1.4. Even if we
do, we should still encourage the Sun team to fix it for 2.0.
 
> I guess I am just much more interested in having someting I can use
> rather than nothing, even without opaque ref counts.
> 

So patch your local tree.

The "I want something now, even if it sucks" approach leads to
software that changes all the time, and is thus unstable and confuses
users. It makes it hard to manage upgrades between versions; it makes
it hard to support legacy apps when we change stuff. It leads to
software that collapses under its own weight and is not maintainable
as a large system.

Features are not free, they have to be maintained and debugged and
supported.

Urgent bugs require some immediate fix, even if it's a hack. New
features do not. This is why GTK doesn't contain all of GtkExtra and
libgnomeui; because something is not better than nothing when
something is going to create a giant maintenance headache. People can
still use the hacky somethings by compiling them into their app or
patching their local copy or using an add-on library, but they
shouldn't go in the core code until they are working properly and
maintainable.

Look, there are these guys at Sun who have session management working
in CDE. We should encourage them to get it working really well in
GNOME: make sure the window manager saves app positions, make sure
apps actually save things such as open documents and cursor positions,
and so on. It's not a huge job to get this right, they are willing to
do it, let's encourage them to do it right.

Havoc

_______________________________________________
gnome-hackers mailing list
gnome-hackers gnome org
http://mail.gnome.org/mailman/listinfo/gnome-hackers