Shortcuts (WAS: api changes)

[Rick Stockton]

The main text of my reply is at the bottom ...

On 04/16/2012 05:15 AM, Michael Jansen wrote:
> On Sunday, April 15, 2012 08:40:38 PM Thiago Macieira wrote:
>> On segunda-feira, 16 de abril de 2012 01.33.31, Stephen Kelly wrote:
>>>> The only applications that should do that are the workspace fixture
>>>> ones:
>>>> kwin and plasma.
>>> Yes, those are the ones that were brought up, together with the
>>> KWindowSystem class. Apart from those I don't think KDE uses X11, but even
>>> KWindowSystem might be partially obsoleted by QPA (there is a task to
>>> figure that out, but no one has taken it up yet).
>> Managing windows is a task only for the workspace applications. Putting
>> those classes in a generic library is a mistake.

I disagree. Things such as "Window Position", Size, and the need to Move 
a Window (to expose a UI keyboard) may also be fundamental for 
Applications on Handheld Platforms (as being described in another 
Thread). Keep it simple - that particular application needs to avoid 
COMPLETELY hiding it's  virtual keyboard, the requirement is 
straightforward - so let's provide the Application-Level tools to do so 
where we can. Where we can't, do it, note that in Doco (As GTK/Gnome has 
done.) GTK seems to agree with me; all of these items ARE available in 
the GtkWindow interface:

http://developer.gnome.org/gtk3/3.4/GtkWindow.html#gtk-window-get-position
http://developer.gnome.org/gtk3/3.4/GtkWindow.html#gtk-window-get-size
http://developer.gnome.org/gtk3/3.4/GtkWindow.html#gtk-window-move
http://developer.gnome.org/gtk3/3.4/GtkWindow.html#gtk-window-get-screen
and their corresponding setters, and a lot of other GtkWindow() 
functions in 3.4.

I noticed, however, that the Gnome/Gtk people have a lot of complaints 
about DPI. Apparently, the value which QX11Info provides isn't 
trustworthy for screens with sizes other than 96 DPI. I wish that I had 
a monitor with more than 96 DPI, but I don't.... so I can't see any 
problems relating to this value.

>>
>>> QX11Info is used in many places (including some widgets), and perhaps some
>>> places where it shouldn't be used, but it's still a porting burden even to
>>> figure out how to port the stuff (It's not clear to me how to, and the
>>> changes file doesn't even note that the class is removed).
>>>
>>> kf5{frameworks}$ grep -roh "QX11Info::[^\)]*)" * | sort | uniq
>>> QX11Info::appDpiX( int )
>>> QX11Info::appDpiY( int )
>>> QX11Info::appRootWindow()
>>> QX11Info::appRootWindow( screen_P )
>>> QX11Info::appScreen()
>>> QX11Info::appTime()
>>> QX11Info::appUserTime()
>>> QX11Info::display()
>>> QX11Info::screen()
>>> QX11Info::setAppDpiX(0, 96)
>>> QX11Info::setAppDpiY(0, 96)
>>> QX11Info::setAppTime(time)
>>> QX11Info::setAppTime(timestamp)
>>> QX11Info::setAppUserTime(time)
>>> QX11Info::setAppUserTime(timestamp)
>> Porting required for some of them, others need refactoring.
> I have one thing to add where we probably need some support from the qt
> project to do it correctly. Global Shortcuts.
>
> Since Qt does not support them we have to implement them ourselves. Which
> means working with X11 KeyCodes. Because there are no exporteded Qt Functions
> that map between X11 KeyCodes and Qt KeyCodes we had to implement the mapping
> ourselves (KKeyServer iirc) but failed to do that correctly because the code
> in question is complex. A source of many kde bugs.
>
> All that descibes Qt4. No idea what changed in Qt5.
> But such function or some Qt support for global shortcuts would help us.
>
> The same applies afaik for the mac. No idea about windows.
I would be delighted to help with the job of pushing KDE 'Golbal 
Shortcuts' Upstream (into a 'Global Shortcuts' property manager within 
Qt). Rather than figure out keyboard layout issues twice (once in Qt for 
"normal input" and Qt's limited shortcuts, a SECOND TIME in KDE for 
Global Shortcuts), do it all in Qt. As you know, Qt already has some 
default keyboard shortcuts values. (Intra-program, loaded for each 
program which includes the relevant headers.) But, for KDE's purposes, 
this would need to be extended: Many 'Global Shortcuts' should be pushed 
up to the Window Manager immediately, and the shortcuts need to be read 
from some sort of properties file, rather than C++ headers.

We should, I think, provide shortcuts, (KWin Global, Intra-Application 
"Global", and "Application-Specific") for mouse gestures and all those 
new mouse buttons. (KDE has an all-time-top-10-voted-for Bug on this, 
IIRC). And a simple, coherent shortcut-override system should be in 
place for any/all of those input devices. But I need some leaders... I'm 
pretty useless as a designer or programmer.