[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice
Subject:    Re: KoToolBox + KoCanvasView
From:       "Tim Beaulen" <tbscope () gmail ! com>
Date:       2006-06-05 12:38:20
Message-ID: dd1e9b170606050538v8e48690ka57b6d42ecd0804a () mail ! gmail ! com
[Download RAW message or body]

I don't see any problem with this.

On 6/5/06, Thomas Zander <zander@kde.org> 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
[prev in list] [next in list] [prev in thread] [next in thread]