a new library

[Inge Wallin]

On Wednesday, December 19, 2012 01:55:38 C. Boemann wrote:
> Hi
> 
> In an attempt to to rework the ui, we have run into a problem:
> 
> KoCreatePathTool in libs/flake needs some widgets from libs/widgets
> 
> however the dependency is in the opposite direction
> 
> So unless we want to move the tools into libs/widgets we need to move the
> tool to somewhere else.
> 
> It can't be moved to a plugin as krita has some tools that inherit from
> KoCreatePathTool.
> 
> My suggestion is thus that we make a new library, which I call alpine as
> it's a superstructure to flake. This alpine library will depend on
> libs/widgets and contain basically tools, shapes and dockers that are too
> important or generic enough that we can't have them in plugins but need to
> be sure is available.
> 
> For now it would only contain the KoCreatePathTool but in the past I've
> thought that maybe the textshape needs to be in a library instead of a
> plugin.
> 
> So what do you say?
> 
> best regards
> C. Boemann
> _______________________________________________
> calligra-devel mailing list
> calligra-devel at kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel

I think that when doing this we should also consider non-desktop platforms. I 
don't like the way that our tools are tied strongly to QWidget right now.

A tool takes input from various sources such as keyboard mouse and pad and 
applies changes to the shape that the tool handles. It also has the option to 
create a dialog widget which is currently embedded in the side bar. This 
widget is hardcoded to be QWidget based which works badly on other platforms 
than the desktop.

The situation is like it is for historical reasons and I don't have a big 
problem with that. But let's not go even further into the QWidget cul-de-sac. 
So when designing this new library that is going to be tied closely into one 
of our most central libraries, flake, please consider how other base classes 
than QWidget can be allowed in the future. Optimally, a gradual migration to 
QML should be possible but I know too little about that to comment on the 
actual implementation.

All this said, I think a refactor could be a good idea. But why not make a 
meaningful name? libflaketools should be obvious enough; alpine is  justa bit 
too clever for me.