Hi, thanks for comments. I vote for the removeProperty(), removeAttribute() pair. If you agree , then I will implement them and make a review request. :)
-- Matus Uzak Software Designer Ixonos Slovakia s.r.o. Sturova 27, 040 01 Kosice, Slovakia mobile 0421 918 718 958 email: matus.u...@ixonos.com http://www.ixonos.com ________________________________________ From: calligra-devel-boun...@kde.org [calligra-devel-boun...@kde.org] on behalf of Jaroslaw Staniek [stan...@kde.org] Sent: Saturday, October 29, 2011 3:03 PM To: Calligra Suite developers and users mailing list Subject: Re: KoGenStyle::rmProperty ? On 29 October 2011 13:13, C. Boemann <c...@boemann.dk> wrote: > On Saturday 29 October 2011 13:01:59 Pierre Ducroquet wrote: >> Quoting Uzak Matus <matus.u...@ixonos.com>: >> > Hi, >> > >> > I would like to discuss addition of a KoGenStyle::rmProperty method. >> > >> > There's a reason (maybe a stupid one) that I could make use of it in >> > libmsooxml at the moment without re-designing and rewriting a lot of >> > code. We collect there a number of KoGenStyle variables storing >> > predefined formatting for paragraphs that we inherit and modify by >> > any overrides for the current paragraph. >> > >> > That's OK for MS Word files. The problem is that positioning of >> > lists in MS PowerPoint is different compared to MS Word (here also >> > positioning of lists inside a text-box is different compared to the >> > main text). At the moment we construct a unique list style in case >> > of ppt/pptx and any floating/inline shapes found in doc/docx based >> > on both the list style and the paragraph style. I still need to >> > remove the inherited fo:margin-left and fo:text-indent from the >> > KoGenStyle for the paragraph because attributes defined in the >> > paragraph style have precedence over the list style. Otherwise we >> > would need a separate textlayout code for text in a text-box and >> > that for both ODP and ODT. >> > Of course that's the price for compatibility with MS Office. >> > >> > At the moment LO/OOo use a similar approach in ppt filters (we do a >> > better job actually), but not in pptx filters. To maintain >> > compatibility with LO/OOo is also important, but I don't think it's >> > doable without keeping the textlayout code simple or discussions >> > with their developers. >> > >> > br, >> > >> > -matus >> >> Hi >> >> After a (too) quick thinking about this, I don't see why we could not >> add a function in KoGenStyle... >> Except for the naming issue : do not call it that way... When I saw >> your mail title, I just did not understand what the topic was... >> Naming it deleteProperty would be far better :) >> > well the reason I asked Matus to send a mail is because, we once had some > method to manipulate styles and that wasn't kosher so we tried hard to remove > it again.I'd like Jaroslaw's opinion on this, before we conclude if it is a > good idea or not. Thanks for discussing this. So far I don't see reason not to add it except of course the naming, which would be removeProperty() to mimick the naming in QMap and QSet. When I look at implementation of the class: maybe we'd want to also add removeAttribute()? -- regards / pozdrawiam, Jaroslaw Staniek http://www.linkedin.com/in/jstaniek Kexi & Calligra (kexi-project.org, identi.ca/kexi, calligra-suite.org) KDE Software Development Platform on MS Windows (windows.kde.org) _______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel _______________________________________________ calligra-devel mailing list calligra-devel@kde.org https://mail.kde.org/mailman/listinfo/calligra-devel
