After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 613543 - OSD's don't work when in overview mode
OSD's don't work when in overview mode
Status: RESOLVED FIXED
Product: gnome-shell
Classification: Core
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
: 633577 658317 664192 691464 (view as bug list)
Depends on: 607029 663629
Blocks: 695021
 
 
Reported: 2010-03-21 23:27 UTC by Hylke Bons
Modified: 2013-03-03 12:09 UTC
See Also:
GNOME target: 3.8
GNOME version: ---


Attachments
Keybindings: add a mechanism to grab a specific key combination (10.90 KB, patch)
2012-06-23 15:37 UTC, Giovanni Campagna
rejected Details | Review
Handle some keybindings even when a compositor grab is active (6.04 KB, patch)
2012-06-23 15:37 UTC, Giovanni Campagna
reviewed Details | Review
Allow a keybinding handler to ignore a keybinding (22.08 KB, patch)
2012-06-23 15:37 UTC, Giovanni Campagna
accepted-commit_now Details | Review
Keybindings: uniquify the name for non-builtin keybindings (8.46 KB, patch)
2012-06-23 15:37 UTC, Giovanni Campagna
reviewed Details | Review
Main: filter keybindings when the shell is modal (10.12 KB, patch)
2012-06-23 15:38 UTC, Giovanni Campagna
reviewed Details | Review
Handle global keybindings in the shell (33.09 KB, patch)
2012-06-23 15:38 UTC, Giovanni Campagna
rejected Details | Review
Disable media-keys plugin when gnome-shell is active (7.84 KB, patch)
2012-06-23 15:58 UTC, Giovanni Campagna
rejected Details | Review
Keybindings: add a mechanism to grab a specific key combination (10.68 KB, patch)
2012-08-29 21:54 UTC, Giovanni Campagna
none Details | Review
Handle some keybindings even when a compositor grab is active (6.03 KB, patch)
2012-08-29 21:54 UTC, Giovanni Campagna
none Details | Review
Keybindings: uniquify the name for non-builtin keybindings (8.89 KB, patch)
2012-08-29 21:58 UTC, Giovanni Campagna
none Details | Review
Main: filter keybindings when the shell is modal (10.06 KB, patch)
2012-08-29 22:01 UTC, Giovanni Campagna
none Details | Review
Handle global keybindings in the shell (33.51 KB, patch)
2012-08-29 22:02 UTC, Giovanni Campagna
none Details | Review
Keybindings: add a mechanism to grab a specific key combination (11.39 KB, patch)
2012-11-10 16:02 UTC, Giovanni Campagna
none Details | Review
Allow a keybinding handler to ignore a keybinding (22.08 KB, patch)
2012-11-10 16:02 UTC, Giovanni Campagna
none Details | Review
Handle some keybindings even when a compositor grab is active (6.03 KB, patch)
2012-11-10 16:03 UTC, Giovanni Campagna
none Details | Review
Keybindings: uniquify the name for non-builtin keybindings (8.87 KB, patch)
2012-11-10 16:04 UTC, Giovanni Campagna
none Details | Review
Main: filter keybindings when the shell is modal (11.17 KB, patch)
2012-11-10 16:04 UTC, Giovanni Campagna
none Details | Review
Prefix keybinding names with 'internal-keybinding-' (6.84 KB, patch)
2012-11-10 16:05 UTC, Giovanni Campagna
none Details | Review
Handle global keybindings in the shell (38.29 KB, patch)
2012-11-10 16:05 UTC, Giovanni Campagna
none Details | Review
Add a new stacking layer for OSD windows. (5.68 KB, patch)
2013-03-02 15:52 UTC, Giovanni Campagna
rejected Details | Review
Layout: add support for the OSD window group (4.71 KB, patch)
2013-03-02 15:53 UTC, Giovanni Campagna
rejected Details | Review
osdWindow: Add a simple OSD popup (8.12 KB, patch)
2013-03-02 19:25 UTC, Florian Müllner
committed Details | Review
shellDBus: Export ShowOSD() method on the bus (1.79 KB, patch)
2013-03-02 19:27 UTC, Florian Müllner
committed Details | Review
switcherPopup: Cancel the OSD popup before showing (1.85 KB, patch)
2013-03-02 19:28 UTC, Florian Müllner
committed Details | Review

Description Hylke Bons 2010-03-21 23:27:27 UTC
OSD's like changing volume or brightness don't work when in overview mode.
Comment 1 Frederic Peters 2010-10-30 20:32:22 UTC
*** Bug 633577 has been marked as a duplicate of this bug. ***
Comment 2 Giovanni Campagna 2010-10-31 09:09:13 UTC
This is actually two bugs:

1) special keys are grabbed when in overview mode and thus are not delivered to gnome-power-manager (brightness) / gnome-settings-daemon (screen rotation, volume) / gnome-session (logout)

2) OSD windows are not shown in overview mode (dup of bug 607029)
Comment 3 Bastien Nocera 2011-11-08 14:41:16 UTC
> 1) special keys are grabbed when in overview mode and thus are not delivered to
> gnome-power-manager (brightness) / gnome-settings-daemon (screen rotation,
> volume) / gnome-session (logout)

Note that all those key shortcuts are now handled by gnome-settings-daemon itself.
Comment 4 Florian Müllner 2011-11-16 12:59:11 UTC
*** Bug 664192 has been marked as a duplicate of this bug. ***
Comment 5 rockonthemoonfm 2011-12-14 10:07:34 UTC
well, I confirm this bug too.
Comment 6 Pierre-Antoine Roiron 2012-03-20 14:19:59 UTC
I confirm it too. It's quite annoying when you use special keys for volume up/down for example.
Comment 7 André Klapper 2012-03-20 14:25:52 UTC
Please also mention your GNOME version and distro when confirming - thanks!
Comment 8 Pierre-Antoine Roiron 2012-03-20 14:30:45 UTC
Sorry for that André, I'm quite new to this and do not have all the good practices. Here's the completed comment :
I can confirm this bug on Fedora 16 with gnome-shell 3.2.2.1.
Comment 9 Jeremy Newton 2012-03-22 23:38:40 UTC
I would assume this is also the same bug that inhibits the changing of brightness and volume through the keys on the new login screen?

Fedora 16 with gnome-shell 3.2.2.1 by the way.
Comment 10 Giovanni Campagna 2012-06-23 15:36:00 UTC
Ok, GrabOverride was supposed to save us all, but it didn't happen, and this bug is extremely annoying, so I decided to go all the way down and reimplement keybinding handling in the shell directly.
It actually turned out to be quite easy, with good code clean ups in mutter and the already present shell keybindings.
Comment 11 Giovanni Campagna 2012-06-23 15:37:13 UTC
Created attachment 217081 [details] [review]
Keybindings: add a mechanism to grab a specific key combination

Instead of requiring a GSettings object, allow to hardcode a specific
combination for a keybinding. This will be used by the Shell to
replace the media keys plugin in gnome-settings-daemon.
Comment 12 Giovanni Campagna 2012-06-23 15:37:25 UTC
Created attachment 217082 [details] [review]
Handle some keybindings even when a compositor grab is active

Do not ignore all key events automatically when a compositor grab
is active, and introduce a flag for masking which keybindings should
be active.
This does not mean that automatically all keybindings are active
when the compositor is modal, it merely moves the policy down to
the handler.
Comment 13 Giovanni Campagna 2012-06-23 15:37:34 UTC
Created attachment 217083 [details] [review]
Allow a keybinding handler to ignore a keybinding

Previous commit moved policy for keybindings when grabbed down to
the handler, but did not replay the event if it is was not handled.
This commit adds the missing bit.
Comment 14 Giovanni Campagna 2012-06-23 15:37:42 UTC
Created attachment 217084 [details] [review]
Keybindings: uniquify the name for non-builtin keybindings

Multiple settings objects could have the same key, so that alone
is not enough to identify the binding. Add also the pointer value
of the GSettings object.
Comment 15 Giovanni Campagna 2012-06-23 15:38:10 UTC
Created attachment 217085 [details] [review]
Main: filter keybindings when the shell is modal

Mutter now handles some keybindings even when the compositor is
grabbed, so we need to filter the invocation at the handler level.
This allows to finally get rid of a old hack.
Comment 16 Giovanni Campagna 2012-06-23 15:38:19 UTC
Created attachment 217086 [details] [review]
Handle global keybindings in the shell

Handling global keybindings, such as volume and brightness keys
but also custom keybindings, directly in the compositor is the only way
to deal with grabs and modal operations that could be active (primarily
the overview, for which special policy was introduced in the last
commit)
Comment 17 Giovanni Campagna 2012-06-23 15:58:08 UTC
Created attachment 217088 [details] [review]
Disable media-keys plugin when gnome-shell is active

Introduce a small utility for marking a plugin as "fallback only"
(so automatically disabled when gnome-shell is on the bus), and
use it for media-keys.
Comment 18 Jasper St. Pierre (not reading bugmail) 2012-06-23 19:35:30 UTC
I have a set of patches that I'm going to work on to allow override-redirect windows in the overview. Really, we shouldn't even be managing OR windows; it's only because of composite that we can. This should remove the OSD implementation from gnome-shell, something which I'm not a fan of.
Comment 19 Jasper St. Pierre (not reading bugmail) 2012-06-23 19:36:03 UTC
( I also tried something like this approach in https://bugzilla.gnome.org/show_bug.cgi?id=665547 , but didn't get as far as you )
Comment 20 Jasper St. Pierre (not reading bugmail) 2012-06-23 19:37:11 UTC
Review of attachment 217084 [details] [review]:

This is semi-related to https://bugzilla.gnome.org/show_bug.cgi?id=666513 , which Florian didn't like. I'm for it, but it's unfortunate that we couldn't get a patch in for this before that.
Comment 21 Jasper St. Pierre (not reading bugmail) 2012-06-23 19:38:29 UTC
Review of attachment 217084 [details] [review]:

::: src/core/keybindings.c
@@ +686,3 @@
+    name = g_strdup_printf ("custom-keybinding-%p-%s", settings, key);
+  else
+    name = g_strdup (key);

This should really be g_strdup_printf ("internal-keybinding-%s", key); to reduce collisions even further.
Comment 22 Jasper St. Pierre (not reading bugmail) 2012-06-23 19:41:41 UTC
Review of attachment 217083 [details] [review]:

Makes sense.

::: src/core/keybindings.c
@@ +1401,1 @@
 invoke_handler_by_name (MetaDisplay    *display,

It doesn't look like you ever respect the return value of invoke_handler_by_name.
Comment 23 Jasper St. Pierre (not reading bugmail) 2012-06-23 19:42:37 UTC
Review of attachment 217086 [details] [review]:

Not a fan. I'd rather you expose a DBus service that allows g-s-d to get a keybinding.
Comment 24 Jasper St. Pierre (not reading bugmail) 2012-06-23 19:42:55 UTC
Review of attachment 217088 [details] [review]:

No.
Comment 25 Jasper St. Pierre (not reading bugmail) 2012-06-23 19:46:37 UTC
Review of attachment 217085 [details] [review]:

I really don't understand how this is supposed to work -- what's stopping something like Alt-Tab from being executed in the overview?

::: js/misc/util.js
@@ +303,3 @@
+ * with Meta.KeybindingFlags.HANDLE_WHEN_GRABBED
+ */
+function wrapKeybinding(handler, onlyInOverview) {

I don't think this belongs in util. And you don't ever pass false for 'onlyInOverview'.
Comment 26 Jasper St. Pierre (not reading bugmail) 2012-06-23 19:48:36 UTC
Review of attachment 217085 [details] [review]:

Er, nevermind. I see you have the magic flag.
Comment 27 Jasper St. Pierre (not reading bugmail) 2012-06-23 19:51:17 UTC
Review of attachment 217082 [details] [review]:

Yeah, this makes sense. Your commit message is a bit misleading -- as of this commit, panel-main-menu, etc. will be active when the compositor is modal, regardless of the policy of a handler.
Comment 28 Jasper St. Pierre (not reading bugmail) 2012-06-23 19:53:47 UTC
Review of attachment 217081 [details] [review]:

I'm not a fan of a generic key grab API.
Comment 29 Giovanni Campagna 2012-06-24 12:33:18 UTC
(In reply to comment #23)
> Review of attachment 217086 [details] [review]:
> 
> Not a fan. I'd rather you expose a DBus service that allows g-s-d to get a
> keybinding.

I don't see what would be the point.
You'd still need to watch GSettings in the shell and grab each key (or worse, reimplement keybindings in _globalKeyHandler). There would be no performance advantage, since the individual actions are all very simple.
Also, you'd still have the problem that changing g-s-d for new keybindings requires matching shell changes, so if you're doing that you may just as well add the JS implementation.

As for the OSD, all UI should live in the shell. Having OR windows in the overview is wrong, and would break with windows created by non standard apps (wine for example creates OR windows in some cases, and for reasons unknown to me...).

(Not to mention that at some point we'll move to wayland, and there is no place in that for OR or passive grabs...)
Comment 30 Jasper St. Pierre (not reading bugmail) 2012-06-24 15:12:59 UTC
(In reply to comment #29)
> (In reply to comment #23)
> > Review of attachment 217086 [details] [review] [details]:
> > 
> > Not a fan. I'd rather you expose a DBus service that allows g-s-d to get a
> > keybinding.
> 
> I don't see what would be the point.
> You'd still need to watch GSettings in the shell and grab each key (or worse,
> reimplement keybindings in _globalKeyHandler).

I guess if we add a generic grab key/ungrab key API, it wouldn't be so bad.

> There would be no performance
> advantage, since the individual actions are all very simple.
> Also, you'd still have the problem that changing g-s-d for new keybindings
> requires matching shell changes, so if you're doing that you may just as well
> add the JS implementation.

I do not understand? We'd expose something like:

    org.gnome.SettingsDaemon.MediaKeys.KeyGrabber

and then we'd have one implementation in the shell and then a fallback implementation in g-s-d. What matching shell changes would that require other than exporting a grab/ungrab API over DBus?

> As for the OSD, all UI should live in the shell. Having OR windows in the
> overview is wrong, and would break with windows created by non standard apps
> (wine for example creates OR windows in some cases, and for reasons unknown to
> me...).

wtf. Still, having OR windows in the overview has its advantages. Maybe we could have a special window property.
Comment 31 Florian Müllner 2012-08-18 07:42:25 UTC
Comment on attachment 217082 [details] [review]
Handle some keybindings even when a compositor grab is active

That is not really what we want - we do want some keybindings to be processed in situations where we have a grab, but we don't want to treat all grabs equally. For instance, we do want switch-workspace to be  handled when in the overview (which this patch does), but not in other situations like while showing a system modal or in the lock screen.
Comment 32 Florian Müllner 2012-08-18 11:12:29 UTC
Comment on attachment 217082 [details] [review]
Handle some keybindings even when a compositor grab is active

Sorry, I should have kept reading ...

Still, I don't really like how the filtering is spread all over the place (e.g. for built-in bindings, it's in init_builtin_key_bindings(), the built-in handler and the custom handler). Can't we have a hook in the compositor (something like meta_compositor_filter_keybinding(display->compositor, binding))?
Comment 33 Giovanni Campagna 2012-08-27 19:49:48 UTC
*** Bug 658317 has been marked as a duplicate of this bug. ***
Comment 34 Giovanni Campagna 2012-08-29 21:05:17 UTC
Apparently this, in addition to being an extremely irritating bug, is a dependence of bug 682229, which is a blocker for 3.6, so let's see if we can get it going.
Comment 35 Florian Müllner 2012-08-29 21:15:39 UTC
Apparently I thought bug 643111 was the "canonical" bug for keybinding overhaul, so I started working on this before I became aware of the patches here - I'm still yak-shaving, but so far what's outlined in comment #32 works quite well (including a fix for bug 682229 and a couple of other issues), so I'd like to at least put up my patches for discussion as well.
Will take me another day or so though ...
Comment 36 Giovanni Campagna 2012-08-29 21:20:30 UTC
Uh, ok, I wasn't aware of bug 643111.
We can move the discussion there and leave this bug for the UI if you prefer, although IIRC Jasper had a patch somewhere to avoid messing with OR windows.
Comment 37 Jasper St. Pierre (not reading bugmail) 2012-08-29 21:22:20 UTC
(In reply to comment #36)
> Uh, ok, I wasn't aware of bug 643111.
> We can move the discussion there and leave this bug for the UI if you prefer,
> although IIRC Jasper had a patch somewhere to avoid messing with OR windows.

I don't think I ever published it anywhere.
Comment 38 Florian Müllner 2012-08-29 21:30:28 UTC
(In reply to comment #36)
> Uh, ok, I wasn't aware of bug 643111.
> We can move the discussion there and leave this bug for the UI if you prefer,
> although IIRC Jasper had a patch somewhere to avoid messing with OR windows.

Are you referring to bug 679500? I still think it is a bad idea, as external UI like docky, awn, maliit etc. will suddenly show up in "random" places in the overview, blocking whatever happens to be positioned below.
Comment 39 Giovanni Campagna 2012-08-29 21:50:30 UTC
(In reply to comment #32)
> (From update of attachment 217082 [details] [review])
> Sorry, I should have kept reading ...
> 
> Still, I don't really like how the filtering is spread all over the place (e.g.
> for built-in bindings, it's in init_builtin_key_bindings(), the built-in
> handler and the custom handler). Can't we have a hook in the compositor
> (something like meta_compositor_filter_keybinding(display->compositor,
> binding))?

I think it's cleaner to handle this in the individual handlers (through Util.wrapKeybinding).
The alternative is having another table in JS, to associate each binding with its policy (be it an enum or a function call).
Comment 40 Giovanni Campagna 2012-08-29 21:54:02 UTC
Created attachment 222874 [details] [review]
Keybindings: add a mechanism to grab a specific key combination

Instead of requiring a GSettings object, allow to hardcode a specific
combination for a keybinding. This will be used by the Shell to
replace the media keys plugin in gnome-settings-daemon.

Even if g-s-d is kept as the central place of global keybindings, this
is needed.
Comment 41 Giovanni Campagna 2012-08-29 21:54:46 UTC
Created attachment 222875 [details] [review]
Handle some keybindings even when a compositor grab is active

Do not ignore all key events automatically when a compositor grab
is active, and introduce a flag for masking which keybindings should
be active.
This does not mean that automatically all keybindings are active
when the compositor is modal, it merely moves the policy down to
the handler.

Rebased on the overlay key changes.
Comment 42 Giovanni Campagna 2012-08-29 21:58:04 UTC
Created attachment 222876 [details] [review]
Keybindings: uniquify the name for non-builtin keybindings

Multiple settings objects could have the same key, so that alone
is not enough to identify the binding. Add also the pointer value
of the GSettings object.

Rebased and comment addressed.
Comment 43 Florian Müllner 2012-08-29 21:58:47 UTC
(In reply to comment #39)
> I think it's cleaner to handle this in the individual handlers (through
> Util.wrapKeybinding).
> The alternative is having another table in JS, to associate each binding with
> its policy (be it an enum or a function call).

Yeah, that's what I'm doing, to allow for finer grained control of which keybindings are available in a specific mode (for instance, we want SWITCH_WORKSPACE in the overview but not in the lock screen, SWITCH_PANEL on the other hand should be available in both).
Comment 44 Giovanni Campagna 2012-08-29 22:01:07 UTC
Created attachment 222877 [details] [review]
Main: filter keybindings when the shell is modal

Mutter now handles some keybindings even when the compositor is
grabbed, so we need to filter the invocation at the handler level.
This allows to finally get rid of a old hack.

Rebased and tested with screen lock and modal message tray.
Comment 45 Giovanni Campagna 2012-08-29 22:02:43 UTC
Created attachment 222878 [details] [review]
Handle global keybindings in the shell

Handling global keybindings, such as volume and brightness keys
but also custom keybindings, directly in the compositor is the only way
to deal with grabs and modal operations that could be active (primarily
the overview, for which special policy was introduced in the last
commit)

I'm attaching this one too, in case during 3.7 cycle we drop fallback mode,
which is the only reason for the ugly hack of handling keybindings through dbus.
Comment 46 Justin 2012-10-03 20:10:16 UTC
Does the patch also enable printscreen in overview? Or should I create another bug?
Comment 47 Giovanni Campagna 2012-11-10 16:01:18 UTC
Fallback mode is officially dropped, media-keys in g-s-d is legacy.

I believe it makes no sense for gnome-shell to grab the keys, turn the X event into a dbus message and then send that to gsd. It is definitely easier and more performant to handle them in the shell.
Therefore, I'm attaching the complete mutter+gnome-shell patchset again, rebased on current master, tested and polished.
Florian, if you have working code for the DBus mechanism, could you post that here too?

Btw, the patchset, up to but not including the last commit for gnome-shell, is valid even if we decide not to move media keys handling in the shell, as it cleans up handling when modal and extension keybindings registration.
Also, as a nice side effect, with these I see fixed both bug 683024 and bug 687922, because overlay key handling is consolidated in mutter.
Comment 48 Giovanni Campagna 2012-11-10 16:02:37 UTC
Created attachment 228627 [details] [review]
Keybindings: add a mechanism to grab a specific key combination

Instead of requiring a GSettings object, allow to hardcode a specific
combination for a keybinding. This will be used by the Shell to
replace the media keys plugin in gnome-settings-daemon.

(This might or might not be needed)
Comment 49 Giovanni Campagna 2012-11-10 16:02:51 UTC
Created attachment 228628 [details] [review]
Allow a keybinding handler to ignore a keybinding

Previous commit moved policy for keybindings when grabbed down to
the handler, but did not replay the event if it is was not handled.
This commit adds the missing bit.
Comment 50 Giovanni Campagna 2012-11-10 16:03:38 UTC
Created attachment 228629 [details] [review]
Handle some keybindings even when a compositor grab is active

Do not ignore all key events automatically when a compositor grab
is active, and introduce a flag for masking which keybindings should
be active.
This does not mean that automatically all keybindings are active
when the compositor is modal, it merely moves the policy down to
the handler.
Comment 51 Giovanni Campagna 2012-11-10 16:04:08 UTC
Created attachment 228630 [details] [review]
Keybindings: uniquify the name for non-builtin keybindings

Multiple settings objects could have the same key, so that alone
is not enough to identify the binding. Add also the pointer value
of the GSettings object.
Comment 52 Giovanni Campagna 2012-11-10 16:04:29 UTC
Created attachment 228631 [details] [review]
Main: filter keybindings when the shell is modal

Mutter now handles some keybindings even when the compositor is
grabbed, so we need to filter the invocation at the handler level.
This allows to finally get rid of a old hack.
Comment 53 Giovanni Campagna 2012-11-10 16:05:10 UTC
Created attachment 228632 [details] [review]
Prefix keybinding names with 'internal-keybinding-'

This is what mutter does internally now, to disambiguate them with
custom keybindings introduced with display.add_keybinding().
Comment 54 Giovanni Campagna 2012-11-10 16:05:42 UTC
Created attachment 228633 [details] [review]
Handle global keybindings in the shell

Handling global keybindings, such as volume and brightness keys
but also custom keybindings, directly in the compositor is the only way
to deal with grabs and modal operations that could be active (primarily
the overview, for which special policy was introduced in the last
commit)
Comment 55 Giovanni Campagna 2012-11-10 16:09:50 UTC
To aid testing, I also pushed wip/media-keys branches of mutter and gnome-shell.

When trying them, don't forget to run
gsettings set org.gnome.settings-daemon.plugins.media-keys active false
Comment 56 Bastien Nocera 2012-11-10 16:50:52 UTC
Did this code regress wrt. handling device specific volume? In g-s-d we used XI2 to change the volume on speakers and headsets rather than the default ouput when the buttons on those were used.
Is XI2 key capture available?
Comment 57 Giovanni Campagna 2012-11-10 16:55:10 UTC
(In reply to comment #56)
> Did this code regress wrt. handling device specific volume? In g-s-d we used
> XI2 to change the volume on speakers and headsets rather than the default ouput
> when the buttons on those were used.
> Is XI2 key capture available?

Ugh, no, mutter doesn't do XI2 yet. I could try rebasing wip/media-keys on top of wip/xinput2r and see what happens...
Comment 58 Jasper St. Pierre (not reading bugmail) 2012-11-10 17:59:25 UTC
That branch is going to be replaced soon. Owen's unhappy with the current state, as it introduces a lot of complexity (multiple grabs, multiple pointers, etc.) for little to no gain, and it also supported Core Events. I'm going to rewrite it to simply use XI2 instead of Core Events. This should give us most things without a lot of drawbacks.
Comment 59 Florian Müllner 2012-11-12 19:32:57 UTC
(In reply to comment #47)
> Florian, if you have working code for the DBus mechanism, could you post that
> here too?

I'm still missing some g-s-d bits, so I've only posted the non-grab set so far, e.g. what I consider a cleaner approach for moving keybinding handling into mutter (comment #32). It also adds a keybinding-mode system, which allows to have different sets of keybindings in different modes (overview, login screen, message tray etc.). Given that the two patch sets have conflict written all over them (though I'm sure both the media-keys patch and the keybinding-mode set could be rebased on the "other" approach), I opened bug 688202 instead.
Comment 60 Bastien Nocera 2013-01-10 09:58:45 UTC
*** Bug 691464 has been marked as a duplicate of this bug. ***
Comment 61 Wolfram 2013-01-10 10:44:04 UTC
I've two keyboard layouts in my system: english and russian.
I've used gnome-tweak-tool to set caps lock as kb layout switch

Then I'm press WIN key (or move mouse into upper-left corner), gnome-shell menu
appears.

But it's impossible to switch kb layout while menu is active (and caps lock
works changes letters case in this menu).

So if I'm chatting in russian, then press WIN and trying to type TERMINAL in
search menu, I can't do this, I should switch layout, then launch menu, then
type what I want.

I've reported this behaviour in 691464. Is it really the same problem? If so, WHY it's still unconfirmed?
Comment 62 Bastien Nocera 2013-01-10 11:00:35 UTC
(In reply to comment #61)
> I've reported this behaviour in 691464. Is it really the same problem? If so,
> WHY it's still unconfirmed?

Because we don't use the UNCONFIRMED state. The fact that this patch has half-a-dozen patches from gnome-shell developers should make it clear that it's being worked on.
Comment 63 gatlin 2013-01-28 01:53:26 UTC
This may be fixed with bug 688202.
It is unfortunate that that fix missed 3.6.2. I only use stable versions.
Comment 64 Bastien Nocera 2013-01-28 06:38:11 UTC
(In reply to comment #63)
> This may be fixed with bug 688202.

It isn't.

> It is unfortunate that that fix missed 3.6.2. I only use stable versions.

It won't be fixed in GNOME 3.6.x at all.
Comment 65 Jordi Mallach 2013-02-03 10:50:59 UTC
I was about to file a bug for OSDs not showing up when a GNOME Shell menu is open (battery status, for example). As I'm running Shell 3.6, pinging first to see if this issue is related to the bug being discussed here, as I suspect.
Comment 66 Giovanni Campagna 2013-03-02 15:15:22 UTC
Ok, so most of the stuff here is obsolete, now that Florian landed bug 643111.
But we still need to handle the OSDs.

Two possibilities exists:
a) We can special case windows from gnome-settings-daemon (with WM_CLASS or a special property), place them in a different window group and paint them normally in the overview.
b) We can move OSD rendering in the shell, and have gsd ask the shell when it wants to show something.

b) is probably simpler, but a) should have better performance (less dbus traffic, less code in the shell)
Comment 67 Florian Müllner 2013-03-02 15:34:17 UTC
(In reply to comment #66)
> Two possibilities exists:
> a) We can special case windows from gnome-settings-daemon (with WM_CLASS or a
> special property), place them in a different window group and paint them
> normally in the overview.
> b) We can move OSD rendering in the shell, and have gsd ask the shell when it
> wants to show something.
> 
> b) is probably simpler, but a) should have better performance (less dbus
> traffic, less code in the shell)

I'm currently working on the g-s-d side of (b), the shell side is pretty much done. It's not a lot of code, and looking at all the hoops g-s-d has to jump though to draw a translucent rectangle with rounded corners, it makes a lot of sense to move this into the shell (where the same is a simple widget + a couple of lines of css).

I'll attach patches in a bit.
Comment 68 Giovanni Campagna 2013-03-02 15:52:24 UTC
Oh, nice, because I implemented a) after I wrote that comment, and it is simple after all.
I'll attach anyway, and then you can decide which way to go.

(Because, you know, grabbing the key in mutter, sending a DBus message to gsd, comparing it to GSettings, and then sending a DBus message again to gnome-shell doesn't strike me as the best possible design...)
Comment 69 Giovanni Campagna 2013-03-02 15:52:50 UTC
Created attachment 237814 [details] [review]
Add a new stacking layer for OSD windows.

OSD windows are the OR windows created by gnome-settings-daemon. The new
layer is required to paint them above the overlay layer, so they're visible
in the gnome-shell overview.
Comment 70 Giovanni Campagna 2013-03-02 15:53:12 UTC
Created attachment 237815 [details] [review]
Layout: add support for the OSD window group

The OSD window group is the new window group holding gnome-settings-daemon
OSD windows (such as volume or brightness).
The stacking order then becomes:
window group -> overlay group (overview) -> chrome (panel) ->
top window group -> osd window group -> screenshield -> chrome
(tray, keyboard) -> chrome (popup menus) -> other
Comment 71 Bastien Nocera 2013-03-02 16:00:40 UTC
(In reply to comment #67)
> (In reply to comment #66)
> > Two possibilities exists:
> > a) We can special case windows from gnome-settings-daemon (with WM_CLASS or a
> > special property), place them in a different window group and paint them
> > normally in the overview.
> > b) We can move OSD rendering in the shell, and have gsd ask the shell when it
> > wants to show something.
> > 
> > b) is probably simpler, but a) should have better performance (less dbus
> > traffic, less code in the shell)
> 
> I'm currently working on the g-s-d side of (b), the shell side is pretty much
> done. It's not a lot of code, and looking at all the hoops g-s-d has to jump
> though to draw a translucent rectangle with rounded corners, it makes a lot of
> sense to move this into the shell (where the same is a simple widget + a couple
> of lines of css).

That, and I've really wanted the OSDs to be styled the same way for volume popups and shell ones, and stop them clashing (have them disappear when the alt-tab popup shows up for example). That's not possible from g-s-d.

I don't see a major problem with the back-and-forth from g-s to g-s-d, there's plenty of things that g-s-d can know better than g-s when it comes to configuration.
Comment 72 Florian Müllner 2013-03-02 19:24:10 UTC
(In reply to comment #71)
> That, and I've really wanted [to] stop them clashing (have them disappear when the
> alt-tab popup shows up for example).

Oh, that makes a lot of sense, added that to the patches.
Comment 73 Florian Müllner 2013-03-02 19:25:07 UTC
Created attachment 237835 [details] [review]
osdWindow: Add a simple OSD popup

Implement a basic OSD popup that shows an icon and optionally a label
and a fill level. It is based on the existing OSD implementation in
gnome-settings-daemon, which it will replace.
Comment 74 Florian Müllner 2013-03-02 19:27:55 UTC
Created attachment 237836 [details] [review]
shellDBus: Export ShowOSD() method on the bus

Export a simple method to trigger an OSD popup. gnome-settings-daemon
will use this to replace its own OSD UI.

I have been wondering if it makes sense to restrict this method - I can imagine that this might be useful for applications like Totem as well, but maybe we should only fulfill the request if the sender is either g-s-d or the currently focused application?
Comment 75 Florian Müllner 2013-03-02 19:28:05 UTC
Created attachment 237837 [details] [review]
switcherPopup: Cancel the OSD popup before showing

It is irritating to show two different system popups at the same
time, so let switcher popups like alt-tab cancel out the OSD.
Comment 76 Jasper St. Pierre (not reading bugmail) 2013-03-02 22:29:27 UTC
Review of attachment 237835 [details] [review]:

I know I was opposed to OSDs in gnome-shell for a long time, but this is really not that much code. I'm impressed.
Comment 77 Jasper St. Pierre (not reading bugmail) 2013-03-02 22:30:46 UTC
Review of attachment 237837 [details] [review]:

OK.
Comment 78 Jasper St. Pierre (not reading bugmail) 2013-03-02 23:05:12 UTC
Review of attachment 237836 [details] [review]:

Minor style nit.

::: js/ui/shellDBus.js
@@ +121,3 @@
+        let icon = null;
+        if (params['gicon'])
+            icon = Gio.icon_new_for_string(params['gicon']);

Gio.Icon.new_for_string.

@@ +123,3 @@
+            icon = Gio.icon_new_for_string(params['gicon']);
+        else if (params['icon'])
+            icon = new Gio.ThemedIcon({ name: params['icon'] });

Why support both?
Comment 79 Florian Müllner 2013-03-03 12:08:43 UTC
Attachment 237835 [details] pushed as 19533f8 - osdWindow: Add a simple OSD popup
Attachment 237836 [details] pushed as 90ea27c - shellDBus: Export ShowOSD() method on the bus
Attachment 237837 [details] pushed as deb77a4 - switcherPopup: Cancel the OSD popup before showing

(In reply to comment #78)
> @@ +123,3 @@
> +            icon = Gio.icon_new_for_string(params['gicon']);
> +        else if (params['icon'])
> +            icon = new Gio.ThemedIcon({ name: params['icon'] });
> 
> Why support both?

Because creating a temporary GThemedIcon just to call g_icon_to_string() is a hassle, and I had missed that GThemedIcon's to_string() implementation explicitly guarantees that it will return the plain icon name in case of a single icon name. Changed to take only an 'icon' parameter, which is expected to hold a serialized GIcon (e.g. what 'gicon' did in the previous version).