Re: [Lxde-list] Global keyboard shortcuts in LXDE.

[Stephan S. <gma...@sp...>]

On 12-07-18 09:25 PM, Andrej N. Gritsenko wrote:
>      It seems I said it bad so was misunderstood. Sorry. I meant not
> global shortcuts for global operations but rather global configuration
> of shortcuts for applications, such as 'Copy', 'Paste', 'Reload', etc.
> Instead of hardcoding them or having some own configurator in every
> application - to have them configurable by common tool. You know, KDE
> hotkeys editor also has different tabs for that - one for globals and yet
> one for applications. But still it's in one tool for all applications.
> And I'm talking about that, not global hotkeys.
>

I never liked KDE's unified application hotkey editor. The global part 
was good for rebinding keys that were already in use, but the 
application-specific portion never really did anything I found useful.

It felt like one more piece of clutter in an already very busy control 
panel and it was much more comfortable and intuitive to go to "Settings 
 > Configure Shortcuts..." in the individual applications.

>
>> 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.
>
>      Ouch, that's a lot really. But most of that could be simplified just
> knowing gtk_accelerator_parse() accepts char * so the config can be in
> plain text with keys defined as (for example) "hideall=<Ctrl>h,<Alt>F12"
> and library will just parse and fill caller's array with such texts which
> will be eaten by gtk_action_group_add_actions(). I think the Qt has some
> similar methods too. And I think of that library as something very simple
> not bound to Gtk, Qt, or whatever at all. And of course, it is possible
> to write a Gtk+ widget over it which will implement what you've described
> above.
>      And anyway I've asked not about implementation yet but about the
> idea to have configured it in common tool. But I cannot see if you like
> it or not. From what I see you want still each application to have own
> keybindings? And if I want to set 'fullscreen' key to be F12, I have to
> set it in each application if that application decided to implement the
> dialog and is written with Gtk+ support, right? And those that aren't
> will have it hardcoded still... I don't see much reasons why I would use
> it, may be only to correct too different bindings which some application
> might have but it's rather rarely and as developer I don't see much of
> advantage but I rather would prefer the KDE way where I set it in some
> keybinding editor once and for all applications.
>

As I said above, I think a common tool would be worse than settings in 
the individual applications.

Specifically, because it would be harder to find if you don't know where 
to look (We already know how to look for "settings" in an application) 
and lumping all the keybindings for the entire system together in one 
place just makes it harder to find what you're looking for. (At least, 
that was my experience with KDE's unified keybinding control panel)

Even ignoring that, I'm not sure you understand how hard that would be 
to implement and maintain. (It would be harder than making Qt, GTK+, and 
Tk share the same theming engine in a mature, flexible, widely-adopted 
manner and nobody has successfully done THAT yet.)

You'd have to agree on a standardized set of action names, get every 
single LXDE application to use them, and make sure that, as new keybinds 
are added, people don't use the old, more ordinary ways to bind keys.

...and that's assuming you just want to standardize the ability to 
override things like Ctrl+X/C/V in LXDE only. Other desktop environments 
are a whole new kettle of fish.

KDE 2.x introduced a simple, powerful desktop message bus named DCOP and 
it took until KDE 4 and a complete rewrite of DCOP in C under the name 
D-Bus just to get GNOME to use it. (GNOME and KDE generally keep their 
technology separate because KDE devs think GNOME tech is shoddy and 
GNOME devs think KDE tech is too infested with C++ and too cluttered 
with configuration toggles)

Unity and GNOME Shell both exist because GNOME developers tend to have a 
"my way or the highway" attitude and stubbornly refused to consider 
Unity's design until after it was already written.

Heck, even if you do get agreement from people, you still have to deal 
with lack of manpower.

The Trinity desktop environment (a KDE 3.5 fork) still doesn't seem to 
comply with the XDG icon naming spec and STILL shows an empty KControl 
window if you install it alongside KDE 4.

I don't think even KDE has what you think you're asking for.

F11 is a unified keybinding for "Fullscreen" in KDE because it's 
implemented once in the KWin window manager, not because it's a single 
unified keybinding that applies to multiple applications.

(It works because "fullscreen" is a Window manager state like 
"maximized" that applications like Firefox can ask for, listen for, and 
react to.)

You can get the same effect under Openbox by adding something like this 
to the config:

<keybind key="F12">
   <action name="ToggleFullscreen"/>
</keybind>

>      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/
>