James Tyrer posted on Sun, 21 Apr 2013 23:23:46 -0700 as excerpted: > On question you missed is Plasma. I have never looked at the plasma > code, but usually the type of instability that Plasma exhibits is caused > by code race conditions. You don't mention if there are any plans to > completely rewrite it from the ground up? Or, what will be done with > it?
I don't know about the general case. I do know some specifics, however. One of the big problems and my personally biggest frustration with plasma, certainly so when one misbehaving plasmoid would freeze or take down the entire thing, is that it was single threaded (at least where it counted), and a single process with no protection between components... in a plugin architecture marketed from the beginning as extensible by third parties with who knows what sort of experience or lack of it, etc. That just made NO sense to me! But apparently, at least part of it was due to compromises forced by the qt4 context they were working with. The technical details went fuzzy on me, but apparently, there was simply no provision in qt4 for multi- threading or protecting critical contexts which would need access from multiple components at the same time. So working with what they had, the solution was to simply serialize pretty much everything... which meant that a freeze or a crash in one third party plugin component froze or crashed the entire thing! I'm not close enough to the development context to know the specifics of how that is resolved in qt5, but I believe it's a reasonable bet that this was a front-and-center concern as they reworked the implementation for qt5, since the negatives of the qt4 solution were so immediately and widely visible in plasma, so if I don't miss my bet, that limitation should either no longer be there or should at minimum be dramatically reduced in effect. So I expect the qt5 plasma to be much better behaved in this regard. OTOH, I honestly don't know what to think about the whole store-all-the- valuable-config-in-a-single-ultra-complex-and-not-particularly-robust- plasma-desktop-appletsrc-file problem. Given the defined plugin architecture nature of the project, THAT problem should have been foreseen early on, and a solution with for example that file as a hierarchy of subdirs, with each component having its own rc file and containers having nested subdirs as necessary, could have been devised instead. Since I don't know why they took the approach that common sense and past experience suggested would be entirely inappropriate there in the first place, with the predictable indeed occurring, I really haven't a clue as to whether they might have learned from that mistake and corrected it in plasma-for-kde-frameworks, or not. I'd /hope/ so, but... Anyway, IMO addressing just those two issues would go a VERY long way toward making plasma the robust plugin architecture desktop it was envisioned and marketed as. I'm definitely hopeful, but other than the reason to believe that the root cause of the one has been addressed in qt5, I really don't have an indication where that's headed, at this point. But if Kevin's correct and they're targetting a tech preview release for this summer, we don't have long to wait now, to get at least a small hint. If the preview has a plasma that still uses that single file for all its components, I'm not going to be happy about the outlook. But if they've fixed that, as it seems they should be doing pretty early on in the new concept if they're planning on doing it at all in ordered to avoid getting locked in again, then I'll have big reason for continued optimism. =:^) -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman ___________________________________________________ This message is from the kde-linux mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde-linux. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.
