[kde-linux] Kget "My Downloads" [Is this MS Windows?]

[Duncan]

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