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 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel