a new library

[C. Boemann]

On Wednesday 19 December 2012 10:41:42 Inge Wallin wrote:
> 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.
Yes, I don't disagree that this is the goal we want in the end, but I'm not 
willing to spend time implementing that now. It's too huge a task. however it 
would be nice to know what the solution might end up being so we could take it 
into consideration.

I just don't have an idea right now, and it's more than just widgets. QAction 
depends on QWidget too so we need to move QAction and KActionCollection out of 
the tools too.

It is simply too much to think of right now, and I would like not to be 
sidetracked too much