Re: Maverick -> Natty upgrade, unity, gnome-panel and windowmanager's party…
On Fri, 2010-11-26 at 11:22 +0100, Didier Roche wrote: > On ven., 2010-11-26 at 10:10 +1100, Christopher James Halse Rogers > wrote: > > On Tue, 2010-11-23 at 12:52 +0100, Didier Roche wrote: > > > Hey fellow desktopers, > > > > > [snip] > > > 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. > > > > If you're already adding a dbus call to set required_component > > dynamically, can't you get gnome-session to also start that component > > when it's added as a required_component? > > > > Unfortunately not, because it has to match /Client and /Apps (if you > look at d-feet, it should be obvious). However, if you launch > gnome-panel from the command-line or from another process, it doesn't > get an id (and every --sm-client-id doesn't seem to work) matching it to > its desktop file, hence the fact we should use libbamf for it, but can > be a little bit overkill :-). > > One idea from seb's after discussing on IRC will be to launch > gnome-panel by gnome-session using a dbus call. That can works, just > have to see how hard it is to hook this in gnome-session. Yeah, this is what I meant; have gnome-session start gnome-panel when you add gnome-panel as a required component. If Seb's already brought it up, good. Great minds think alike ;). signature.asc Description: This is a digitally signed message part -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Maverick -> Natty upgrade, unity, gnome-panel and windowmanager's party…
On ven., 2010-11-26 at 10:10 +1100, Christopher James Halse Rogers wrote: > On Tue, 2010-11-23 at 12:52 +0100, Didier Roche wrote: > > Hey fellow desktopers, > > > [snip] > > 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. > > If you're already adding a dbus call to set required_component > dynamically, can't you get gnome-session to also start that component > when it's added as a required_component? > Unfortunately not, because it has to match /Client and /Apps (if you look at d-feet, it should be obvious). However, if you launch gnome-panel from the command-line or from another process, it doesn't get an id (and every --sm-client-id doesn't seem to work) matching it to its desktop file, hence the fact we should use libbamf for it, but can be a little bit overkill :-). One idea from seb's after discussing on IRC will be to launch gnome-panel by gnome-session using a dbus call. That can works, just have to see how hard it is to hook this in gnome-session. Didier -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Re: Maverick -> Natty upgrade, unity, gnome-panel and windowmanager's party…
On Tue, 2010-11-23 at 12:52 +0100, Didier Roche wrote: > Hey fellow desktopers, > [snip] > 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. If you're already adding a dbus call to set required_component dynamically, can't you get gnome-session to also start that component when it's added as a required_component? signature.asc Description: This is a digitally signed message part -- ubuntu-desktop mailing list ubuntu-desktop@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-desktop
Maverick -> Natty upgrade, unity, gnome-panel and windowmanager's party…
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/
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 h
