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

List:       koffice-devel
Subject:    Re: ODF Lists
From:       Pierre <pinaraf () pinaraf ! info>
Date:       2008-07-28 20:53:38
Message-ID: 200807282253.39341.pinaraf () pinaraf ! info
[Download RAW message or body]

On Monday 28 July 2008 17:44:07 Girish Ramakrishnan wrote:
> Thomas Zander wrote:
> > On Monday 28. July 2008 14:32:22 Pierre wrote:
> >>> Lets keep an open mind :)  Open source means taking advantage of peer
> >>> review, after all.
> >>
> >> Yes, but I'm quite tired of this discussion, sorry.
> >
> > I'm sorry for continuing a thread that apparently you have had with other
> > people as well. :(
> > The thing here is that your reasons for placing the property in a layout
> > structure seem odd to me. I'm thinking that maybe you are
> > misunderstanding some of the structures as I designed them in KOffice.
> > Allow me to try to find out where the confusion lies :)
> >
> >> I already explained that I stored it there because when saving, we could
> >> duplicate styles if we use the TextFormats.
> >
> > The thing is, there is no 1-to-one mapping between formats and styles.
> > Formats are just a data object in Qt and styles indeed copy their data
> > into it. But the formats store data from various other sources as well.
> > In effect a format is just a added document-data structure.
> >
> > With that in mind, I have a hard time following your arguments. How would
> > putting a boolean on the paragraph level have any effect on styles
> > saving?
>
> The reason for the confusion is that when we write out the ODF, we do a
> diff between the format (QTextBlockFormat, QTextCharFormat) and the
> style (KoParagraphStyle, KoCharacterStyle). This diff just does a blind
> compare of each and every key of the QMap of the format and the QMap of
> the style. Whatever is the diff, we generate as the automatic style.
>
> It could very well be that we have not explicitly ignored properties
> when comparing the QMaps above because the need has not arisen. But
> because of the way the code is right now, it leads to an understanding
> that a format and the ODF style have a one-one mapping.
That's what I was mentionning... Sorry for being really messy, close to 
unreadable...

> A reason to have it in the block format is copy/paste. When you copy the
> block, we want all the block properties - the fact that it is a heading
> too. Currently, this is not a problem since we save/load odf on
> copy/paste which is extremely inefficient when pasting with kword
> itself. A solution that is faster for internal copy/paste would involve
> just copying the format of the block (and we don't need to write any
> special code to save extra properties in block data).
>
> On a tangent: We desperately need information like this on a wiki
> (especially design). It is very hard on a new comer to understand all
> these intricacies. At least for this topic, I will put whatever the
> outcome on the wiki.
Agree...

> >> This attribute is not to be shared between several blocks, if we store
> >> it in a KoParagraphStyle, it could be "shared".
> >
> > Girish asked about putting it in a format, why are you talking about a
> > KoParagraphStyle?
>
> You read my mind and correctly translated what I meant, hee hee.
>
> For the rest, to be more clear: When I said "KoParagraphStyle property",
> I meant a KoParagraphStyle::IsHeader. I additionally meant that this
> property should be stored in the format as
> format.setProperty(KoParagraphStyle::IsHeader, true).
Well, do not hesitate to implement it this way... I can't do it myself because 
I have a lot of local changes and I don't want to mix this mess with something 
as simple as the headings. Moreover, I'm not physically able to do it right 
now (medics powered, sry)...

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