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