How to use a shape without using its tools?

[Inge Wallin]

On Thursday, July 07, 2011 09:57:51 Thorsten Zachmann wrote:
> On Thursday, July 07, 2011 09:34:55 Inge Wallin wrote:
> > I have just added a patch to the reviewboard:
> > http://git.reviewboard.kde.org/r/101871/  This mail is about an issue
> > with this patch.
> > 
> > Here is the description of (one of) the issues that it solves:
> > > 1. It fixes a serious issue with loading frame shapes with unknown
> > > contents. Previously, when a frame with unrecognized contents, such as
> > > an embedded spreadsheet, was loaded, it went through all the objects in
> > > the frame. If even one of the objects were recognized, such as a
> > > preview image, then a shape was created for that object. This means
> > > that the real contents of the frame got lost and only the preview
> > > image could be saved back.  This is not how it's supposed to be.  The
> > > new logic is to create an Unavail shape as soon as the payload of the
> > > frame, i.e. the first object in it, is unrecognized. It is then up to
> > > the unavail shape to load and store any preview images. It is also up
> > > to the unavail shape to save everything back. This patch does this.
> > > 
> > > 2. It gives the Unavail shape the ability to show preview images.
> > > Actually it gives the shape the ability to show both vector images
> > > using SVG and bitmap images using any format that QImage supports. We
> > > have not integrated this with the picture shape since we couldn't find
> > > a way to disable the picture tool for this shape alone.
> > 
> > I chatted with Zagge about this, and he said that he didn't like the fact
> > that with this patch, showing a preview image is only possible with svg
> > and bitmap formats.  All preview of other vector formats like WMF, EMF
> > and SVM is lost. This is true, and indeed serious.
> > 
> > When preparing this patch, Dan and I tried to integrate the picture shape
> > and if that had gone well also the vector shape. However, that failed
> > because we couldn't find a way to disable the picture tool. We do not
> > want the user to be able to replace the preview image with something
> > else.
> 
> I think we should not limit this functionality. I feel it would be much
> better to display a warning when the user edits the shape that it contains
> e.g. additional information that will be lost when the operation is done.

Remember that it's not the shape data itself that the user would be 
manipulating.  That data cannot be edited per definitions, since if Calligra 
understood it it wouldn't use the unavail shape to begin with.  A typical 
example is an embedded document, like a spreadsheet in an text document. 
Instead it's the image that is supposed to show the user what that data looks 
like. Since the user cannot edit the data, he shouldn't be able to edit the 
preview image.

If we allow the user to change the preview image and then save the result 
back, we could end up with an absurd situation like an embedded spreadsheet 
with a preview image of a flower.

> > So, as it is now the patch is important (it fixes a dataloss problem) but
> > it also removes some nice preview features.  We would be able to solve
> > this problem if we could find a way to use the image or vector shapes but
> > with their tools disabled.  Any ideas on how to do that?
> 
> I see at least 2 ways to do that.
> 
> 1. Use a ProxyShape that displays the content of the shape that can
> represent the data. A mechanism like that is used in the KWCopyShape that
> displays the content of another shape at a different position.

This is interesting.  Is there such a ProxyShape that is available for all to 
use?  That should probably be in the flake library rather than an application. 

> 2. Use a flag that disables modification of the shape by its tool.

This sounds much simpler.  But we must only disable the tools of the shape 
itself, not e.g. the default tool because then we wouldn't be able to move the 
shape. That should be allowed even if we cannot edit the contents.

> Both methods can also be used to implement the warning I talked about
> above.
> 
> Throsten
> _______________________________________________
> calligra-devel mailing list
> calligra-devel at kde.org
> https://mail.kde.org/mailman/listinfo/calligra-devel