The frameId only makes sense for a Client, in case of Unmanaged the
same window id is used as for the window() handle. Client creates the
frame and destroys it.
Given that it makes sense to let Client manage the frame properly.
The ::frameId() is therefore virtual and as base implementation it
returns the client id. Client reimplements it and returns the proper
frame id.
Method is also implemented in Deleted as it used to be passed to
deleted.
We have windows which we don't want to destroy (e.g. the managed
clients) but still would like to be able to use the nicer API.
Therefore the not creating ctor and reset method have a second bool
arg to whether destroy the window or not. Default is to keep the
RAII functionality.
There used to be an own action collection in KDE 3 times for the
block global shortcuts shortcut. But the code ws disabled and by
that I didn't see it during removing the global shortcuts blocking.
And it explains why the global shortcut blocking didn't work.
Method replaces the logic of the macros. The macros are still there
to not need to change all the code. Major difference is that the new
method uses the compile time checked connect syntax.
KSessionManager is deprecated and there is no replacement yet. So
let's get rid of the warnings for now. Needs to be re-added once
there is a working QSessionManager again.
All the globalShortcutChanged slots are removed and replaced by a
generic one for the new signal by KGlobalAccel.
The define for creating the shortcut is dropped and replaced by a
templated function creating connections through the new connect
syntax.
Used to include quite a bit no longer needed. In order to get rid of
the utils.h inclusion one enum is moved to options (where it actually
belongs to).
When a window is added while the effect is running
it shall either be highlighted or hidden, but not exit
the effect what happened, because the property notification
is invoked to test whether the window has a highlight
property (questionable since the effect is running, but
valid - could be different X11 client) and that routine
exits the effect if no property is found (assuming it was
withdrawn)
REVIEW: 112494
Because that's where it's placed. Notable esp. when there're panels on opposing sides.
Since snapping keeps max'd windows in position, it should preferably keep it in the proper position ;-)
REVIEW: 112322