From koffice-devel Tue Mar 31 19:10:49 2009 From: Jeremias Epperlein Date: Tue, 31 Mar 2009 19:10:49 +0000 To: koffice-devel Subject: Re: GSOC: KFormula Shape Message-Id: X-MARC-Message: https://marc.info/?l=koffice-devel&m=123852668216084 Hi, 2009/3/29 Alfredo Beaumont : ... > I'm not sure if i understand correctly what you mean, but I think it's not > complete. Consider the following case: > > 37*x > > 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: > > 37|*x > > to: > > 37|*x > > 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: 37|*x 37|*x 37|*x 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 and . > > 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: > > 37|*x > > 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 > > |37*x > > To move again to chidren navigation, use _down_: > > |37*x > > or > > |37*x > > 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: > > 3[7]*x > [37]*x > [37*]x > [37*x] > >> 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 >> and add an option in the user interface to >> turn it into a , , ... 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