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.
