Separate Plasma::DataSource and data engines

[Marco Martin]

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 ;) since 
they offer out of the box all the asyncness that like it or not, is simply 
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