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

List:       koffice-devel
Subject:    Re: GSOC: KFormula Shape
From:       Jeremias Epperlein <jeeree () web ! de>
Date:       2009-03-27 17:36:57
Message-ID: f80fad6f0903271036o2e511d71h652f98ff8158b7fc () mail ! gmail ! com
[Download RAW message or body]

Thanks for the comments,

I think I might use the next days, to look at, how other applications
handle the editing and put
something up on the wiki. I think the most important thing to do is to
actually show the user in which type
of element the cursor is right now, e.g. by showing a bounding box and
a the type of the element maybe as a tooltip.
Koffice 1.6 underlined the element where the cursor is in, so you
could see if you are in the <mrow> or the token.
This actually works quite well for me, although I like the edges of
the bounding box like painted by lyx more.
Basically my approach for keyboard navigation in the basic case woulde
be the following, assuming the user pressed the left key:
- if we are in a Token move left within the Token, if we are already
at beginning of the Token, move to its parent before the Token
- if we are in a mrow or an inferred mrow move into the next child
element, if it accepts the cursor, otherwise in front of it, if we are
at the beginning, move to the parent
I think this differs from the behaviour of Koffice 1.6, whose keyboard
navigation I find a little bit unpredictable, whereas selection
and mouse navigation is working fine. From what I have seen up to now,
the navigation in lyx i like most, but since it is a
wysiwym latex editor, it doesn't have some of the problems, like
having multiple token types.

A very interesting question is what element to add, if the user starts
to type, when the cursor is in an mrow.
I would tend to apply as less magic as possible and simply add a
<mtext> and add an option in the user interface to
turn it into a <mi>, <mn>, ... Because if we want to allow the
creation of (almost) arbitrary mathml and not only a subset
like OO does, this is needed anyways.

Sadly I missed you (abeaumont) today on IRC, hopefully I can discuss
come specific questions about the code with you in the
next days. Dou you think the Implementation section of the proposal
needs more details?

I hope post an updated proposal soon.

Greetings,
Jeremias


2009/3/26 Alfredo Beaumont <alfredo.beaumont@gmail.com>:
> Overall i like the proposal, some quick thoughts:
>
> Thursday 26 March 2009(e)an, Jeremias Epperlein(e)k idatzi zuen:
> [...]
>> Implementation Details:
>> For the editing part, I will add the missing logic in FormulaCursor
>> and KoFormulaTool
>> as well as implement the missing methods in the classes, that
>> represent the MathML
>> elements. For inserting mathematical objects I will select useful
>> MathML templates
>> and add a possibility to insert them to the tool docker.
>>
>> Tentative Timeline:
>> 2 weeks getting keyboard navigation working
>
> The main issue with mathml navigation is that there're many elements are
> 'extensible'. With text processing you usually just write text, which is
> itself a chain of characters. In math each character you write may be part of
> a chain or the beginning of the next. E.g: you write 'a', this is an
> identifier. Next you write 'b', you have the a two letter identifier: 'ab'.
> But if you write '=' instead of 'b', then you have _one_ identifier and _one_
> operator: 'a' '='
>
> Now consider you have that chain as a numerator in a fraction (using tex
> syntax with intended spaces for clarification):
>
> $\frac{a =}{}$
>
> This means that the user may want to put the cursor (some cases are ignored,
> becase the problem would be the same):
>
> 1. After 'a', to complete the identifier. E.g:
> $\frac{ab =}{}$
> 2. Before '=', to complete the operator. E.g:
> $\frac{a <=}{}$
> 3. After '=', to complete the operator. E.g (doesn't make sense in this
> particular example, but you get the idea):
> $\frac{a =<}{}$
> 3. After '=', to add a new kind of element, as another identifier. E.g.:
> $\frac{a = b}{}$
>
> To make all this a bit more complex, there's no rule that prohibits a user to
> make an identifier (or operator, or whatever) like 'a=', or whatever. So this
> a user may aswell _intend_ to write:
>
> $\frac{a= != a}{}$
> $\frac{a b= c}{}$
> $\frac{a = <}{}$
> $\frac{a= b}{}$
> $\frac{a =b}{}$
>
> This makes keyboard navigation design pretty complex.
>
> Take a look at mathml spec talking about mrow, inferred mrows and token
> elements.
>
>> 3 weeks add mouse interaction, drag&drop, selecting and moving elements
>
> The same complexity appies here. Take for example:
>
> $\frac{a b= c}{}$
>
> The user may want to copy&paste:
>
> 1. Whole fraction
> 2. Numerator
> 3. 'a'
> 4. 'b='
> 5. 'c'
> 6. 'a b='
> 7. 'b= c'
>
> But, should it be allowed to select, for example, 'a b'? If so, consider that
> you should copy one identifier and _part_ of an operator.
>
>> 3 weeks investigate, how other math software designs the interface for
>> inserting mathematical objects,
>>        design and implementing the ToolWidget
>
> Due to complexities i comment above, i think it'd be a good idea to take a
> look at how other people solve this from the beginning.
>
> This would include, i guess, UI elements to allow matrix/tables creation,
> under/over elements and so on. It should also include ways to include
> operators, greek letters, etc. (including math unicode symbols).
>
>> 3 weeks improve the loading of MathML, add Unit tests
>> 1 week clean up the code, add missing documentation
>
> There's already a bunch of unit tests, so it would be enough with passing them
> :). Anyway, i think that UI has enough work to do, and i'd consider a success
> having the previous points completed. This should be considered an extra :)
>
> 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
>
_______________________________________________
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]