I would have crossposted if this was a mailing list too
http://lists.laptop.org/pipermail/server-devel/2009-March/003119.html
Hello!
I am a student interested in helping the Moodle project over the summer. I want to apply to this year's Google Summer of Code.
I have a pretty good experience with developing a paint application. The current demo / proof of concept is available open-source at Google Code:
http://code.google.com/p/paintweb
Since it's just a proof of concept: the entire code needs reorganization, separation into multiple files, proper packaging, perf improvements, additional tools and options, and a new GUI.
> On Thu, Mar 19, 2009 at 11:16 AM, Alex Wulms
> wrote:
>> Regarding the finger painting application: at
>> the moment we don't have much
>> information about what is expected about it.
Finger painting application, not sure what you mean here. It's a matter of the device the user has available. To me, from the technical POV, it's a mouse / a pointing device.
If you are referring to the the OLPC input devices, I'd like further details. I haven't tested any OLPC myself. Do Web applications need any additional technical support for finger touch?
>> Here is the info that we have:
>> --- start of info
>> * Moodle is the Course Management
>> System / Learning Management System.
>> It is the "main face" of the webbased tools
>> that the
>> School Server offers. Most of online
>> (webbased) interaction is via forms -- a
>> text-heavy approach, thus aimed at older kids.
>> * Young children find it easier to paint
>> and draw.
>> * If we can switch the WYSIWYG HTML
>> editors in forms with a Paint Here
>> facility, then we make web based tools easier
>> for them.
True, kids like to paint and since they are kids, well you don't have to give them Photoshop-level features. Something to the level of KolourPaint / MS Paint (preferrably even above this level) should be sufficient for children. Anyhow, it is important to have a working paint tool, one that can be further expanded, with new functionality as deemed necessary.
Regarding the integration of a paint tool in Moodle: I believe there are two main approaches to this aspect.
1. Integrate the paint tool into TinyMCE, such that users can select an image and click Edit. Once they start editing the image the tool bars change to provide the painting functionality.
This has the advantage of contributing to the upstream project: TinyMCE. They might as well enjoy this and provide all of their users with the paint tool extension.
2. Integrate the paint tool into Moodle itself, such that it can be used independently of TinyMCE.
The main advantage in this case is you can have an "Edit image" option in your file manager, which loads the paint tool inplace, without TinyMCE.
Personally I would opt for the second method of integration. Let me further explain why I believe it's a better choice.
TinyMCE doesn't currently (and I am not sure it will ever) have a proper graphical user interface for a paint tool. Currently, it's a bunch of toolbars with buttons. A paint tool needs more: it will need layers, it will need tool options, and much more.
The GUI approach for a WYSIWYG HTML editor is much different from one for a paint tool. This is why I say TinyMCE might never have a proper GUI for a paint tool.
Another reason for wanting the paint tool integration into Moodle itself is you can use it whenever you want, you don't really restrict image editing to articles. It wouldn't be nice.
Also, the TinyMCE team would probably not want a paint tool (you know the saying "do one thing, and do it right"). As such, if the Moodle project forks the TinyMCE code, then updating TinyMCE in Moodle when a new upstream release is available, will become harder. (obviously, this really depends how we choose to do the integration work)
Last, but not least, having the paint tool tightly integrated (maybe as an extension?) into Moodle does not prevent us from integrating the paint tool into TinyMCE as well.
It's perhaps the best way.
From a technical perspective: the integration I have in mind would make use of AJAX to invoke the paint tool everywhere it's needed. Therefore, you won't need a separate page for editing an image - even if you edit in the file manager, or in the article editor (tinymce).
>> Implementation idea
>>
>> * Write a vector-based "paint" facility
>> in JS that runs in the browser.
>> * Write a vector or bitmap paint
>> facility in Flash, bearing in mind that
>> OLPC ships Gnash instead of Adobe's Flash
The project I am working on, Paint.Web, does not use Flash. It's all based on open specifications. It uses the new Canvas 2D context API from HTML5 - lots of JavaScript and DOM work. It is already implemented in Safari, Google Chrome, Firefox, Opera, all Webkit and all Gecko based Web browsers. I am not sure about mobile devices.
Regarding performance: all Web browsers are working on serious performance improvements. Canvas is the best choice in my opinion, much better than Flash.
Currently, Paint.Web is only a bitmap-based painting tool. We could extend it to SVG, however, that would require a lot of work. I presume kids won't mind it's not vector-based, at least not for now. We should aim to get something working, which is expandable.
The matter of having a "replay" button should not pose a problem. I can implement a replay button, which would allow the user to see how he painted the image.
>> Another question is about how you see the
>> further integration with Moodle and
>> potentially with TinyMCE.
> - If it is possible to integrate it into
> TinyMCE itself it might be a
> good idea -- means that it canbe reused by
> any other webapp using TinyMCE
> - I _think_ that TinyMCE is relatively modular.
> If this can "plugin" into tinyMCE, great so
> moodle can ship a "standard" TinyMCE with a
> plugni, rather than a patched TinyMCE. This
> may well be impossible though
Exactly, my point as well. We should think about making the paint tool nicely integrated into Moodle and add just a simple "plugin" into TinyMCE which calls the new paint tool using AJAX, to edit the selected image.
> The whole magic of this is "paint right there in
> the form". We already
> have "switch to a Paint program, paint, save,
> go to the browser,pick the file to submit,
> post it", and it's unusable for young kids,
> anduncomfortable for everyone...
True, and this can be done. We can make sure the workflow is simple enough.
I am open to questions, suggestions and ideas. Let's see if we can decide on something.
I am a student interested in helping the Moodle project over the summer. I want to apply to this year's Google Summer of Code.
I have a pretty good experience with developing a paint application. The current demo / proof of concept is available open-source at Google Code:
http://code.google.com/p/paintweb
Since it's just a proof of concept: the entire code needs reorganization, separation into multiple files, proper packaging, perf improvements, additional tools and options, and a new GUI.
> On Thu, Mar 19, 2009 at 11:16 AM, Alex Wulms
> wrote:
>> Regarding the finger painting application: at
>> the moment we don't have much
>> information about what is expected about it.
Finger painting application, not sure what you mean here. It's a matter of the device the user has available. To me, from the technical POV, it's a mouse / a pointing device.
If you are referring to the the OLPC input devices, I'd like further details. I haven't tested any OLPC myself. Do Web applications need any additional technical support for finger touch?
>> Here is the info that we have:
>> --- start of info
>> * Moodle is the Course Management
>> System / Learning Management System.
>> It is the "main face" of the webbased tools
>> that the
>> School Server offers. Most of online
>> (webbased) interaction is via forms -- a
>> text-heavy approach, thus aimed at older kids.
>> * Young children find it easier to paint
>> and draw.
>> * If we can switch the WYSIWYG HTML
>> editors in forms with a Paint Here
>> facility, then we make web based tools easier
>> for them.
True, kids like to paint and since they are kids, well you don't have to give them Photoshop-level features. Something to the level of KolourPaint / MS Paint (preferrably even above this level) should be sufficient for children. Anyhow, it is important to have a working paint tool, one that can be further expanded, with new functionality as deemed necessary.
Regarding the integration of a paint tool in Moodle: I believe there are two main approaches to this aspect.
1. Integrate the paint tool into TinyMCE, such that users can select an image and click Edit. Once they start editing the image the tool bars change to provide the painting functionality.
This has the advantage of contributing to the upstream project: TinyMCE. They might as well enjoy this and provide all of their users with the paint tool extension.
2. Integrate the paint tool into Moodle itself, such that it can be used independently of TinyMCE.
The main advantage in this case is you can have an "Edit image" option in your file manager, which loads the paint tool inplace, without TinyMCE.
Personally I would opt for the second method of integration. Let me further explain why I believe it's a better choice.
TinyMCE doesn't currently (and I am not sure it will ever) have a proper graphical user interface for a paint tool. Currently, it's a bunch of toolbars with buttons. A paint tool needs more: it will need layers, it will need tool options, and much more.
The GUI approach for a WYSIWYG HTML editor is much different from one for a paint tool. This is why I say TinyMCE might never have a proper GUI for a paint tool.
Another reason for wanting the paint tool integration into Moodle itself is you can use it whenever you want, you don't really restrict image editing to articles. It wouldn't be nice.
Also, the TinyMCE team would probably not want a paint tool (you know the saying "do one thing, and do it right"). As such, if the Moodle project forks the TinyMCE code, then updating TinyMCE in Moodle when a new upstream release is available, will become harder. (obviously, this really depends how we choose to do the integration work)
Last, but not least, having the paint tool tightly integrated (maybe as an extension?) into Moodle does not prevent us from integrating the paint tool into TinyMCE as well.
It's perhaps the best way.
From a technical perspective: the integration I have in mind would make use of AJAX to invoke the paint tool everywhere it's needed. Therefore, you won't need a separate page for editing an image - even if you edit in the file manager, or in the article editor (tinymce).
>> Implementation idea
>>
>> * Write a vector-based "paint" facility
>> in JS that runs in the browser.
>> * Write a vector or bitmap paint
>> facility in Flash, bearing in mind that
>> OLPC ships Gnash instead of Adobe's Flash
The project I am working on, Paint.Web, does not use Flash. It's all based on open specifications. It uses the new Canvas 2D context API from HTML5 - lots of JavaScript and DOM work. It is already implemented in Safari, Google Chrome, Firefox, Opera, all Webkit and all Gecko based Web browsers. I am not sure about mobile devices.
Regarding performance: all Web browsers are working on serious performance improvements. Canvas is the best choice in my opinion, much better than Flash.
Currently, Paint.Web is only a bitmap-based painting tool. We could extend it to SVG, however, that would require a lot of work. I presume kids won't mind it's not vector-based, at least not for now. We should aim to get something working, which is expandable.
The matter of having a "replay" button should not pose a problem. I can implement a replay button, which would allow the user to see how he painted the image.
>> Another question is about how you see the
>> further integration with Moodle and
>> potentially with TinyMCE.
> - If it is possible to integrate it into
> TinyMCE itself it might be a
> good idea -- means that it canbe reused by
> any other webapp using TinyMCE
> - I _think_ that TinyMCE is relatively modular.
> If this can "plugin" into tinyMCE, great so
> moodle can ship a "standard" TinyMCE with a
> plugni, rather than a patched TinyMCE. This
> may well be impossible though
Exactly, my point as well. We should think about making the paint tool nicely integrated into Moodle and add just a simple "plugin" into TinyMCE which calls the new paint tool using AJAX, to edit the selected image.
> The whole magic of this is "paint right there in
> the form". We already
> have "switch to a Paint program, paint, save,
> go to the browser,pick the file to submit,
> post it", and it's unusable for young kids,
> anduncomfortable for everyone...
True, and this can be done. We can make sure the workflow is simple enough.
I am open to questions, suggestions and ideas. Let's see if we can decide on something.
Hi Mihai,
I used the expression "finger painting" because the XO laptops have touchpads, so any mouse/pointer means that the user will paint with the finger
It is a good call to make it JS based rather than Flash/Gnash, and it is cool as a bitmap tool. It is entirely your call whether to do things bitmap of vector.
The TinyMCE integration I am suggesting has some reasons to it, but you raise valid points. I do think it can be useful for you to consider it a bit more, for the following reasons:
- The goal is to enable very simple painting in the same dialogs that allow a rich text editor. For that, your point of integration can be the code that pulls in TinyMCE or TinyMCE itself.
(A separate "image editor" form control is desirable, and a definite plus in your plans -- you want to consider adding it to MoodleForms API. But it is not the main goal...)
- Even if it's not tightly integrated into TinyMCE, they have to work as one from the PoV of the user.
- If it is a Moodle specific tool, then the userbase that benefits is Moodle users, and the programmers to maintain it are... the Moodle programmers. If it is integrated to TinyMCE, the benefits expand to the userbase of many webbased OSS tools... and the number of programmers interested in making it good is much larger.
- For the reasons above, it might pay to see whether TinyMCE is pluggable, and if the plug-in mechanism is good for your purposes (or could be made good with some work on the API itself).
As I mentioned in private, I really like paintweb, but performance on the XO is not very good. If you do get the GSoC project, you'll get an XO to test on.
Actually, if you are interested in optimising paintweb for the XO, you should apply for an XO regardless of GSoC - see http://wiki.laptop.org/index.php/Developers_Program
I used the expression "finger painting" because the XO laptops have touchpads, so any mouse/pointer means that the user will paint with the finger
It is a good call to make it JS based rather than Flash/Gnash, and it is cool as a bitmap tool. It is entirely your call whether to do things bitmap of vector.
The TinyMCE integration I am suggesting has some reasons to it, but you raise valid points. I do think it can be useful for you to consider it a bit more, for the following reasons:
- The goal is to enable very simple painting in the same dialogs that allow a rich text editor. For that, your point of integration can be the code that pulls in TinyMCE or TinyMCE itself.
(A separate "image editor" form control is desirable, and a definite plus in your plans -- you want to consider adding it to MoodleForms API. But it is not the main goal...)
- Even if it's not tightly integrated into TinyMCE, they have to work as one from the PoV of the user.
- If it is a Moodle specific tool, then the userbase that benefits is Moodle users, and the programmers to maintain it are... the Moodle programmers. If it is integrated to TinyMCE, the benefits expand to the userbase of many webbased OSS tools... and the number of programmers interested in making it good is much larger.
- For the reasons above, it might pay to see whether TinyMCE is pluggable, and if the plug-in mechanism is good for your purposes (or could be made good with some work on the API itself).
As I mentioned in private, I really like paintweb, but performance on the XO is not very good. If you do get the GSoC project, you'll get an XO to test on.
Actually, if you are interested in optimising paintweb for the XO, you should apply for an XO regardless of GSoC - see http://wiki.laptop.org/index.php/Developers_Program
The idea is we should make the paint tool (let's name it paintweb from now) as a reusable component, in tinymce and moodle, so both communities benefit (both can use it).
I haven't done direct comparison, but I presume drawing SVG is slower than drawing in a bitmap Canvas. However, in the future I do not exclude having them both in paintweb. Yet, for now, we should focus on one thing, so we can get the project done.
For improved performance on the XO it all boils down to simplifying paintweb as much as possible.
I will look into the entire Moodle codebase and the codebase of TinyMCE, and I'll come up with a more detailed technical plan.
I haven't done direct comparison, but I presume drawing SVG is slower than drawing in a bitmap Canvas. However, in the future I do not exclude having them both in paintweb. Yet, for now, we should focus on one thing, so we can get the project done.
For improved performance on the XO it all boils down to simplifying paintweb as much as possible.
I will look into the entire Moodle codebase and the codebase of TinyMCE, and I'll come up with a more detailed technical plan.
Hi,
We were having a bit of a discussion about something similar here:
http://moodle.org/mod/forum/discuss.php?d=119477
I envisaged the tool mainly keeping in mind courses that need diagrams and figures support. Here, i find the interests are similar, a heavy painting tool would have come up a step ahead according to me.
I think a totally reusable component can be worked out with applets without having to delve too much into where we need to integrate it.
The accesses can be simply granted using parameters to the applet.
I am currently figuring out ways to efficiently transfer object states from user to user to facilitate real-time drawing between users/instructor.
I would also suggest saving the image finally on the server itself so that it can cater to the needs like mentioned by Olli at the forum topic i mentioned.
I would definitely like to co-work on this.
We were having a bit of a discussion about something similar here:
http://moodle.org/mod/forum/discuss.php?d=119477
I envisaged the tool mainly keeping in mind courses that need diagrams and figures support. Here, i find the interests are similar, a heavy painting tool would have come up a step ahead according to me.
I think a totally reusable component can be worked out with applets without having to delve too much into where we need to integrate it.
The accesses can be simply granted using parameters to the applet.
I am currently figuring out ways to efficiently transfer object states from user to user to facilitate real-time drawing between users/instructor.
I would also suggest saving the image finally on the server itself so that it can cater to the needs like mentioned by Olli at the forum topic i mentioned.
I would definitely like to co-work on this.
Personally, I would use Flash for this drawing application for a couple of reasons. First and foremost, this sort of application has been done hundreds if not thousands of times before through Flash. There is plenty of Flash documentation for a project like this, but I seriously doubt that there would be much JS coverage. Second, even if the JS drawing app works flawlessly in all modern browsers, it is highly unlikely to work in older browsers. I'm sure that plenty of your site users still use the accursed IE6, which is unlikely to support any of the JS magic necessary for a decent drawing app.
If I am chosen to build this app, I will avoid using vectors. The performance gap between a well-executed bitmap dynamic animation and a vector animation is enormous (see http://www.kirupa.com/forum/showthread.php?t=310697 ). I'm not worried about the client side drawing app; it should be a relatively simple task. However, the most difficult part will undoubtedly be the transfer of the image from the client to the server. The final bitmap will need to be converted to bytecode at the client, sent to the server, and converted back into an image by a server-side script. It may be possible to fool the server into thinking that the image is a standard attachment, but it will take plenty of research.
Good luck with the drawing app; hopefully I'll be able to help out.
If I am chosen to build this app, I will avoid using vectors. The performance gap between a well-executed bitmap dynamic animation and a vector animation is enormous (see http://www.kirupa.com/forum/showthread.php?t=310697 ). I'm not worried about the client side drawing app; it should be a relatively simple task. However, the most difficult part will undoubtedly be the transfer of the image from the client to the server. The final bitmap will need to be converted to bytecode at the client, sent to the server, and converted back into an image by a server-side script. It may be possible to fool the server into thinking that the image is a standard attachment, but it will take plenty of research.
Good luck with the drawing app; hopefully I'll be able to help out.
I have prepared a project proposal of my own. Please see:
http://docs.moodle.org/en/Development:Paint_tool
In there you will find my detailed answers to why it's not a good idea to use Flash nor Java applets.
I would also like everyone to discuss my proposal. Anyone is welcome to help out.
Thank you.
http://docs.moodle.org/en/Development:Paint_tool
In there you will find my detailed answers to why it's not a good idea to use Flash nor Java applets.
I would also like everyone to discuss my proposal. Anyone is welcome to help out.
Thank you.
In reply to Mihai Sucan
Re: gsoc: what you paint is what you get - discussion
by Mauno Korpelainen -
Hi Mihai,
I checked your demo site with IE7, FF3, Opera 9.6.4 and Safari4 and your canvas looks really nice and fascinating. The text you wrote to documentation is also well grounded but there is one thing that I want to point out:
" Cross-browser and cross-platform compatibility. Users do not need to install a different browser (it works in almost all major browsers, including, but not limited to Safari, Chrome, Opera, Firefox, Konqueror, Epiphany), and they do not need additional plugins, nor additional settings rather than the defaults. No specific operating system requirements are made either. Developers who want to work on the paint tool do not need to switch to Windows in order to edit some Flash project, and they do not need a completely different development stack for editing some Java project. Given the fact that all major browsers implement the Canvas 2D context API, except Microsoft Internet Explorer, makes it reasonable to expect that an upcoming release of MSIE will indeed support Canvas. Major companies already use Canvas in their projects (see Yahoo Pipes). Ultimately, it is in Microsoft's best interest to support a wider range of Web applications. Internet Explorer 8 has proven the renewed interest of Microsoft to implement new Web technologies, in an interoperable way. This is yet another reason to believe they will also support Canvas."Safari4 seems to be able to use all features of your demo but IE7 could not use it at - and FF3 & Opera 9.6.4 could not use text tool ("Error: your browser does not implement Canvas Text API! The text tool cannot be used.")
This is more important than any other aspect - the tool *must* be cross-browser and cross-platform compatible but it does not need to use one implementation method for all OS and all browsers. I have struggled with math editors and situation with SVG support and MathML support makes everything in implementing MathML tools for IE difficult - and we need fallback scripts for IE there...
If you visit for example http://www.twiddla.com/1 or http://www.dabbleboard.com/draw those tools "just work". In my opinion the ideal tools can be simple and they can use java, flash, canvas etc as long as they can be used as a part of moodle - integrated and functional parts of moodle. And open source is always better than closed code...
In reply to Mauno Korpelainen
Re: gsoc: what you paint is what you get - discussion
by Mauno Korpelainen -
Mihai,
one example from http://fooplot.com/ (not a drawing application - just an example about using separated graphics rendering):
That demo is trying to use browser-independent vector graphics rendering (VML in IE, SVG in FF and Opera, Canvas for Safari) and separates the code with
var ezvg_browser='';
if(navigator.userAgent.toLowerCase().indexOf('opera')!=-1) ezvg_browser='opera';
else if(navigator.userAgent.toLowerCase().indexOf('gecko')!=-1) ezvg_browser='firefox';
else if(navigator.userAgent.toLowerCase().indexOf('msie')!=-1) ezvg_browser='msie';
else if(navigator.userAgent.toLowerCase().indexOf('safari')!=-1) ezvg_browser='safari';
var ezvg_usesvg=0;
var ezvg_usevml=0;
var ezvg_usecanvas=0;
if(ezvg_browser=='opera') ezvg_usesvg=1;
else if(ezvg_browser=='firefox') ezvg_usesvg=1;
else if(ezvg_browser=='safari') ezvg_usecanvas=1;
else if(ezvg_browser=='msie') ezvg_usevml=1;
and so on.
-----------------------------
Most "basic" things can be done with simple javascripts and php as well - still basic tools can have addons or extra tools for some advanced features that do not need to be cross-browser compatible...
In reply to Mauno Korpelainen
Re: gsoc: what you paint is what you get - discussion
by Mauno Korpelainen -
Mihai,
finally comment to your optimism in
"Internet Explorer 8 has proven the renewed interest of Microsoft to implement new Web technologies, in an interoperable way. This is yet another reason to believe they will also support Canvas"
IE will not support new Web technologies, they develop technologies of their own (closed code) and require that others support their inventions.
Just tested your demo with IE8 stable and the message was clear:
"Your browser does not support <canvas>. You cannot use this Web application."
So in my opinion you need to change the code to support all browsers with different technologies or use other tools like some of those mentioned in http://moodle.org/mod/forum/discuss.php?d=119477 and http://moodle.org/mod/forum/discuss.php?d=110902
In reply to Mauno Korpelainen
Re: gsoc: what you paint is what you get - discussion
by Ritesh Mehta -
That is what even I was thinking about, but for sometime now, I have stopped following MS's plans about Open Source. So wasn't sure of anything.
Anyways the issue is that IE still has a user share of about 67.40 % with the nearest rival being Firefox with around 21.63 %.
And if MS's history is to go by, I wouldn't dare challenge what Mauno has already mentioned. And the easiest way to get around is by plugins which both Flash and java use. There are trade offs of course.
Am running into my end semester exams in 2 days and the entire april is packed but I'm very hopeful that the problem can be solved the way i plan to.
Here's it in brief:
SVG is slower than drawing in a bitmap Canvas
We'll use bitmap. (gotta make it real time u c)
To make byte tranfers:
Grab the pixels from the bitmap.
Create byte stream of RGbs.
Zip it after creation and send it.
The file is unzipped after retrieving
and pixels are retrieved and copied to another array.
plot them.
Now this is only theory, so I'd like to know if this sounds feasible.
I think Hubert can advice on this.
I'd write my application if it is.
Anyways the issue is that IE still has a user share of about 67.40 % with the nearest rival being Firefox with around 21.63 %.
And if MS's history is to go by, I wouldn't dare challenge what Mauno has already mentioned. And the easiest way to get around is by plugins which both Flash and java use. There are trade offs of course.
Am running into my end semester exams in 2 days and the entire april is packed but I'm very hopeful that the problem can be solved the way i plan to.
Here's it in brief:
SVG is slower than drawing in a bitmap Canvas
We'll use bitmap. (gotta make it real time u c
To make byte tranfers:
Grab the pixels from the bitmap.
Create byte stream of RGbs.
Zip it after creation and send it.
The file is unzipped after retrieving
and pixels are retrieved and copied to another array.
plot them.
Now this is only theory, so I'd like to know if this sounds feasible.
I think Hubert can advice on this.
I'd write my application if it is.
In my opinion, the cross-browser obstacles to a Javascript or canvas-based drawing app are far too great. Even if it is possible for you to find suitable technologies for all the major browsers (including IE6), the browser accommodations would take up a considerable amount of your time and energy.
A Java applet would solve some of the cross-browser problems, but it isn't entirely standardized either. More importantly, Java applets are quite slow, even on modern computers.
Flash is certainly your technology of choice. It has an incredibly consistent code base and almost universal support. A good Flash developer can create applets that are both small and fast. Although Gnash's limited compatibility is troubling, someone who is familiar with ActionScript 2 should be able to create this drawing app quickly and easily.
A Java applet would solve some of the cross-browser problems, but it isn't entirely standardized either. More importantly, Java applets are quite slow, even on modern computers.
Flash is certainly your technology of choice. It has an incredibly consistent code base and almost universal support. A good Flash developer can create applets that are both small and fast. Although Gnash's limited compatibility is troubling, someone who is familiar with ActionScript 2 should be able to create this drawing app quickly and easily.
I agree -- we have to keep the requirements reasonable for Mihai and any other takers for this project. An initial implementation based on Canvas does not look bad, and hopefully a different backend can be added later for IE, or MS adds support to IE.
Remember, WYSIWYG was not cross-browser for a very long time
Remember, WYSIWYG was not cross-browser for a very long time
Exactly my point.
For example, the current version of TinyMCE used in Moodle does not support Opera. However, Opera implemented rich text editing support since version 9.0 technical preview 1 (since october 2005). (an update to a newer TinyMCE version is very much needed...)
I have updated my proposal to include two mockup screenshots on how I plan to integrate PaintWeb into TinyMCE.
In the updated proposal I have also included more details about MSIE support. There are ways to work around the lack of native Canvas support.
In the initial proposal I did not imply MSIE 8 will support Canvas. I know it doesn't, and this month it was released as a final version. I have tested all their public betas. They have made many standards-related improvements in order to catch up with the competition, and it's reasonable to expect they will continue this trend.
Additionally, I would like to mention that native Canvas support can be worked around with Flash and with VML. Personally I plan to use the ExplorerCanvas project which implements the Canvas API using VML. It requires no plugins. I am confident we can make this work.
Please take a look at:
http://www.azarask.in/blog/post/flash-canvas/
http://code.google.com/p/explorercanvas/
While it's true a painting tool can be coded using Java and Flash, I am sure it would not stand the test of time. Performance, accessibility and stability problems will always emerge. Choosing Flash is basically limiting the developers who want to join the project only to Windows. Gnash compatiblity will only create more burden.
Therefore, I stand by my decision to use Canvas. It is by far the best choice on the long term, and given the project difficulty being high we need to make a good decision. Given the amount of work and complexity decisions for such projects need to be made for longer terms.
I do not believe that the central point of developing a paint tool is how to transfer/stream image bytes over HTTP. This is rather trivial and does not require much work. The really important parts to developing a paint tool are deciding on the technology to use and the features it will provide in initial version.
I know very well that the Canvas text API is unsupported by current versions of Opera and not even by Firefox 3.0. However, it's already working in Firefox 3.5 betas. As for Opera, I am sure I can code a work around until they have native support. Remember that the current PaintWeb application is simply a demo / proof of concept which has no browser-specific work arounds to fix any compatibility issues.
For example, the current version of TinyMCE used in Moodle does not support Opera. However, Opera implemented rich text editing support since version 9.0 technical preview 1 (since october 2005). (an update to a newer TinyMCE version is very much needed...)
I have updated my proposal to include two mockup screenshots on how I plan to integrate PaintWeb into TinyMCE.
In the updated proposal I have also included more details about MSIE support. There are ways to work around the lack of native Canvas support.
In the initial proposal I did not imply MSIE 8 will support Canvas. I know it doesn't, and this month it was released as a final version. I have tested all their public betas. They have made many standards-related improvements in order to catch up with the competition, and it's reasonable to expect they will continue this trend.
Additionally, I would like to mention that native Canvas support can be worked around with Flash and with VML. Personally I plan to use the ExplorerCanvas project which implements the Canvas API using VML. It requires no plugins. I am confident we can make this work.
Please take a look at:
http://www.azarask.in/blog/post/flash-canvas/
http://code.google.com/p/explorercanvas/
While it's true a painting tool can be coded using Java and Flash, I am sure it would not stand the test of time. Performance, accessibility and stability problems will always emerge. Choosing Flash is basically limiting the developers who want to join the project only to Windows. Gnash compatiblity will only create more burden.
Therefore, I stand by my decision to use Canvas. It is by far the best choice on the long term, and given the project difficulty being high we need to make a good decision. Given the amount of work and complexity decisions for such projects need to be made for longer terms.
I do not believe that the central point of developing a paint tool is how to transfer/stream image bytes over HTTP. This is rather trivial and does not require much work. The really important parts to developing a paint tool are deciding on the technology to use and the features it will provide in initial version.
I know very well that the Canvas text API is unsupported by current versions of Opera and not even by Firefox 3.0. However, it's already working in Firefox 3.5 betas. As for Opera, I am sure I can code a work around until they have native support. Remember that the current PaintWeb application is simply a demo / proof of concept which has no browser-specific work arounds to fix any compatibility issues.
In reply to Mihai Sucan
Re: gsoc: what you paint is what you get - discussion
by Mauno Korpelainen -
Lots of good points here - and some confusion...
Moodle 2.0 (still unstable) will have TinyMCE 3.x that supports all modern browsers = is cross-browser-compatible.
All current stable versions of moodle use HTMLArea that supports only Firefox and IE although the old TinyMCE 2 is still included to packages (some 3rd party modules used it in the past). HTMLArea was written so many years ago that nobody knew about Safari and Opera not to mention Chrome and the successor of HTMLArea - Xinha - does also support these modern browsers (since last year) like FCKEditor.
For testing purposes it is possible to use either Martin's clean port integration (not upgraded for a while...) or I could attach a theme based integration next week with the latest version of TinyMCE if you want to use it (integration is made through theme). If you try to use TinyMCE3 directly with old versions of moodle moodlelib.php and function can_use_html_editor blocks Opera, Safari and Chrome and you just need to allow moodle to use editor with other browsers than FF and IE.
I think it's good to have several people in this kind of *large* projects creating different solutions with different technics - actionscript (in Flash) is actually very similar to javascript and I could use any new technology you can offer because I have all the modern browsers installed. I'm not against canvas - it's cool - but I tried just to remind that tool is useless if only 1% of users can use it. Main features must work with FF and IE in the long run. I also agree with Martin that project like this can't be too demanding.
There are some ajax based applications available too like http://draw.labs.autodesk.com/ADDraw/draw.html
and talking about Flash here's a new really nice Free Online Image Editor called SUMO Paint from Finland http://www.sumopaint.com/app/ - worth of testing! Note however that it requires Flash Player 10.
I would love to see one canvas based tool, one java based tool and one flash based tool (or flex or ajax or ...) - they are all most welcome because we don't have any such tools available right now in moodle! 
In reply to Mauno Korpelainen
Re: gsoc: what you paint is what you get - discussion
by Mauno Korpelainen -
One important question is what to do with "presentations" - do you want to save them to moodle as code (database) or files/images or do you want to use some external service and just embed the tool itself and results (embedded presentations) to moodle.
Check also http://www.sumopaint.com/info/ and
http://www.sumopaint.com/web/#/image/5314
as an example. Any comments, Martin?
In reply to Mauno Korpelainen
Re: gsoc: what you paint is what you get - discussion
by Mauno Korpelainen -
And to see what you can do with Flash check
In reply to Mauno Korpelainen
Re: gsoc: what you paint is what you get - discussion
by Mauno Korpelainen -
In fact I just sent email to executive director Lauri Koutaniemi from Snap Group about possible use/embedding of SUMO Paint tools/images to moodle - let's see if we get any response. Their company has developed some interesting tools using Flex and Flash that might be useful in moodle as well... like all modern tools - directly or through plugins.
In reply to Mauno Korpelainen
Re: gsoc: what you paint is what you get - discussion
by Graham Evans -
Has there been any progres in using the api for Sumo to integrate with Moodle?
In reply to Graham Evans
Re: gsoc: what you paint is what you get - discussion
by Mauno Korpelainen -
Not actually (since March 2009)
Lauri Koutaniemi from Snap Group did reply the next day (16 months ago) to my email and they were very interested but when I told about their interest to Martín Langhoff I got an answer that the people in laptop.org projects were not at all interested in closed code - flash tools - like Sumo Paint, they wanted to use open source tools. I replied to Lauri and he understood the reasons...
In reply to Mauno Korpelainen
Re: gsoc: what you paint is what you get - discussion
by Graham Evans -
Seems a real shame.
In reply to Mauno Korpelainen
Re: gsoc: what you paint is what you get - discussion
by Mihai Sucan -
Haha. I understood from the community that TinyMCE is the default for Moodle. Looks like where I read it wasn't mentioned which version of Moodle. Oops.
I have to get Moodle 2 and update the mockup screenshot.
Sure, I know HTMLArea is rather outdated, same as TinyMCE 2. I didn't recognize it's HTMLArea in the Moodle 1.9 weekly because I thought it's a theming / configuration decision.
Yes, I agree about browser compatibility. Firefox and IE compatibility will be achieved, as you can see in my proposal: there are ways to make Canvas work in IE.
As for percentage of users, it has been pointed out that now only 66% of people use IE. It's not like the feature would be useless if it would only work in the rest of the browsers. Anyhow, it won't come to this: IE will be supported.
It's true that if you have multiple paint tools, each using its own technologies, you can achieve best browser compatibility. However, community resources are sometimes limited. It would be best if there would be one official, default paint tool, and the alternatives being provided so the user can pick the best. Generally, it's better to try to do one thing as good as possible, instead of many average projects.
I'm sure we will be able to create a really good project for the Moodle users.
By the way, thanks for your feedback. It's always welcome. ;)
I have to get Moodle 2 and update the mockup screenshot.
Sure, I know HTMLArea is rather outdated, same as TinyMCE 2. I didn't recognize it's HTMLArea in the Moodle 1.9 weekly because I thought it's a theming / configuration decision.
Yes, I agree about browser compatibility. Firefox and IE compatibility will be achieved, as you can see in my proposal: there are ways to make Canvas work in IE.
As for percentage of users, it has been pointed out that now only 66% of people use IE. It's not like the feature would be useless if it would only work in the rest of the browsers. Anyhow, it won't come to this: IE will be supported.
It's true that if you have multiple paint tools, each using its own technologies, you can achieve best browser compatibility. However, community resources are sometimes limited. It would be best if there would be one official, default paint tool, and the alternatives being provided so the user can pick the best. Generally, it's better to try to do one thing as good as possible, instead of many average projects.
I'm sure we will be able to create a really good project for the Moodle users.
By the way, thanks for your feedback. It's always welcome. ;)
In reply to Mihai Sucan
Re: gsoc: what you paint is what you get - discussion
by Mauno Korpelainen -
Thanks, Mihai!
I fully support all your ideas and it's great that you did not feel my feedback as criticism - we have different needs in moodle and inside the large community - and your project is closer to original idea given by Martin http://wiki.laptop.org/go/XS_Project_Ideas#Moodle:_What_you_paint_is_what_you_get
than the idea of embedding external service - although I like that idea too. If you haven't noticed I support all new ideas and flexibility everywhere - so keep up your good work!
In reply to Mauno Korpelainen
Re: gsoc: what you paint is what you get - discussion
by Mihai Sucan -
I appreciate all feedback. I didn't think of all this as criticism. Such discussion can only be beneficial for the community in deciding on the best available approaches for building a paint tool inside Moodle.
SumoPaint is certainly great, I like it. It's more mature as a project. However, I'd like to say we can do all that with Canvas as well. This is not just "tounge-in-cheek", I do know how it can all be done, but it takes time and lots of work. Community help would speed up the development quite much.
The problem with using an external service is not all users want to use an online service, nor would they like to sign up to yet another Web service. There are people who use Moodle without having an Internet connection at all times.
Given the idea of having alternatives, SumoPaint would be really good candidate for an alternative paint tool. Certainly, it can't be the default for the above reasons.
Personally, based on experience with educational software, I prefer Martin's approach/idea. Each with his/her own experience. ;)
SumoPaint is certainly great, I like it. It's more mature as a project. However, I'd like to say we can do all that with Canvas as well.
The problem with using an external service is not all users want to use an online service, nor would they like to sign up to yet another Web service. There are people who use Moodle without having an Internet connection at all times.
Given the idea of having alternatives, SumoPaint would be really good candidate for an alternative paint tool. Certainly, it can't be the default for the above reasons.
Personally, based on experience with educational software, I prefer Martin's approach/idea. Each with his/her own experience. ;)
In reply to Mihai Sucan
Re: gsoc: what you paint is what you get - discussion
by Mauno Korpelainen -
I'm not totally sure what kind of application might be the best drawing tool for different users. We have clearly a need for Photo Shop like tool for online drawing - a sort of professional tool for teachers and older students - but we might need a very simple and easy to use tool for kids. Obviously both goals can't be reached with one and only default tool.
Or do we need a different Kids Moodle with customized activities for young children? (It has been asked before but most moodlers have felt that moodle is good enough right now and there is plenty of work in current core packages already... )
Anyway - your new documentation in http://docs.moodle.org/en/Development:Paint_tool is very impressive, Mihai!
I see a timeline -- and looks good!
A couple of notes...
- You'll want to put also the dates it lines up with. Useful to coordinate with your mentor, testers, release cycle of moodle or related tools...
- I would suggest giving more time to the TinyMCE and Moodle integration. That is where the meat of the work is, and you are new to both codebases. If you are going to find any nasty surprises, it's there.
- In other words, let that soak up the time set aside for IE support and extended features. Let those be optional steps, if the main bit of work gets through without problems.
- There is no time in the schedule for testing, requesting review, reworking of bugfixing. We all need that time Make sure that after the main integration chunk of work you have time to make a milestone release and get feedback from testers and mentors...
Good stuff overall. You're on good track.
A couple of notes...
- You'll want to put also the dates it lines up with. Useful to coordinate with your mentor, testers, release cycle of moodle or related tools...
- I would suggest giving more time to the TinyMCE and Moodle integration. That is where the meat of the work is, and you are new to both codebases. If you are going to find any nasty surprises, it's there.
- In other words, let that soak up the time set aside for IE support and extended features. Let those be optional steps, if the main bit of work gets through without problems.
- There is no time in the schedule for testing, requesting review, reworking of bugfixing. We all need that time
Good stuff overall. You're on good track.
In reply to Martín Langhoff
Re: gsoc: what you paint is what you get - discussion
by Mauno Korpelainen -
I agree - Mihai has done very nice work!
Marc Grober has pushed on our integration of AsciiMathML and AsciiSVG plugins for TinyMCE (and HTMLArea) and I will use the coming weeks mainly for testing Maths tools with the latest TinyMCE as a part of Maths theme (to allow old versions of moodle to use maths without changing core files) but if you need any help in testing those Paintweb TinyMCE plugins or integration just send me a message...
Both SVG and Canvas have a couple of security issues that should be taken care when you check the code - for example free editing of SVG code itself should be avoided or somehow filtered to prevent direct code injections.
In reply to Mauno Korpelainen
Re: gsoc: what you paint is what you get - discussion
by Mihai Sucan -
Thanks Mauno, for your appreciation.
I will definitely need as much testing as possible.
Regarding security issues in Canvas, please elaborate. (we might be on the same line, but ... I better ask)
I'll update the timeline as suggested by Martin.
I will definitely need as much testing as possible.
Regarding security issues in Canvas, please elaborate. (we might be on the same line, but ... I better ask)
I'll update the timeline as suggested by Martin.
In reply to Mihai Sucan
Re: gsoc: what you paint is what you get - discussion
by Mauno Korpelainen -
Nothing specific to worry right now in your code or Canvas - those few canvas related examples were actually partly browser bugs and partly application bugs (how they have used canvas, URLs etc)
SVG may be more vulnerable if you plan to add support for editing SVG later ( By the end of the year ... http://docs.moodle.org/en/Development:Paint_tool#Conclusion )
In reply to Mauno Korpelainen
Re: gsoc: what you paint is what you get - discussion
by Mihai Sucan -
One known security issue which will be fixed during code reorganization is the use of eval() for the JSON code I have used for the color palettes. The fix is just a simple use of a JSON lib when a native JSON parser is not available.
Thanks. I was worried you might think there are some security issues in my Canvas code. As far as I know, currently there are no problems.
Thanks. I was worried you might think there are some security issues in my Canvas code. As far as I know, currently there are no problems.
Hello Martin!
Thanks for your feedback.
I have updated the timeline and the mockup screenshots. Please let me know if that's good for you.
Any additional feedback is welcome.
Thanks for your feedback.
I have updated the timeline and the mockup screenshots. Please let me know if that's good for you.
Any additional feedback is welcome.
Hi,
Not exactly the same project, but here's my proposal:
http://docs.moodle.org/en/Development:Interactive_paint_tool
Suggestions for improvement are most welcome.
Not exactly the same project, but here's my proposal:
http://docs.moodle.org/en/Development:Interactive_paint_tool
Suggestions for improvement are most welcome.
In reply to Martín Langhoff
Re: gsoc: what you paint is what you get - discussion
by Kathy Morello -
As a classroom teacher who uses Moodle in a face to face environment mostly: I would love for my students to use a paint like tool so that they can handwrite their work on problems while in Moodle (we are 1-1 tablet school so everyone has a tablet already). This would be a terrific tool for me to be able to use in quiz that involves students working out problems. As of now I have to give that part of test on paper.
This combined with the project to have ability to record and post audio/video on the fly into resources would make Moodle even more attractive to us in the classroom. I do not have expertise to offer help in development but sure do offer my encouragement as work proceeds.
This combined with the project to have ability to record and post audio/video on the fly into resources would make Moodle even more attractive to us in the classroom. I do not have expertise to offer help in development but sure do offer my encouragement as work proceeds.
Thank you Kathy! That's really appreciated.
If you want, you can test the paint tool yourself over at:
http://www.robodesign.ro/paintweb/trunk/demos/demo1.html
and http://www.robodesign.ro/paintweb/trunk/demos/demo-tinymce.html
Your feedback as a potential user is always greatly appreciated.
If you want, you can test the paint tool yourself over at:
http://www.robodesign.ro/paintweb/trunk/demos/demo1.html
and http://www.robodesign.ro/paintweb/trunk/demos/demo-tinymce.html
Your feedback as a potential user is always greatly appreciated.