On Friday, June 10, 2011 17:06:15 Jos van den Oever wrote:
> On Friday, June 10, 2011 08:22:04 AM Jos van den Oever wrote:
> > Here is an idea to improve code quality in Calligra.
>
> Here is a version that works fine with a small example use:
>
> #include "odf.h"
> #include
> #include
>
> int
On Friday, June 10, 2011 20:54:48 Jos van den Oever wrote:
> On Friday, June 10, 2011 20:36:36 PM Pierre wrote:
> > Also, another question about your proposal : would it be strict regarding
> > the content types ?
> > I mean : a positiveInteger attribute for a given node must remain a
> > positiveI
On Friday, June 10, 2011 08:43:39 Jos van den Oever wrote:
> On Friday, June 10, 2011 08:30:36 AM Pierre Stirnweiss wrote:
> > I like the idea.
> > On the headerWriter example you give, the end-element is written when the
> > Writer gets out of scope. We'd need to verify that all our start/end
> >
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/101562/#review3839
---
Ship it!
Please fix the things I pointed out and commit. I have
Thorsten Zachmann wrote:
> Hello,
>
> On Friday, June 10, 2011 08:22:04 Jos van den Oever wrote:
>> Here is an idea to improve code quality in Calligra.
>>
>> Currently, we use KoXmlWriter to write ODF XML. For this, functions like
>> startElement, endElement, addAttribute are used.
>>
>> By usi
On Friday, June 10, 2011 20:43:38 PM Pierre wrote:
> BTW, what RNG parser do you use to generate this .h file ?
> So far, we have a terrible one in a test case (yeah, I write ugly code
> sometimes, sorry about that, but this one was gonnabe too complex
> otherwise...)
I wrote a Relax NG parser and
On Friday, June 10, 2011 20:36:36 PM Pierre wrote:
> Also, another question about your proposal : would it be strict regarding
> the content types ?
> I mean : a positiveInteger attribute for a given node must remain a
> positiveInteger, and that could even be checked at compilation time...
Yes, th
On Friday 10 June 2011 20:28:55 Jos van den Oever wrote:
> On Friday, June 10, 2011 20:24:08 PM Pierre wrote:
> > On Friday 10 June 2011 12:49:18 Jos van den Oever wrote:
> > > On Friday, June 10, 2011 08:22:04 AM Jos van den Oever wrote:
> > > > Can you think of a reason why this would not work?
>
On Friday 10 June 2011 08:56:06 Jos van den Oever wrote:
> On Friday, June 10, 2011 08:43:58 AM Pierre wrote:
> > That is a really interesting solution. The biggest trick would be not to
> > forget to delete the objects at the right time if the endElement stays in
> > the destructor.
> > But I'm no
On Friday, June 10, 2011 20:24:08 PM Pierre wrote:
> On Friday 10 June 2011 12:49:18 Jos van den Oever wrote:
> > On Friday, June 10, 2011 08:22:04 AM Jos van den Oever wrote:
> > > Can you think of a reason why this would not work?
> >
> > I can now. The circular nature of element nesting make is
On Friday 10 June 2011 12:49:18 Jos van den Oever wrote:
> On Friday, June 10, 2011 08:22:04 AM Jos van den Oever wrote:
> > Can you think of a reason why this would not work?
>
> I can now. The circular nature of element nesting make is harder to create
> these classes. E.g. office:document can h
On Friday, June 10, 2011 08:22:04 AM Jos van den Oever wrote:
> Here is an idea to improve code quality in Calligra.
Here is a version that works fine with a small example use:
#include "odf.h"
#include
#include
int
main() {
QFile out;
out.open(stdout, QIODevice::WriteOnly);
KoXmlW
On Friday, June 10, 2011 08:22:04 AM Jos van den Oever wrote:
> Can you think of a reason why this would not work?
I can now. The circular nature of element nesting make is harder to create
these classes. E.g. office:document can have (at some depth) a "office:image"
which can have an "office:do
13 matches
Mail list logo