Ticket #850 (closed task: fixed)

Opened 11 years ago

Last modified 10 years ago

Figure out what to do about Unity

Reported by: jdreed Owned by: jdreed
Priority: blocker Milestone: Natty Beta
Component: -- Keywords:
Cc: Fixed in version:
Upstream bug:  LP:724604


Nothing has happened with  LP:724604 (new-style panel forced on classic session), and now that the video drivers are available, the new Unity interface is also functional. Although not really usable, because navigating the menus to find gnome-terminal is worse than when XP introduced the new-style Control Panel. (I'm not interested in hearing about Alt-F2).

We should figure out what we're going to do, whether it's default to "Classic", but let people choose, or write our own thing to bring back Lucid-style panels (and throw the FF icon back in the panel) or what.

Note that if we want FF or Evolution launchers on the desktop for new accounts, we need to decide like, now, so we can get the changes to Garry by April 1.

Change History

comment:1 Changed 11 years ago by jdreed

  • Milestone changed from The Distant Future to Natty Alpha

comment:2 Changed 10 years ago by jdreed

Upstream appears to not care. If anyone is adept at poking people on IRC to get a straight answer, I'd appreciate it, but I don't have the time to do that.

But short of debathenifying gnome-panel, I think we lose.

comment:3 Changed 10 years ago by jdreed

Getting the old menus back seems to be as simple as removing IndicatorAppletAppmenu? from the list of panel applets. I'm not sure what the best way to do this programmatically is.

I'll note that disabling /etc/X11/Xsession.d/80appmenu is also sufficient to get the menus to appear back in each application, but it leaves a lingering (and functional) File->Close in the menubar. Disabling the applet entirely appears to DTRT, even with the sketchy .so loaded.

comment:4 Changed 10 years ago by jdreed

This may now be moot, as "Ubuntu Classic" works now and gets me amounts to Lucid. However, it only works if I create a new local account (or nuke my gconf), since something is borked with gconf migration.

We may win, but we still need to find a way to ensure that users correctly get the "Ubuntu Classic" session, at least on cluster.

comment:5 Changed 10 years ago by jdreed

OTOH, we'll have to deal with Unity in a year anyway:


comment:6 Changed 10 years ago by jdreed

Investigate creating an Athena session type which can vary on a per-release basis. Right now it should symlink to gnome-classic.

comment:7 Changed 10 years ago by jdreed

So, once the session is in place, we need to run "/usr/lib/gdm/gdm-set-default-session athena". However, xsession doesn't depend on gdm-config or gdm. Should it? (it's kind of useless without it) Or should the athena.desktop session go in gdm-config? In fact, xsession is probably already wrong, as the nocalls session already explicitly calls gnome-session, so xsession should probably just depend on gnome-session and move on?

comment:8 Changed 10 years ago by jdreed

  • Status changed from new to accepted
  • Owner set to jdreed

comment:9 Changed 10 years ago by jdreed

  • Status changed from accepted to committed

Having heard a resounding chorus of crickets, I did this in gdm-config, r25146

comment:10 Changed 10 years ago by jdreed

  • Status changed from committed to development

Wheee, idempotence. /usr/lib/gdm/gdm-set-default-session -k athena returns 2 if the default session is already set and dbus is running, and returns 0 under the same conditions when DBus isn't running (because it falls back to editing the file manually). We should file an LP bug or something.

Anyway, fixed in r25163, and I'm going to re-push this to -dev (1.27.1)

comment:11 Changed 10 years ago by jdreed

OK, that broke Lucid logins on -dev machines, because "--session=classic-gnome" is not a valid argument to gnome-session in pre-Unity. Please don't move gdm-config 1.27.1 out of -dev for now.

So do we:
a) ship our own wrapper (/usr/bin/athena-session) for the .desktop file which decides how to exec gnome-session
b) only ship our .desktop file for gnome session >= 2.32.1-0ubuntu2 (when support was added for --session)
c) something else

I'm leaning towards (a)

comment:12 Changed 10 years ago by jdreed

Alternatively, embrace the darkness that is Unity, letting it envelop our hearts, and punt the idea of our own session. But we still set the gdm default session to classic-gnome, and let people pick Unity if they want it.

comment:13 Changed 10 years ago by jdreed

We will go with /usr/bin/athena-session, assuming it works.

comment:14 Changed 10 years ago by jdreed

OK, this mostly works except that dbus gets invoked with
--exit-with-session athena-session.

It's not clear if this is a problem.

comment:15 Changed 10 years ago by jdreed

  • Status changed from development to committed

comment:16 Changed 10 years ago by jdreed

  • Status changed from committed to development

Built as 1.28 because the current version was breaking Lucid -dev machines.

comment:17 Changed 10 years ago by jdreed

er, do we want classic-gnome or gnome-2d?

comment:18 Changed 10 years ago by jdreed

Right, so, this is awesome. The first time a user logs in, using the Athena default sesion,  LP:649809 is triggered (gdm's g-s-d sticks around and conflicts with the users'). Subsequent logins generally work, except when they don't. Logging in with "Ubuntu Classic" sometimes works and sometimes doesn't. I... don't have a good solution here. And of course the user can't kill gdm's g-s-d. My current bad idea involves an Xsession.d that sleeps for up to 10 seconds, checking ps to see if gdm's g-s-d is dead.

comment:19 Changed 10 years ago by jdreed

I cannot reliably reproduce the bug if the first login is "Ubuntu Classic". I have diffed ~/.gconf* between broken and working logins, and nothing differs except the mtimes in the XML in .gconf. The only possible thing is that something, somewhere, is upset that the session is not called "gnome-session".

comment:20 Changed 10 years ago by jdreed

Zephyr discussion suggests upstream is also having problems reproducing this on anything but Ubuntu, and that it primarily affects VMs, but does manifest on real hardware. I suggest the following stupid workaround:

Index: debathena-branding
--- debathena-branding	(revision 25221)
+++ debathena-branding	(working copy)
@@ -109,6 +109,7 @@
     # Here on a Stop signal from the session manager.
     def sm_on_Stop(self):
+        subprocess.call(["/usr/bin/pkill", "-f", "gnome-settings-daemon"])
 def main(options):

comment:21 Changed 10 years ago by jdreed

  • Status changed from development to proposed

The actual fix (new athena session) has moved to proposed. The g-s-d stuff is now in #979.

comment:22 Changed 10 years ago by jdreed

  • Status changed from proposed to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.