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@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 _______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
