Shortcuts (WAS: [Development] api changes)

Rick Stockton rickstockton at
Mon Apr 16 23:00:39 BST 2012

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

More information about the kde-core-devel mailing list