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