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

List:       koffice-devel
Subject:    Re: Formula Shape - Inferred rows
From:       Alfredo Beaumont <alfredo.beaumont () gmail ! com>
Date:       2007-07-10 16:52:22
Message-ID: 200707101852.22926.alfredo.beaumont () gmail ! com
[Download RAW message or body]

Ar, 2007eko Uztren 10a(e)an, Martin Pfeiffer(e)k idatzi zuen:
> So,
> switch discussion to the list to have discussion/ decisions archived.
>
> 1. Inferred rows
> In the patch I send to you Alfredo, I removed the InferredRowElement class
> as there was just a single method in it. Instead I propose to just inherit
> directly from RowElement as it was done before InferredRowElement. As long
> as I went on implementing element classes there were no problems ( namely I
> did ErrorElement, StyleElement, started FenceElement - all three not yet
> commited ).
[...]
> 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 ?

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.

> 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.

> 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 ?

> 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.

>   -> this would be first logic for somebody who wants to understand our
> code -> second it makes loading/ saving code easier, as we just have to
> load/ save 1 : 1 and don't have to consider implicit rows.

We just need to check that at loading stage, and it takes 3 lines of code. And 
otherwise we should check that at the rest of our code.

>   -> 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 ?

> 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.

> -> the code for substituting elements in the case we don't use RowElement
> is very compact:
> Each element class has implemented insertElement which is a method that
> assigns a new children to the current cursor position. For RootElement it
> might look like:
>
> RootElement::insertElement( cursor, newElement ) {
>    if( cursor is in exponent )
>        exponent = newElement;
>    else
>        base = newElement;
> }
>
> Which is everything we have to do. The other code is in FormulaCursor:
> FormulaCursor::insert( newElement )
> {
>     BasicElement parent;
>     if( currentElement->elementType() == Basic ) {
>         parent = currentElement->parentElement();
>         delete currentElement;
>         parent->insertElement( newElement, currentElement )
>     }
>     else if( currentElement->elementType() == Row )
>          currentElement->insertElement( newElement )
>     else {
>          RowElement* tmp = new RowElement();
>          tmp->insertElement( currentElement );
>          currentElement->parentElement()->insertElement( tmp );
>      }
> }
>
> This is for me a very logic way to do things. What do you think?

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.

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>

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 ?

Cheers!
-- 
Alfredo Beaumont Sainz
http://www.alfredobeaumont.org/blog.cgi
_______________________________________________
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]