On 12-07-18 07:38 PM, Andrej N. Gritsenko wrote: > Hello! > > Stephan Sokolow has written on Wednesday, 18 July, at 18:40: >> For portability's sake, I write all my apps to bind their own global >> hotkeys using XGrabKey(). (Which means all my PyGTK apps also depend on >> python-xlib or XPyB and, on Windows, fall back to not supporting global >> hotkeys) > > Well, it's low-level grab and may conflict with Gtk+/Qt/etc. event > handlers and also the application should make own event handler to work > with this. So it's not solution for application using some toolkit.
I'm not sure I understand. What other way WOULD you implement a global hotkey aside from adding in the "enable/disable all global hotkeys" binding that KDE's hotkey daemon offers? The whole point of a global hotkey is that it fires no matter which window has focus. (And I use XGrabKey to make my volume-control keys function while inside games that would otherwise exclusively grab the entire keyboard) > >> It would be nice to see a unified keybinding daemon to complement the >> unified notification daemon but, until there's a >> freedesktop.org-standard D-Bus API that lets a single hotkey daemon be >> shared between KDE, GNOME, Xfce, and LXDE apps, I just don't see this >> idea being anything more than yet another DE-specific process wasting >> resources. > > I never proposed this to be process. I proposed it to be very small > library which implements access to files, parsing and update, one time > operation. If you change keybinding with some editor it will alert you it > will be applied only on application new start, not on running one. Just > so simple. We also can discuss some method of signaling if we want the > applications refresh own maps in runtime but I highly doubt it should be > done as it will require recreate of many of application's widgets and > that is much resource consuming so better just restart the application. > So... you're not really talking about "global hotkeys" but rather "unified and/or standardized configuration of application-specific hotkeys"? I'm not sure I'd want the complexity UNIFIED keybinding stuff would bring (Just getting people to agree on where to store the keybindings could be a fight and I never saw the point to throwing the keybindings for every application on the system together into one confusing control panel). However, I'd definitely like to see a keybinding library that makes it easy to add a standard "edit keybindings" dialog to any GTK+ app, independent of which desktop you're using. I'd envision such a library having at least two parts: First, some kind of KeybindingManager which abstracts away the binding of keys and the serialization and deserialization of action-hotkey mappings. In my eyes, such a thing would center around a method which takes an ID, a human-readable title, a default keybind, a callback, and an optional set of widgets to act as a scope. (With the ability to add widgets to a given ID as they're created). Second, a standardized compound widget for editing keybindings, a dialog which wraps it, possibly a widget for viewing and editing a single keybind (a la GtkFileChooserDialog, GtkFileChooserWidget, and GtkFileChooserButton), and a new stock icon and pre-translated "edit keyboard shortcuts" title suitable for adding to menus. Third, a Vala .vapi and some GObject Introspection definitions so language wrappers like PyGI can use it, to provide the highest return on investment to get other developers using it quickly. If those two things were offered, I'd definitely use it in my own apps. As is, I tend to just limit my non-global keybindings to the built-in Alt+Accelerator support for widgets. >> ...especially given that Openbox can already do global hotkey binding >> for functions that don't map directly to a KDE, GNOME, or XGrabKey-using >> application. > > The trick is you cannot map the shortcut into lxde if it's already > mapped by Openbox since Openbox's binding will be activated once you try > to press the combination in the editor. :) > > And, please, don't do topposting! I understand, you like to see own > text but let others see the text you're replying too. Thanks! > This sort of top-post vs. bottom-post thing is one of the lesser reasons I usually avoid mailing lists. (The main one is that most of them aren't bridged to NNTP via GMane and it's too much hassle to manage mailing lists in Thunderbird) They just provide too messy and inefficient a user experience when combined with the tools available to me and I've got far too many more personally-relevant things on my plate. (Now, if we could get all the NNTP clients collapsing quoted text by default (the way GMail does) or auto-scrolling to the first un-quoted block of text, then bottom-posting would be unarguably be superior) > Andriy. > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ------------------------------------------------------------------------------ Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ _______________________________________________ Lxde-list mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/lxde-list
