Shortcuts (WAS: [Development] api changes)

[Rick Stockton]

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 
> <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
>
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.