[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 15:07:13
Message-ID: 200609011707.13808.zander () kde ! org
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


On Sunday 27 August 2006 10:26, Thorsten Zachmann wrote:
> 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.

While true, we are using DOM and there is no need for the 'first'. We just 
need to make sure that the styles loaded are properly cached.

> In koffice 1.6 kword and kpresenter uses KoOasisStyles and 
> KoOasisContext. The KoOasisContext is then passed to the load method of
> the shape.

Looks good, yes.
But for the designing phase (which we are in now) its a bit of overkill to 
want to have everything perfect on the first go :)
So, to BKS I'd say this part can be ignored for now.

> 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 idea is a bit similar to mine, I just put it in the 
KoCreateShapesTool.  Its fine to put it in another class and let it load 
stuff.
There are some differences, but please read my original emails to see what 
they are ;)


> > +    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.

This point is not entirely correct.
The CSTool was passed for the benefit of callback so its being delegated 
outside the shape. But we still need that argument :)
At least for the KoShapeContainer.

> > +     * @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.

Well, this is a bool, so a difference between app and shape is already 
made.
That said; I'm not sure this bool is needed. Or better, I don't know when 
it would be needed.

When a drop is made the dropTool reads all the mimetypes that are 
transferred in the DnD and it will use the KoShapeRegistry to find all 
shape types that are eligble for such a drop. By eligable I mean the 
shape types we can instantiate and load with the new data.

While moving the mouse (which the dragTool naturally gets all the events 
for) the shape(s) under the mouse can be matched to be of the specified 
type. So dragging that image from krita can be dropped on an image shape 
replacing its content. Similar for a text. It just will be handled 
different to not replace anything but the selection.
For trying to drop on a KoShapeContainer its even easier; if there is a 
shape that can host the content then you can drop it on any 
KoShapeContainer after which a new shape will be created and added to 
that container.

As discussed before, the drop tool will delegate the pasting to the 
specific tools. Overview in a mail from a week ago..
-- 
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]