Shortcuts (WAS: [Development] api changes)
Thomas Lübking
thomas.luebking at gmail.com
Mon Apr 16 21:53:09 BST 2012
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
<rickstockton at 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
More information about the kde-core-devel
mailing list