Maverick -> Natty upgrade, unity, gnome-panel and windowmanager's party…

[Didier Roche]

Hey fellow desktopers,

So, with unity coming as the default interface, we have a lot of
interesting things to deal in the upgrade process.

First, the basics and background informations to deal with part 2 of the
mail (sorry for it being so long):

- gnome-session has some required_components notion. Those components
are automatically respawned in case of crash or even when exited with a
0 status. They are really "required" :)
Those are set as gconf keys:
/desktop/gnome/session/required_components_list has a list of required
components name that we find in:
/desktop/gnome/session/required_components/<name>

Ok, there you will notice 3 components by default:
* filemanager -> "nautilus" (yeah, don't have to do anything with that
as unity will keep nautilus to draw the desktop)
* panel -> "gnome-panel". Needed on:
    - "gnome-classic session"
    - in the default session, if unity tells "I can't run on that
hardware" (unity has additional GL requirements than compiz). We will
only have compiz + gnome-panel there.
    - in the default session if compiz even can't run (case the vesa
driver for instance) and we fallback to metacity.
BUT if unity runs, gnome-panel shouldn't be there.
* windowmanager -> depends…
    - "gnome-wm" by default, this one looked for override and installed
windowmanager. It will prefer compiz over metacity. It's a wrapper
script which can be slow as it's making multiples call to gconftool-2.
Note that the gdm user (for gdm) always call gnome-wm.
    - "compiz" or "metacity" if one of them is chosen in the "visual
effects" tab in gnome-appearance-properties (the first time you click on
None/Normal/Extras, gnome-wm can't be set back by any GUI then).
Consequently, this gnome-wm is really of a small use and can only add
startup slowness (not mesured so).
     - <"your favorite window manager because every others are bad">,
but I think you're not anymore concerned by the upgrade there :)

Unity being a compiz plugin, there is no need to set it as "panel",
having compiz/gnome-wm launching compiz as a required_components is
enough.


Ok, then, we should discuss what to do on upgrade. Both parts can be
read independently:
1. we have now auto-detection in compiz after working with upstream on
it (will come with tomorrow's update, I hope), to fallback in metacity
when needed, or to launch compiz without unity if unity isn't supported
(of course, tests will be needed and card blacklist set). So one idea
would be to set "compiz" by default as a window manager required
component if previous windowmanager was gnome-wm, even on upgrade and
rely on that to select the right windowmanager (compiz/metacity).
People having "no effect" selected ("metacity" set as default), won't
have unity and we can face some "why I don't get unity, the new shiny
thing" on upgrade by not having a predictable upgrade path.

This will only remove the gnome-wm script for those people who never
touched gnome-appearance-properties. Still a win on startup time. Not
sure it worths it to be honest. Compiz being a recommends of
ubuntu-desktop, it will be reinstalled if uninstalled on upgrade by
update-manager, so "not having compiz on upgrade" and getting a broken
session will be because of uninstalling compiz, not having
ubuntu-desktop and changing manually the sources.list + dist-upgrade (no
update-manager or do-release-upgrade). We can think advanced users only
are in that case.
Note that a similar tweak (changing key in user session to set metacity
by default) was done in dapper upgrade.

As the plan is to get a popup the first time you fallback to either
compiz without unity or metacity telling "you don't get the full ubuntu
experience…", we need to consider the gdm user and make sure not
launching compiz but metacity as the popup can appear in gdm as well :).
I've discussed with the xubuntu guys (will get some feedback soon with
the lubuntu ones) and they don't use gnome-session but a .desktop file
in autostart in gdm, so they aren't impacted by any gdm change there.

Thoughts?


2. Now the even more tricking question: gnome-panel/unity!
   2.1  "gnome-classic session": There is no need of a hack there, the
session stuff still give us the possibility for different gconf key, it
should just be a default key as it is today.
   2.2 in the default session: So, basically, there are two use case, if
we abstract from the windowmanager:
    + unity -> no gnome-panel
    + no unity -> gnome-panel

And here is the issue, there is no way to tell to gnome-session
"add/remove me this required_components" dynamically (for reference,
it's called autorestart in the code) and I think we still want
gnome-panel to respawn gnome-panel if it's needed and in case of crash.

I think playing some kind of "ping pong" like killing gnome-panel
because we have unity, gnome-session respawn it, killing it again,
gnome-session respa… can be fun, but no what we want (I still had to
mention it for reference :))

I have hacked yesterday afternoon on that, and I have a way to tell
"gnome-session, please remove this App as a required_component" through
dbus.
2.2.1 So, we can put gnome-panel as a required_component in the default
session, and if unity can run on it, remove it as a required_component
and kill it.
-> nothing to do if unity can't run (because of compiz not being able to
run or unity itself)
-> we have a flipping there: gnome-panel tries to run, and then, is
killed. Even if we can cache the result (but having to tweak in case of
a driver change), the first session load will get that. Not optimal. 

2.2.2 So, we can think the other way around: only run gnome-panel when
needed and not setting it as a required_components by default in the
default sessions but still on the gnome classic session (this can be
done as well as sessions adds some additional gconf paths).
-> 2.2.2.1 if unity runs, nothing to do, no flipping
-> 2.2.2.2 if unity can't run, we need to launch gnome-panel. That's
currently done as a compiz plugin (and the code is executed even if
opengl compiz can't be run on that hardware). So, we can launch
gnome-panel, BUT there is no way to set it dynamically as a required
component without making heavy changes to gnome-session: basically, what
gnome-session doesn't launch, it doesn't know what it is, so we need
some kind of libbamf library to match the .desktop file or whatever so
that I can add to my yesterday hack a way to set it as a
required_component dynamically.
A tradeoff will to not have it as a required_component  for the first
session (praying for it not crashing) and changing the gconf key to set
gnome-panel as a required component.
However, we will have to deal when people change their graphical driver,
like vesa -> nvidia proprietary driver to reset that. It means an
additional script at startup…
-> 2.2.2.3 if metacity or another window manager than compiz is set as a
default… well, that's a mess… we don't have anything to launch
gnome-panel. We can still add a gnome-panel.desktop file with an
autostart condition or rely on the above script to deal with that case
as well.

Please note that there is no strong push to get those improvements and
to deal with those issues gnome-session upstream itself, as after
discussing with some GNOME people, it seems there are little interests
there as they are waiting for systemd to deal with the session.

For the curious, what GNOME shell is doing is to get gnome-panel in gdb
and then hide the window.

Thoughts?

Cheers,
Didier


PS : There are also some others issues with saved GNOME session saving
required_components and interfering with our default. I won't enter
there into the details there as most of you should already be exhausted
and I think I'll just patch as I've done in maverick for UNE :)