From koffice Mon Jun 05 12:38:20 2006 From: "Tim Beaulen" Date: Mon, 05 Jun 2006 12:38:20 +0000 To: koffice Subject: Re: KoToolBox + KoCanvasView Message-Id: X-MARC-Message: https://marc.info/?l=koffice&m=114951112506494 I don't see any problem with this. On 6/5/06, Thomas Zander wrote: > Yesterday I spent the day at boud's place and we were pretty productive! > One thing we did was design and partially implement (read: port from > Krita) a toolbox. > Below is the design we decided upon and one that I will start > implementing. I'd love to hear feedback / questions. > > KOffice 2.x will require applications to provide specialized tools to edit > their shapes. > This means, for example, that a KWord text-frame is a KoTextShape and > there will be a tool to edit that text to go with it. The tool will > allow keyboard and mouse input to be used for the manipulation of the > shape (or shapes, if more are selected) so the user can type text; use > the arrow keys to navigate through the text etc. This is all done in the > class that extends flakes KoTool. > > Since all KOffice applications should be able to use that tool, we need a > way to register it and load it dynamically. For this we invented: > * KoToolRegistry A list of all tools that the system knows. > Using .desktop files they are found all over the KDE installation. > * KoToolFactory each tool has a Factory object that can create one > specific type of tool. A KoInteractionToolFactory will create > KoInteractionTool instances, for example. > * KoToolManager a class that is a singleton per process and that uses the > registry to get all the factories. The Toolmanager can be tweaked by > the application to register other tools and following that it can create > a KoToolBox instance. > The toolmanager will listen to signals like a tools sigDone and then make > the appropriate other tool active. For example. It really manages all > the tools for the application so apps basically don't need to know much > about active tool or stuff like that. > One method provided will be a KoToolManager::activeTool() > > > For usability reasons we decided its best to have exactly one toolbox > visible per application. So, if you have a split view, you will see only > one toolbox and it will work on the currently active view. This is > slightly different from the way things are done now, since now we > destruct the toolbox and create a new one when the view changes. In the > new design we have just one toolbox widget and all user input is routed > to the toolManager which then redirects it to the right tool for the > right view (aka canvas) > > This has an immediately visible effect that toolsettings are application > wide. Just like you see in MDI apps like photoshop. Click on the > gradient tool in one view and after switching views the gradient tool > will be active there as well. The reasoning behind this change is that > _in one application_ most users works sequentially, which is to say, they > do one type of action after each other and will be unlikely to reap any > benefits from each view remembering their own tool and settings. > > The ToolBox; > In KOffice all applications will supply tools, but the most used is the > KoInteractionTool that lives in the flake library. Its the 'arrow' tool > that does move/rotate/scale etc. > The ToolManager will be the one that creates the ToolBox and thus all > KOffice applications that use it (I'm hoping all will) will see the same > toolbox. The interaction tool will always be present, thats obvious. > But other actions will be configurable by the application. > I see 4 sections in the toolbox; from top to bottom: > * generic tools. > * Application specific tools. > The application specific tools can be things like 'move canvas'. > * Shape specific tools > The shape specific tools-section will change its visible icons based on > the selected shape(s) > * Color selector widget. > > > The Canvas; > Each KOffice application is still expected to provide its own canvas. > This is for various reasons. What we see is that the features I see that > KWord and KPresenter provide in their canvas will be provided for about > 75% by flake; so your canvas can be pretty thin. > As another extra; I provided a KoCanvasView in flake. This is a > QScrollArea derived class and tools that want to alter the zoom or the > position of the canvas in the scroll view can get a pointer to that one > to do their work. > So, for best effect I think all applications should use the KoCanvasView > like KWord and Karbon already do. Its designed to be flexible enough for > even Krita, but if someone runs into problems, please let me know. > > -- > Thomas Zander > > ____________________________________ koffice mailing list koffice@kde.org To unsubscribe please visit: https://mail.kde.org/mailman/listinfo/koffice