GNOME Bugzilla – Bug 739534
use separate dbus name for key grabber
Last modified: 2021-07-05 14:12:22 UTC
Created attachment 289844 [details] [review] media-keys: use separate dbus name for key grabber Please don't require org.gnome.Shell for key grabber. This forces to use org.gnome.Shell name in sessions that does not use shell.
Created attachment 289845 [details] [review] use separate dbus name for key grabber Patch for gnome-shell.
Created attachment 289853 [details] [review] use separate dbus name for key grabber Better patch for gnome-shell.
I don't think the direction of this makes sense; gnome-shell and gnome-settings-daemon are the two essential components of a GNOME session; they are tightly coupled.
I'm not going to change the name if the expectation is that this API is stable. It's a private internal API between gnome-settings-daemon and gnome-shell. Passing to gnome-shell.
Looks like gnome-settings-daemon works fine without gnome-shell. I am trying to keep alive old GNOME Fallback session now known as GNOME Flashback. I want be able to use almost all original GNOME components except gnome-shell and mutter and use gnome-panel and metacity instead. Currently to make media-keys work I need to own org.gnome.Shell name and export key grabber interface on it. It works, but that does not feel right - applications thinks that they are running in GNOME Shell, menubar is hidden, empathy does not show notification are icon and probably there are other problems too. So I would like that key grabber has its own name. I don't ask to add anything non-shell or add direct support for something. It is only about moving key grabber interface from org.gnome.Shell to org.gnome.Shell.KeyGrabber or any other name if you don't agree with this name. I have created patches for this - so no coding on your side. If patches must be updated I will do it. I have tested patches in both sessions - GNOME Shell and GNOME Flashback. It works fine. I understand that for example search is shell thing, but at least I can change audio volume with keyboard, I can have custom keybindings.
Other desktops like Unity will also benefit from a more generic interface name (actually, keygrabbing being non-functional outside GNOME Shell is one of the reasons Unity is still using a copy of ancient g-s-d codebase).
(In reply to comment #6) > Other desktops like Unity will also benefit from a more generic interface name True. But then *gnome*-settings-daemon is not a general-purpose tool, but a core component of the GNOME desktop. While I am not aware of any third party applications using the existing shell interface to register global keybindings, I wouldn't easily dismiss that they exist - after all, this API has been around for three stable releases by now. If we are potentially breaking applications, I would like a more convincing reason than making it easier for non-gnome desktops to re-use core gnome components, sorry.
(In reply to comment #7) > True. But then *gnome*-settings-daemon is not a general-purpose tool, but a > core component of the GNOME desktop. While I am not aware of any third party > applications using the existing shell interface to register global keybindings, > I wouldn't easily dismiss that they exist - after all, this API has been around > for three stable releases by now. > If we are potentially breaking applications, I would like a more convincing > reason than making it easier for non-gnome desktops to re-use core gnome > components, sorry. TBF, I expect that we'll have to break this interface anyway when we get application sandboxing.
I think this is a small change that's within reason to make GNOME Flashback easier. I'd be fine with it.
(In reply to comment #7) > True. But then *gnome*-settings-daemon is not a general-purpose tool, but a > core component of the GNOME desktop. While I am not aware of any third party > applications using the existing shell interface to register global keybindings, > I wouldn't easily dismiss that they exist - after all, this API has been around > for three stable releases by now. > If we are potentially breaking applications, I would like a more convincing > reason than making it easier for non-gnome desktops to re-use core gnome > components, sorry. GNOME has nice unstable releases. If this is done for 3.15.2 then there is plenty of time to adapt these changes in other applications and that would not require much work. As Jasper said this is small change and it does not change functionality.
Applications shouldn't be using the gnome-shell keygrabber. The only "application" using it should be gnome-settings-daemon. I also really don't care about GNOME Flashback because if it means that when we stop maintaining it we still have to maintain, just what's the point.
(In reply to comment #10) > GNOME has nice unstable releases. If this is done for 3.15.2 then there is > plenty of time to adapt these changes in other applications GNOME applications don't use the interface. I would not count on other applications to test unstable GNOME releases. (In reply to comment #11) > Applications shouldn't be using the gnome-shell keygrabber. The only > "application" using it should be gnome-settings-daemon. Fair enough.
If the patch was a big revamp of the system to move it all back to XGrabKey's inside g-s-d, then I'd complain, but this is fairly straightforward. Even if we, the upstream, don't want g-s-d to be useful outside "pure GNOME", it's clear that downstreams (of which I am now one, keep in mind) find value in it, and if it's not too much work, we should strive to keep them happy.
(In reply to comment #11) > Applications shouldn't be using the gnome-shell keygrabber. The only > "application" using it should be gnome-settings-daemon. I also really don't This is not changing... gnome-settings-daemon need someone that provides this key grabber, in GNOME it is shell. In non-shell session media-keys plugins does nothing without key grabber. I want provide my own key grabber, but currently I need to export it on org.gnome.Shell, but that means applications will think that they are running in GNOME Shell session and this is problem. :( > care about GNOME Flashback because if it means that when we stop maintaining it > we still have to maintain, just what's the point. But you don't have to maintain GNOME Flashback, you don't need to care if it works or not.
(In reply to comment #14) > (In reply to comment #11) > > Applications shouldn't be using the gnome-shell keygrabber. The only > > "application" using it should be gnome-settings-daemon. I also really don't > > This is not changing... gnome-settings-daemon need someone that provides this > key grabber, in GNOME it is shell. In non-shell session media-keys plugins does > nothing without key grabber. I want provide my own key grabber, but currently I > need to export it on org.gnome.Shell, but that means applications will think > that they are running in GNOME Shell session and this is problem. :( You're trying to make gnome-settings-daemon work in something other than GNOME. That's not supported. > > care about GNOME Flashback because if it means that when we stop maintaining it > > we still have to maintain, just what's the point. > > But you don't have to maintain GNOME Flashback, you don't need to care if it > works or not. I have to review patches, and make sure that they don't break things that were working, and then maintain any changes you might have made to gnome-settings-daemon. Your patch is small, but next you'll be asking for other gnome-shell specific interfaces that gnome-settings-daemon uses to be switched (the screenshooter, the screencasting, the screen locking, etc.). Where do we stop exactly?
(In reply to comment #14) > But you don't have to maintain GNOME Flashback, you don't need to care if it > works or not. That's only true as long gnome-flashback does not interfere with (or even break) anything in gnome - it's not like there weren't precedents for this[0]. I'd having to deal with bug reports about broken keybindings and it turns out that a curious user ran your-key-grabber to see what it does and it kicked us off the bus (note: if this gets in and something like that ever happens, I reserve the right to revert the change without discussion) [0] https://git.gnome.org/browse/metacity/commit/?id=881d5baf3edafe959
This doesn't seem like a finite activity to me. We'd also have to grab bus names at a very fine granularity - one bus name per interface - who knows how other interfaces will want to group things. If there are interfaces we are providing for applications that need to be standardized cross desktop, then we should standardize them properly in the free-desktop namespace, but I don't see trying to make GNOME components reusable outside of the GNOME desktop.
(In reply to comment #15) > I have to review patches, and make sure that they don't break things that were > working, and then maintain any changes you might have made to > gnome-settings-daemon. Your patch is small, but next you'll be asking for other > gnome-shell specific interfaces that gnome-settings-daemon uses to be switched > (the screenshooter, the screencasting, the screen locking, etc.). > > Where do we stop exactly? Changing interface name is only thing that I ask and might ask in future. I am not going to ask to add support for something directly in GNOME core components. We start and stop only with interface name changing. (In reply to comment #16) > (In reply to comment #14) > > But you don't have to maintain GNOME Flashback, you don't need to care if it > > works or not. > > That's only true as long gnome-flashback does not interfere with (or even > break) anything in gnome - it's not like there weren't precedents for this[0]. > I'd having to deal with bug reports about broken keybindings and it turns out > that a curious user ran your-key-grabber to see what it does and it kicked us Then user needs to run gnome-flashback applications that is only autostarted (by required components) in GNOME Flashback. > off the bus (note: if this gets in and something like that ever happens, I > reserve the right to revert the change without discussion) Ok. > [0] https://git.gnome.org/browse/metacity/commit/?id=881d5baf3edafe959 Does this have caused problems? This was added to support ubuntu themes and I can revert this, but it looks like mutter soon will not use metacity themes. Also probably better solution to this would be to simply ignore anything in theme that is not supported both in mutter and metacity. P.S. You all always can ask me to fix something that might be broken or stop working by changes that I have asked/made. I am interested in working GNOME Flashback session so I will help fixing bugs if that will be needed.
(In reply to comment #17) > This doesn't seem like a finite activity to me. We'd also have to grab bus > names at a very fine granularity - one bus name per interface - who knows how > other interfaces will want to group things. > > If there are interfaces we are providing for applications that need to be > standardized cross desktop, then we should standardize them properly in the > free-desktop namespace, but I don't see trying to make GNOME components > reusable outside of the GNOME desktop. Non reusable components forces to fork them. Don't see anything good here. If components are reusable then it would mean that if other desktop maintainers find bugs in GNOME they contribute patches to upstream. Do maintainers of forks submit patches here?
Any news about this?
The original problem is that by putting the keygrabbing interface on the org.gnome.Shell bus name, the provider of that interface needs to own the org.gnome.Shell bus name, and owning that name has side effects as other components change behavior when that name is around. Changing just the bus name to something more specific is completely backward compatible, though, since dbus only uses the bus name for routing to the process, not for message dispatch within the process, and the old name would still be around. What I mean is there's no dbus analog to apache's "name based virtual hosting" or anything like that. The object path and interface serves the purpose of routing the message within the process, not the bus name. We also have prior art of owning multiple bus names... gnome-shell owns a few, gnome-settings-daemon owns a few. The patch changes the object path (and interface name), too. I don't understand why, since it doesn't fix any problem, but then requires updating gnome-settings-daemon. Changing just the bus name doesn't seem like a big deal to me. I mean given the current shell bus apis, it could have just as easily and arbitrarily ended up with the new name from the start when the code was first getting written. Still, the slipper-slope precedent and expectations it creates could be problematic going forward. It creates a head wind...
Created attachment 292665 [details] [review] own dbus name - org.gnome.Shell.KeyGrabber
Created attachment 292666 [details] [review] watch for org.gnome.Shell.KeyGrabber dbus name
I updated patches so they don't change object patch and interface name. So now they are even smaller. Ray Strode can you please look at gnome-session bug (it is about same thing - dbus name): https://bugzilla.gnome.org/show_bug.cgi?id=738264
I have created wip/flashback branches in gnome-flashback, gnome-shell, gnome-session and gnome-settings-daemon with all changes that I think is necessary to allow Flashback session work without workaround - owning org.gnome.Shell dbus name. 1) gnome-session is updated to use org.gnome.SessionManager.EndSessionDialog not org.gnome.Shell for end session dialog. 2) Key grabber is moved to org.gnome.Shell.KeyGrabber. 3) OSD is moved to org.gnome.Shell.OSD. 4) Screenshot is moved to org.gnome.Shell.Screenshot. 5) Screencast is moved to org.gnome.Shell.Screencast. No functionality is changed - nothing removed, nothing added.
May I ask for some attention to this bug report? Please!
February 16 is listed as freeze date in GNOME Schedule wiki page. I guess after this date these changes will not be allowed, right? Can you please decide if you are going to accept these changes or not?
Ahh...What is the problem here? This is a very simple patch with just name changes & doesn't affect gnome-shell anyway or other. Beside, according to me, using "org.gnome.Shell" as KeyGrabber name is simply wrong. Why does a dbus name for a such a specific thing has to be so general? This does not adhere to freedesktop specification. > Bastien Nocera: You're trying to make gnome-settings-daemon work in something other than GNOME. That's not supported. Really? Then why does Gtk+ accepts a patch which enables user to move windows buttons to left? Why does Gnome accept patch from Ubuntu to have the ability to disable app-menu for non-shell session? Gnome does not require those? Does it? Clearly some people wants Gnome components to be reused outside Gnome. Some does not. This is not helpful in FOSS. If you want to be so restrictive, then, why not make Gnome closed-source & be done with it?
(In reply to Khurshid Alam from comment #28) > Clearly some people wants Gnome components to be reused outside Gnome. Some > does not. This is not helpful in FOSS. If you want to be so restrictive, > then, why not make Gnome closed-source & be done with it? Nice strawman. You can fork it as well, it's Free Software, that's what the Unity folks ended up doing. You should consider it as well.
(In reply to Khurshid Alam from comment #28) > Really? Then why does Gtk+ accepts a patch which enables user to move > windows buttons to left? Because GTK+ is not a core desktop component, but a toolkit that *does* aim to be usable outside of GNOME (there wouldn't be much point in Windows/Mac backends otherwise, would there?). This does not apply at all to components like *gnome*-settings-daemon or *gnome*-shell.
I just don't understand... GNOME Panel was part of GNOME, you dropped it, ok, but it still GNOME. Where is problem accepting these changes so we have option to use old GNOME Panel session? Does these patches do something terrible with GNOME? So you are suggesting to fork gnome-session, gnome-settings-daemon. Are you ok that I will push gnome-flashback-session, gnome-flashback-settings-daemon to git.gnome.org? And only difference will be different dbus name between gnome-* and gnome-flashback-* components? (I don't plan to do it...) I wrote patches that would allow GNOME Flashback to work better with GNOME, you are rejecting. I wrote patches for glib for per session overrides support that could partially solve problem (in flashback session) caused by using org.gnome.Shell. Again, looks like you are not interested. Both changes could be useful by other sessions/desktops: 1. Unity probably could drop their fork (i don't know all reason why it was forked). 2. Desktops could set their default settings without breaking other desktops. If there is no real reason to reject this, please, reconsider your decision. P.S. Bug for per-session overrides (if someone does not know about it): https://bugzilla.gnome.org/show_bug.cgi?id=746592
To be genuinely honest, I'd like to see g-s-d split out to separate processes again. A lot of g-s-d's functionality is either being taken over by the compositor, or by something systemd or lower levels could do (e.g. housekeeping should be replaced by a systemd timer) I am fine with the GNOME Shell patches, but I'm not the maintainer of settings-daemon. I'm not sure why Bastien is morally opposed to them.
(In reply to Jasper St. Pierre from comment #32) > To be genuinely honest, I'd like to see g-s-d split out to separate > processes again. A lot of g-s-d's functionality is either being taken over > by the compositor, or by something systemd or lower levels could do (e.g. > housekeeping should be replaced by a systemd timer) That's the plan, see bug 741688 comment 5
Biggest problem is that Gtk/ShellShowsAppMenu is set to TRUE / 1 when someone starts owning org.gnome.Shell dbus name. Would you accept patch that tries to get ShellVersion property when shell has appeared and if version is empty string it just calls notify_have_shell (manager, FALSE)?
Created attachment 302691 [details] [review] xsettings: use ShellVersion to adjust Gtk/ShellShowsAppMenu When org.gnome.Shell dbus name appears try to get ShellVersion property. If ShellVersion is empty string assume that we have no shell and set Gtk/ShellShowsAppMenu to FALSE / 0.
Created attachment 302755 [details] [review] xsettings: don't monitor shell under GNOME Flashback
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new ticket at https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/ Thank you for your understanding and your help.