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

List:       koffice-devel
Subject:    KoToolBox + KoCanvasView
From:       Thomas Zander <zander () kde ! org>
Date:       2006-06-05 12:55:39
Message-ID: 200606051455.40353.zander () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


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

[Attachment #5 (application/pgp-signature)]

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel


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