Looking around and thinking ahead

[Aaron J. Seigo]

On Thursday, December 12, 2013 13:33:38 Sebastian Kügler wrote:
> The plasmoid object collates what we present as public API, and the QML
> tricks, so maybe put a skeleton API class in libplasma, and derive from that
> in the scriptengine (and putting the QML specific bits in there). This

just so i know we’re talking about the same thing ... you mean the 
AppletInterface class?

if so .. the uglyness there is that both QtQuickItem and Plasma::Applet are 
QObjects, so they can’t be synthesized into one class by MI.

that said ... it shouldn’t be necessary.

taking a look at what is there now, it is quite clear that the class should be 
refactored out.

many of the methods simply proxy to Plasma::Applet as it is; so my suggestion 
would be to import Plasma::Applet *as* plasmoid into the runtime.

that still leaves us with a large number of methods to reshuffle. suggestions:

a number of methods which have become purely business logic (easily seen as 
they are POD properties) were moved out of Plasma::Applet. they should be 
returned to Plasma::Applet. these include:

* isBusy
* backgroundHints
* file (use the package)
* scripting API version (which would get it from the AppletScript object)

others should probably be moved elswhere, e.g. to DeclarativeAppletScript 
itself, such as:

* compactRepresentationCheck
* updatePopupSize
* expanded
*  bool fillWidth() const;
*  bool fillHeight() const;
 * qreal minimumWidth() const;
 * qreal minimumHeight() const;
 * qreal maximumWidth() const;
 * qreal maximumHeight() const;
 * qreal implicitWidth() const;
 * qreal implicitHeight() const;

most of these simply query the root QML object from the plasmoid and are read-
only. 

the geometry methods are probably the most difficult: these seem to be there 
specifically for containments and dialogs. or is there some other purpose to 
them?

assuming they are there primarily for containments and dialogs, i assume these 
already have access to the root qml objects? the only trick is whether to use 
the compact representation or the root item itself, and one would hope that 
this would be made simple: the dialog should know what item is in it, the 
containment should also.

i fail to see why these continue to exist at all rather than using the 
properties directly from QML.

some methods are deprecated:
* hideOnWindowDeactivate (Dialog handles this now)

this leaves us with two issues:

Actions API: this API *sucks*. it was there to make it as easy as possible to 
make simple additions to the context menu from javascript. it is not very 
declarative at all, however. it would be far nicer to have an actual 
AppletContextMenu QML item imho  and then just drop this API.

Configuration read/write: similarly, the read/write config object API should 
probably die, die die. it is also not very declarative, and we have a 
declarative replacement for it already from Plasma Active that Sebas wrote. 

yes, this means some 

in summary:

* actions and config API axed
* get rid of unused / deprecated API
* move some business logic methods back into Plasma::Applet
* move the rest of it into DeclarativeAppletScript

thoughts? problems?

-- 
Aaron J. Seigo