Hello,

as it was allready written a lot of stuff to different aspects it is not so 
easy to respond to each so here is what I think:

- I think we should use the oasis file format as the format for exchange.
This has some consequences:
+ style and objects are separated. 
+ there is no standard defined for copy and pasting objects or even some 
selected text.

To load shapes in odf first the styles for the shapes have to been loaded so 
that when the shape is loaded the style for the shape can be found. In 
koffice 1.6 kword and kpresenter uses KoOasisStyles and KoOasisContext. The 
KoOasisContext is then passed to the load method of the shape.

As we have loading during loading of a document and loading during copy and 
paste and drag and drop the code should be shared. 
As the objects are used in different apps the loading of the pages and 
additional stuff like animations is different form application to 
application. However the loading of the object on a page are the same in 
every app. So we can us the same code here. 

Form this I think we should have a instance which should do the loading of the 
shapes. I call it shapeloader form now on.

The shapeloader should find out which shape can load the data and then create 
that shape and call the load method of this object howerver it can be that 
there are shapes that supports more then one type of object e.g. the 
KoPathShape can be used to pathes with curves or only a poly line which are 
different objects in odf. The object will then load itself. 
For nested objects (<g/> in odf) the shapeloader create the group and then 
again load all objects (like in the loading of an object) that belong to the 
group and add it to the group. 
For inline objects in a text paragraph this is a bit more complicated, as this 
can contain all kinds of objects again again. If the loading in the text 
object finds a inline object it alls again the shapeloader to get the 
embedded objects. Maybe David has some more info about that as he has done 
the current impementation.
After the loading is finished the created object are then returned.

The shapeloader can be called form the KoDropTool, copy and paste or the 
loading tool of the application. The objects will then be added to the 
document by the one calling the shapeloader.

Also for the saving we need something that can save the styles of the objects 
as they are saved seperatly. It will call the save method of the the 
indifidual objects and then creat save the styles and creat a document.

Maybe for copy and pasting we can creat a new odf document type which does not 
need to contain pages but only copied shapes. If this works good maybe it can 
be added to the standard so that copy and pasted between all apps supporting 
odf would be possible. David what do you think about this?

On Friday 25 August 2006 05:57, Benjamin K. Stuhl wrote:
> Replying to myself with some patches to KoShape.h and KoTool.h to make
> the discussion a bit more concrete. These aren't to be applied, since
> (a) they won't compile without a bunch of porting of all the
> shapes and tools, and (b) I have an SVN account now. ^_^
>
> I'm not sure what the rules are on which libraries can link to what. In
> particular, I hope it is OK to give Flake a dependency on kostore?
>
> One thing that occurs to me as I'm writing this up: perhaps
> KoTool::cut(), KoTool::paste(), and KoTool::copy() should be passed
> the same arguments as KoShape::load() or KoShape::save() so that
> KoTool itself can implement the basic clipboard and filter handling?
> Or should KoTool::paste() be given a mime type argument?
>
> +    /** @brief Load the entire shape
> +     * Each shape is resposible for knowing how to load itself and any
> possible sub-shapes +     * from a KoStore; that is done by this method.
> Shapes that accept drops or pastes will +     * also need some method to
> communicate partial loads from their corresponding tool. +     * @param
> rootElement the top-level XML element defining this shape; may or may not
> be the +     * root element of the entire document
> +     * @param store the container that the document is loaded from; useful
> when the XML element is +     * just a reference to another file in the
> store, such as for images embedded in ODF +     * @param createShapes the
> tool that lets a shape create sub-shapes for unhandled elements in +     *
> its XML
> +     */
> +    virtual void load(const QDomElement &rootElement, KoStore *store,
> KoCreateShapesTool *createShapes) = 0; +

As pointed out above we should not pass a KoCreateShapeTool to the shape as 
adding to the document should not be done by the shape. We have to add here a 
KoOasisContext. So I porpose the following which is what we have in kword and 
kpresenter at the moment.

void virtual void loadOasis(const QDomElement &element, 
KoOasisContext&context ) = 0;

> +    /** @brief Save the shape and its childre
> +     * Each shape is responsible for knowing how to save itself and its
> children to a XML document in +     * a KoStore; that is done by this
> method. Shapes that have tools with some concept of a selection +     *
> will also want to impelment some shape-specific method of saving a subset
> of the shape so that +     * the tool can serialize the selection to the
> clipboard or to a mouse drag. +     * @param xmlWriter the XML document to
> save to
> +     * @param manifestWriter the manifest file of the KoStore, useful if
> the shape needs to add a file to +     * the store
> +     * @param store the outer container for the XML document and all its
> associated files +     */
> +    virtual void save(KoXmlWriter *xmlWriter, KoXmlWriter *manifestWriter,
> KoStore *store) = 0; +

Pleas have a look how this is done in kword and kpresenter 1.6.

>      /**
> +     * Setting the shape to refuse drops means that drop and paste
> requests will be +     * delegated to the parent shape or the top-level
> document.
> +     * @param acceptDrops the new value
> +     */
> +    void setAcceptDrops(bool acceptDrops) { m_acceptDrops = acceptDrops; }
> +
> +    /**
> +     * Setting the shape to refuse drops means that drop and paste
> requests will be +     * delegated to the parent shape or the top-level
> document.
> +     * @return whether this shape accepts drop or paste requests
> +     */
> +    bool acceptDrops() const { return m_acceptDrops; }

I'm not sure if the shape should be the one that accepts the drops should it 
not be the application? Ok if I dorp it in text shape it would should be 
forwarded to the shape.

> Index: flake/KoTool.h
> ===================================================================
> --- flake/KoTool.h	(revision 576400)
> +++ flake/KoTool.h	(working copy)
> @@ -35,6 +35,7 @@
>  class QKeyEvent;
>  class QWidget;
>  class QPainter;
> +class QPoint;
>
>  /**
>   * Abstract base class for all tools that manipulate flake objects.
> @@ -145,6 +146,31 @@
>       */
>      virtual void keyReleaseEvent(QKeyEvent *event);
>
> +    virtual void cut() = 0;
> +    virtual void copy() = 0;
> +    virtual void paste(const QPoint &where) = 0;

I think this should be not pure virtual methods but an empty implementation as 
not all tool will support them.

Hope that sounds reasonable :-) Sorry for being long. 

Have a nice day,

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