plasma-framework in kdereview

[Marco Martin]

On Friday 25 April 2014 17:46:23 David Edmundson wrote:
> > Well... it's been planned this way for three years if not more. Before
> > that it was in kdelibs.
> > 
> >> Also, right now there is only one user of this framework
> >> (plasma-desktop),
> > 
> > That's because the other users weren't ported to KF5 yet. But there's
> > definitely more plasma users (amarok comes to mind, skrooge too iirc), not
> > really shells.
> 
> That was before QtQuickControls and KDeclarative's imports. Back then
> Plasma was the convenient way to get some sort of button

/me notes that the widgets were just a later aftertought in that library and 
not even remotely the point of that library ever.
that decision had exactly zero to do with plasma being the way to do buttons, 
in fact, even tough it still depends from too much for my taste, one thing it 
does *not* depends from is what? ah, QML.

as now maintainer of that library and components i call that library has 
framework quality and is very general purpose.
one may want to use it or not (to do applets made with qwidgets, or only to 
parse kconfigskeletons at runtime for what i'm concerned), that's the call of 
the application developer, as any workspace.
It just comes as an huge (disappointing) surprise that just today
* after the move has been started
* after years the decision has been made
* ignoring the fact that such decision was made after, and in part because of, 
was possible to remove all the widget stuff, making it finally a small 
library.

> If Amarok or Skrooge wants to use anything from Plasma we are doing
> something wrong.
yes, I think this team is seriously doing something really wrong.

Let's see what we have that has zero to do with qml controls:
* packages
* configloader
* dataengines
* services
* qpainter based (and going to stay qpainter based) svg stuff
* plugin based (the whole point of having anything)

you can hate every single one of those things, and believe till the end of the 
days that can be solved with $magicbullet in qml, for some things, are complex 
problems, everywhere that there is a similar problem, you'll end up 
reimplementing a non negligible proportion of it, almost identical.

now i have no idea if that is needed or not by amarok or skrooge, again, if 
for instance the user interaction paradigm they would choose would be "a page 
in which you can add widgets that say things"
one starts to say "how hard can it be", will end up with a quite near 
reimplementation of corona, containments and packages (replicating in the 
meantime many of the bugs we had and solved).
For instance the mediacenter wanted to be a shell again to support widgets 
again, I'm sure you would advise them against and reimplement the whole 
mechanism instead, i'm wondering why the project is in such state tough.

what i'm seeing, (and it's not new of this, it's going on since a while)
is that the history of things, and why thay are in a certain thing and not 
another is being ignored, and that's excusable (and somewhat comprehensible, I 
know I'm not that good in neither explanation or documentation, sorry)
But what is less is the systematically not caring of the why.

Ending up having to defend the project against the project itself, I am 
seriously starting to wonder what the hell I'm doing here.

-- 
Marco Martin