[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: Review Request: bug fix "Text displayed at wrong place in this
From:       "Thomas Zander" <zander () kde ! org>
Date:       2010-05-14 12:12:09
Message-ID: 20100514121209.21260.17989 () localhost
[Download RAW message or body]


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/3699/#review5667
-----------------------------------------------------------


To be honest, I'd not go for either :)
The problem here is really that ODF has a ridiculous amount of choice (that I have a \
really really hard time justifying) and this is a problem because it turns up in our \
public API. The class should be easy to use first.

So, there are 3 conflicting things;
* we want to be able to load and save *all* ODF properties.
* we want to create a really nice and useful API for developers to program to
* we want to provide a nice user interface with selected options for the user.

Thinking about this longer my conclusion has to be that changing the design as it is \
now (with 7 and 6 items) and going for the either of the suggestions you made is not \
going to work for either my second or 3rd point. So how to make sure we can still \
load/save this stuff?

I suggest to move the 4 enums you propose to be defined on the private. Leave the 2 \
enums as they are in SVN intact. The loading saving code can store the values on the \
private so roundtripping will work. This would be in addition to the two existing \
enums already stored on the private with less options.

I know you will ask me now; how then will we support all 90 horizontal alignments and \
50 vertical ones and my answer simply is; we don't.  I'm open to find the most common \
ones saved in existing ODF files to see if we can add those to the public API or just \
map them onto there with some precision loss but supporting all of them is not \
something I think makes a whole lot of sense to me.

What do you think?

- Thomas


On 2010-05-07 15:20:10, Matus Hanzes wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/3699/
> -----------------------------------------------------------
> 
> (Updated 2010-05-07 15:20:10)
> 
> 
> Review request for KOffice.
> 
> 
> Summary
> -------
> 
> To place draw objects properly in kword document I needed to add more support for \
> anchoring in kword.(style:vertical-pos,style:vertical-rel,style:horizontal-pos,style:vertical-rel)
>  I tried to make anchoring backward compatible.
> 
> Comments are welcome.
> 
> 
> Diffs
> -----
> 
> trunk/koffice/kword/part/KWPageStyle.h 1123976 
> trunk/koffice/kword/part/KWPageStyle.cpp 1123976 
> trunk/koffice/kword/part/KWPageStyle_p.h 1123976 
> trunk/koffice/kword/part/KWPageTextInfo.h 1123976 
> trunk/koffice/kword/part/KWPageTextInfo.cpp 1123976 
> trunk/koffice/kword/part/frames/KWAnchorStrategy.h 1123976 
> trunk/koffice/kword/part/frames/KWAnchorStrategy.cpp 1123976 
> trunk/koffice/kword/part/frames/KWFrameLayout.cpp 1123976 
> trunk/koffice/kword/part/frames/KWTextDocumentLayout.cpp 1123976 
> trunk/koffice/libs/kotext/KoTextAnchor.h 1123976 
> trunk/koffice/libs/kotext/KoTextAnchor.cpp 1123976 
> trunk/koffice/libs/kotext/opendocument/KoTextLoader.cpp 1123976 
> 
> Diff: http://reviewboard.kde.org/r/3699/diff
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Matus
> 
> 

_______________________________________________
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]