With the advent of Plasma shell scripting, a rather large implementation hole in our widgets started showing through: almost none of them were able to react to external configuration changes. That means that when altering a widget via a script, configuration changes simply wouldn't be picked up.
We scampered through the most fundamental ones for the 4.4 and 4.5 releases, but in 4.6 we have committed to all of the widgets we ship being re-configurable via scripting. We're actually almost done, thanks to efforts by people such as Ann-Marie (KDE Edut and Plasma Picture Frame fame) and Anthony Bryant (a relative new-comer to the Plasma scene). It's been a relatively easy grind, actually, perfect for even newer developers because all the widgets needed to do was implement the configChanged() slot.
The rule is simple: in configChanged() (a public virtual Q_SLOT), all config values should be read. The common practice is to therefore call configChangd() from the widget's init() method. When the configuration interface is shown, it is also automatically called. This happens after anything that is connected to the configuration dialog in the widget's createConfigurationInterface method, which means that the widgets now have one slot connected to the configuration dialog's applyClicked() and okClicked() signals that does all the configuration data writing (taking values from the config dialog), and configChanged() which is called automatically which reads these values back in and does any updates necessary to the widget in response.
The beautiful this about this approach is that if your configuration dialog works, then it is guaranteed that your widget will also work perfectly with scripting or any other behind-the-widget's-back configuration changes.
What about all those scripted Plasmoids out there? Well, it's the same idea, just a bit simpler. Most scripted Plasmoids get their config dialogs "for free" just by including the correct ConfigXML and QtDesigner files in the package. When the configuration changes (either due to the config dialog or scripting), then the configChanged method is called in the script. In the Javascript bindings this means doing something like: plasmoid.configChanged = function() { .. do stuff in reaction to changes .. }
Oh, and if you are looking for other similar easy-to-get-into tasks, we're once again keeping up a page of such tasks over on community.kde.org.
Friday, September 10, 2010
Subscribe to:
Post Comments (Atom)

3 comments:
guess I'll be adding this to my little first plasmoid adventure page ;)
what's not entirely clear to me: does a plasmoid have to expose its properties as Q_PROPERTY or something for them to become available to scripting or does everything automagically become accessible to scripting? The latter being a security risk I guess.
no Q_PROPERTY stuff is necessary. :)
i am currently storing a password for my plasmoid (in the wrong way, still have to look into kwallet).
What would be the correct way to protect it from 3rd party script access?
Post a Comment