Attached hopefully will be a zip of four files which together should change the functionality of the dragmath http://www.dragmath.bham.ac.uk/ integration so that delimiters are added by dragmath and not by the integration scripts.
Replace your existing dlg_ins_smile.php with the one included in the archive (this deletes the line that adds the doubleddollar delimiters. )
The config.xml file replaces the file of the same name in your dragmath/applet/ classes directory. It only identifies a new export format described below.
Latex.xml and ASCIIMathML.xml need to be placed in dragmath/applet/classes/formats. Latex.xml will simply replace the existing Latex.xml and the only change here is that the doubledollarsigns that were inserted for tex interpretation by the integration script (see above) have been moved to the Latex.xml file using the <Initial> tags.
The other file ASCIIMathML.xml, is named after that package/script/filter written by Peter Jipsen http://www1.chapman.edu/~jipsen/mathml/asciimath.html because the xml file employs backticks as delimiters and begins an attempt to provide ASCIIMathML conversion for dragmath in addition to true tex. At present its major benefit is avoiding insertion of square bracket and encapsulating text expressions in backticks, thereby invoking the asciimathml filter. You could replace the backticks with amath and endamath if you so choose.
In this manner dragmath could be used to create filter specific text expressions.
Thanks to Chris and Pete for their assistance. As Chris suggested, one could also create a moodletex.xml that added the doubledollars for filters and leave the Latex.xml as is for when you do not want the delimiters. The format and syntax are relatively easy to manipulate.
In reply to Marc Grober
Re: Dragmath integration - Extending functionality - files
by Alex Billingsley -
Marc,
I shall include the ASCIIMathML.xml file into DragMath on SourceForge, and I shall make a moodletex.xml from your Latex.xml, so that people can use the existing Latex.xml as well.
Adding these will allow people who want to use these files in Moodle able to easily upgrade to newer versions of DragMath while keeping the files.
Then the standard integration of DragMath in Moodle could set moodletex.xml as the default format?
Alex
www.dragmath.bham.ac.uk
In reply to Alex Billingsley
Re: Dragmath integration - Extending functionality - files
by John Isner -
Alex and Marc,
Anthony Borrow is in the process of moving DragMath into the CONTRIB section of the moodle cvs repository so that we have better control over versioning. He is still working out the details of how it will be done, since DragMath is not a standard plugin, but rather an integration. Once our cvs is up and running, we will fix the smiley button issue and make these other valuable changes.
Anthony Borrow is in the process of moving DragMath into the CONTRIB section of the moodle cvs repository so that we have better control over versioning. He is still working out the details of how it will be done, since DragMath is not a standard plugin, but rather an integration. Once our cvs is up and running, we will fix the smiley button issue and make these other valuable changes.
In reply to John Isner
Re: Dragmath integration - Extending functionality - files
by Anthony Borrow -
Yes, folks that are interested in seeing the progress on this issue, comment, help with testing, or simply vote for it can go to CONTRIB-333. Peace - Anthony
In reply to Anthony Borrow
Re: Dragmath integration - Extending functionality - files
by Luis Perez -
Anthony
Have you installed TinyMCE, that includes Dragmath, in Moodle 1.9 (final)? I did it but the editor is not running in firefox, but it is with IE7. In IE7 the dragmath applet is not found - all the other functionalities are working.
Do you have any idea of what could be the problem?
Thanks for your help.
Luis
In reply to Luis Perez
Re: Dragmath integration - Extending functionality - files
by Anthony Borrow -
Luis - I have not tried the TinyMCE editor. Could you point me to where the instructions are for using TinyMCE and then I can give it a shot. Peace - Anthony
In reply to Anthony Borrow
Re: Dragmath integration - Extending functionality - files
by Luis Perez -
Anthony - this is the address of the editor
http://moodle.org/mod/data/view.php?d=13&rid=1119
In the documentation section you will find the info for installation.
Thanks for the excellent work that you are doing in the Moodle community.
Luis
http://moodle.org/mod/data/view.php?d=13&rid=1119
In the documentation section you will find the info for installation.
Thanks for the excellent work that you are doing in the Moodle community.
Luis
Just out of curiosity, there is a tinyMCE folder in 1.8.2. Is there a way to test your integration by selecting tinyMCE for 1.8.2? I noticed that while there is a selection as to whether to use an html editor or not, there is no apparent GUI selection for choosing tinyMCE over htmlarea and I was wondering if this is included in 1.9
Marc
Marc
Marc
I have no idea. I downloaded the Tinymce3 file that its available at
http://moodle.org/mod/data/view.php?d=13&rid=1119 an installed it in my
Moodle 1.9 final version. The advantage of this one is that it includes the
tinymce and tha dragmath applet integrated.
Luis
I have no idea. I downloaded the Tinymce3 file that its available at
http://moodle.org/mod/data/view.php?d=13&rid=1119 an installed it in my
Moodle 1.9 final version. The advantage of this one is that it includes the
tinymce and tha dragmath applet integrated.
Luis
In reply to Luis Perez
Re: Dragmath integration - Extending functionality - files
by Anthony Borrow -
Luis - It does not look like I will have a chance to look at it this week as I had hoped. Perhaps someone else already familiar with TinyMCE can help you out. Peace - Anthony
In reply to Luis Perez
Re: Dragmath integration - Extending functionality - files
by Mauno Korpelainen -
The problem in Glen's TinyMCE integration is in the path and in file dragmath.php:
line starting with codebase should be:
codebase="<?php echo $CFG->wwwroot.'/lib/editor/tinymce3/plugins/dragmath/applet/classes' ?>"
and if dragmath is as a plugin in folder lib/editor/tinymce/jscripts/tiny_mce/plugins then codebase should be given by tags
codebase="<?php echo $CFG->wwwroot.'/lib/editor/tinymce/jscripts/tiny_mce/plugins/dragmath/applet/classes' ?>"
Works ok in IE7 as well...thank you for a great plugin!!!
In reply to Alex Billingsley
Re: Dragmath integration - Extending functionality - files
by Marc Grober -
Alex,
As I came across Chris' name first on the DragMath page than yours I have been chatting him up about this via e-mail.
Let me cover a couple of points from our correspondence as well as my "private" concerns:
a) I was hoping to address a question I had about the usage of /cdot. If I delete the /cdot stanza from the xml file so as to avoid, for example {2 /cdot ab} which is what dragmath produces if you do "2ab" , you cannot then intentionally insert the dot if you want to use it, which is not an advancement...... I suggested to Chris that I thought the java was inserting the /cdot in this instance (whenever it saw a coefficient in a term), and where as there was nothing wrong with it and it was technically correct, not everyone wanted a dot behind every coefficient.... and I wondered whether deleting that automated insertion was "trivial" or not.
b) I think the key to avoiding unnecessary frustration in the transition is to ensure that the default format file IS set to moodletex.xml so as to make sure that there aren't then lots of posts about double doubledollars signs... I have attached a file that sets this as default and also is format neutral as far as the function... which makes no practical diff, but I think adds clarity. And I assume you will add the moodletex.xml item to config.xml
c) I mentioned to Chris that I had assumed that the applet would simply read the formats and languages directories, as opposed to requiring identification of these in config.xml and he said he would bounce that off you as he thought there had been perm issues....
d) While Peter Jipsen has I think appropriately noted that one of his interests in developing ASCIIMathML was to avoid the necessity of a gui, I thought that offering students the ability to start with the gui and and see the asciitex made good pedagogical sense. A full XML mapping is going to require more work than my current ASCIIMathML file reflects, but pending a simple resolutions of issues such as square brackets in ewiki it does serve a purpose and will if nothing else afford backticks as delimiters for those using ASCIIMathML as a filter, so I would like to see that included in any distro in the hope (slim perhaps but nevertheless there) that someone may beat me to completing the asciimathml xml file ;=}
e) Having looked over much of the work Peter has put into integrating adciimathml into htmlarea and xinha, I am concerned that the decisions regarding the new editor to be core moodle take into account the need to accomodate scientific and mathematical notation "out of the box" and whated to simply opine to the ether here that whether FCKEd., tinyMCE or some other candidate is chosen, it wold be nice if the moodle version had easily managed hooks, API, etc (I smile every time I notice where my smileys no longer appear in htmlarea....) Is anyone looking at this or talking to editor/ wiki developers about such matters?
Thanks for all the work you and others have done on this!
As I came across Chris' name first on the DragMath page than yours I have been chatting him up about this via e-mail.
Let me cover a couple of points from our correspondence as well as my "private" concerns:
a) I was hoping to address a question I had about the usage of /cdot. If I delete the /cdot stanza from the xml file so as to avoid, for example {2 /cdot ab} which is what dragmath produces if you do "2ab" , you cannot then intentionally insert the dot if you want to use it, which is not an advancement...... I suggested to Chris that I thought the java was inserting the /cdot in this instance (whenever it saw a coefficient in a term), and where as there was nothing wrong with it and it was technically correct, not everyone wanted a dot behind every coefficient.... and I wondered whether deleting that automated insertion was "trivial" or not.
b) I think the key to avoiding unnecessary frustration in the transition is to ensure that the default format file IS set to moodletex.xml so as to make sure that there aren't then lots of posts about double doubledollars signs... I have attached a file that sets this as default and also is format neutral as far as the function... which makes no practical diff, but I think adds clarity. And I assume you will add the moodletex.xml item to config.xml
c) I mentioned to Chris that I had assumed that the applet would simply read the formats and languages directories, as opposed to requiring identification of these in config.xml and he said he would bounce that off you as he thought there had been perm issues....
d) While Peter Jipsen has I think appropriately noted that one of his interests in developing ASCIIMathML was to avoid the necessity of a gui, I thought that offering students the ability to start with the gui and and see the asciitex made good pedagogical sense. A full XML mapping is going to require more work than my current ASCIIMathML file reflects, but pending a simple resolutions of issues such as square brackets in ewiki it does serve a purpose and will if nothing else afford backticks as delimiters for those using ASCIIMathML as a filter, so I would like to see that included in any distro in the hope (slim perhaps but nevertheless there) that someone may beat me to completing the asciimathml xml file ;=}
e) Having looked over much of the work Peter has put into integrating adciimathml into htmlarea and xinha, I am concerned that the decisions regarding the new editor to be core moodle take into account the need to accomodate scientific and mathematical notation "out of the box" and whated to simply opine to the ether here that whether FCKEd., tinyMCE or some other candidate is chosen, it wold be nice if the moodle version had easily managed hooks, API, etc (I smile every time I notice where my smileys no longer appear in htmlarea....) Is anyone looking at this or talking to editor/ wiki developers about such matters?
Thanks for all the work you and others have done on this!
In reply to Marc Grober
Re: Dragmath integration - Extending functionality - files
by Alex Billingsley -
Marc,
In response to your questions:
a) DragMath does insert a dot whenever it parses text and sees a coefficient. Removing the automated insertion would be trivial, however as DragMath works with other formats such as Maple and Maxima, not just LaTeX, removing it would cause problems. As LaTeX is presentational it doesn't matter if we write '2x' or '2*x'. Formats like Maple and Maxima will only accept '2*x' though. The only way I can think to achieve this without creating a Moodle/LaTeX specific DragMath version, is to offer the user an option within the program to turn on/off the automatic insertion?
c) The config.xml file was for implementation purposes, as I did not find a way to list the files in a directory that weren't local.
d) As I know the structure of the xml format files best, it would probably be easiest for me to complete the asciimathml file. I would just need to look up the syntax for asciimathml.
I shall add these changes as feature requests to the SourceForge project.
Alex
In response to your questions:
a) DragMath does insert a dot whenever it parses text and sees a coefficient. Removing the automated insertion would be trivial, however as DragMath works with other formats such as Maple and Maxima, not just LaTeX, removing it would cause problems. As LaTeX is presentational it doesn't matter if we write '2x' or '2*x'. Formats like Maple and Maxima will only accept '2*x' though. The only way I can think to achieve this without creating a Moodle/LaTeX specific DragMath version, is to offer the user an option within the program to turn on/off the automatic insertion?
c) The config.xml file was for implementation purposes, as I did not find a way to list the files in a directory that weren't local.
d) As I know the structure of the xml format files best, it would probably be easiest for me to complete the asciimathml file. I would just need to look up the syntax for asciimathml.
I shall add these changes as feature requests to the SourceForge project.
Alex
In reply to Alex Billingsley
Re: Dragmath integration - Extending functionality - files
by Marc Grober -
Thanks Alex,
I was afraid the dot would present issues with other filters. Can the "switch" you mention be invoked automagically by tying it to the export format? This might have additional uses, as well, if such switches could be included in the format's xml (e.g. <JavaFunction><nodotinsert=true></JavaFunction>.) But I am thinking that also may mean there may be state issues involved? I am not looking to make more work for you, really! ;=} What do you think?
Peter Jipsen provided this reference to me,
Marc
I was afraid the dot would present issues with other filters. Can the "switch" you mention be invoked automagically by tying it to the export format? This might have additional uses, as well, if such switches could be included in the format's xml (e.g. <JavaFunction><nodotinsert=true></JavaFunction>.) But I am thinking that also may mean there may be state issues involved? I am not looking to make more work for you, really! ;=} What do you think?
Peter Jipsen provided this reference to me,
The basic description of the syntax is at http://www1.chapman.edu/~jipsen/mathml/asciimathsyntax.html (yes, it is pretty brief).as far as asciimathml syntax and indicated that about as much as there is.....
Marc
In reply to Marc Grober
Re: Dragmath integration - Extending functionality - files
by Alex Billingsley -
Marc,
An option in the format's xml file would make sense, then DragMath can determine whether or not to include the syntax for the dot when it is creating the output syntax.
I have added MoodleTex and ASCIIMathML files to the DragMath CVS on SourceForge. I tried to convert as much of the ASCIIMathML as possible.
The files can be viewed here:
http://dragmath.cvs.sourceforge.net/dragmath/ddma/formats/
In reply to Alex Billingsley
Re: Dragmath integration - Extending functionality - files
by Marc Grober -
Alex,
Could not find the files in the Moodle CVS but did find it in yours. I checked them out and want to point out that the MoodleTex.xml file, while providing the double dollars in the Initial tag, does not avoid the square bracket issue, which I think is what is intended (i.e. MoodleTex is only the Latex file with the initial tags) . As a matter of curiosity does the moodle tex filter interpret /root and if so, should we use /root for Nth Root in MoodleTex until Moodle 2.0's release provides an Nwiki with more advanced tagging, escaping, etc? The ASCIIMathML file seems to work just fine and we are putting it through its paces. Thanks!
As far as adding extra tags to address such matters as the insert of the /cdot, which src file accomplishes this and are there other instances in which it does interpretation prior to using the format file to parse the text?
I was also wondering if you knew what format OpenOffice used for text expressions. Truth of the matter is that is where this started for me (a teacher here was doing all his Math assignments in OpenOffice and he became distressed when the text expressions OOo produced did not seem to be interpreted correctly by anything except OOo. It has some nice tools (including the ability to produce MathML, gifs and go back and forth between text expression and MathML but I can't seem to find anything about the syntax of its text expressions.
Could not find the files in the Moodle CVS but did find it in yours. I checked them out and want to point out that the MoodleTex.xml file, while providing the double dollars in the Initial tag, does not avoid the square bracket issue, which I think is what is intended (i.e. MoodleTex is only the Latex file with the initial tags) . As a matter of curiosity does the moodle tex filter interpret /root and if so, should we use /root for Nth Root in MoodleTex until Moodle 2.0's release provides an Nwiki with more advanced tagging, escaping, etc? The ASCIIMathML file seems to work just fine and we are putting it through its paces. Thanks!
As far as adding extra tags to address such matters as the insert of the /cdot, which src file accomplishes this and are there other instances in which it does interpretation prior to using the format file to parse the text?
I was also wondering if you knew what format OpenOffice used for text expressions. Truth of the matter is that is where this started for me (a teacher here was doing all his Math assignments in OpenOffice and he became distressed when the text expressions OOo produced did not seem to be interpreted correctly by anything except OOo. It has some nice tools (including the ability to produce MathML, gifs and go back and forth between text expression and MathML but I can't seem to find anything about the syntax of its text expressions.
In reply to Marc Grober
Re: Dragmath integration - Extending functionality - files
by Alex Billingsley -
Marc,
I'm not sure whether we should use \root or not in Moodle. If needed I can change the syntax in the Moodletex file.
I know nothing of the OpenOffice expressions.
I'm not sure whether we should use \root or not in Moodle. If needed I can change the syntax in the Moodletex file.
I know nothing of the OpenOffice expressions.
In reply to Marc Grober
Re: Dragmath integration - Extending functionality - files
by Anthony Borrow -
Marc - the dragmath code is now in CVS so feel free to create an issue and upload the zip file in the tracker (CONTRIB section, dragmath compenent) and it will automatically assign itself to John Isner who can evaluate the zip file and work on incorporating as appropriate. Peace - Anthony
In reply to Anthony Borrow
Re: Dragmath integration - Extending functionality - files
by Marc Grober -
I think I am lost in time here Anthony ;=}
Was this a general heads up or with respect to specific issues? I think everything moodlish we have discussed already other than a future change in the java code to exclude assumed usage of cdot has been addressed. Isn't that correct Alex and John? Do I need to take an additional step with respect to the mod that deletes the insertion of the double dollars in the integration file or has this already been done? Is the dragmath code going to live somewhere other than at the dragmath site?
Was this a general heads up or with respect to specific issues? I think everything moodlish we have discussed already other than a future change in the java code to exclude assumed usage of cdot has been addressed. Isn't that correct Alex and John? Do I need to take an additional step with respect to the mod that deletes the insertion of the double dollars in the integration file or has this already been done? Is the dragmath code going to live somewhere other than at the dragmath site?
In reply to Marc Grober
Re: Dragmath integration - Extending functionality - files
by Anthony Borrow -
Marc - Sorry for any confusion ... I feel like I do live in a time warp on good days, an alternate universe on others. In any case, I was going through items that I had tagged as needing follow up and I was simply responding to an old message. I have been working with John Isner who will be maintaining the Moodle HTML-Editor integration code and keeping a copy of DragMath code in Moodle's CVS to help simplify installation. The goal is to have a zip file that folks can copy into their installation and have the DragMath button function in the HTML-Editor. If you have changes for the DragMath code itself, that would be handled separately; however, if it relates to the Moodle integration and those changes have not been applied or considered then I would suggest using the tracker. Does that help to clear things up? Peace - Anthony
In reply to Anthony Borrow
Re: Dragmath integration - Extending functionality - files
by John Isner -
Anthony and Marc,
I have been confused about DragMath since Day One. I will gladly stand aside and let Marc take over the version in contrib if (a) Marc wants the responsibility and (b) Anthony approves.
I have been confused about DragMath since Day One. I will gladly stand aside and let Marc take over the version in contrib if (a) Marc wants the responsibility and (b) Anthony approves.
In reply to John Isner
Re: Dragmath integration - Extending functionality - files
by Anthony Borrow -
John - I certainly have no problems with whoever wishes to maintain. I will let you and Marc thumb wrestle for who the primary maintainer is but I can give you both access CVS so that you can tag team it. Just let me know what works best for you. Peace - Anthony
I think John is doing a great job handling this (confusion and all) and I was not looking to take this over... Not that I am opposed to helping out, but this is simply outside of my usual scope of activity. And of course I am sure I don't have the patience John has shown. With new editors coming on board this is also going to require a pretty extensive understanding of the existing code base and huge amount of time, and I am afraid I am quite a bit short on both.... I stuck my nose in here simply because I was trying to get a teacher I am supporting off the ground with Math notation in the moodle and should not be confused with someone who should be responsible for this.....
I think that John is the man by acclamation. But I also think we need to help him out, as he has I think suggested, by trying to promote the use of the CVS and providing some easy guidelines for people who have code to offer... Is that a reasonable way to put tnat John? A forum can be a bewildering place and uploading code a bit intimidating.
I think that John is the man by acclamation. But I also think we need to help him out, as he has I think suggested, by trying to promote the use of the CVS and providing some easy guidelines for people who have code to offer... Is that a reasonable way to put tnat John? A forum can be a bewildering place and uploading code a bit intimidating.
Hi Marc,
Thanks for the kind words, but I respectfully disagree: I'm not doing a great job. I'm not doing any job! I became frustrated with social-constructionist version control and decided to exit the game a while ago. I haven't been following the discussions of ASCIIMathML, moodletexml, TinyMCE, etc., although I'm sure they are important and interesting discussions.
IMO we should not offer a "full integration package" -- i.e., an all-in-one zip file that you "simply unzip in your rootdir" -- even though that's what the users obviously want. It invites the versioning problems and will lead the posting of even more all-in-one zip files in the forums.
In particular, I feel strongly that we should not make copies of the DragMath editor. Users should download it independently from SourceForge, where Alex and Chris maintain it. Alex and Chris should be able to update it at any time they like without having to coordinate with Moodle, unless the change breaks an interface, in which case they should give us a heads-up.
DragMath integration is a patch. Like other 3rd-party patches, it should be a collection of diff files made with the Unix diff command that can be applied to Moodle core files using the Unix patch command. Of course this will not be popular with users in the Math Tools forum, and they won't do it. Someone will come along with an all-in-one zip file, and that person will be a hero until version issues creep back in and the "DragMath doesn't work" posts start again. IMO it's a losing battle.
Thanks for the kind words, but I respectfully disagree: I'm not doing a great job. I'm not doing any job! I became frustrated with social-constructionist version control and decided to exit the game a while ago. I haven't been following the discussions of ASCIIMathML, moodletexml, TinyMCE, etc., although I'm sure they are important and interesting discussions.
IMO we should not offer a "full integration package" -- i.e., an all-in-one zip file that you "simply unzip in your rootdir" -- even though that's what the users obviously want. It invites the versioning problems and will lead the posting of even more all-in-one zip files in the forums.
In particular, I feel strongly that we should not make copies of the DragMath editor. Users should download it independently from SourceForge, where Alex and Chris maintain it. Alex and Chris should be able to update it at any time they like without having to coordinate with Moodle, unless the change breaks an interface, in which case they should give us a heads-up.
DragMath integration is a patch. Like other 3rd-party patches, it should be a collection of diff files made with the Unix diff command that can be applied to Moodle core files using the Unix patch command. Of course this will not be popular with users in the Math Tools forum, and they won't do it. Someone will come along with an all-in-one zip file, and that person will be a hero until version issues creep back in and the "DragMath doesn't work" posts start again. IMO it's a losing battle.
Warning - this is probably way too long, but I did want to get some if this on the table.
I think that part of the "job", John, sometimes a the most difficult part, is channeling all this energy; like herding cats. I think you are being a bit too hard on yourself in that you are the reason we are having this discussion.... it is a critical discussion for the reasons you note.
I support quite a bit of what you are saying, but, a cat is a cat after all, and I have to have a few caveats of my own ...
If I hear distant trumpets calling over a dispute as to whether dragmath integration should become a full dragmath moodle plugin, module, etc I think I have to agree that in this respect we are I think over stepping the bounds I think (did I stick enough "I thinks" in there.....?) DragMath has, as I think I mentioned earlier, functionality and application beyond Moodle. If anyone were to take that on such a unitized package, I would have to argue it would be Alex (though breathe easy Alex as I am not arguing for that either - at least at present ;=} ) as it is their app.
On the other hand, as a user I would dearly love to see a slam bam solution... and I have spent a good deal of time because the user I was supporting was lost in space and I was volunteered ..... So, I would support an integration that would be as simple as putting folder X in path Y. Then again, I think you should be able to upload and add modules from inside the moodle interface, so its not like I have my finger on the pulse of the community!
That being said, I see a larger problem in that we want to support use of Math in moodle, or for that matter, any alternative orthography, so if someone from SRA wants to demo some Reading Mastery (praise be to all copyrights and the holders thereof) access to applets that allow one to insert mathml or any other xml schema that can be accomplished, both from the standpoint of construction (the creation of whatever is necessary to enable display, as in DragMath) or display (which is separate and apart, woe is us, from construction). Peter Jipsen I think had it closest in trying to use the same set of tools for contraction as well as display when he modded htmlarea and xinha to do asciimathml. BUT, here we have to address whether the moodle should remain constructor and display neutral, or adopt specific technologies as core or moduled elements.
From the user perspective, having a super duper editor that does everything lighting fast with no detrimental impact on anything and works in every browser is top o' the list.... (wait, can't you just hear the cats meowing again) However, while the argument was one of the nobler I have heard, the recent discussion of nwiki vs ouwiki was enervating and one need only put an ear to the disputes between phpgroupware and egroupware to see just how difficult things can get when you talk about singling out this or that.
I am therefore firmly and positively on the fence.... I want everything and I want it easy.... but I want to make sure that those who want sugar in their coffee and milk in their tea have that option.... no matter the senselessness of such ideas.... milk, indeed!
To me that suggests that moodle developers suggest, propose, design, what have you an API for html editor plugins and ask the html editor developers and the plugin editors (and in this view DragMath would be an editor plugin) to think about working towards that interface. That eliminates the integration issue altogether, in the fullness of time (does someone hear meows....) How does it go, "We can change. If we have to. I guess.."
And display wise it would be nice if moodle would support tools that displayed everything you through at it, one reason I like asciimathml (and will love it if it will do openoffice math ext expressions as well) though it seems to me that rather than filter every page we should be able to tag what pages need filtering. Open, universal, easy.
Short term: one folder, no edits, KISS. No grand schemes unless those who are maintaining the code (read Alex for example) take that on, and should that become the case there is already a process which may or may not obsolete the integration. Don't offer or call it a patch as that is scary and some won't have shell access, but keep it much like it is today.
Sorry for the rant (and I do support <rant> </rant>)
And, btw, thanks John....
I think that part of the "job", John, sometimes a the most difficult part, is channeling all this energy; like herding cats. I think you are being a bit too hard on yourself in that you are the reason we are having this discussion.... it is a critical discussion for the reasons you note.
I support quite a bit of what you are saying, but, a cat is a cat after all, and I have to have a few caveats of my own ...
If I hear distant trumpets calling over a dispute as to whether dragmath integration should become a full dragmath moodle plugin, module, etc I think I have to agree that in this respect we are I think over stepping the bounds I think (did I stick enough "I thinks" in there.....?) DragMath has, as I think I mentioned earlier, functionality and application beyond Moodle. If anyone were to take that on such a unitized package, I would have to argue it would be Alex (though breathe easy Alex as I am not arguing for that either - at least at present ;=} ) as it is their app.
On the other hand, as a user I would dearly love to see a slam bam solution... and I have spent a good deal of time because the user I was supporting was lost in space and I was volunteered ..... So, I would support an integration that would be as simple as putting folder X in path Y. Then again, I think you should be able to upload and add modules from inside the moodle interface, so its not like I have my finger on the pulse of the community!
That being said, I see a larger problem in that we want to support use of Math in moodle, or for that matter, any alternative orthography, so if someone from SRA wants to demo some Reading Mastery (praise be to all copyrights and the holders thereof) access to applets that allow one to insert mathml or any other xml schema that can be accomplished, both from the standpoint of construction (the creation of whatever is necessary to enable display, as in DragMath) or display (which is separate and apart, woe is us, from construction). Peter Jipsen I think had it closest in trying to use the same set of tools for contraction as well as display when he modded htmlarea and xinha to do asciimathml. BUT, here we have to address whether the moodle should remain constructor and display neutral, or adopt specific technologies as core or moduled elements.
From the user perspective, having a super duper editor that does everything lighting fast with no detrimental impact on anything and works in every browser is top o' the list.... (wait, can't you just hear the cats meowing again) However, while the argument was one of the nobler I have heard, the recent discussion of nwiki vs ouwiki was enervating and one need only put an ear to the disputes between phpgroupware and egroupware to see just how difficult things can get when you talk about singling out this or that.
I am therefore firmly and positively on the fence.... I want everything and I want it easy.... but I want to make sure that those who want sugar in their coffee and milk in their tea have that option.... no matter the senselessness of such ideas.... milk, indeed!
To me that suggests that moodle developers suggest, propose, design, what have you an API for html editor plugins and ask the html editor developers and the plugin editors (and in this view DragMath would be an editor plugin) to think about working towards that interface. That eliminates the integration issue altogether, in the fullness of time (does someone hear meows....) How does it go, "We can change. If we have to. I guess.."
And display wise it would be nice if moodle would support tools that displayed everything you through at it, one reason I like asciimathml (and will love it if it will do openoffice math ext expressions as well) though it seems to me that rather than filter every page we should be able to tag what pages need filtering. Open, universal, easy.
Short term: one folder, no edits, KISS. No grand schemes unless those who are maintaining the code (read Alex for example) take that on, and should that become the case there is already a process which may or may not obsolete the integration. Don't offer or call it a patch as that is scary and some won't have shell access, but keep it much like it is today.
Sorry for the rant (and I do support <rant> </rant>)
And, btw, thanks John....
In reply to John Isner
Re: Dragmath integration - Extending functionality - files
by Anthony Borrow -
John - Actually my hope is that by having it in CVS we have a version that folks can point to and say, this is the latest version that someone has done some work with and is most likely to work. Having a copy in Moodle of DragMath should not in any way inhibit those who are developing it. They should not feel obliged to check and see what we are doing. They work independently and we adapt to do what they choose to do. Having a single zip file that folks can point to for a particular version of Moodle should help to standardize things. If others want to use a different version that they download from the DragMath site and it works better, then they can do a feature request that we upgrade ours. I think having it in CVS makes life easier for everyone as there is at least some coordination when it comes to troubleshooting things. I know that based on my experience of working with the GBPv2 patch, I frequently ask folks to upgrade to the latest version. Since it is always in the same location there is no need to have a bunch of zip files in the forum. This is what CVS attempts to avoid. So I really think that we can have our cake and eat it too 
Peace - Anthony
In reply to Anthony Borrow
Re: Dragmath integration - Extending functionality - files
by Marc Grober -
John,
Do you have a smiley for a spinning head ;=}
As far as the DragMath htmlarea integration, here is what my understanding is of what has taken place:
Do you have a smiley for a spinning head ;=}
As far as the DragMath htmlarea integration, here is what my understanding is of what has taken place:
- Alex put together a new set of xml files so that the doubledollars signs could be moved from the integration to dragmath itself, since dragmath is built to do that.
- Alex also added additional xml format files so that dragmath would do ASCIIMathML
- The files Alex built are in the DragMath CVS.
- I uploaded my proposed amendment to the dlg file to the forum, but did not put it anywhere else. I thought I saw something from someone else that indicated they were going to move that file to the Moodle DragMath Integration CVS in consort with Alex (since the change in the dlg file should be contemporaneous with any changes to the dragmath files)
- The changes I made (documented in the file I think I uploaded to the forum) basicaly did 3 things: changed the name of the function so it was not format specific, removed the insertion of the double dollar signs by the php script, and set by default the MoodleTex format (which used DragMath's <Initial> tag to insert dollar signs.)
In reply to Anthony Borrow
Re: Dragmath integration - Extending functionality - files
by Marc Grober -
Anthony Alex and John,
I have uploaded the dlg_ins_smiley.php file I fiddled to go along with Alex's addition and modification of his xml export format files into CONTRIB-333 in the hope that this is what the next step was. However, as I understood the discussion in the tracker the idea was to maintain a a full integration package, so I am not quite sure whether someone offering one is expected to put together the entire zip and upload it? That should be taken care of in the CVS, no? Sorry, but I am now way more confused than John has ever been.....
I have uploaded the dlg_ins_smiley.php file I fiddled to go along with Alex's addition and modification of his xml export format files into CONTRIB-333 in the hope that this is what the next step was. However, as I understood the discussion in the tracker the idea was to maintain a a full integration package, so I am not quite sure whether someone offering one is expected to put together the entire zip and upload it? That should be taken care of in the CVS, no? Sorry, but I am now way more confused than John has ever been.....
In reply to Marc Grober
Re: Dragmath integration - Extending functionality - files
by Mauno Korpelainen -
Hi all,
Glen's TinyMCE is a TEST integration but it would be fantastic to get a couple of optional Equation editors to moodle.
Mathieu Petit-Clair has just started working on new core editor integration and TinyMCE, FCKEditor and Xinha are alternate editors http://tracker.moodle.org/browse/MDL-11113 for moodle 2.0. All those editors work with latest versions of Opera and Safari and adding Equation editor plugin without replacing any old plugins like smilies should be easy and special Character plugins like Enrique's "Insert Special Character" with small fix by Dean http://moodle.org/mod/forum/discuss.php?d=20864 can also be modified to new editor(s).
In reply to Marc Grober
Re: Dragmath integration - Extending functionality - files
by Anthony Borrow -
Marc - I have added you as a watcher to CONTRIB-333 so you should get emails of any comments made there. Feel free to stop watching if you want but I wanted to keep you up to date on things. In any case, part of the reason of using CVS is that it will automatically create a zip file of the latest code every night which is available at http://download.moodle.org/patches/dragmath.zip. The users take the files in the dragmath folder (which is a single folder called lib) and copy them into/over their Moodle installation files and voila they have dragmath enabled for their HTMLEditor. Does that make any more sense? Peace - Anthony
In reply to Anthony Borrow
Re: Dragmath integration - Extending functionality - files
by Marc Grober -
I see where you are going now, nice idea....
but...
I have to suggest (see my babbling post above, below or where ever of even date) that while we might reference dragmath we need to be careful about packaging something that is separate. If you want to throw a link to Alex's CVS to a dragmath that works with a specific version of the integration, well I might go that far, but as John suggests, with so much opportunity to get cross wise on versioning and no cpan like moodle utility to hunt down and reconcile versioning and dependencies as part of module installation (what a neat idea!) is this really where we should go?
and...
WIll we end up doing the same thing for each and every editor and each and every "plugin".
I like the idea of it being modular and dragmath being a plugin... I just have concerns about including the plugin in the package and the degree to which such modularization is just limited to his matter, or will be generalized across editors and plugins...
Your thoughts?
but...
I have to suggest (see my babbling post above, below or where ever of even date) that while we might reference dragmath we need to be careful about packaging something that is separate. If you want to throw a link to Alex's CVS to a dragmath that works with a specific version of the integration, well I might go that far, but as John suggests, with so much opportunity to get cross wise on versioning and no cpan like moodle utility to hunt down and reconcile versioning and dependencies as part of module installation (what a neat idea!) is this really where we should go?
and...
WIll we end up doing the same thing for each and every editor and each and every "plugin".
I like the idea of it being modular and dragmath being a plugin... I just have concerns about including the plugin in the package and the degree to which such modularization is just limited to his matter, or will be generalized across editors and plugins...
Your thoughts?
In reply to Marc Grober
Re: Dragmath integration - Extending functionality - files
by Anthony Borrow -
Moodle makes use of code from other projects - HTMLEditor being a prime example - we choose a version that works for Moodle and customize it, tweak it, mangle it whatever we need to do for Moodle. Yes, as the product (whether it be HTMLEditor, DragMath, etc) continues to develop merging in the fixes, improvements, etc. can be a challenge but that is what the maintainer does for the rest of the community - they maintain it and determine which things will suit the community the best. Of course individuals are always free to customize, developers are free to play, and specific patches can be suggested by the community and the maintainer(s) will use his, her, or their best judgment based on what serves the community and what they are willing and able to do. On the other hand, there are parts of Moodle in which the version is not as important. Here I am thinking of things like aspell, clamav, eAccelerator where the user is expected to go out and get the tool that they need. I am not familiar enough with the DragMath software to know which category it falls in and I made a guess/assumption that others might not be familiar with it either so I figured it best to include it as one bundle (at least for now). My idea was to minimize confusion about where the DragMath files were to be installed; however, like with aspell and other tools we could add a configuration setting for the DragMath path. To do so, I would recommend adding a new feature issue to the tracker requesting that the setting be made to allow for the independence of where the DragMath code is installed on the system. I'm open to whatever suits the community the best. Ultimately it is the maintainer's choice after listening to the community and making an informed decision. Peace - Anthony
In reply to Marc Grober
Re: Dragmath integration - Extending functionality - files
by Mauno Korpelainen -
I have been playing with Xinha, TinyMCE and FCKEditor configuration for several days now and I think we can get dragmath to work as plugin with any editor. Xinha is almost like Htmlarea (they use mostly same code), Glen's tinymce Dragmath had just a small problem with path of codebase and plugins of FCKeditor are not too much different from other editors. It is also possible to rewrite htmlarea plugin - why should it take away smilies plugin?
The best situation is that we can upgrade moodle, editors and plugins separately - what ever editor we use upgrading the files of Dragmath should be easy.
In reply to Mauno Korpelainen
Re: Dragmath integration - Extending functionality - files
by Marc Grober -
I think what has come out of the smiley discussion has been the following:
- If various components of any solution are essentially being managed out of the forum it becomes an unmitigated disaster as it gets very confusing very quickly and frustrating for the user, the developer and the maintainer.
- Since we are talking about three different levels of development, if we don't have coherency then we will have things that break. For example, the Dragmath integration still includes dbldollars while DragMath has also added same. (as I understand it, Anthony's solution is not the same as John's, John's is published, and neither addresses the new version of dragmath or the changes that allow dragmath to insert the dbldollars....)
- There will arguably be a different integration for each "plugin" to each editor.
- While you are correct in stating that smilies for example can be retained, the question becomes one of managing resources and those resources include not only the time and energy to cobble the code, but the time and energy as well as to manage QA and versioning....