Not much idea about the context, but
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
<rickstock...@reno-computerhelp.com>:
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