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

List:       koffice-devel
Subject:    Re: RFD: loading/pasting/DnD in Flake?
From:       Thomas Zander <zander () kde ! org>
Date:       2006-09-01 14:01:05
Message-ID: 200609011601.09597.zander () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Thursday 24 August 2006 17:16, Benjamin K. Stuhl wrote:
> On Thu, 24 Aug 2006 10:21:39 +0200, Thomas Zander inscribed:
> > Morning :)
> > Long emails, but progress is being made! Thanks for taking this on.
>
> Indeed. And it's a complex problem, so I, at least, don't mind the
> verbiage. ^_^

Sorry for long delay in replying. I was otherwise occupied.
But I very much enjoyed my long weekend in London :P

Some general feedback on Tools.

> > I'm not into XML loading very much in KOffice, but should that source
> > not be a xml element ?  Since the loading will be cascaded and
> > loading of a small part of the XML tree is just delegated. No need to
> > recreate an xml.
>
> The vague motivation for a mime-type was to let the shape declare
> support for all the mime types that can somehow be filtered into what
> it can handle, but the filter-chain hunts can just as easily be done
> outside the shape )in the KoDropTool or the like... perhaps there
> should be a KoSaveTool and a KoLoadTool to encapsulate that logic?

A KoTool is a class that is the 'controller' bit of MVC, but its heavily 
specialized to only do the user-interaction part.
So, it will basically translate all user input to the specific shapes it 
can operate on.
For this reason inventing a load or save tool is not really appropriate as 
they are just helper classes.
I suggest to create some private classes for the appropriate tool instead.


> > As elaborated earlier in this email I think this should be moved to a
> > KoDropTool in unison with KoCreateShapesTool.
> > Since the (currently not-implemented) KoToolManager can create and
> > register actions the dropTool could create the action for pasteAs.
> > We load all plugins in the same process so the tool can just call;
> >   QClipboard *clipboard = QApplication::clipboard();
> > to get access to the clipboard.  No access to the application needed.
>
> Yeah, if we go the KoDropTool route (which I think we should, it's
> sounding better and better) the dropTool can be responsible for
> managing the clipboard. OTOH, I think that would mean that a dropTool
> would need to always be active, at least in the background? _Someone_
> needs to listen for QClipboard::changed() signals to enable/disable
> pasting into the current shape...

The KoToolManager manages all tools (duh!) :)
It will instantiate all tools needed for a specific canvas as soon as the 
canvas is registered. Which means that the lifetime of a tool is equal to 
that of the canvas it is associated with. It also means that there are 
possibly multiple versions of one tool instantiated at all times (for 
different canvasses, for example)
With that in mind; the DropTool could very well be the one that is 
connected to the clipboard. I'm not sure.

-- 
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]