problems in package land

[Marco Martin]

On Saturday 16 July 2011, Aaron J. Seigo wrote:
> 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.

aand, (indeed thanks unit tests) i you had other problems othe the ones 
described, make sure 
d4b8d3b8f6db83e4d92acc7c23b6218e1c85a4de
is megrged in the plasma2 branch (package tests are all green in master again)

> 
> 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.

so, if someone would like to connect to a signal would have to do 
connect(package->structure(), SIGNAL(....

i i understood correctly, right?

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

ok


-- 
Marco Martin