From koffice-devel Mon Jun 05 12:55:39 2006 From: Thomas Zander Date: Mon, 05 Jun 2006 12:55:39 +0000 To: koffice-devel Subject: KoToolBox + KoCanvasView Message-Id: <200606051455.40353.zander () kde ! org> X-MARC-Message: https://marc.info/?l=koffice-devel&m=114951219603257 MIME-Version: 1 Content-Type: multipart/mixed; boundary="--===============0051872920==" --===============0051872920== Content-Type: multipart/signed; boundary="nextPart29479023.Xbl9PvfSEY"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit --nextPart29479023.Xbl9PvfSEY Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline 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=20 Krita) a toolbox. Below is the design we decided upon and one that I will start=20 implementing. I'd love to hear feedback / questions. KOffice 2.x will require applications to provide specialized tools to edit= =20 their shapes. This means, for example, that a KWord text-frame is a KoTextShape and=20 there will be a tool to edit that text to go with it. The tool will=20 allow keyboard and mouse input to be used for the manipulation of the=20 shape (or shapes, if more are selected) so the user can type text; use=20 the arrow keys to navigate through the text etc. This is all done in the=20 class that extends flakes KoTool. Since all KOffice applications should be able to use that tool, we need a=20 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=20 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=20 the appropriate other tool active. For example. It really manages all=20 the tools for the application so apps basically don't need to know much=20 about active tool or stuff like that. One method provided will be a KoToolManager::activeTool() =46or usability reasons we decided its best to have exactly one toolbox=20 visible per application. So, if you have a split view, you will see only=20 one toolbox and it will work on the currently active view. This is=20 slightly different from the way things are done now, since now we=20 destruct the toolbox and create a new one when the view changes. In the=20 new design we have just one toolbox widget and all user input is routed=20 to the toolManager which then redirects it to the right tool for the=20 right view (aka canvas) This has an immediately visible effect that toolsettings are application=20 wide. Just like you see in MDI apps like photoshop. Click on the=20 gradient tool in one view and after switching views the gradient tool=20 will be active there as well. The reasoning behind this change is that=20 _in one application_ most users works sequentially, which is to say, they=20 do one type of action after each other and will be unlikely to reap any=20 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=20 KoInteractionTool that lives in the flake library. Its the 'arrow' tool=20 that does move/rotate/scale etc. The ToolManager will be the one that creates the ToolBox and thus all=20 KOffice applications that use it (I'm hoping all will) will see the same=20 toolbox. The interaction tool will always be present, thats obvious. =20 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=20 the selected shape(s) * Color selector widget. The Canvas; Each KOffice application is still expected to provide its own canvas. =20 This is for various reasons. What we see is that the features I see that=20 KWord and KPresenter provide in their canvas will be provided for about=20 75% by flake; so your canvas can be pretty thin. As another extra; I provided a KoCanvasView in flake. This is a=20 QScrollArea derived class and tools that want to alter the zoom or the=20 position of the canvas in the scroll view can get a pointer to that one=20 to do their work. So, for best effect I think all applications should use the KoCanvasView=20 like KWord and Karbon already do. Its designed to be flexible enough for=20 even Krita, but if someone runs into problems, please let me know. =2D-=20 Thomas Zander --nextPart29479023.Xbl9PvfSEY Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) iD8DBQBEhCnMCojCW6H2z/QRAnDsAKCsVejwccmeu8o6hiDS96K9CP8egACeI53W 4bIC/hjA+51z87FIidPVtrk= =ueES -----END PGP SIGNATURE----- --nextPart29479023.Xbl9PvfSEY-- --===============0051872920== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ koffice-devel mailing list koffice-devel@kde.org https://mail.kde.org/mailman/listinfo/koffice-devel --===============0051872920==--