No, I went for another solution. But it's worth noting that I was causing the problem by making the workspaceSwitcherPopup not reactive.
Indeed, that may well be the cause ! I noticed that this wasn't happening all the time, but frequently enough. What you describe seems to match what I noticed.Where you able to find a way to work around that bug, or simply ignored it and choosed another solution ?2015-01-29 18:20 GMT-08:00 Michele <micxgx gmail com>:Hi,
I did have a similar problem. I didn't need the signal anymore and I forgot about that. But this was my comment at that time:
"It seems that the mouse pointer remains linked to the previous actor when moving to a non reactive one. The change-hover is triggered and the hover updated but, calling later manually sync_hover on the actor causes the hover status to be wrongly calculated."
In fact you will notice that the hover problem appears only if that's the last actor you hovered before changing workspace.
I'm not sure if it's a bug or what.
Michele
On Wed, 28 Jan, 2015 at 9:44 AM, deadal nix <deadalnix gmail com> wrote:
pong !
2015-01-23 23:18 GMT-08:00 deadal nix <deadalnix gmail com>:
ping ping ping ?
2015-01-16 21:45 GMT-08:00 deadal nix <deadalnix gmail com>:
Hi all, I'm the author of a gnome shell extension.
In this extension, I hook a callback on the app menu when it is hovered. It works well, except when I change desktop.
First, the hover event is triggered when changing desktop, which seems very weird. Even weirder, calling get_hover on the app menu return true during this event.
I've found no way to make the difference between that hover and a regular hover, which create a bug in my extension.
1/ Is there a way to make the difference ? What can i do to know am I transitionning from one desktop to the other ?
2/ Is that a bug ???
The extension is pixel saver, if that matter. The code concerned is here (look for onAppMenuHover): https://github.com/deadalnix/pixel-saver/blob/master/pixel-saver%40deadalnix.me/app_menu.js