GNOME Bugzilla – Bug 676238
App menus for 2 instances get merged
Last modified: 2012-06-19 15:58:47 UTC
gnome-shell-3.4.1-3.fc17.x86_64 1. Launch epiphany 2. Open a website to differentiate it 3. Launch epiphany -p (a private instance) 4. Select the empty window launched in 3. 5. Click on the app menu and select "Personal Data" The "Personal Data" section should be empty, as "epiphany -p" doesn't copy that. But it's full of stuff, which means you just activated the app menu for instance 1. This should be reproduceable by launching any 2 instances of an application with an app menu.
We wrongly assume that all GtkApplications are single-instance, see http://git.gnome.org/browse/gnome-shell/tree/src/shell-app.c#n1225
That assumption is right - one ShellApp matches to one GMenu (or bad stuff will probably happen at the JS layer). The problem is that multiple logical applications (such as global epiphany and private epiphany, or empathy and empathy-chat) are merged into one ShellApp. We need better application heuristics, especially when we have explicit information from GtkApplication.
(In reply to comment #2) > That assumption is right - one ShellApp matches to one GMenu (or bad stuff will > probably happen at the JS layer). I think it is unfortunate that we got G_APPLICATION_NON_UNIQUE, but as it's done we should support it, e.g. one GtkApplication matches one GMenu (with one ShellApp one or more GtkApplications). Updating the menu as necessary is actually not hard, but a fancier solution would iterate over all the ShellApp's windows and activate the appropriate action in the non-unique case.
Created attachment 214267 [details] [review] shell-app: Update app menu if necessary Currently we assume that GTK_UNIQUE_BUS_NAME is shared between all windows of an application. This assumption does not hold true for applications that specify G_APPLICATION_NON_UNIQUE, so make sure to update the menu as necessary. For what it's worth, this is the first (inferior imo) solution which makes the app menu per-window in case of non-uniqueness. Technically it works, but I don't like it from a UI POV (see comment #3).
Yeah, I'd prefer it if we actually had supported multiple ShellAppRunningStates for every app -- one per unique bus name.
(In reply to comment #4) > For what it's worth, this is the first (inferior imo) solution which makes the > app menu per-window in case of non-uniqueness. Technically it works, but I > don't like it from a UI POV (see comment #3). Actually I've thought about it a bit more, and the approach in this patch should be better in most cases (like "about", "preferences"). We might want to special-case actions called "quit" to activate them once for each instance eventually though.
should we just go with this, then ?
Yup, waiting for review.
Review of attachment 214267 [details] [review]: Not a giant fan, but it works.
Attachment 214267 [details] pushed as c303c6b - shell-app: Update app menu if necessary