a new library

[Inge Wallin]

On Wednesday, December 19, 2012 15:01:50 C. Boemann wrote:
> 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.

Sure and agreed.  I just ask that some consideration is taken now on how to do 
it in the future so that we design away any possibilities.

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

They do??  I thought they were completely stand-alone.

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