[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-08-21 17:26:05
Message-ID: 200608211926.11537.zander () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Monday 21 August 2006 17:50, Benjamin K. Stuhl wrote:
> All --
>   So as ThomasZ continues to run ahead with kotext2 and .kwt loading
> (very nice, by the way! ^_^)
:-)

> , it occurred to me that that loading code 
> (and therefore pasting and DnD-accepting) for a given flake should
> probably all be in the associated tool? It doesn't make sense to have,
> say, multiple copies of the .odt style and text-loading code running
> around, but every writable KoTextShape should, IMHO, be able to accept
> (e.g.) text/plain, text/html, and ODT text pastes and drops. However,
> given ODF embedding semantics, we can't just hand a raw ODF chunk to
> the KoTextTool and expect it to completely deal with it: what if there
> is, say, a formula embedded in that chunk?

First some general thoughts.
- Tools are for manipulating shapes, and there can be more then one tool 
that handles one shape-type. Only the KoCreateShapesTool can create 
shapes due to it being passed a controller.

- There is a KoShapeContainer that allows any number of children. So 
anyone that is able to show child shapes should extend that class instead 
of the normal KoShape.

I would say that filling a shapes data should be done in the shape itself, 
preferable, due to encapsulation. The idea was that a shape can load / 
save itself in the ODF format.
You are right that nested shapes are a bit more tricky.
A shape that somehow finds data it can not load should be able to delegate 
that. Effectively creating a new shape that loads that data.
I'm not sure how 'nested' ODF is, but I am sure that since the creation of 
new shapes is something that the shapeCreatorTool should do, some 
createShape(QDomElement) method should be added on that.

A shape that finds out it needs to create a child-shape then needs to call 
that.
Effectively;
myTool::paste(QDomElement e) {
	firstSelectedObject->paste(e,
          KoToolManager::instance()->shapeCreatorTool(m_canvas);
}
KoShape::paste(e, createTool) {
   // foo
}
KoCreateShapesTool::createShape(QDomElement elem);

 It would use the ShapeRegistry to find out which shapeFactory can be used 
for the datatype.  This means some mime-type should be registered on the 
KoShapeFactory.

> Also, what about pasting? Do 
> we need an explicit notion of a cursor, or do we just define that
> loading a chunk of data into a Tool is defined to always occur at the
> current insertion point, overwriting any preexisting selection?

I think that using the current cursor position certainly is best.
And tools that don't have a cursor position should probably just deny 
pasting leading the application to paste it to the parent (probably a 
page).

>   Also, what about the flip side? Tools should probably know how to
> serialize their shapes, too? (After all, the tool is the logical
> element to provide data sources for cut/copy operations, and probably
> should be responsible for saving its shapes, too?)

Tools themselves don't hold data and there is no guarantee that there is 
one tool per shape. But if you replace 'tool' with 'shape' in your 
question, then yes, each shape should be able to save itself in the ODF 
format. I would think that this format is used by DnD as well. This makes 
a KoShape method 'fillClipboard()' easy enough for the majority of the 
cases. It just uses the ODF.

>   Some other possible complications to further muddy the waters:
> *  multiple clipboard formats: both copying and pasting... and an
> application should be able to provide a "Paste as..." menu, with e.g.
> "Paste as... -> New Frame" and "Paste as... -> Unformatted Text" for a
> rich text clipboard item in kword.
Good idea :)

> *  embedded objects and object references in ODF: how does a tool pass
> back an unhandled object (e.g. a formula in an ODT document) to hand it
> off to another shape? what about a reference, like an image in an ODF
> document?
Shapes that allow children know how to do that.

> *  consistent menus and DnD behavior: should menus (like "Paste as...")
> and drops be under the control of the tool or the application? Perhaps
> give them to the application, but let the application delegate to the
> tool if it can?

Good question. Not much thought has gone into that. :)
-- 
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]