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. _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
