plasma-framework in kdereview

[David Edmundson]

On Fri, Apr 25, 2014 at 6:56 PM, Marco Martin <notmart at gmail.com> wrote:
> 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.

That KConfigLoader already moved to KConfigGui.

(and I agree that class is really really useful)

> 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.

Not aware of rather than ignoring.

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

That was not my intention. Sorry. *hugs*

What I understood of Alex's email was to say; do we want to commit to
ABI compatibility given it has gone through more changes than the
others.

 On reflection we did have that thread in Plasma recently not that
long ago and I remember there was a discussion about the plasmaquick
lib not being released as ABI stable. As long as that statement still
holds I withdraw my comments.