problems in package land

[Aaron J. Seigo]

hi ...

first off: unit tests are indeed The Awesome. the findings below are all a 
result of trying to make the unit tests in libplasma pass. i probably would 
not have noticed these issues, along with several others that i have already 
fixed, if it were not for those unit tests. and these are tests written 
sometime last year: they just keep paying dividends. so anyone looking for 
"junior job" stuff that really, REALLY has long term value in libplasma: 
writing unit tests is a terrific sart.


so, some annoyances in the Package merge effort. locally i'm 27 commits ahead 
of the branch and have touched 1000s of lines of code in dozens of files. but 
i haven't yet pushed, so there is no "too far to turn back or change 
direction" .. ah, git, i love you.

so ... annoyances? PackageStructure used to rely on one small detail: virtual 
methods. in particular:

* pathChanged
* installPackage
* removePackage

moving to Packages-by-reference-only means doing (cheap) copies of the 
objects, and of course as soon as you do, say, this:

Package p(PluginManager::load("Plasma/Applet"));

then you have a regular Package object named 'p' and the virtual methods in 
PlasmoidPackage (which is what gets made for a "Plasma/Applet" request) 
evaporate away. result is that this next call:

p.setPath(packagePath);

does _nothing_: the main script does not get identified properly. fail.

i've rolled around various ideas in my head since i ran into this problem 
yesterday afternoon. and i think i'm going to have to reintroduce 
PackageStructure, though with some changes. PackageStructure will become a 
reference counted (new) QObject subclass (as it was). it will also not hold 
any data itself, but simply be a mutator for Package. that way we can still 
share _one_ instance of the structure for multiple Package classes, something 
we haven't been able to do since the introduction of configChanged a couple 
years ago, actually, and Package will still be passed by reference.

what this means is that instead of setting things up in the ctor, package 
structures will be set up with an initPackage() that will be called when the 
path is first set. pathChanged() will then be called every time the path 
changes in a Package thereafter. the Package class in question will be passed 
in as a parameter in both cases. ditto for the install and remove package 
methods.

with this, porting will be necessary, but it will be nominal. which is the 
same situation as the current plans. it also means i can de-uglify the plugin 
loader macro again.

i'm not 100% happy with this, but can't see an alternative at the moment.

btw, as an added optimization, for mobile builds i will not be storing the 
mimetype and name information in Package objects since those are only useful 
for using Packages in things like Plasmate. on the desktop, those extra bytes 
and allocations are completely trivial and non-important. on mobile, i want to 
preserve resources as much as possible :)

anyways, just a small update. i'll end up pushing sometime this weekend with 
all these changes.

-- 
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/20110716/f716e7ba/attachment.sig