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 547554 - Need to activate Hotkey three times in order to open applet
Need to activate Hotkey three times in order to open applet
Status: RESOLVED OBSOLETE
Product: hamster-applet
Classification: Deprecated
Component: general
2.23.x
Other All
: Normal minor
: ---
Assigned To: hamster-applet-maint
hamster-applet-maint
Depends on:
Blocks:
 
 
Reported: 2008-08-13 09:11 UTC by Roni Yaniv
Modified: 2010-01-23 17:21 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Roni Yaniv 2008-08-13 09:11:22 UTC
Please describe the problem:
If I press <super>H, the applet gets focused, but doesn't open completely - only the currently displayed line is focused.
I need to press the hotkey two more times to reach the actual applet window - once to deactivate and another to really open the applet.

Steps to reproduce:
1. start hamster with default settings
2. do as described

Actual results:


Expected results:


Does this happen every time?
yes

Other information:
Comment 1 Patryk Zawadzki 2008-08-13 09:14:39 UTC
Which version of GNOME/Metacity/Compiz are you using? There used to be a Metacity compositor bug that prevented it from properly drawing Hamster's window 50% of the time.

Works fine for me with GNOME 2.23.6.
Comment 2 Toms Bauģis 2008-08-13 09:20:02 UTC
Oh, i'm experiencing this one too on Ubuntu Hardy (not using compiz).
Patryk - does it work for you even if you have a window where hamster's main drop-down should appear?
Comment 3 Patryk Zawadzki 2008-08-13 09:28:43 UTC
Ah! Now I see what you mean. Easily fixable by setting Hamster to always appear on top like the clock's calendar does.
Comment 4 Patryk Zawadzki 2008-08-13 09:43:50 UTC
...or not. Focus stealing prevention still does not allow the window to get keyboard focus even if it ends up in front. Toms, could you check if calling .present() on window fixes this? I'm at work right now and can't do any immediate checks.

If not, could you ask Metacity developers what is the right way to handle that case?
Comment 5 Toms Bauģis 2008-08-13 10:48:06 UTC
window.present() didn't solve the problem

based on somewhat outdated thread http://osdir.com/ml/gnome.gtk+.python/2004-12/msg00046.html i tried to call the window display function with gtk.idle_add()

and it appears to work quite well (like 100% on my box :)  ) - i wonder if we can consider this to be a dirty hack or something we can live with.
Comment 6 Toms Bauģis 2008-08-13 10:52:43 UTC
anyway - checked in TRUNK - at least this one works
http://code.google.com/p/projecthamster/source/diff?r=373&format=side&path=/trunk/hamster/applet.py

Marked also as TODO, since this is only going around race condition, not really solving it.
Comment 7 Toms Bauģis 2008-08-13 10:53:16 UTC
This problem has been fixed in the development version. The fix will be available in the next major software release. Thank you for your bug report.

sorry for bugspam!
Comment 8 Toms Bauģis 2008-08-13 11:28:37 UTC
reopening until we get response from metacity guys how to solve this properly
Comment 9 Toms Bauģis 2010-01-23 17:21:45 UTC
workaround is marked as TODO in code and metacity has not gotten back about this, so, errm, the TODO should suffice here