Plasmoids, DataEngines & GHNS

[Aaron J. Seigo]

On Thursday, December 23, 2010, Thomas Olsen wrote:
> On Thursday 23 December 2010 17:22:55 Aaron J. Seigo wrote:
>  1) Create a test-bed widget to start with instead of hacking the Widget
> Explorer.

i might just use plasmapkg myself. since it can install packages, it uses 
exactly this code from libplasma and it's a nice simple command line tool. 
it's in kdebase/runtime/plasma/tools/

>  2) Create a "new" installPackage method which returns a subclassed KJob
> that does the work.

correct.

>  3) Add the code (a new (static?) method?) to check for dependencies.
> Should this be X-KDE-PluginInfo-Depends or something else? Should it be
> e.g. comma separated values? How to check the dependencies: DataEngine
> name, path to an ocs site. Well actually both are needed I guess? Should
> we only focus on DataEngine dependencies? (please say yes ;)

yes :)

i don't think X-KDE-PluginInfo-Depends is going to be useful for us here, as 
it is supposed to mean, fwiu, other plugins of the same type that this plugin 
relies on.

let's go simple for now and use a new entry: X-Plasma-RequiredDataEngines=

we may want/need to index that in ksycoca, so an entry added to 
kdelibs/plasma/data/servicetypes/plasma-applet.desktop would probably be in 
order (there are entries at the bottom that you can copy from :)
 
>  3) Add a signal that is emitted if there are unmet dependencies. Should
> the job be halted and later "restarted" or should the caller drop that job
> until the dependencies are met?

it's probably easiest if the job is suspend()ed and then resume()d ... and 
yes, if we want the notice of dependencies and confirmation request to be 
handled not by job itself by whatever UI is doing the work, then we will need 
a signal; the consumer of the signal could then decided to either resume() the 
job or kill() it.

we'll want a fallback, however, so that the existing static methods that 
return a bool can continue to work, and existing code that uses Package will 
continue to work even if it means showing a dialog popup to the user. so 
perhaps for the first draft, let's not wory so much about the signal and 
suspend/resume/kill and just implement everything in the job.

once that's working, then a signal can be added to the KJob* subclass that can 
be connected to. fortunately for us there is QObject::receivers which can tell 
us if anything is connected to this signal. if not, the fallback route can be 
used.

> What if the package it depends on itself has unmet dependencies?

i think we want to avoid a "full" dependency resolver, akin to what apt-get, 
zypper and yum have. one thing that would need to be resolved is the issue of 
circular dependecies, perhaps, which is easy enough by keeping the state of 
all asked-for dependencies so far.

-- 
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 Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20101223/ea0f2a56/attachment.sig