AppletScript & configAccepted

[Aaron J. Seigo]

On Thursday 11 September 2008, Petri Damstén wrote:
> On Thursday 11 September 2008 17:47:27 Aaron J. Seigo wrote:
> > there is a configChanged() signal from KCoreConfigSkeleton as well; we
> > might be able to use that. it gets emitted when writeConfig() is
> > called... soooo ... we could do sth like:
> >
> > * connect d->configXml configChanged to a configChanged signal (or slot?)
> > * create dialog using d->configXml
> > * writeConfig gets called by the dialog (for free) and that triggers
> > things
>
> I'll write a patch based on this and test it with html applet.
>
> > Petri, since you're working on an html based applet, would you mind
> > coming up with an example patch to the webkit appletscript engine that
> > would work for you as a consumer of that api?
>
> Diff attached is very much work in progress, but it's a start. At least I
> would like to do something to following issues:

+WebAppletPackage::WebAppletPackage(QObject *parent, QVariantList args)
+: Plasma::PackageStructure(parent, "Web")
+{
+    Q_UNUSED(args)
+    addFileDefinition("webpage", "html/index.html", i18n("Main Html"));
+    setRequired("webpage", true);
+    addFileDefinition("mainconfigui", "ui/config.ui", i18n("Config user 
interface"));
+    addFileDefinition("mainconfigxml", "config/config.kcfg", i18n("Config xml 
definition"));
+    addFileDefinition("screenshot", "screenshot.png", i18n("Screenshot"));
+}

personally, to keep the proper semantics in place for UI, config, etc, i'd do 
something like:

// copy the main applet structure
(*this) = Applet::packageStructure(); 

// now add our own stuff
addFileDefinition("webpage", "html/index.html", i18n("Main Html"));


*that* said ... what's wrong with simply having code/main the same as 
html/index.html, and stuffing the rest of the html files into code/?


-K_EXPORT_PLASMA_APPLETSCRIPTENGINE(webapplet, WebApplet)
+K_EXPORT_PLASMA_APPLETSCRIPTENGINE(webkit, PlasmaWebApplet)

if we're going to do this, then we really all the Plasma specific methods 
should be moved to PlasmaWebApplet, e.g. dataUpdated, dataFor, configAccepted..

why are you managing the engines yourself instead of letting the Applet* you 
are given do that for you? that's a lot of duplicated code that's unecessary.

the direction is good, though.

> - css from plasma theme colors (Or could plasma theme have some default
> stylesheet, that would benefit news applet too)?

that could be a nice idea, yes.. a whole other realm of exploration though, as 
we'd then have to define set CSS entries.

> - Background does not work currently.

... define?

> - more applet functions (setBackgroundHints, resize, etc.)

into the JS API you mean?

> - Is it ok that dashboard widgets get all the plasma functionality too? Or
> should this be a separate scriptengine.

which plasma functionality, exactly? it could only be things we do 
automatically, as the Dashboard widgets will not see any adjustments to their 
API (they are not coded for plasma =)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Trolltech

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20080911/c01302c7/attachment.sig