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

List:       koffice-devel
Subject:    Re: GSOC: KFormula Shape
From:       Alfredo Beaumont <alfredo.beaumont () gmail ! com>
Date:       2009-03-29 11:01:18
Message-ID: 200903291301.18791.alfredo.beaumont () gmail ! com
[Download RAW message or body]

Friday 27 March 2009(e)an, Jeremias Epperlein(e)k idatzi zuen:
> 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'm not sure if i understand correctly what you mean, but I think it's not 
complete. Consider the following case:

<mrow><mn>37</mn><mo>*</mo><mi>x</mi></mrow>

This would be:

37*x

Consider you have the cursor after the '*' element:

37*|x

Then you move left:

37|*x

Now, you move again to the left, where should the cursor be now? IMHO, it 
should be again where is was now:

37|*x

This is how koffice 1.6 works. Why should it be there? It seems that we have 
not moved the cursos, but in fact we did. We moved from:

<mrow><mn>37</mn><mo>|*</mo><mi>x</mi></mrow>

to:

<mrow><mn>37|</mn><mo>*</mo><mi>x</mi></mrow>

So the cursor is now at the end of the number, and not at the beginning of the 
operator.

So if we move left again:

3|7*x

We are navigating inside the number.

If I understand correctly your proposal, this could be done with it, yet your 
proposal doesn't support another 'navigation mode' kformula supports: 'parent 
navigation'.

Suppose we have the same example:

37*|x

Then you move left:

37|*x

Now you move _up_:

37|*x

It again seems that the cursos is in the same position, but it's in 'parent 
navigation' mode:

<mrow><mn>37</mn>|<mo>*</mo><mi>x</mi></mrow>

As you can see, it's not inside any child, but in between two elements, the 
user could edit a new element there. Now if the user moves left again:

|37*x

or

<mrow>|<mn>37</mn><mo>*</mo><mi>x</mi></mrow>

To move again to chidren navigation, use _down_:

|37*x

or

<mrow><mn>|37</mn><mo>*</mo><mi>x</mi></mrow>

This is more or less the behaviour we had in 1.6, that allowed to make use of 
all the flexibility MathML provides, but it may be a bit too hard for the 
average user.

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

This is because selection behaviour is different from navigation. It works 
only in 'parent mode', that is, your may select part of a token, the whole 
token, part of the parent element, etc., but there's no need to such 
flexibility. Selection posibities are:

<mrow><mn>3[7]</mn><mo>*</mo><mi>x</mi></mrow>
<mrow>[<mn>37</mn>]<mo>*</mo><mi>x</mi></mrow>
<mrow>[<mn>37</mn><mo>*</mo>]<mi>x</mi></mrow>
[<mrow><mn>37</mn><mo>*</mo><mi>x</mi></mrow>]

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

Guessing what element to add shouldn't be too dificult, there are some rules 
at the spec, iirc. But basically, everything that seems to be a number, it'll 
be a number, everything that seems to be a math operator will be an operator 
and otherwise it'll be an identifier. So giving a reasonable default it's 
better than nothing, anyway this is not so important right now, so whatever is 
ok.

> 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'd like to see a list of UI elements to be added, not to be taken seriously 
but to aid you getting the overall idea of what's to be done. You can take a 
look at kformula 1.6 and mathml spec and get a list of which elements could be 
'wizarded' from the UI: fracs, roots, tables, matrices...

> I hope post an updated proposal soon.

Great!

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]