On 04/16/2012 01:53 PM, Thomas Lübking wrote:
Not much idea about the context, but
Context was handheld- where Qt wants to be capable.
Managing windows is a task only for the workspace applications.
Putting
those classes in a generic library is a mistake.
Am 16.04.2012, 21:25 Uhr, schrieb Rick Stockton
<[email protected]>:
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 ...
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-move
The function does NOT allow to move a window directly but asks the WM
to do so.
Everything else is highly error prone because the client will usually
not know about the context (eg. pa. handhelds will often have
fullscreen WM, but you also maybe in a tiling environment or the
window is in a particular state that "forbids" being moveResized) or
maybe fail on the condition (user currently moves windows around)
application needs to avoid COMPLETELY hiding it's virtual keyboard
ideally such would be achieved by a hint on the window (eg. the type,
keep_above state) or using struts instead of managing the window by
the client - i guess this discussion pointed wayland but eg. at least
on X11 you easily get yourself into trouble if your start playing on
the stacking order against the WM (therefore there's a restack request
as well, and kwin even supports it since about ... some rather short
time ;-)
Cheers,
Thomas
I know that such a request is only "an optional suggestion" to the WM.
Now, looking ahead: Do we want KWin (and maybe PLasma, as well) to
continue "skip layers", going directly to xcb or wayland (or ??) in the
same way we currently do a lot of X11 queries and commands directly? If
so, then, I'll be less concerned about the API which Qt 5.x provides for
KDE use.
