Separate Plasma::DataSource and data engines

[David Edmundson]

On Mon, Jan 19, 2015 at 11:28 AM, Marco Martin <notmart at gmail.com> wrote:

> On Monday 19 January 2015, Pier Luigi Fiorini wrote:
> > Hi,
> >
> > I would like to use Plasma::DataSource and the data engine plugins in
> > my project because it suits my needs very well.
> >
>
> However it introduce large dependencies (plasma-framework and
> > plasma-workspace).
> >
> > Would you consider moving the code into a framework pretty much like
> > what you did with KPackage?
>
> It's something that I would kinda like, however there are some problems
> with
> it.
> Splitting KPackage (thing that is still actually far from done, there is
> still
> a lot of porting to do) has been a thing that taken a really long time.
> Literally few days to do the actual split, months and months to make sure
> there aren't too many behavior chages, that everything is perfectly
> retrocompatible, and porting every user.
> I think it was worth it since it's of global interest and relatively small.
>
> On dataengines, personally I would love that as well, but on one hand, they
> are more complicated than kpackage, therefore it would take even more time
> (that I'm not sure i have in the next months among the other stuff to do..)
> On the other hand I'm not sure it would be really worth it, because I see
> in
> general people don't like them, I don't see people wanting to write new
> ones
> (as opposed to a qml import) even for problems where it would match.
>
> Personally I still think they are the way to go for certain kind of
> problems
> (my deep dislike for qml import proliferation I think it's well known ;)


and my personal feelings are equally well known I assume :)


> since
> they offer out of the box all the asyncness that like it or not, is simply
>

I find that interesting; one of the things I disliked about dataenegines
was how they were very synchronous.
Your only option is to return garbage and then update it, the solid
dataengine does that with brightness for example.
(or you unpredicatably just don't provide any data, and then your QML spews
a tonne of errors)

I don't see how that's any different from providing QML plugin.

Servicejob does have async helpers, sure.



> necessary in a gui project, that in a qml import would have be to be either
> reimplemented from scratch or (usually) just ignored producing fun freezes.
> On an ideal world, I would make them in a separate framework, redesigning
> some
> parts that i think can be improved and all..
> But anyways, at the moment (I'm always open to change idea) I don't have
> much
> motivation to undergo a massive porting effort on something that very few
> would ever want to use.
>
> --
> Marco Martin
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20150119/3a88c7bb/attachment.html>