Moodle

hello,

my current plan is to
1/ create a new wiki page describing new text editors support in 2.0
2/ fix known issues with current dragmath plugin in cvs (mostly finished)
3/ evaluate current asciimath plugin
4/ create a text formats proposal for 2.0

When finished we could discuss this in moodle.org forums.

In any case thanks to you and other moodlers that worked hard on better support for teaching of mathematics in Moodle

Petr,

I'm not sure if this is the correct place to add one old note that Mathieu never recognized but...

Line 49 in file lib/editor/tinymce/plugins/dragmath/dragmath.php (current moodle 2.0)

<param name="outputFormat" value="Latex" />

could be changed to

<param name="outputFormat" value="MoodleTex" />

and

lines 21 to 24 in file lib/editor/tinymce/plugins/dragmath/js/dragmath.js

//

// Escape the expression

//

text = '$$' + text + '$$';

can then be deleted because we should be able to select also other output format than Latex in Dragmath (Options > Set export format > Latex/Maple/MathML/Maxima/MoodleTex/ASCIImathML) and if default format given in applet tags is MoodleTex Dragmath inserts double dollars automatically.

The benefit is that when we use Dragmath only for inserting LaTeX it works ok with MoodleTex format and if we want to add Latex inside current existing LaTeX tags we can change output format to LaTeX in Dragmath which does not add new double dollars around new addition that would mess old tags - and people like Marc can use Dragmath mostly for adding ASCIIMathML and simply change Output format without a need to edit plugin first...

Your current plan is excellent - it really does not matter a lot where files of Dragmath are as long as plugins find it from correct place - moodle 2.0 is so different from previous versions that we need to rewrite other plugins as well and when 2.0 is getting more and more stable and well documented it is easier for everybody to create new plugins or upgrade old plugins for tinymce in moodle 2.0.

The plugins I have written were created for a test environment where you don't need to do any changes for core files of moodle and therefore I selected the theme based integration but those math plugins can be easily converted to use file structure of moodle 2.0 as well - can't wait to start testing the new flexible plugin system of moodle 2.0 when you and Tim have finished the major changes to core files and repository system of moodle 2.0...

Thanks a lot Manuo, the proposed changes are in cvs.

Nahhhhh: Let's forget about the current usage and the current code and just start from scratch.... LOL

btw, the brief discussion MK provided (which appears in a number of places in the forum and tracker already) is a major reason why dragmath should be functional even when TeX is off (not sure which MDL sub task proposed just the opposite.....) as Dragmath is used by lots of folk who don't use the Moodle TeX filter.....

I am reminded of the story of the Monkey's Paw......

Oh, why do they use it then? I believe that for usability reasons it can not be always enabled by default.

Ahhhhh...... excellent question....

They use it to as an equation constructor which converts a GUI representation of an equation into a wide variety of text expressions as well as native dragmath files.

It is important to understand that the usage of math notation in Moodle, as in other online locations, can be broken up among a number of different functions.... (I think I opined about this in the Math Tools doc....) including construction, display, and computation. A variety of applications address one or more of the above.

SO, a teacher could use dragmath to produce a maxima expression to show the class how to use SAGE for example. Or she might use Dragmath to insert an asciimathml text expression in an assignment. The edtech.alaskapolicy.net site provides some examples of how instruction and assessment in math can be done via asciimathml without relying on any image files, and as image files and their storage are the bane of math notation, that is not just whistling dixie....

Specifically, I changed the dragmath integration files to rely on dragmath's own functionality to address tokenization, the change Mauno referenced above, and Chris assisted in the change by included some new xml files that provided tokens if one wanted to have Moodle display a tex expression, as well as asciimath tokens.... this is easily done in dragmath because it is xml based and means that the dragmath user can extend dragmath usage.

SInce you mention OpenOffice Math, it is my hope that at some point dragmath will also include a file for OOo and that at some point asciimathml will be able to parse and display OpenOffice math as well as maxima and other dialects (much as it now does latex) and that construction and display technologies weill eventually be able yto use common xml files that make that all transparent.... the efforts in demoing asciimath in wikipedia so that moodle docs will support it in part suggests such an eventual target in the future....

I should also mention that some of the discussion of math tools in moodle also mentioned replacing the algebra filter with latexml (the perl library, not latexmathml, the js in part included in asciimathml now, nominatively, if not functionally as the discussion has in part focused on breaking libraries out of the core asciimathml library and including as plugin libs....) as the algebra filter uses the webworks parser to provide a subset of latex for no apparent reason.... if one wanted to use a perl app to do tex, then latexml would be a complement in that it is perl based and as it produces mathml, would serve as a mathml complement to the current tex filter, which at present does not...

asciimathml is used by many because it is simple, both to extend and to write (much simpler than tex) so it makes a great tool for students... as you can see from Mauno's test site, it also allows us to offer something like SEE which can include SVG, calculator, etc all from the same core package... By using a display technology "just in time" we can easily change features thematically, and some of the initial excitement over MK's work last year was over the ability to have user selected editors with user selected plugins - I have not looked at those old tracker exchanges with Matthieu for some time but it might make for some excellent background reading...

Now as far as usability, I guess I have no clue what you mean.... as I mentioned in asking that you include the dragmath line in adminlib.php, if one turns off the icon (or removes it from the pallette in tinyMCE) it might as well not exist.... if the icon is there, the only impact is that it takes up some space on a configurable toolbar... that is not a usability issue in my mind, especially where an editor affords the option to have some menu toolbars... so what exactly is the usability issue you are concerned with? And when you say "enabled" are you talking about hiding an icon, or actually disabling functionality (which would be something new that we have not had to address to date....)?

Actually, the dragmath.php code could probably be cleaned up even more as the changes rendered a number of variables extra baggage as I recall.... but at the time I wanted to get minimal changes committed to determine how well the transition of dragmath to CVS would work. I subsequently determined it was largely not worth the time required (consider, for example that the version in HEAD has never been consistent with the version in contrib....) and that I might as well as not mess further until I fully understood whether we wold be transitioning dragmath to core tech or not and what that might mean both as far as htmlarea and fkeditor, tinyMCE, xinha, etc.

But, if you are ensuring that dragmath works with tinyMCE in Moodle 2 then you might want to look at a leaner version of dragmath.php....

>They use it to as an equation constructor which converts a GUI representation of an equation into a wide variety of text expressions as well as native dragmath files.
This is not the purpose of HTML editor in Moodle - it is intended for easy entering of rich text into forum posts, HTML resources, glossaries, etc - dragmath helps to enter formulas the way they already know from MS Word. Editor is not a specialised tool for teaching of advanced mathematics.

I agree things above should be possible via creating of new editors plugins or even adding custom tinymce plugins, but I strongly disagree this should be enabled in default Moodle installation.

Thanks a lot for explaining your needs, I will take them into consideration when trying to make our editors as much flexible/configurable as possible
Btw just today I committed major plugin improvements into cvs HAED, these add all standard plugin features to editors

Could you please wait a bit more? I need to stabilize editor embedding and integration with formslib code, repository file pickers, trusttext and a few other things in this area. I am starting to work on Resource module 2.0 migration right now, I will need to solve these problems when I get to new Resource page module...

Where exactly is the "leaner version of dragmath.php"? I was not able to find it, all I found was old code in contrib/patches/dragmath - there is no dragmath.php file in contrib at all

> This is not the purpose of HTML editor in Moodle - it is intended for easy entering
> of rich text into forum posts, HTML resources, glossaries, etc - dragmath helps to
> enter formulas the way they already know from MS Word. Editor is not a specialised
> tool for teaching of advanced mathematics.

You are wrong, Petr, and I think a bit confused.....

First off, Moodle should have nothing to do with MS Word, and frankly should have nothing to do with anything Microsoft.

As far as uses, Dragmath is a constructor which allows creating of text expressions from a gui.... and that allows insertion of the resulting text expressions in a variety of formats.... by way of example, it can be used as explained for inserting into an editor the correct text expression to be used, a need that has consistently been documented in moodle.org forums. If you look at what we have done with such tools you will perhaps understand the real needs that such tools address. And since an editor is the single most important tool for interacting with Moodle, it is indeed a critical tool for teaching any subject.... including mathematics....

Frankly I think it best if dragmath is not Moodle 2 core at this point as I am afraid what will become of it based on your comments, Petr.... I assumed that incoporation would flow from functional usage, but just the reverse is what is taking place....

I sympathize with you vis-a-vis the extent of the work before you and I am not pushing timewise so you take as long as you want..... My position has been that dragmath and asciimath should be rolled out in moodle 1.9.x so that experience with it could be gleaned by core developers before Moodle 2 work.... but that was not where the focus was....

In any event, I am sure you will continue to find Mauno a great resource as far as your continued work.

The code that Mauno mentioned is based on dlg_ins_dragmath.php for htmlarea:
http://cvs.moodle.org/contrib/patches/dragmath/lib/editor/htmlarea/popups/dlg_ins_dragmath.php?view=log
Mauno was pointing out that the code in HEAD did not reflect the changes made in the contrib CVS for dragmath.
As I said, I did not make further edits to the code for a number of reasons.... however, the edits that Mauno mentions about were quick functional changes, and if you are doing major rewriting then the code could probably benefit from some cleaning as there would be no reason for it to trace all its history and instantiate variables that are not necessary.

I am wondering whether the "enabled" discussion is a linguistic artifact. Code that is integrated may be appropriately hidden, but disabled is a separate question.... SO if we are talking being able to disable plugins, as well as hide them, then I have to disagree, the functionality should be there, with the admin, teacher, student, depending on feature set, able to hide and enable. Comparing this to 1.9.x usage.... while dragmath is easily added to a Moodle, the ability to hide the icon requires manually editing of adminlib.php, or production of regular patches to accommodate that, while adding to the array to allow hifing of an icon simply extends easy of usage without really impacting anything.... all a question of easy/functional for whom...

what is turned on in a default installation is one thing, what cannot be turned via the gui once the install is done is another.... I don't really care what the default install turns on, as long as an admin can easily make the functionality available via the gui..... if not, then there is no real reason to include dragmath in core.... This is much the same bit as was argued over with respect to profile spam..... core functionality is a different thing than default settings....

Oh, this really looks like a huge misunderstanding!

We do not need advanced math tools in core imo. I think we need simple user friendly tool that lets you enter formulas in HTML editor. We already have two basic filters for displaying of formulas in core - tex and algebra. Up until now you had to learn tex to enter formulas - like in older version of Openoffice where you have to type it in some weird syntax too (not weird for me but for very many people yes). Majority of people know how to add formulas in MS Word, that is why I keep mentioning it (not because I like/dislike it personally).

For mathematicians Moodle should allow replacing of default editor with something much much more advanced, that is why I fought hard to get the editor plugin infrastructure implemented (both MD and Mathieu were against it in 2.0 due to time constraints). I am also planning to implement user preferences for text editors - that way mathematicians may select to use advanced tinymce with multitude of maths plugins everywhere in Moodle. It will be even possible to remove/disable default tinymce editor.

Removing dragmath from core now - why???
1/ It does work fine imho
2/ other editors may still use lib/dragmath/* files
3/ I really like it and I think it is a great usability improvement compared to entering $$tex$$ directly in editor

Petr and Marc,

You are BOTH right - default configuration of moodle should be simple and easy-to-use for everybody AND flexible enough to allow advanced/selectable features for advanced needs either from site wide administration or for example from themes or editors themselves. These different configuration options should not conflict with each other - they should be complementary.

Algebra filter could as well be taken totally away from code base of moodle 2.0 - it is only a sub filter of TeX filter and could be installed separately if somebody needs algebra filter.
In the future ASCIIMathML could replace algebra filter as a selectable core filter but "somebody" should find the time to rewrite new filter code for ASCIIMathML. One problem in filter approach is that ASCIIMathML filter should use MathML type filter code only for Firefox and other MathML capable browsers - yet it could primarily use (clone of) TeX filter directly for image fallback if MathML is not supported. Because code of ASCIIMathML (javascript) files is not just replacing some tags with some other tags like most filters do we are currently using ASCIIMathML with separate javascripts - that way different plugins or themes can be used to load and render ASCIIMathML no matter what the core configuration is. Different tinymce plugins for "math edit mode/preview mode conversion" (asciimath) and for adding asciimathml, latexmathml, latex or graphs could be all combined to one plugin ( SEE = Super Equation Editor ) including dragmath, calculator and any other features we like to add the same way we have style plugin in tinymce for editing any styles but some people may prefer plugins where you have only one output format in each plugin and you can select which plugins to use and which ones to hide or not at all install. The ideal plugins might allow both - simple use and advanced use or even user selectable options but adding user selectable options would require either use of cookies or some kind of user profile (either site user profile or a customized profile as a part of some new activity, theme etc) All kinds of solutions are possible - some of them are just more complex than others.

Our "work-around-solution" has been to use themes because core code of current stable moodle (before moodle 2.0) does not allow you to edit editor configuration or add new plugins to HTMLArea as easily (un)installable/upgradable packages and even making one-line-change to some core file has been too hard for many people. In TinyMCE & moodle 2.0 the structure of init code allows more flexibility - the main weakness of integration of TinyMCE in moodle has been the missing administration of selectable settings simply because the original moodle 1.0 was based on a single-editor-system and many developers probably feel that they don't need editor at all (because they can use html directly). Ordinary teachers and students need simple and usable tools like editors with well chosen and pre-configured buttons and plugins with help buttons, tutorials and documentation. I think the main challenge of moodle 2.0 is to offer this flexibility so that administrators can select, install and configure some additional plugins (modules, blocks etc or even additional editors and their plugins if installed) from administration menu without hacking the core code of moodle.

Also different users of moodle may need different editor configurations - the plugins we need for young kids are not necessarely the same as teachers or professors of Maths or language teachers require. If some "plugin-based" settings came as a part of packages themselves and not as a part of core code (site administration) integration of any optional plugins/programs/advanced themes with advanced features might be easier. I tried to keep some noise about theme based/user based/activity based settings a year or two ago because originally I felt that learning environment for kids should not look the same as learning environment for adults no matter if we are talking about themes, editors or content. Some people obviously misunderstood those discussions and thought that we were planning a system where kids become administrators and can select some settings or configurations of moodle as well... in my opinion user selectable options are just a positive feature - you can select some optional things but you don't need to change anything - and the more personal you can make your learning environment the more interesting it is. If those options are pre-configured administrator can select which options are available and to whom and current role system is secure enough to keep students away from documents of teachers.

In a way Moodle looks like ?koda - if developers of moodle had prefered the first stable version moodle would have lived a couple of years as a basic tool and then other open source learning environments might have filled moodle's place. In new features of moodle 2.0 core developers are planning something similar like people in current ?koda production have "...relying on many years of tradition in technical know-how, combined with modern scientific findings and experience, as well as with the Concern's support. During this process, our designers seek perfection; passion and love for their work are manifested in every single detail of the vehicle models they create..." ( http://new.skoda-auto.com/com/innovation/design/Pages/skodadesign2.aspx )

Neither Moodle nor ?koda are perfect but we need new goals and seeking of perfection, fresh ideas, reqular testing and innovation to keep our products on markets... we need to think future (how are we going to solve this?) instead of history (how did we do it in the past?) if we are talking about development - still stability is more important than new features in stable production versions... Both are important...

If moodle 2.0 will allow adding different kinds of plugin packages the same way we have been able to add/change/edit/remove languages and themes using a standard structure I will be jumping for joy and be all smiles forever... and if this really happens it sounds like moodle 2.0 is getting very near the ideal situation (IMO) we were talking about year ago - where you can change (hide or show) not only themes and languages but also editors (configuration/init code) and even configuration of plugins of editors.

Thank You again, both of You Gurus!

What the heck happened to my ticks over Skoda - they vanished and took S as well - I did not mean to write koda...

yeah, diacritics were borked during Jira upgrade a few months ago :-D

I am no guru, but Well put Mauno....

Petr, I have started a thread in the math forum about simply dumping the algebra filter (I broached this before and found no technical argument in opposition). If moodle 2 is in fact going cease to be your grandmother's moodle, then I see no reason to drag along as core filters based on 5 year old code borrowed from webworks (GPL3 issues there??) that really hasn;t been documented or supported and offers no benefits over tex filter..... (unless we are going to provide greater integration between webworks and moodle, which I think would be great, but is clearly outside the present scope....)

Should a separate MDL be created, and if so, where?

I don't have a problem collecting up the asciimath MDLs for linking, but in a way this was done a couple of times before, so some guidanc on how best to organize would be helpful

Maybe it is time to start rethinking a totally different combination of tools as advanced editor&theme&activity package for maths/physics/chemistry...

I have been reading the code of latest moodle 2.0 now some days and I must say the new editor code that Petr has written to editorlib.php is great - in fact genious - and it allows use of totally pluggable parallel versions of TinyMCE and with some extra work also other editors than tinymce just like Petr promised.

So it is already possible to create different configurations (math editor, kids editor etc) on site administration level in moodle 2.0 - I can do it using the old test cases and plugins - and if Petr can implement the user preferences (or user/role/course/content based selections of editor or configuration) it is possible replace relic HTMLArea of previous versions of moodle with most flexible editor system ever in the history of learning environments, mankind and whole universe in a larger scale...

Well... some tiny parts are still missing but this latest move to bring pluggable editors back to moodle 2.0 is excellent!

Now when it is possible to use custom versions of TinyMCE or custom configurations and custom plugins it is easier to create those advanced math editor packages as well. It is also possible to use themes if we want so we have two optional ways to implement asciimath/latexmathml/latex/graph etc plugins to moodle 2.0

It may be soon possible to get a developer API key for Wolfram|Alpha too ( I filled the form of application ID to use the Wolfram|Alpha API but it may take some time to get a key and to check if it is usable ) and some other tools that could be placed to full screen init code as well if third row of math editor becomes too full of buttons with init code for fullscreen_settings.

Lol- yes, I applied for WA ID right way as well and played with graphing functions on EdTech.alaskapolicy.net - graphing features were impressive, but I don't see how they are going to sustain open usage and details via-a-vis engine usage vs access to db pretty thin. WA would be easily harnessed much as we are doing asciimath now... I am getting a big impatient with WA sending out "it is coming soon" updates... I did create a thread for WA, and we need to becareful we don't turn tracker items into texts on math tools - lol

One update, Marc:

I tested today a "full math editor package" with TinyMCe in moodle 2.0 with a customised theme (Custom corners with AM tags in meta.php and $CFG->texteditors = 'tinymce2,textarea'; in theme config.php, 3 customised editors (2 versions of tinymce with different configurations and CKEditor with basic configuration), with customised plugins and even with two versions of YUI and basicly everything worked just fine. The current flexible system of moodle 2.0 is great - it just takes some time to do all finetuning - for example my plugins were using file /lib/yui/element/element-beta-min.js and this does not exist at all in moodle 2.0 - the new name in new version of YUI is /lib/yui/element/element-min.js ...

I moved my files from lib/editor/common to folder lib/common to keep lib/editor clean for editors and made the needed changes to paths - nothing to worry, Marc... The new system is different but nothing is lost. On the contrary the new editor integration system of moodle 2.0 makes creating of advanced or simplified (math) editors easy and theme based integration works just like before.

Manuo: thanks a lot for testing! I have discussed the editor integration a bit with MD, I guess he liked our current direction in this area. I will continue with more improvements and implementation of user editor preferences when I finish my current task (Resource module migration).

I added a subtask to move 0.7.8.2 into HEAD. The GPL3 subtask is still not closed though that has been addressed in 0.7.8.2.

Not sure whether dragmatyh is supposed to work automagically when tex filter turned on, or will require additional tinyMCE plugins. Also, with filter options can dragmath work if tex filter only available.

I guess I was totally in a fog as I thought the implementation of tinyMCE was going to include gui configurator.