Re: [kde-linux] Kget "My Downloads" [Is this MS Windows?]
- Date: Mon, 22 Apr 2013 08:11:23 +0000 (UTC)
- From: Duncan <1i5t5.duncan@xxxxxxx>
- Subject: Re: [kde-linux] Kget "My Downloads" [Is this MS Windows?]
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
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-
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
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
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.
More info: http://www.kde.org/faq.html.