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

List:       koffice-devel
Subject:    Re: Formula Shape - Inferred rows
From:       Martin Pfeiffer <hubipete () gmx ! net>
Date:       2007-07-11 17:43:51
Message-ID: 200707111943.51979.hubipete () gmx ! net
[Download RAW message or body]

Hey,
> > If there is a special right for InferredRowElement to be there please
> > tell me about it.
>
> I don't see any problem with having a class with just one method ? Well,
> you could remove it if you provided an alternative solution, but not just
> because it contains only a single method. I don't see any changes on those
> classes' (ErrorElement, StyleElement...) loading code so I guess they will
> just work wrong. Have you checked if they pass the tests in testsuite ?
I did not want to remove it just because there is just one method.

> The reason I had for having InferredMrowElement class with a single element
> is that MathML allows inferred mrows, and those have to be treated
> specially. To do so, we could either go through each element that is
> allowed to contain inferred mrows and write special loading code or write
> InferredMrowElement, which inherits everything from MRowElement but loading
> code, where it does the special checking. I think this second solution is
> more clean both conceptually and technically, since we have the special
> loading code in a single place, and elements allowed to have inferred mrows
> are explicitely marked in class definition.
Could you please be more precide I walked the spec and did not find anything 
saying: elementXY is not allowed to have this and that element as child. 
Which elements are not allowed to contain inferred rows?

> > 2. Formula tool options
> > I commited a widget that I think is suitable for some input tasks. I
> > would like to fill the list view with "templates" that are bricks to
> > build a formula of: the common element like fraction, root etc and things
> > like binomial operator, a common 3-component vector...
> > What do you think about it?
>
> I think it's something we need. But I also think we should carefully think
> how we want to fill such a widget. My idea is to have different elements
> grouped by category, something similar to what both kile and OOMath
> provide: a group being relations, another one arrows, greek letters,
> fractions, brackets, etc.
Well yes grouping can be done as we want... I am not decided there already. 
What is more interesting atm is how to implement it:
I imagine to have a icon view of the things that are actually inserted. It 
would also be very interesting to provide the possibility to let the user 
define its own constructs. This would require a rendering on demand of the 
existing templates, which is certainly possible and cool but might take very 
long, what do you think?
The alternative would be to have hard coded templates and provide icons, like 
OO does it.

>
> > 3. Using BasicElement or RowElement for "empty" elements
> > As I understood the problem is that if we use BasicElement we have to
> > write a lot of code for insertElement() and removeElement() methods in
> > the single elements. First I thought the same now I think we don't need
> > to. Why I want to use BasicElement instead of RowElement:
> > a) we can use ->elementType() == Basic
> >   -> this is the most important point as it simplifies a lot of code
>
> How's that ?
elementType() == Basic gives the information if there is already an element 
existing that is worth interacting with, just as example:

Loading code of FractionElement with BasicElements as "empty" :
    forEachElement( tmp, parent ) {
        if( m_numerator->elementType() == Basic )
            m_numerator->readMathML( tmp );
        else
           m_denominator->readMathML( tmp );
    }

and with RowElements ( there is a counter ):
    int counter = 0;
    KoXmlElement tmp;
    forEachElement( tmp, parent ) {
        if ( counter == 0 ) {
            if ( ! m_numerator->readMathMLChild( tmp ) ) return false;
        }
        else if( counter == 1 ) {
            if ( ! m_denominator->readMathMLChild( tmp ) ) return false;
        }
        else
            return false;
        counter++;
    }

>
> > b) we would have the same tree in memory ( represented by our element
> > classes ) as it is saved to xml.
>
> I think you are wrong. We have the same tree in memory as it's saved to xml
> with RowElements, not with BasicElement.
Your unit tests work often after the principle that the stuff saved to MathML 
has to be the same as it was loaded. Imagine

> >   -> third it might be useful when we have a widget that shows a tree of
> > the current MathML and with RowElements it would show row elements that
> > were not saved in the file - this confuses the user
>
> Then just save them. Why wouldn't we save them ?
Depends on how you generate the tree: If you walk the element classes then you 
will have

FractionElement
  RowElement
     OperatorElement
  RowElement
     NumberElement

instead of
FractionElement
   OperatorElement
   NumberElement
what I consider to the thing you loaded.

>
> > c) it results in less and clearer code
> >   -> if we don't use RowElements our loading/ saving code is everywhere
> > consistent, as we always just implement the writeMathMLContent() method,
> > this makes the code logic, there are no excuses for RowElements and so...
>
> What do you mean ? We are just implementing writeMathMLContent() now too> .
Perhaps these additional functions relate to inferred mrows... my mistake.

> Well, with RowElements we would just have:
>
> RootElement::insertElement( cursor, newElement ) {
>     if( cursor is in exponent )
>         exponent->insertElement( cursor, newElement );
>     else
>         base->insertElement( cursor, newElement );
> }
>
> and we can let RowElement's inserting/deleting code do its work, which
> makes more sense to me.
I know the inserting/ removing code is easier with just RowElements, that is 
true. But then we would actually only need this method in RowElement. My 
point was just that it is very simple to implement the two methods also for 
the other elements.

> Let's explain again why I think we need RowElements in general. These
> markups are equivalent:
>
> <mfrac>
>  <mi>x</mi>
>  <mi>y</mi>
> </mfrac>
> and:
>
> <mfrac>
>  <mrow>
>   <mi>x</mi>
>   <mi>y</mi>
>  </mrow>
> </mfrac>
You meant
> <mfrac>
>  <mrow>
>   <mi>x</mi>
    </mrow>
    <mrow>
>   <mi>y</mi>
>  </mrow>
> </mfrac>

> What I do propose is that, as they are equivalent, we should take the
> second case, which is more general, and just convert the first one to the
> second one at loading stage. What you do propose is that we should write
> independente code for both cases, even with conversion code at different
> stages (since with your proposal, a user can start with initial markup and
> end with second markup). This clearly more complex and, IMHO, less logic
> and clear. Do I understand correctly ?
I know what you propose and it makes sense! But I am proposing a simpler and 
more logic ( imho :-D ) solution.
First: with my proposal we would not write code to handle these two cases 
independent, they are just loaded, with the difference to your solution, that 
there is no conversion.
Second: How can a user start with the first example and end up with the second 
when there is never a conversion??? This is something that might happen with 
your code.

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