[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-31 19:10:49
Message-ID: f80fad6f0903311210k2648160euf4665a8a763c7430 () mail ! gmail ! com
[Download RAW message or body]

Hi,

2009/3/29 Alfredo Beaumont <alfredo.beaumont@gmail.com>:
...
> 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'.

This navigation mode is what I tried to discribe above, although my
description had the difference, that
it would have moved like this:
<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>
where the second step is indeed most likely unnecessary and only slows
done keyboard movement, since token elements
can't have childs (right? I still have to read more of the
Specification, hope to find time soon, but was moving houses today)
and therefor when I insert something when the cursor set like in the
third line, we know that the user wants to add it between </mn> and
<mo>.

>
> 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 it is a little bit confusing, especially if the user doesn't
know that much about MathML and only wants to
write a formula. Can you give a use case, where creating a certain
piece of MathML is only possible using parent navigation
mode? Additionally, it would be nice to have up and down keys for
navigation in matrices available.


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

So here comes the second draft:

Name:
Jeremias Epperlein

Email Address:
jeeree@web.de

Freenode IRC Nick:
JeremiasE

Location (City, Country and/or Time Zone):
Aue, Germany, GMT+1

Proposal Name:
Enhance Formula Shape

Motivation for Proposal / Goal:
Being able to add formulas is a requirement for many users of an office
suite like teachers or scientists. Although most of the later use LaTeX for
this, when you need a lot of manual layout, a program like kword is a
better choice. Koffice in Version 1.6 included a very good formula editor.
The port to the new flake architecture in Koffice 2.0 is very incomplete
and lacks several features. Especially the user interface
needs a lot of work. I would like to add support for navigating and
editing a formula, as well as inserting various mathematical elements
like Greek letters.

Additionally I would like to work on the loading and saving of MathML,
which is used in ODF for storing formulas, or add the possibility to enter
a certain subset of LaTeX.

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.
There should be a possibility to insert (this list is not necessarily complete):
Templates
- fractions
- roots
- matrices
- fenced elements (braces, brackets, ...)
- super- / subscript
- alignment hints
Tokens:
- operator symbols (small / big)
- Greek letters
- arrows
Styling:
- under / over bars
- boxes

Tentative Timeline:
3 weeks getting keyboard navigation working
3 weeks add mouse interaction, drag&drop, selecting and moving elements
3 weeks design and implementing the ToolWidget for inserting elements and
             changing there style
2 weeks improve the loading of MathML, get more unit tests to pass
1 week clean up the code, add missing documentation

Do you have other obligations from late May to early August (school,
work, etc.)?:
I will have university until end of July, but I will have a very low
course load, basically only one seminar and two lectures.
For the same reason, I would also be able to start coding earlier.
Apart from that I hope to be a guide at the
International Mathematical Olympics at the end of July but this will
take only one and a half week.
Finally in August I may start a Hebrew course, but this will
nevertheless allow me to finish the project.

About Me (let us know who you are!):
I am a student of mathematics and computer science  in my last year at
the Technical University of Dresden.
I have experience programming in C++ with QT from
various university projects. I started using Linux and KDE around 7 years ago.
Apart from writing a small patch for
Canorus (www.canorus.org) I have never before programmed for an open
source project. But I am already reading koffice-devel for a year and
so I think I could find into the project relative easily.
In my free time I like to play trumpet, bike, travel,
do stuff with my friends, my girlfriend and the guys from my church.

Comments as always very welcome. I did some research in the last days,
how other MathML editors handle these problems and will hopefully post
something about this in the wiki tomorrow. I hope to submit my
proposal to google on Thursday.

Greetings,
Jeremias Epperlein
_______________________________________________
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]