Subject: Re: End lines patch - msg#00172

Previous Message by Date: click to view message preview

End lines patch

Hi,I made a patch to add shapes and the end of lines.If you have a question, do not hesitate and ask me here or on IRC (XwZ).I send it here beacause i can't send it on the reviewboard (i don't know why). Regards,Jérémy. _______________________________________________ koffice-devel mailing list koffice-devel@xxxxxxx https://mail.kde.org/mailman/listinfo/koffice-devel

Next Message by Date: click to view message preview

Re: xml:id preservation and RDF metadata support for ODF

Hello, On Friday 20 November 2009 09:27:50 Ben Martin wrote: > Abstract: > The non-RDF question is about preserving xml:id on ODF across > load/save cycles. > > Hi, > I'm adding support for loading and saving RDF metadata in ODF > documents for kword. Of course, other ODF like documents like > spreadsheets which support RDF can also be added to the KOffice suite, > I've tried to make what I've done generic so it can be expanded as such. > I'm focusing on kword right now. > > I've mostly got external manifest.rdf based metadata working, but I'm > having a few problems with so called inline RDF. From the ODF > specification, inline RDF follows a slightly askew subset of RDFa. This > means that one can have xhtml:about, xhtml:property and xhtml:content > associated with an XML node and these are used to generate an RDF triple > during loading. I mostly have loading of such metadata working, with a > few little corner cases to address. > > The two problems I have found is that KOffice discards xml:id > attributes during load and that I need to track the node that inline RDF > gets generated from in order to store it back properly on document save. > These problems are somewhat intermixed because if xml:id's can be saved > for input documents, then saving the xhtml:about etc could also be done > in the same code. > > I thought I'd ask advise from the list because adding xml:id support > seems like a fairly intrusive change, and those currently more familiar > with the codebase might have some ideas as to how to best support it. > The xhtml:about attribute can appear on many XML elements including > text:p. > > From my investigations, the pertinent code is in the class KoTextLoader. > Looking at KoTextLoader::loadParagraph() if there is a style applied > then KoParagraphStyle is used, then loadSpan() is called and, if the > text:p has no style and only a text child node cursor.insertText() is > called. This means there are many choices for where to store an xml:id > for the text:p, but none of them straightforward. I don't think the KoParagraphStyle is a good place to store the stuff as it can be reused for different paragraphs. Maybe the someone more familiar with KoText can comment. > Looking at other elements, it seems that KoInline, KoShape for example > would also need some augmentation to store an xml:id if one was supplied > in the input ODF file so that the xml:id can be preserved on save. > > I look forward to any thoughts or preferences on how the koffice hackers > would like to see the xml:id support added... > thanks for the very detailed explanation. I think there are two possible solutions: 1. Don't store the xml:id of the element but attach the meta data to it. This could be done by having a class containing all the metadata for one element. and store the data according to the element. 2. Have a map with the xml:id to metadata. Storing the metadata internally has the benefit of no need to synchronize a central map when e.g. a element is deleted/created ... That is also the way koffice works most of the time, not keeping the old ids but generating new ones on save. Also koffice might handle stuff differently internally as saved in odf so keeping the data in sync might be problematic. This also means the xml:id is not preserved, but it should not harm as the data is saved back again with a new xml:id. Having a separate map makes it easier to load save the data. I hope that explains it a little bit more. Looking to here form you on what you think. Thorsten _______________________________________________ koffice-devel mailing list koffice-devel@xxxxxxx https://mail.kde.org/mailman/listinfo/koffice-devel

Previous Message by Thread: click to view message preview

End lines patch

Hi,I made a patch to add shapes and the end of lines.If you have a question, do not hesitate and ask me here or on IRC (XwZ).I send it here beacause i can't send it on the reviewboard (i don't know why). Regards,Jérémy. _______________________________________________ koffice-devel mailing list koffice-devel@xxxxxxx https://mail.kde.org/mailman/listinfo/koffice-devel

Next Message by Thread: click to view message preview

Re: End lines patch

Hello Jérémy, On Friday 20 November 2009 23:13:35 Jérémy Lugagne wrote: > Hi, > > I made a patch to add shapes and the end of lines. > > If you have a question, do not hesitate and ask me here or on IRC (XwZ). would it be possible to rename KoLineEnd and the methods to something like KoMarker. In a discussion with Jan he told me that in svg there is also the possibility to have markers at any position of a path. So that might be something which will come later. Here are some comments: +class KoEndLineShapeModel : public QAbstractListModel +{ +public: + KoEndLineShapeModel( QObject * parent = 0 ); + ~KoEndLineShapeModel() {} Please move the implementation into the source file. +++ plugins/dockers/shapeendlines/KoShapeEndLinesDocker.h (révision 0) ... +#include <KoUnit.h> +#include <KoXmlReader.h> +#include <KoCanvasObserver.h> +#include <QtGui/QDockWidget> +#include <QListView> +#include <QDockWidget> +#include <kdebug.h> +#include <QStringList> Please move the includes not needed in the header into the source file. +class KoShapeBorderModel; +class KoCanvasController; +class KoLineEnd; looks like the above forward declarations are not needed. +class QComboBox; +class QSlider; +class KoCanvasBase; + +/// A docker for setting properties of end lines +class KoShapeEndLinesDocker : public QDockWidget, public KoCanvasObserver +{ + Q_OBJECT + +public: + /// Creates the end lines docker + KoShapeEndLinesDocker(); + virtual ~KoShapeEndLinesDocker(); +private slots: + void applyChanges(); + /// End Line has changed + void beginEndLineChanged(int index); + void endEndLineChanged(int index); + void beginEndLineSizeChanged(int index); + void endEndLineSizeChanged(int index); + + /// selection has changed + void selectionChanged(); + /// reimplemented + virtual void setCanvas( KoCanvasBase *canvas ); + void setEnabled(bool enable); +private: + KoCanvasBase* m_canvas; + KoXmlDocument m_doc; The m_doc is not needed in the header. Just use a temporary KoXmlDocument when reading the config file. + QString m_beginEndLineCurrentName; + QString m_endEndLineCurrentName; the above two are not needed. They are only set but never used. Please remove + int m_iconW; + int m_iconH; These two are no needed just set the values correct values on m_iconSize construction. Please remove. + int m_beginSize; + int m_endSize; + QSize m_iconSize; + QMap<QString, QString> m_pathEndLineMap; + QMap<QString, QString> m_viewEndLineMap; The above two variables are not used. Please remove. + QComboBox * m_beginEndLineComboBox; + QSlider * m_beginEndLineSize; + QSlider * m_endEndLineSize; +} One more thing throughout the code. The coding style for koffice was updated since the code was written. + virtual void setCanvas( KoCanvasBase *canvas ); there are no more spaces used after the opening bracket and before the closing bracket. So the above should be like: + virtual void setCanvas(KoCanvasBase *canvas); I only looked at the above class for now. If I find more time I will also look at the rest. Thanks for your good work, Thorsten _______________________________________________ koffice-devel mailing list koffice-devel@xxxxxxx https://mail.kde.org/mailman/listinfo/koffice-devel