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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
