RFD: loading/pasting/DnD in Flake?

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? 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?
  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?)
  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.
*  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?
*  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?

That's probably enough problems for one day, so all you
folks who were
at the Flake meeting, let me know what you think! ^_^

Thanks,
-- BKS
_______________________________________________
koffice-devel mailing list
koffice-develkde.org
h
ttps://mail.kde.org/mailman/listinfo/koffice-devel

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
_______________________________________________
koffice-devel mailing list
koffice-develkde.org
h
ttps://mail.kde.org/mailman/listinfo/koffice-devel

On Mon, 21 Aug 2006 19:26:05 +0200, Thomas Zander inscribed:
> 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.

So the KoCreateShapesTool is how shapes can associate
themselves to a
parent document or shape? Ok, I can work with that.
 
> - 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);

How does this work when only a subset of a shape (e.g. a few
words in a
KoTextShape) is selected? I guess the tool needs some
(perhaps private)
way of informing the shape what the current selection is.
(e.g. the
KoTextTool could pass a QTextCursor or something to the
KoTextShape?)

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

Fleshing this out a bit more, I think that appropriate
method
signatures would be something like

void KoShape::loadAs(QIODevice *source, const QString&
mimeType,
KoCreateShapesTool *createTool) {
  // we can create a KoStore from |source|, or read an image
from it,
  // or insert it as raw data, or whatever is appropriate
  // 
}

enum SaveWhat { SaveSelection, SaveEntireShape };

void KoShape::saveAs(QIODevice *dest, const QString&
mimeType,
KoShape::SaveWhat what) {
  // store either the selection or the entire shape into
|dest|;
  // the definition of the selection is privately negotiated
between
  // a shape and its tools
}

// returns list of supported mime types, perhaps from
//  a KServiceTypeTrader query for import plugins?
QList<QString> KoShape::canLoadAs() const;

// returns list of supported mime types, perhaps from
//  a KServiceTypeTrader query for export plugins?
QList<QString> KoShape::canSaveAs() const;

(Method names are, of course, open to better suggestions.)

The can*As() queries are then duplicated into KoTool, which
can
delegate the queries to the selected shape or restrict them
to a
subset or add new ones (e.g., the KoTextTool might add
whatever the
mime type is for a literal URL to its canLoadAs() list,
since it
knows how to insert links, even though it doesn't make much
sense
IMHO for the KoTextShape to pretend to be able to
"load" from them):

QList<QString> KoTool::canSaveAs() const;
QList<QString> KoTool::canLoadAs() const;

The queries are useful to populate open or save as
dialogs, as well as tp decide whether to give drops or paste
requests
to the current tool. I think it's reasonable to assume that
if the
clipboard or drop request is of a type that the current tool
knows
how to handle, it should be expected to accept it? 

(How do drop requests get handled when there is no current
tool? As a
user, I would expect dropping an image from Firefox on to my
document 
to depend only on where I drop it, not on whether I had the
TextTool 
selected or not... Maybe there should be a KoDropTool that
is 
automatically created on a dragStarted() or dragEntered()
event, that 
then delegates the drop to the default tool of whatever
shape the drop 
is on?)

As you can see, I'm also trying to figure out where import
and export
plugins fit into this... I think that they should be
discovered and
used by the appropriate Shapes? So e.g. the KoTextShape
could query for
and find a KoHtmlTextImporter that knows how to take HTML
and feed it
into a KoTextShape? Perhaps just
KoImporterPlugin::importAs() which
mirrors KoShape::loadAs(), except that it manipulates an
external
shape, and likewise for KoExporterPlugin::exportAs() and
KoShape::saveAs()? The plugins wouldn't need can*As(),
since that would
be declared in their .desktop... For a constructor, maybe
just

KoImporterPlugin::KoImporterPlugin(KoShape *target);

and the constructor does a static_cast<> to the
appropriate shape
(e.g. static_cast<KoTextShape> for the
KoHtmlTextImporter)?

As for the KoCreateShapesTool, it needs a

  KoShape * KoCreateShapesTool::createShape(QIODevice *src,
const
QString& mimeType);

and also, to do much of the real work, (for ODF at least), a

  KoShape * KoCreateShapesTool::createShape(KoStore *store,
QDomElement
elem);

The KoStore is important, since e.g. images are stored
out-of-line, in
another file in the ODF zip archve.

What about error handling? Should the shape simply have a 

signals:
  void loadFailed(const QString& reason);

to report when something didn't work? Or do we want
something a bit more
complex so that we can let the user do partial imports up to
the broken
point?

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

Sounds good to me.
 
> >   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.

My idea was that this would simply be a saveAs(buf,
mimeType,
KoShape::SaveSeleection), where buf is a QBuffer; the
underlying
QByteArray can then be given to a QMimeData.

> [other stuff snipped for now]

KoTools should probably be given some extensions to
adequately deal
with selections and such... perhaps

signals:
// emitted as true when something is selected, false when
the selection
// is cleared -- good for (e.g.) enabling the cut and copy
actions
  void KoTool::hasSelection(bool);

public:
// asks the tool to paste as the given mimetype, or as the
best
// available if |mimeType| is empty -- lets applications
implement
// "Paste As..." logic, while letting shapes
decide what the "best"
// format is
  void KoTool::paste(QMimeData *source, const QString&
mimeType);

Thinking further on the "Paste As..." menu, that
is really IMHO a
property of the current clipboard contents, and so _has_ to
be managed
by the application, perhaps with the help of the shape
registry.

That's probably enough for now, it's getting kind of late
here. Let me
know what you think.

Thanks,
-- BKS
_______________________________________________
koffice-devel mailing list
koffice-develkde.org
h
ttps://mail.kde.org/mailman/listinfo/koffice-devel

Morning 
Long emails, but progress is being made! Thanks for taking
this on.

On Thursday 24 August 2006 06:35, Benjamin K. Stuhl wrote:
> On Mon, 21 Aug 2006 19:26:05 +0200, Thomas Zander
inscribed:

> > 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);
>
> How does this work when only a subset of a shape (e.g.
a few words in a
> KoTextShape) is selected? I guess the tool needs some
(perhaps private)
> way of informing the shape what the current selection
is. (e.g. the
> KoTextTool could pass a QTextCursor or something to the
KoTextShape?)

The selection inside the shape is always part of the Tool,
In the case of 
the KoTextShape there is a QTextCursor member.
In the case of the KoPathTool there is a:
QList<KoPathPoint*> m_selectedPoints

> > }
> > 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.
>
> Fleshing this out a bit more, I think that appropriate
method
> signatures would be something like
>
> void KoShape::loadAs(QIODevice *source, const
QString& mimeType,
> KoCreateShapesTool *createTool) {
>   // we can create a KoStore from |source|, or read an
image from it,
>   // or insert it as raw data, or whatever is
appropriate
>   //
> }

I don't think the mimetype should be there Any instance of
a KoShape has 
only the required knowledge for loading exactly one
mimetype. No more.  A 
textShape can only load a whole text in ODT format. A
PathShape can only 
load a path in ODG format.  [more on this below]

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.

> enum SaveWhat { SaveSelection, SaveEntireShape };
>
> void KoShape::saveAs(QIODevice *dest, const
QString& mimeType,
> KoShape::SaveWhat what) {
>   // store either the selection or the entire shape
into |dest|;
>   // the definition of the selection is privately
negotiated between
>   // a shape and its tools
> }

Due to MVC separation, I think the selection will have to be
passed here 
in some way. Since you can't have a member in KoShape to
point either to 
the tool or to the selection.
I'd suggest to have a save() method like you describe and a
second method 
saveSelection() which is only implemented on the shapes that
actually 
need it.
Reason for this suggestion is that  a) many shapes don't do
selection 
(that can be saved) anyway.  b) in the shape that needs it
you can 
finetune the signature of the saveSelection method to pass
the needed 
info. Like a:
  KoTextShape::saveSelection(dest, int from, int length).

Same comment about the mimetype as above.

> // returns list of supported mime types, perhaps from
> //  a KServiceTypeTrader query for import plugins?
> QList<QString> KoShape::canLoadAs() const;
>
> // returns list of supported mime types, perhaps from
> //  a KServiceTypeTrader query for export plugins?
> QList<QString> KoShape::canSaveAs() const;

This would have to be moved to somewhere else since a Shape
instance is 
not present when you are searching for "Who can load
this!".
And I guess you don't want to instantiate one shape of all
plugins to find 
out if it can load the data you have 

We have all instances of KoShapeFactorys, so I suggest
having a getter 
there.

This indeed throws a big wrench into your plan to have
shapes do the 
loading on dragNdrop. I would guess that the suggestion you
made to have 
a dropTool which is activated on drag-enter or similar would
be a good 
alternative idea. The advantage that that gives are non
trivial.
For example we can highlight a shape which can take the drop
with an 
outline, or just the whole page when there is no such shape
selected.
With multithreading we can even parse the drop data while
the user is 
still dragging it and show a preview of the data
half-transparent on the 
canvas 

So, in overview;
* KoTool inheriting classes handle selection-based pastes.
Possibly using 
a loadSelection on the shape its working on.
* KoShape inheriting classes handle single loading of
single-shape data 
(no subobjects) coming from the KoCreateShapesTool.
* KoShapeContainer inheriting classes handle loading of
multi-shape-data 
coming from, and with callbacks to KoCreateShapesTool
* KoCreateShapesTool handles pastes that current tool
delegates and DnD 
loading which is delegated by KoDropTool
* a new KoDropTool is created which decides where data will
go. Inside a 
shape, shapeContainer or to the page.

Saving is only relevant for KoShape, KoShapeContainer and
KoTool (for 
current selection of the active shape(s)).

> As you can see, I'm also trying to figure out where
import and export
> plugins fit into this... I think that they should be
discovered and
> used by the appropriate Shapes? So e.g. the KoTextShape
could query for
> and find a KoHtmlTextImporter that knows how to take
HTML and feed it
> into a KoTextShape?

We use KoFilter in KOffice 1.x for that. This is a service
based framework 
where each filter has a 
"X-KDE-Import=application/x-kword" 
and "X-KDE-Export=Foo" pair.
I think we should use and extend that for cases like a html
drop on a 
shape that takes rich-text (KoTextShape) or an image
(Krita-layer) by 
using a filterchain that convert from html to ODT (which the
textshape 
can load) or png to .kra which the krita shape should be
able to load.

> Perhaps just KoImporterPlugin::importAs() which 
> mirrors KoShape::loadAs(), except that it manipulates
an external
> shape, and likewise for KoExporterPlugin::exportAs()
and
> KoShape::saveAs()? The plugins wouldn't need can*As(),
since that would
> be declared in their .desktop... For a constructor,
maybe just
>
> KoImporterPlugin::KoImporterPlugin(KoShape *target);
>
> and the constructor does a static_cast<> to the
appropriate shape
> (e.g. static_cast<KoTextShape> for the
KoHtmlTextImporter)?

Since all shapes are plugins (including the KoTextShape) I
don't see how 
that can work. The fact that KoTextShape is located in
libs/kotext is 
just legacy and its likely it will move to /shapes/text
before the 
release.

> What about error handling? Should the shape simply have
a
>
> signals:
>   void loadFailed(const QString& reason);
>
> to report when something didn't work? Or do we want
something a bit
> more complex so that we can let the user do partial
imports up to the
> broken point?

AFAICS just returning a boolean would work fine.

> KoTools should probably be given some extensions to
adequately deal
> with selections and such... perhaps
>
> signals:
> // emitted as true when something is selected, false
when the selection
> // is cleared -- good for (e.g.) enabling the cut and
copy actions
>   void KoTool::hasSelection(bool);

Sounds good.

> public:
> // asks the tool to paste as the given mimetype, or as
the best
> // available if |mimeType| is empty -- lets
applications implement
> // "Paste As..." logic, while letting
shapes decide what the "best"
> // format is
>   void KoTool::paste(QMimeData *source, const
QString& mimeType);
>
> Thinking further on the "Paste As..." menu,
that is really IMHO a
> property of the current clipboard contents, and so
_has_ to be managed
> by the application, perhaps with the help of the shape
registry.
>
> That's probably enough for now, it's getting kind of
late here. Let me
> know what you think.

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.

-- 
Thomas Zander
_______________________________________________
koffice-devel mailing list
koffice-develkde.org
h
ttps://mail.kde.org/mailman/listinfo/koffice-devel

On Thursday 24 August 2006 10:21, Thomas Zander wrote:

> This indeed throws a big wrench into your plan to have
shapes do the
> loading on dragNdrop. I would guess that the suggestion
you made to have
> a dropTool which is activated on drag-enter or similar
would be a good
> alternative idea. The advantage that that gives are non
trivial.
> For example we can highlight a shape which can take the
drop with an
> outline, or just the whole page when there is no such
shape selected.
> With multithreading we can even parse the drop data
while the user is
> still dragging it and show a preview of the data
half-transparent on the
> canvas 

Now that would be so cool...

-- 
Boudewijn Rempt 
http://www.va
ldyas.org/fading/index.cgi
_______________________________________________
koffice-devel mailing list
koffice-develkde.org
h
ttps://mail.kde.org/mailman/listinfo/koffice-devel

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. ^_^
 
> On Thursday 24 August 2006 06:35, Benjamin K. Stuhl
wrote:
> > On Mon, 21 Aug 2006 19:26:05 +0200, Thomas Zander
inscribed:
> 
> > > 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);
> >
> > How does this work when only a subset of a shape
(e.g. a few words
> > in a KoTextShape) is selected? I guess the tool
needs some (perhaps
> > private) way of informing the shape what the
current selection is.
> > (e.g. the KoTextTool could pass a QTextCursor or
something to the
> > KoTextShape?)
> 
> The selection inside the shape is always part of the
Tool, In the
> case of the KoTextShape there is a QTextCursor member.
> In the case of the KoPathTool there is a:
> QList<KoPathPoint*> m_selectedPoints

Ok.
 
> > > }
> > > 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.
> >
> > Fleshing this out a bit more, I think that
appropriate method
> > signatures would be something like
> >
> > void KoShape::loadAs(QIODevice *source, const
QString& mimeType,
> > KoCreateShapesTool *createTool) {
> >   // we can create a KoStore from |source|, or
read an image from
> > it, // or insert it as raw data, or whatever is
appropriate
> >   //
> > }
> 
> I don't think the mimetype should be there Any
instance of a KoShape
> has only the required knowledge for loading exactly one
mimetype. No
> more.  A textShape can only load a whole text in ODT
format. A
> PathShape can only load a path in ODG format.  [more on
this below]
> 
> 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?
or, thinking a bit more, I suppose the KoCreateShapesTool is
the one
that needs to be able to figure out "I have a chunk of
text/html, I
can use a filter chain to get it to ODT, so I need to create
a
KoTextTool"... but that still leaves perhaps a
KoSaveTool to take the
XML from the KoTextTool and convert it to, say, LaTeX.)

Does every application in koffice do its loading from XML in
a KoStore?
Then instead of the QIODevice*, we could pass (KoStore
*store,
QDomElement elem), just like we do to the createShape(). We
do still
need the 

> > enum SaveWhat { SaveSelection, SaveEntireShape };
> >
> > void KoShape::saveAs(QIODevice *dest, const
QString& mimeType,
> > KoShape::SaveWhat what) {
> >   // store either the selection or the entire
shape into |dest|;
> >   // the definition of the selection is privately
negotiated between
> >   // a shape and its tools
> > }
> 
> Due to MVC separation, I think the selection will have
to be passed
> here in some way. Since you can't have a member in
KoShape to point
> either to the tool or to the selection.
> I'd suggest to have a save() method like you describe
and a second
> method saveSelection() which is only implemented on the
shapes that
> actually need it.
> Reason for this suggestion is that  a) many shapes
don't do selection 
> (that can be saved) anyway.  b) in the shape that needs
it you can 
> finetune the signature of the saveSelection method to
pass the needed 
> info. Like a:
>   KoTextShape::saveSelection(dest, int from, int
length).
> 
> Same comment about the mimetype as above.

So then there would need to be KoTool::cut(),
KoTool::copy(), and
KoTool::paste() methods to connect the application to the
shape? (And,
presumably, the shape manipulation tool would need to be
able to cut,
copy, and paste one or more entire shapes? But that's ok,
since that
can just use the public KoShape::save() and KoShape::load()
methods.)

> > // returns list of supported mime types, perhaps
from
> > //  a KServiceTypeTrader query for import plugins?
> > QList<QString> KoShape::canLoadAs() const;
> >
> > // returns list of supported mime types, perhaps
from
> > //  a KServiceTypeTrader query for export plugins?
> > QList<QString> KoShape::canSaveAs() const;
> 
> This would have to be moved to somewhere else since a
Shape instance
> is not present when you are searching for "Who
can load this!".
> And I guess you don't want to instantiate one shape of
all plugins to
> find out if it can load the data you have 
> 
> We have all instances of KoShapeFactorys, so I suggest
having a
> getter there.

Ok.

> This indeed throws a big wrench into your plan to have
shapes do the 
> loading on dragNdrop. I would guess that the suggestion
you made to
> have a dropTool which is activated on drag-enter or
similar would be
> a good alternative idea. The advantage that that gives
are non
> trivial. For example we can highlight a shape which can
take the drop
> with an outline, or just the whole page when there is
no such shape
> selected. With multithreading we can even parse the
drop data while
> the user is still dragging it and show a preview of the
data
> half-transparent on the canvas 
> 
> So, in overview;
> * KoTool inheriting classes handle selection-based
pastes. Possibly
> using a loadSelection on the shape its working on.
> * KoShape inheriting classes handle single loading of
single-shape
> data (no subobjects) coming from the
KoCreateShapesTool.
> * KoShapeContainer inheriting classes handle loading of
> multi-shape-data coming from, and with callbacks to
KoCreateShapesTool

And _anything_ that can have some other format embedded in
it is a
KoShapeContainer? Ok.

> * KoCreateShapesTool handles pastes that current tool
delegates and
> DnD loading which is delegated by KoDropTool

Yup; the KoDropTool itself delgates the actual data transfer
back to
the shape's default tool or to the KoCreateShapesTool, as
appropriate.

> * a new KoDropTool is created which decides where data
will go.
> Inside a shape, shapeContainer or to the page.
> 
> Saving is only relevant for KoShape, KoShapeContainer
and KoTool (for 
> current selection of the active shape(s)).
> 
> > As you can see, I'm also trying to figure out
where import and
> > export plugins fit into this... I think that they
should be
> > discovered and used by the appropriate Shapes? So
e.g. the
> > KoTextShape could query for and find a
KoHtmlTextImporter that
> > knows how to take HTML and feed it into a
KoTextShape?
> 
> We use KoFilter in KOffice 1.x for that. This is a
service based
> framework where each filter has a 
"X-KDE-Import=application/x-kword" 
> and "X-KDE-Export=Foo" pair.
> I think we should use and extend that for cases like a
html drop on a 
> shape that takes rich-text (KoTextShape) or an image
(Krita-layer) by 
> using a filterchain that convert from html to ODT
(which the
> textshape can load) or png to .kra which the krita
shape should be
> able to load.

I know _of_ the filter framework, but I'll need to take a
deeper look
at it... my only concern is, do the filters all produce ODF,
or do they
still produce legacy .k*?

That also brings up a side question: is the plan to use the
krita shape
for _all_ embedded images? It seems to me that that might be
a bit of
overkill? (Not to mention slow, since it has to convert PNG
and JPEG
images to .kra on loading and then back again on saving,
since .kra is
not one of the image formats ODF supports... :-/) Perhaps it
might be
work making just a KoPictureShape that supports anything
QImage does
and just has trivial resize and "Open in Krita"
actions? (Even MSOffice
pops open a Paint window to edit raster images.)

Also, I would suggest that KoTool::activate() should get a
QPoint(F?)
(I'm not really sure when to use which version...) argument
so that you
can, say, simply click a text shape twice (or double-click)
to get the
cursor where you clicked? It's really rather irritating to
always have
to mouse over to the toolbox to be able to enter text in a
word
processor... ^_^

> > Perhaps just KoImporterPlugin::importAs() which 
> > mirrors KoShape::loadAs(), except that it
manipulates an external
> > shape, and likewise for
KoExporterPlugin::exportAs() and
> > KoShape::saveAs()? The plugins wouldn't need
can*As(), since that
> > would be declared in their .desktop... For a
constructor, maybe just
> >
> > KoImporterPlugin::KoImporterPlugin(KoShape
*target);
> >
> > and the constructor does a static_cast<> to
the appropriate shape
> > (e.g. static_cast<KoTextShape> for the
KoHtmlTextImporter)?
> 
> Since all shapes are plugins (including the
KoTextShape) I don't see
> how that can work. The fact that KoTextShape is located
in
> libs/kotext is just legacy and its likely it will move
> to /shapes/text before the release.

True. Linking plugins against other plugins is unportable,
IIRC?
(MaxOSX?)

> > What about error handling? Should the shape simply
have a
> >
> > signals:
> >   void loadFailed(const QString& reason);
> >
> > to report when something didn't work? Or do we
want something a bit
> > more complex so that we can let the user do
partial imports up to
> > the broken point?
> 
> AFAICS just returning a boolean would work fine.

I just thought it might be nice to be able to say
"your document did not
load, because the ZIP file was corrupted" or
"your document did not
load because no manifest could be found" rather than
just "unable to
open document"... but that is a nicety that could
probably be added
later.

> > KoTools should probably be given some extensions
to adequately deal
> > with selections and such... perhaps
> >
> > signals:
> > // emitted as true when something is selected,
false when the
> > selection // is cleared -- good for (e.g.)
enabling the cut and
> > copy actions void KoTool::hasSelection(bool);
> 
> Sounds good.

How should shapes declare that they do not accept drops or
pastes of
their mimetype? Just a

bool KoShape::acceptsDrops() const;

?

> > public:
> > // asks the tool to paste as the given mimetype,
or as the best
> > // available if |mimeType| is empty -- lets
applications implement
> > // "Paste As..." logic, while letting
shapes decide what the "best"
> > // format is
> >   void KoTool::paste(QMimeData *source, const
QString& mimeType);
> >
> > Thinking further on the "Paste As..."
menu, that is really IMHO a
> > property of the current clipboard contents, and so
_has_ to be
> > managed by the application, perhaps with the help
of the shape
> > registry.
> >
> > That's probably enough for now, it's getting
kind of late here. Let
> > me know what you think.
> 
> 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...

Thanks,
-- BKS
_______________________________________________
koffice-devel mailing list
koffice-develkde.org
h
ttps://mail.kde.org/mailman/listinfo/koffice-devel

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?

-- BKS

Index: flake/KoShape.h
============================================================
=======
--- flake/KoShape.h	(revision 576400)
+++ flake/KoShape.h	(working copy)
 -34,6
+34,7 
 class QRectF;
 class QPainterPath;
 class QVariant;
+class QDomElement;
 
 class KoSelection;
 class KoPointerEvent;
 -41,6
+42,8 
 class KoShapeBorderModel;
 class KoShapeManager;
 class KoShapeUserData;
+class KoCreateShapesTool;
+class KoStore;
 
 /**
  *
 -106,6
+109,31 
      */
     virtual void paintDecorations(QPainter &painter,
const KoViewConverter &converter, bool selected);
 
+    /** 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;
+
+    /** 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;
+
     /**
      * brief Scale the shape using the zero-point which is
the top-left corner.
      * see position()
 -400,6
+428,20 
     bool keepAspectRatio() const { return m_keepAspect; }
 
     /**
+     * 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; }
+
+    /**
      * Return the position of this shape regardless of
rotation/skew/scaling and regardless of
      * this shape having a parent (being in a group) or
not.<br>
      * The returned value is the center of the shape.
 -527,7
+569,7 
     int m_zIndex;
     KoShapeContainer *m_parent;
 
-    bool m_visible, m_locked, m_keepAspect;
+    bool m_visible, m_locked, m_keepAspect, m_acceptDrops;
 
 
     QSet<KoShapeManager *> m_shapeManagers;
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);
 
+    /**
+     * Called when a Cut action has been requested.
Implementors may need to add
+     * some sort of saveSelection() method to the tool's
shape if the tool has a notion
+     * of a selection 
+     */
+    virtual void cut() = 0;
+
+    /**
+     * Called when a Copy action has been requested.
Implementors may need to add
+     * some sort of saveSelection() method to the tool's
shape if the tool has a notion
+     * of a selection 
+     */
+    virtual void copy() = 0;
+
+    /**
+     * Called when a Paste action has been requested.
Implementors may need to add
+     * some sort of loadAtCursor() method to the tool's
shape if the tool has a notion
+     * of a cursor. This method is also used to implement
drops, in which case p where
+     * is the position of the drop; otherwise p
where.isNull() is true. If the tool's
+     * associated shapes return false for their
acceptDrops() method, this method will 
+     * never be called.
+     * param where the position that the drop was executed,
or (0, 0) if there is no position
+     */
+    virtual void paste(const QPoint &where) = 0;
+
 signals:
 
     /**
 -177,6
+203,16 
      */
     void sigCursorChanged(QCursor cursor);
 
+    /**
+     * This signal is used to inform the application that
the tool does or does not
+     * currently have a selection, and so the application
should enable or disable
+     * actions such as Cut or Copy which require there to
be a selection. Note that
+     * tools are responsible themselves for managing the
QClipboard::Selection
+     * clipboard, since filling that is implicit in having
made a selection.
+     * param hasSelection if true, the tool currently has a
selection
+     */
+    void sigHasSelection(bool hasSelection);
+
 protected:
     /**
      * Classes inheriting from this one can call this
method to signify which cursor
_______________________________________________
koffice-devel mailing list
koffice-develkde.org
h
ttps://mail.kde.org/mailman/listinfo/koffice-devel

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-develkde.org
h
ttps://mail.kde.org/mailman/listinfo/koffice-devel

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 bond :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
_______________________________________________
koffice-devel mailing list
koffice-develkde.org
h
ttps://mail.kde.org/mailman/listinfo/koffice-devel

On Thursday 24 August 2006 17:16, Benjamin K. Stuhl wrote:
> Also, I would suggest that KoTool::activate() should
get a QPoint(F?)
> (I'm not really sure when to use which version...)
argument so that you
> can, say, simply click a text shape twice (or
double-click) to get the
> cursor where you clicked? It's really rather
irritating to always have
> to mouse over to the toolbox to be able to enter text
in a word
> processor... ^_^

I've had the horrible experience of having to use Scribus
for the last 
week. The way that focus is switched between items is truly
horrible and, 
well, .. just leave it at that.

So, after figuring out how _not_ to do it here are some
ideas on what is 
easier and better.

* Tools are sticky.  With this I mean that having a text
tool in use and 
clicking on another text shape should keep that tool. No
(auto) 
unselecting and reselecting is allowed 
* Double click to start using the shapes tool should work.
* single click on the empty canvas should deselect all
shapes. Combined 
with point 1 the default tool should become usable (to
select another 
shape) but if the current tool is usable on the newly
selected shape 
there it should be switched to immediately.  In other words;
switching 
shape by unselecting and reselecting should not forget the
tool.


-- 
Thomas Zander
_______________________________________________
koffice-devel mailing list
koffice-develkde.org
h
ttps://mail.kde.org/mailman/listinfo/koffice-devel

On Thursday 24 August 2006 17:16, Benjamin K. Stuhl wrote:
> That also brings up a side question: is the plan to use
the krita shape
> for _all_ embedded images? It seems to me that that
might be a bit of
> overkill? (Not to mention slow, since it has to convert
PNG and JPEG
> images to .kra on loading and then back again on
saving, since .kra is
> not one of the image formats ODF supports... :-/)
Perhaps it might be
> work making just a KoPictureShape that supports
anything QImage does
> and just has trivial resize and "Open in
Krita" actions? (Even MSOffice
> pops open a Paint window to edit raster images.)

For simple RGB (A) images a QImage will likely be enough,
but its not as 
simple as that.
When we want to print an image we need to have color
profiles support. 
Importing non-rgb images needs the krita shape anyway. And
above all, 
having one common interface to all images is important.

So, I'm not sure if there is much gain in having two, but
if there are 
then we should make the transition as smooth as possible.

For now; I'd like to see where things lead with just having
a Krita shape.
-- 
Thomas Zander
_______________________________________________
koffice-devel mailing list
koffice-develkde.org
h
ttps://mail.kde.org/mailman/listinfo/koffice-devel

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
_______________________________________________
koffice-devel mailing list
koffice-develkde.org
h
ttps://mail.kde.org/mailman/listinfo/koffice-devel

> For simple RGB (A) images a QImage will likely be
enough, but its not as
> simple as that.
> When we want to print an image we need to have color
profiles support.
> Importing non-rgb images needs the krita shape anyway.
And above all,
> having one common interface to all images is important.
>
> So, I'm not sure if there is much gain in having two,
but if there are
> then we should make the transition as smooth as
possible.
>
> For now; I'd like to see where things lead with just
having a Krita shape.

stupid question: having only krita's image shape, wouldn't
that make kword 
somehow depend on krita ? I mean, adding an image to a
document is a very 
important feature, so lets say that krita isn't installed,
the user can't add 
images ? or won't see images in the document he opened ? If
I am correct, I 
think that a qimage shape might be usefull as a backup
solution if krita is 
not available.

-- 
--- Cyrille Berger ---
_______________________________________________
koffice-devel mailing list
koffice-develkde.org
h
ttps://mail.kde.org/mailman/listinfo/koffice-devel

On Friday 1 September 2006 18:11, Cyrille Berger wrote:
> > For now; I'd like to see where things lead with
just having a Krita
> > shape.
>
> stupid question: having only krita's image shape,
wouldn't that make
> kword somehow depend on krita ? I mean, adding an image
to a document
> is a very important feature, so lets say that krita
isn't installed,
> the user can't add images ? or won't see images in
the document he
> opened ? If I am correct, I think that a qimage shape
might be usefull
> as a backup solution if krita is not available.

I think thats a good point. But at the same time I'm
thinking about cases 
like not having a formula shape available with approximately
the same 
issues.
Most corporate documents actually don't have images (be
sure to make the 
distinction between vector and raster here!) and the vector
shape are 
supplied by koffice libs.

Having the qimage fallback sounds nice, but I fear that
telling the user 
we can't print (with color management anyway) while we will
show the 
image on screen will not be accepted leading to a slippery
slope of 
moving all features into a shape.

That said; if someone has time to create (AND MAINTAIN) such
a qimage 
shape and all the problems due to it, I don't have a big
problem against 
it 

-- 
Thomas Zander
_______________________________________________
koffice-devel mailing list
koffice-develkde.org
h
ttps://mail.kde.org/mailman/listinfo/koffice-devel

On Fri, 1 Sep 2006, Thomas Zander wrote:

> For now; I'd like to see where things lead with just
having a Krita shape.

Amen to that.

Boudewijn

_______________________________________________
koffice-devel mailing list
koffice-develkde.org
h
ttps://mail.kde.org/mailman/listinfo/koffice-devel

On Friday 01 September 2006 18:34, Thomas Zander wrote:
> I think thats a good point. But at the same time I'm
thinking about cases
> like not having a formula shape available with
approximately the same
> issues.

> Most corporate documents actually don't have images
(be sure to make the
> distinction between vector and raster here!) and the
vector shape are
> supplied by koffice libs.

Well, most logo's I see on corporate documents are bitmaps
-- jpegs, to add 
insult to injury! But then, I usually only see the output
from smaller 
companies who generally don't have competent design staff.

> Having the qimage fallback sounds nice, but I fear that
telling the user
> we can't print (with color management anyway) while we
will show the
> image on screen will not be accepted leading to a
slippery slope of
> moving all features into a shape.

I would not mind moving the basis KisPaintDevice, being a
color managed single 
layer raster image into KOffice libs, similar to the vector
shapes, while 
still keeping all the fancy tools and filters in Krita.
Shapes are general 
building blocks, while applications are the specialized user
interfaces for a 
specific task.

> That said; if someone has time to create (AND MAINTAIN)
such a qimage
> shape and all the problems due to it, I don't have a
big problem against
> it 

-- 
Boudewijn Rempt 
http://www.va
ldyas.org/fading/index.cgi
_______________________________________________
koffice-devel mailing list
koffice-develkde.org
h
ttps://mail.kde.org/mailman/listinfo/koffice-devel

> > Most corporate documents actually don't have
images (be sure to make the
> > distinction between vector and raster here!) and
the vector shape are
> > supplied by koffice libs.
>
> Well, most logo's I see on corporate documents are
bitmaps -- jpegs, to add
> insult to injury! But then, I usually only see the
output from smaller
> companies who generally don't have competent design
staff.

plus I have see quiet a lot of technical document including
images (bitmap 
ones), and mostly people wouldn't care about color
management for those 
document (at least while red looks like red and not green on
other 
computers).

> > Having the qimage fallback sounds nice, but I fear
that telling the user
> > we can't print (with color management anyway)
while we will show the
> > image on screen will not be accepted leading to a
slippery slope of
> > moving all features into a shape.
>
> I would not mind moving the basis KisPaintDevice, being
a color managed
> single layer raster image into KOffice libs, similar to
the vector shapes,
seems a good idea for me. as pigment is allready in kolib,
there isn't much 
code left to move in.

> while still keeping all the fancy tools and filters in
Krita. Shapes are
> general building blocks, while applications are the
specialized user
> interfaces for a specific task.
that brings us to the last thing I don't understand about
flake (I think). 
Maybe it belongs to an other thread ? So a little scenario,
I have launched 
kword, I am writting a document, I add an image to it (it's
using krita's 
flake shape), now I select it, what happen ? does the gui
suddently get 
filled with krita tools/filters/palettes/whatever ? or an
edit button appears 
offering me to launch it in a krita window ?

-- 
--- Cyrille Berger ---
_______________________________________________
koffice-devel mailing list
koffice-develkde.org
h
ttps://mail.kde.org/mailman/listinfo/koffice-devel

On Saturday 02 September 2006 12:53, Cyrille Berger wrote:
> > I would not mind moving the basis KisPaintDevice,
being a color managed
> > single layer raster image into KOffice libs,
similar to the vector
> > shapes,
> seems a good idea for me. as pigment is allready in
kolib, there isn't much
> code left to move in.
Of course there is. KisPaintDevice uses (for starters)
KisLayer, KisPainter, 
KisImage, KisMemento, KisSelection, and of course the entire
tile management 
system. Unless you'd also call that not much and plan to
dump them in 
KOfficelibs, or somehow split those of off the
KisPaintDevice, of course.

Bart
_______________________________________________
koffice-devel mailing list
koffice-develkde.org
h
ttps://mail.kde.org/mailman/listinfo/koffice-devel

On Saturday 2 September 2006 10:18, Boudewijn Rempt wrote:
> > Having the qimage fallback sounds nice, but I fear
that telling the
> > user we can't print (with color management
anyway) while we will show
> > the image on screen will not be accepted leading
to a slippery slope
> > of moving all features into a shape.
>
> I would not mind moving the basis KisPaintDevice, being
a color managed
> single layer raster image into KOffice libs, similar to
the vector
> shapes, while still keeping all the fancy tools and
filters in Krita.
> Shapes are general building block

I personally don't see the gain in that. I know that since
we are 
technical we tend to focus on corner cases, but really, how
usefull is it 
to design for the one case where people want to have images
in their 
documents but refuse to install krita (aka the rest of
koffice) ?

I'd say that this is the (small) downside of integrating
all KOffice apps 
more, that people have to have more installed.
-- 
Thomas Zander
_______________________________________________
koffice-devel mailing list
koffice-develkde.org
h
ttps://mail.kde.org/mailman/listinfo/koffice-devel

On Saturday 2 September 2006 12:53, Cyrille Berger wrote:
> > Well, most logo's I see on corporate documents
are bitmaps -- jpegs,
> > to add insult to injury! But then, I usually only
see the output from
> > smaller companies who generally don't have
competent design staff.
>
> plus I have see quiet a lot of technical document
including images
> (bitmap ones), and mostly people wouldn't care about
color management
> for those document (at least while red looks like red
and not green on
> other computers).

I have a problem with giving worse printed results based on
a missing 
component. People loose faith in the software if the output
is 
inconsistent even if its their stupid fault for not
downloading that 
2.5Mb package.

-- 
Thomas Zander
_______________________________________________
koffice-devel mailing list
koffice-develkde.org
h
ttps://mail.kde.org/mailman/listinfo/koffice-devel