Plasmoids, DataEngines & GHNS

[Thomas Olsen]

On Thursday 23 December 2010 17:22:55 Aaron J. Seigo wrote:
> On Wednesday, December 22, 2010, Thomas Olsen wrote:
> > I'm guessing I could clean up some space and I suppose I would only need
> > to checkout a subset of libplasma?
> 
> yes, just kdelibs. all the work would be in kdelibs/plasma/, but libplasma
> assumes it is in kdelibs for build purposes. it is probably workable to
> take just kdelibs/plasma/ and muck with the CMakeLists.txt file to get it
> to build outiside of kdelibs, but if you can spare the disk space, it's
> really not worth it. the sources for kdelibs are 228MB, my build dir for
> kdelibs is 1.9 GB.

It should be doable to clear enough space for that. Then I can just let the
first build run over night because it's gonna be slooow with my old processor...

> > But I would still need someone to make a plan and mentor me through
> > something Junior Job'ish to start with ;-)
> 
> np; a plan was in the original email ... for the first item, i suppose the
> non-obvious bits are how to make a syncronous wrapper around a KJob (which
> is done using job->exec()) and how to use QMetaObject::invokeMethod to
> call the new slot (which has the side of effect of making it behave like a
> virtual method but without breaking binary compat).

Yep. here I have close to no clue what to do ;-)

> the biggest work would probably be taking the contents of
> Package::installPackage and putting it into a subclass of KJob. that's
> mostly copy and paste work, and the resulting KJob subclass itself would
> be a private class and go into kdelibs/plasma/private/

On first look this doesn't seem that difficult and it would also have the positive
side effect of dealing with the TODO at:
http://api.kde.org/4.5-api/kdelibs-apidocs/plasma/html/package_8cpp_source.html#l00318
as that could go in the errorString() for the job.

> i'd be happy to mentor you as you go and answer questions if you're
> interested in taking this on :)

Sounds great :-)

Please correct my mistakes but as I see it the steps would be:

 1) Create a test-bed widget to start with instead of hacking the Widget Explorer.

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

 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 ;)

 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? What if the package it depends on itself has unmet dependencies?

 4) Look at the things I have absolutely no clue about :-D

I guess I'll be spending the holidays at techbase and setting up a build environment but
I don't have any obligations so thats cool with me :-)

-- 
Best regards / med venlig hilsen

Thomas Olsen

Dropbox and my thumb drive had an epic battle. Dropbox won. http://db.tt/T0p6d6L
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 230 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20101223/17015e75/attachment.sig