Screens provides a size which is constructed from the size of
the bounding geometry of all screens and provides an overload taking
an int to return the size of a specified screen. For geometry() a new
ovload is added without an argument, which is just a convenient wrapper
for QRect(QPoint(0, 0), size()).
Both new methods are exported to effects and scripting as new
properties there called virtualScreenSize and virtualScreenGeometry.
The (virtual) size gets cached in screens and is updated whenever the
count or geometry changes.
Construction of Screens is slightly changed by moving the init code
from ctor into a virtual method init(). Reason is that we ended in
a loop with accessing the singleton pointer before it was set.
REVIEW: 116114
* this effect is way cheaper than blur, don't cache it
* use its own atom
* also pass the matrix in the x property
* remove remnants of the cache
* do just a single pass
* get rid of config ui remnants
This was not yet ported functionality. In addition the usage of
KActionCollection is removed as it's not needed - all it was used
for is setting the object name.
A declarative KWin script needs to register the QQuickWindows it is
using in the KWin object. This method ensures that the QQuickWindow
will destroy the platfrom window once it gets hidden. So the next
time the QQuickWindow is shown a new platform window is created.
As can be seen in the OSD this is not really nice, therefore a
KWin.Dialog should be created which takes care of these steps.
The DBusCall is exported as a QObject to the QML environment. It is
intended as a declarative replacement for the callDBus method which used
to be exported on global scope in the QtQuick 1 world.
Example usage:
DBusCall {
id: dbus
service: "org.kde.KWin"
path: "/KWin"
method: "setCurrentDesktop"
arguments: [1]
Component.onCompleted: dbus.call()
}
Getting all functionality from old solution into new one is not really
possible. Main problems are that QtScript provided more functionality
than the QJSEngine. For example it's no longer possible to just export
functions to the engine. We need to have a Qt wrapper object. At the
moment this wrapper object doesn't export all functions as the callbacks
are tricky. A solution might be to create specific QML types
encapsulating functionality which used to be exported on the functions.
Nevertheless a basic QML script loads and works and the ported readConfig
function works, too.
AbstractThumbnailItem inherits from QQuickPaintedItem using QPainter to
do the fallback painting of icons.
The scene is adjusted to get the information from QQuickItem instead of
QDeclarativeItem. Clipping got a little bit more complex as the clip
path does not exist any more. To get it right the ThumbnailItem needs to
specify the parent it wants to be clipped to with the clipTo property.
E.g.:
clipTo: listView
The scene uses this clipTo parent item to correctly calculate the clip
region. Also the ThumbnailItem needs to have clipping enabled.
Note: this commit currently breaks TabBox as the qml and view are not
yet adjusted. In scripting the export of the item is disabled, but any
qml script using a ThumbnailItem would obviously also fail.
Not sure why kdeclarative gets its own subdir, nor why
there is no CMake module to to add it to the include dirs
on find_package, but this matches what plasma-framework
does at the moment.
* "" needs to be wrapped in QStringLiteral
* QString::fromUtf8 needed for const char* and QByteArray
* QByteArray::constData() needed to get to the const char*
Let KDeclarative::setupBindings() add the import paths: it too takes
paths from KGlobal::dirs()->findDirs("module", "imports"); it adds paths
in the correct (reverse) order [1].
[1] See kdelibs 400b9f2e9d10386bb175b6123fe0cdaafeaffe61 for further
details.
REVIEW: 110670
When the scripting KCM triggered a loading of a script it did not work
because the scripting code was operating on an old data set.
Reparsing the configuration before evaluating which scripts to (un)load
solves this problem.
Cherry-picked from 4.10 branch: dd5b4bdec8e24359d4715c078e2f442967a3f873
CCBUG: 319767
When the scripting KCM triggered a loading of a script it did not work
because the scripting code was operating on an old data set.
Reparsing the configuration before evaluating which scripts to (un)load
solves this problem.
REVIEW: 110357
BUG: 319767
FIXED-IN: 4.10.4
The view is never shown or used in any way except to create the
QDeclarativeEngine. So instead of using a view as a wrapper, let's create
a QDeclarativeEngine and a Component and create the script from the
Component.
To have Plasma.Dialog working we also need to add the created script item
to a QGraphicsScene.
Following the approaches of other split out functionality Screens is a
singleton class created by Workspace.
The class takes over the responsibility for:
* screenChanged signal delayed by timer
* number of screens
* geometry of given screen
* active screen
* config option for active screen follows mouse
The class contains a small abstraction layer and has a concrete subclass
wrapping around QDesktopWidget, but the idea is to go more low level and
interact with XRandR directly to get more detailed information.
All over KWin the usage from QDesktopWidget is ported over to the new
Screens class.
REVIEW: 109839
All activities related code moves into new singleton class Activities.
This class gets only included into the build if the build option is
enabled which means there are less ifdefs all over the code and it also
handles better the moc doesn't like ifdef case.
The class holds the list of open and all activites, the current and the
previous activity and the KActivities::Controller. It also emits the
signals for any activities related changes.
Workspace still contains some activities related code. That is the
adjustment on change of current activity. Nevertheless the code looks
much cleaner now and does not contain the confusing naming conflict with
takeActivity() which existed before.
In all the places where Activities got used the code got adjusted and
quite often the ifdef got added with a fallback for the disabled case.
A new ClientModel is added which provides multiple different views on
KWin's Clients. The model is organized as a tree model supporting the
following levels:
* activities
* virtual desktops
* screens
* none
The levels can be ordered in whatever way one wants. That is the tree
structure can have an ordering of activities then virtual desktops or
the other way around.
In addition the model provides Exclusion flags to exclude clients of
certain types. E.g. it's possible to exclude all windows which are not on
the current desktop or all windows which are of type dock.
The model gets automatically updated whenever a Client is added/removed
or changes a state in a way that it should be excluded/included.
The ClientModel is not directly exported to QML. Instead there are
specific sub classes for certain common orderings. This solutions is
chosen to workaround some limitations of QML. The initial idea was to
use a property taking a list of the levels, but this doesn't work because
we are not notified when the QDeclarativeListProperty changes.
Currently the following models are provided to QML:
* ClientModel -> no restrictions
* ClientModelByScreen -> ordering by screen
* ClientModelByScreenAndDesktop -> screen, then desktop
These can be used to get all Clients:
ClientModel {
}
Or to get the classic Present Windows on current desktop:
ClientModelByScreen {
exclusions: ClientModel.OtherDesktopsExclusion | ClientModel.NotAcceptingFocusExclusion | ...
}
Or to get the classic Present Windows on all desktops:
ClientModelByScreen {
exclusions: ClientModel.NotAcceptingFocusExclusion | ...
}
Or our well known desktop grid:
ClientModelByScreenAndDesktop {
id: desktopGrid
exclusions: ClientModel.NotAcceptingFocusExclusion | ...
}
To support filtering as known by the Present Windows effect one can use
a ClientFilterModel, which is a QSortFilterProxyModel filtering on
window caption, role and class:
ClientFilterModel {
id: filterModel
clientModel: desktopGrid
filter: filterItem.text
}
In case it's a tree level obviously QML does not support this correctly.
So we need to use a VisualDataModel:
VisualDataModel {
id: clientModel
model: filterModel
Component.onCompleted: {
clientModel.rootIndex = modelIndex(0);
clientModel.rootIndex = modelIndex(0);
clientModel.delegate = thumbnailDelegate;
}
}
As we can see, the rootIndex has to be set to the level which contains
the Clients. Also it seems to be important to create the delegate after
the model index has been set. The idea is to have only one ClientModel
and multiple VisualDataModels if multiple views on the data is needed.
The model has been tested with a painful modeltest session. It looks good
so far modulo the listed limitations and that modeltest is not liking
closing Yakuake in the ClientModelByScreenAndDesktop setup, though it
works fine in real world testing.
REVIEW: 109604
Also harmonize script parsing - any combination of animationarray
and global animation setting that results in a valid animation is
possible using the global settings as default on the array values
REVIEW: 109212
Messages in scripts are written to kwin_scripts.pot, messages in
scripting are written to kwin_scripting.pot. The cataloges are loaded in
the configuration interfaces and in main kwin.
REVIEW: 108975
A scripted component providing:
* ui/config.ui
* config/main.xml
can get a config interface by using the following in metadata.desktop:
X-KDE-ServiceTypes=KWin/Effect,KCModule
X-KDE-PluginKeyword=`X-KDE-PluginInfo-Name`
X-KDE-Library=kcm_kwin4_genericscripted
X-KDE-ParentComponents=`X-KDE-PluginInfo-Name`
`X-KDE-PluginInfo-Name` has to be replaced by the actual value. In case
of a KWin Script the X-KDE-ServiceTypes needs to be:
X-KDE-ServiceTypes=KWin/Script,KCModule
The GenericScriptedConfig tries to identify the package from the keyword
and creates a Plasma::ConfigLoader and loads the UI from the packaged UI
file.
Since the introduction of VirtualDesktopManager we do have a signal
emitted when the desktop layout changes which we can use as NOTIFY for
the desktopGrid properties.
REVIEW: 108953
In fact it already used to be a Singleton as there is just one object
hold by the Singleton Workspace. So let's make it a proper Singleton
following our kind of standard approach of having a ::create factory
method called from Workspace ctor and a ::self to get to the singleton
instance.
The main difference is that the activation of an edge is no longer
broadcasted to all effects and scripts, but instead a passed in slot of
the Effect/Script is invoked.
For this the EffectsHandler API is changed to take the Effect as an
argument to (un)reserveElectricBorder. As callback slot the existing
borderActivated is used.
In addition the ScreenEdge monitors the object for beeing destroyed and
unregisters the the edge automatically. This removes the need from the
Effect to call unregister in the dtor.
BUG: 309695
FIXED-IN: 4.11
This rewrite is mostly motivated by the need to handle multi screen
setups correctly. That is have edges per screen and not for the combined
geometry. Also porting from XLib to XCB has been a motivation for the
rewrite.
The design of the new ScreenEdge handling is described in the
documentation of ScreenEdges in screenedge.h.
In addition the following changes have been performed:
* move configuration from Options to ScreenEdge
* add screen edge information to Workspace::supportInformation (obviously
replaces what had been read from Options)
* have Workspace hold a pointer to ScreenEdges instead of an object
* forward declaration of ScreenEdges in workspaces.h, this explains the
seemingly unrelated changes of just another include in some files
BUG: 290887
FIXED-IN: 4.11
The ownership for virtual desktops is moved from Workspace into a new
VirtualDesktopManager. The manager is responsible for providing the count
of virtual desktops and keeping track of the currently used virtual
desktop.
All methods related to moving between desktops are also moved from
Workspace to the new manager, though all methods related to Clients on
Virtual Desktops remain in Workspace for the time being. This is to have
the new manager as independent from KWin core as possible.
An rather important change for the handling of virtual desktops is that
the count and the id of a desktop is now an unsinged integer instead of
an integer. The reason for that is that we cannot have a negative count
of desktops as well as it is not possible to be on a desktop with a
negative identifier.
In that regard it is important to remember that a Client can be on a
desktop with a negative identifier. The special value for a Client being
on all desktops is handled by using -1 as a desktop. For the time being
this is not adjusted but instead of comparing the virtual desktop ids one
should prefer to use the convenient methods like isOnDesktop and
isOnAllDesktops. This would allow in future to internally change the
representation for on all desktops.
The current API call to animate a window does not feel very JavaScripty.
Therefore a new method "animate" is added to the global scope, which
takes a JavaScript object of the following structure:
{
window: EffectWindow, /* the window to animate, required */
duration: int, /* duration in msec, required */
curve: QEasingCurve.Type, /* global easing curve, optional */
type: Effect.Attribute, /* for first animation, optional */
from: FPx2, /* for first animation, optional */
to: FPx2, /* for first animation, optional */
delay: int, /* for first animation, optional */
animations: [ /* additional animations, optional */
{
curve: QEasingCurve.Type, /* overrides global */
type: Effect.Attribute,
from: FPx2,
to: FPx2,
delay: int
}
]
}
At least one animation needs to be specified either on the root level
or in the array of animations. Curve is the only property on root level
which is used in the animations, if not provided.
REVIEW: 107079
A script can register a callback through registerUserActionsMenu to be
informed when the UserActionsMenu is about to be shown. This menu calls
the Scripting component to gather actions to add to a Scripts submenu.
The Scripting component now asks all scripts for the actions, which will
invoke the registered callbacks with the Client for which the menu is to
be shown as argument.
The callback is supposed to return a JSON structure describing how the
menu should look like. The returned object can either be a menu item or
a complete menu. If multiple menu items or menus are supposed to be added
by the script it should just register multiple callbacks.
The structure for an item looks like the following:
{
text: "My caption",
checkable: true,
checked: false,
triggered: function (action) {
print("The triggered action as parameter");
}
}
The structure for a complete menu looks quite similar:
{
text: "My menu caption",
items: [
{...}, {...} // items as described above
]
}
The C++ part of the script parses the returned object and generates
either QAction or QMenu from it. All objects become children of the
scripts QMenu provided by the UserActionsMenu.
Before the menu is shown again the existing menu is deleted to ensure
that no outdated values from no longer existing scripts are around. This
means the scripts are queried each time the menu is shown.
FEATURE: 303756
FIXED-IN: 4.10
REVIEW: 106285
