plasma, patches and parallelism

i have three emails open and waiting for me in the morning, each with a patch set that i have to look over, possibly debug, hopefully give the thumbs up to. for bigger patches the review process can often take a few iterations; i'm constantly afraid people will run away due to having to deal with someone who can be a bit anal about things at times. really, i just want to see decent design and make sure that we cover as many of the issues as well as possible. this results in a slightly slower development pace at times, but hopefully it increases the overall speed of development as we don't have to constantly re-do things over and over. in fact, it's been the patch sets that i've said, "yeah, sure, just throw it in i'll look at it later" that have caused plasma the most grief. so to all the other plasma hackers out there: thanks for sticking through the review process. if it's any consolation, you not only keep me busy, you often push my abilities (such as being to keep up with N conversations at once, or deal with things as disparate as threading, geometry and packaging issues). which i actually enjoy =)

the Package* classes just recently went through a small refactoring to make them more real-world usable. due to the house cleaning frenzy today i didn't get to a screencast (or much hacking for that matter), though i really want to do one on the package stuff so people can see how cool it is even now. thanks go to Paolo Capriotti for doing the majority of the grunt work there.

krunner is now multithreaded. after a couple weeks of kicking around design issues and patches with me on the plasma-devel list, Ryan Bitanga committed the full kit and kaboodle today. the difference in responsiveness is remarkable. unfortunately, if you really try hard and abuse the line edit in krunner you can run out of available threads due to runners lagging behind. this is because instead of trying to make runners interuptable, we let them run even if the user has moved on. so if you are especially devilish you can stack up enough runners that you have to wait a few seconds for them all to return (there's a 4 thread maximum, making for a long queue). the upside to this approach was a small number of locks needed in the code and keeping it very simple to write runners. in fact, when writing a runner you hardly notice there's anything thread like going on at all. pretty neat. we will be implementing optional abort support in runners that have nasty running times as well as tweaking the start-the-match-process algorithm a bit to improve this last point, even though you really pretty much need to be trying to trigger this behaviour. still, good apps should work well in as many situations as possible. i'm just stoked to see threading in krunner.

there's also a patch set on the list for threading svg rendering that i need to look at.

i also put out a call asking for what is ready to be pulled over from playground. the way things work in plasma generally is that new development on plugins (of which there are 6 types now, each for a different sort of thing =) or major new additions that don't substantially build on existing code happen in playground. this way anyone can work on anything they want without having to have "working" code or even do something that anyone else thinks it productive. it's amazing just how much working code for useful things comes out of there, though. ;) the plasma team's job then becomes to pull the good stuff from playground into extragear or kdebase. this isn't completely dissimilar to how one might work with a decentralized system, except it's within the capabilities (or limitations, depending how you see it =) of a centralized system like svn.

it looks like there are a handful of new applets, runners and engines that will be crossing over into extragear soon. post 4.0, we'll be doing regular releases of the stuff in extragear. so while the kdebase things will likely follow the more docile kdelibs-driven release schedule, we'll get much more often plasma refreshes out of extragear. i still want to release [lib]plasma packages for testers on a more agressive basis as well, but we'll see how that pans out before 4.1.

the downside to this development system is that i will at some point become a bottleneck to the process, at least if plasma gets anywhere near the scope i want it to. before that happens, i'm aware that there will be need for others in the project who are well versed enough in the concepts and code that they can take on these things as well. i think we're getting close to that point with a couple of people already, though until 4.0 is out and i have time to write more documentation about the design, purpose and implementation seen within plasma that process is somewhat hampered.

another downside is that indeed some people can't hack the less free-for-all mentality, especially for libplasma. however, there are so many people that continue to contribute quality stuff to plasma on a regular, repeat basis that it's evidently not that bad.

still, i am open to feedback from those involved as to how to make things better. (besides, "use git" .. yes, i'm looking at you Ruphy ;)