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 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel