libgtkhotkey 0.1, Portable Hotkey Integration
I just rolled the first release of gtkhotkey a library for platform independent hotkey handling. It started out as some code chunks for WinWrangler, but I quickly came to the conclusion that way to many applications copy-paste the Tomboy hotkey management code. This is of course a great tribute to the Tomboy devs, but I felt that I had to put my foot down here.
Currently it is just a fat GObject wrapper around the Tomboy hotkey code (yes, I copied it again, *sigh* ;-P), but it is nice and object oriented design so other implementations can be swapped in easily (fx also other platform backends). Basic promises:
- Abstraction of hotkey binding and unbinding via GObjects and signals
- Persistent management of hotkeys. Currently there is only a GKeyFile backend but a GConf one should be easy.
- Introspection of registered hotkeys – ie if the user tries to bind Alt-F3, you could give an error message like “The hotkey you requested ‘Alt F3′ is already registered by the application ‘Deskbar Applet’, please choose another”. In future versions you might even append ” – or click here to change the hotkey of Deskbar Applet”.
On the longer term it would be nice to get this functionality into Gtk itself, but as I understand it this might not be feasible.
Snippet from the README
Idea and Future ----------------------- I wrote GtkHotkey because I needed a platform independent way to manage and bind desktop hotkeys. Gnome applications can register hotkeys via GConf and Metacity, but I wanted desktop neutrality and more flexibility.I would like to see the functionality end up in Gtk+ some day, but there are obstacles, and I needed a solution fast. Should it turn out that such functionality is not feasible in Gtk+ itself, this library is still simple and has a narrow well defined goal, which should make it maintainable in the future. To ease maintainability unit tests has been implemented using the gtest framework found in glib versions >= 2.15. It is the goal to also include a set of Gtk+ widgets for managing hotkeys as well as a global configuration dialog for editing all registered hotkeys. Design ------ The idea of the library is to keep it as simple as possible, while sticking to an object oriented design, without falling back to C-isms (read: '#ifdefs') where it would otherwise be tempting. It can be argued that the code base is too small to be put in a separate library. However the functionality is very well defined and would probably appear oddly placed in some bigger helper library for GTk+ apps, where it would likely live in a hodge podge of unrelated functionality. API Guarantees -------------- 0.MINOR.MICRO: API stability between versions with same minor version 1.MINOR.MICRO: (not reached yet) All 1.*.* will be API and ABI compatible Credits ------- Currently src/x11 contains some code scrubbed from the Tomboy project. The stolen code is released under LGPL 2 or later, and I included in GtkHotkey as a LGPL 3 dependency.
Release: grillbar.org/gtkhotkey-0.1/gtkhotkey-0.1.tar.gz
Documentation: grillbar.org/gtkhotkey-0.1/doc
Bzr trunk: http://grillbar.org/gtkhotkey
March 11th, 2008 at 5:00 pm
How would this coexist with http://bugzilla.gnome.org/showdependencytree.cgi?id=349256 ?
March 11th, 2008 at 5:10 pm
I am not sure exactly what you mean dBera. Let me try an answer anyway
gtkhotkey does not duplicate any functionality found in libegg or Gtk. It can be used to for example pop up a window from an applet (that does not have focus), like deskbar or Tomboy. Ordinary Gtk accels can’t do that.
However the Tomboy code I’ve included does use eggaccelerator. I have looked a bit at that and it appears that it should be fairly easy to change the relevant code to gtk_accelerator*. This will be in a later release – I just wanted to get this one out in the wild.
March 11th, 2008 at 5:22 pm
“However the Tomboy code I’ve included does use eggaccelerator. I have looked a bit at that and it appears that it should be fairly easy to change the relevant code to gtk_accelerator*. This will be in a later release – I just wanted to get this one out in the wild.”
^^ This is what I meant. About using egg code when gtk people are trying to get rid of it. The sad part is beagle also copy-pastes the Tomboy code and there are several other bugs open about that (the eggaccel code has some inherent problems like it does not accept multimedia buttons easily and some other that I dont remember now). And I dont understand these things enough, not being a Gnome user is not helping me either.
So for a second I got thrilled about using this library to do our shortcut handing for beagle-search. Well… I can only say I will keep an eye open on the future development of libghotkey
March 12th, 2008 at 2:43 am
Good to hear. I had an inkling feeling that Deskbar and Tomboy where not the only ones using that code
It has been my motivation to get rid of the egg-code from the start. Let’s hope that I don’t come across any ugly issues when writing it out…
March 12th, 2008 at 3:31 am
If you can get this to the state where, when setting up the next system, all I have to do is to copy my old .gnome2/hotkey.conf file to get all my -bound hotkeys on the new system, then you will be my personal hero. The day it happens I will send you a postcard or something!
March 12th, 2008 at 3:32 am
Hey. nice, this is interesting… although I do not personally have a need for global hotkeys (yet).
March 12th, 2008 at 5:22 am
I’ve been using the _keybinder.so file from Deskbar in some of my own Python programs, so I’m very grateful that you are making a better solution. Basic collision-handling support for global keyboard shortcuts is a long overdue feature for GTK development. Thanks for working on this!
March 12th, 2008 at 8:15 am
@mg: Sorry it will store persistent data under ~/.config/hotkeys (following the FDO spec). Will this mean I don’t get a postcard when it is ready?
@marko: Oh, you will have – you will have
@Ryan: Yeah, now we just need language bindings for gtkhotkey…. Should not be a problem though.
March 12th, 2008 at 8:51 am
I’m down with FDO specs, so that won’t take you of the postcard list.
cheers,
mg
March 12th, 2008 at 1:46 pm
Just wanted to say “great work!” and it is good to see that you must somehow be managing to write code and change diapers on the kid at the same time.
March 12th, 2008 at 2:01 pm
@Mads:Ha, yeah, it is not always easy, you know that all too well
I usually have an hour or two around morning after Liv is sent to the daycare, and then an hour or two again after the kids have been put to sleep at night (and then my brain collapses to something not worthy of words).
March 12th, 2008 at 6:10 pm
I’m looking forward to this functionality as well. I’m a developer of Tilda (a quake-like dropdown terminal. See http://tilda.sourceforge.net ) and we copied the code from Tomboy as well, after running into tons of problems rolling our own.
I did end up replacing some of the stuff using the copied eggaccelerators code with gtk_accelerator_*() functions. This shaved quite a lot off our binary, actually, especially after commenting out the parsers. The only part I couldn’t figure out was how to replace the mapping between the X server’s keys (NumLock, CapsLock, etc) and the EGG_VIRTUAL_MODIFIER key. Something like that, anyway. I haven’t looked at that code in quite a while.
Anyway, I can’t wait. I’ll be watching.
April 24th, 2008 at 6:49 am
[...] I have decided to change my priorities. I had actually started to look into the libegg situation of GtkHotkey last night (as I promised earlier), but in the new light of things I think I better follow the ball [...]
April 24th, 2008 at 11:52 am
Please don’t use the Gtk namespace with GtkHotkey*. That namespace belongs to gtk+, not
an outside add-on library. Instead, this could be proposed and integrated into
gtk+-2.14, in which case it should be in the gtk+ namespace, otherwise not. That’s my personal educated opinion though.
April 24th, 2008 at 12:20 pm
Infact the namespace is GtkHotkey, not Gtk
I am aware that C can not differentiate this, so it is obviously a problem.
OTOH, this will ease transition to Gtk if that ever becomes relevant. If Gtk adopts a _hotkey_ namespace by other meanse it is pretty likely that my GtkHotkey lib will be deprecated.
May 14th, 2008 at 4:20 am
Nice! Keep up the good work!
June 17th, 2008 at 1:38 pm
Nice! I was about to copy the tomboy code for my project (http://code.google.com/p/gnome-menu-file-browser-applet/), but will use this instead. I was surprised GTK didn’t already include this functionality, so this lib would definitely be a good addition to GTK.
Thanks.
Also, re: “Vision or Fatamorgana?”, I agree with many (all) or your ideas and plan for a possible Gnome future and would be willing to help with development.
June 17th, 2008 at 2:00 pm
Nice! I was about to copy the tomboy code for my project (http://code.google.com/p/gnome-menu-file-browser-applet/) but will use this instead.
One question: How does one register a callback method or otherwise catch the “activated” event. I tried g_signal_connect() but the callback function is not being called. The event is definitely firing (I can see the printout), but the function registered in g_signal_connect is never called.
Thanks.
June 17th, 2008 at 2:04 pm
Never mind…
June 17th, 2008 at 2:44 pm
@Axel: I am glad you can use it. It bugs me that I have not been able to hack on it for a while – being immersed in xesam stuff.
Your project is certainly interesting and I’ve actually pondered something similar many times – glad that someone else had a similar idea!
June 19th, 2008 at 5:15 pm
Works like a charm! Thanks for this, and for all the other Gnome stuff you do.
June 20th, 2008 at 4:39 am
@Axel: Glad to hear. Thanks!
September 21st, 2008 at 10:20 am
In Tomboy SVN, we relicensed Alex’s hotkey code to MIT/X11, if that helps you at all.
September 22nd, 2008 at 2:22 am
@Sandy: Oh, cool. I think the old one was hard coded to LGPL 2, and not LGPL 2 or later…
A MIT license is definitely easier to work with…