Summary:
when plasma is starting up, there are no panel views yet
this means that if a thickness (or other values)
are written to the config file and then the resolution changes before
the panel view gets created, we'll have a view that will default
to 30 pixels regardless what the layout js file specified.
This makes the scripting only write to a [Default] group for resolution
dependent properties when panels are not actually present
when they are already there, interact directly with the view which is
the safest option.
the view will use whatever is in the defaults group as default if the
resolution dependent is there, and when a new value is set for a
resolution dependent one, also update the default, which will
be used when screen resolution changes, as new default value
Test Plan:
* With virtualbox, change resolution continuously when plasma is starting up
with an empty setup, panel is the expected size now, as opposed to 30
* Stop Plasma. Change Screen resoluton with plasma *not* running, to a resoluton
still "unknown" to plasmashellrc, then start plasma again. Now the thickness saved
in [Default] is picked, instead of the arbitrary 30
Reviewers: #plasma, broulik
Reviewed By: #plasma, broulik
Subscribers: apol, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D22893
Summary:
Port plasma desktop scripting to qjsengine, removing every trace of QScript from plasma-workspace.
The scripting is 100% API compatible.
the bindings are partly done on the javascript part as some things are only possible there and not on the QJSEngine part:
* setting AppInterface as the globalobject's __proto__ with property getters that are evaluated every time
* setting functions that act as constructors (using newQMetaObject gives way more complex and uglier c++ code in Containment, as the scriptengine is not immediately accessible)
* a QRectF wrapper which exposes all properties and methods that were exposed in the previous implementation
Test Plan:
* some manual api test from the interactive console
* tested both from the desktop console and first start with some pretty complex layouts from lnf packages (the default one, netrunner, united, elpas)
* tested every property/methos of the qrectf wrapper
Reviewers: #plasma, davidedmundson
Reviewed By: #plasma, davidedmundson
Subscribers: davidedmundson, plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D13112
the api containment.name was incorrect and broken,
(using it it actually breaks the whole layout since
breaks the containment->activity association)
in order to make it coherent with the other activity
related api, add global functions activityName
and setActivityName
it's not very object oriented but is coherent with
the other api already in place
(as there isn't an "Activity" class binding)
The basic design of Plasma is that scripts and and the shell (in theory)
manipulate a tree of basic applet geometry and configs.
Plasmashell then reacts to those changes and displays them visually with
a distinct separation between the layout and UI.
Panel's scriptengine seemed to do away with all, and try and manipulate
the graphic object directly..which might not exist and that leads to
complex code.
This changes it to read/write from the same config object as
PanelView will use. More akin to how the script engine for applet and
contiainment works.
If there's a view for this panel, we update immediately, otherwise it'll
just get loaded when it's needed. PanelView::reload() has the error
checking/bounds management so no point duplicating that.
BUG: 355918
REVIEW: 125921
Alexander Lohnau
Adrien Faveraux
Marco Martin
Friedrich W. H. Kossebau
Laurent Montel
Aleix Pol
David Edmundson
Eike Hein