[Server-devel] Some notes on the What you paint is what you get

[Alex Wulms]

Hi,

We are currently investigating how easy/complex it would be to make the finger 
paint application as a TinyMCE module/plugin. We would like to build the 
paint module on top of the dojo toolkit, which provides a cross-browser 2D 
graphics sub-library. Dojo toolkit is available under the BSD license and 
under the AFL (see http://dojotoolkit.org/license). Do you know if one of 
those two licenses would be compatible with the GPL license used for moodle 
and the LGPL license used for TinyMCE?

Thanks and kind regards,
Alex




Op woensdag 25 maart 2009, schreef Martin Langhoff:
> Alex Wulms was recently asking for some detail on this in a private
> conversation -- the revelevant bits below...
>
> [ to everyone involved, let's have the conversations via server-devel :-) ]
>
> On Thu, Mar 19, 2009 at 11:16 AM, Alex Wulms <alex.wulms at scarlet.be> wrote:
> > Regarding the finger painting application: at the moment we don't have
> > much information about what is expected about it.
> >
> > 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.
> >
> >
> > This project aims to develop a finger painting facility.
> >
> > 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
> >
> > Technical notes
> >
> > *       Moodle is using a WYSIWYG editor called TinyMCE - that is a
> > possible integration point.
> > *       Performance matters - the OLPC XO has a relatively low power CPU,
> > so image editing has to be tuned / optimised to be
> > responsive
> > --- end of info
>
> That info is pretty much all I have too ;-) there is a thread I
> started on moodle.org where I asked people to report on nice Flash or
> JS based editors, and a few very nice ones emerged. It's nice to play
> with the many implementations out there, and see what feels good.
>
> (I think I posted that link before, don't have it handy atm...)
>
> > So we have a few questions.
> >
> > One question is the age category that you have in mind for this
> > application.
>
> 6 to 12 roughly. But "kids of any age" is my target ;-)
>
> I am already taking the TinyMCE editor and switching off most options.
> A very simple editor is enough (brush size, color, eraser). A
> sophisticated editor can be a bonus, but it's only interesting the
> main goal is that the "core" functionality works really well.
>
> In other words, if there are more buttons, we might hide them as we do
> with tinymce.
>
> Another aspect of 'sophistication' -- after looking at many editors,
> the most valuable feature I've seen is the "replay" button, way more
> important than anything else. (see the thread in moodle.org about the
> editors ;-) )
>
> > 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 :-/
>
> >  How would you see a typical use case or
> > user-interaction? Would the school server for example show an assignment
> > like 'paint a tree' and then the child would paint the tree and submit it
> > back to the server for review by the teacher?
>
> Yes. Or propose "paint something" in a moodle forum which is more fun
> and educational than an assignment.
>
> My example "use cases" and notes...
>
>  - I want to use moodle's forum and "just paint" instead of writing each
> post.
>
>  - As a teacher, when I hit 'edit' to edit the texts in the course
> outline page (technically called "labels" in moodle code), I want to
> be able to paint.
>
>  - Nice workflow for the user:
>   - I am using TinyMCE, there is a button that switches mode to 'painting'
>   - Nice to have: if I've written something before hitting the
> 'painting' switch, then I would paint in top of that (the written
> words get rendered...)
>   - I am _not_ expecting to be able to switch back from painting to
> writing. Keep it simple...
>
> > Should the children be able to
> > save their paintings on the server and also load/retrieve them again from
> > the server?
>
> Well, they aren't "separate documents" -- they'd get just teh same
> treatment that the content of an html-area (TinyMCE) driven form gets.
> Most TinyMCE-powered forms in Moodle also accept an attachment (and if
> it's an image, moodle will display it inline). This feaure could be
> available only on those forms, so the changes to moodle core code
> would be none or minimal.
>
> > Or would loading/saving only happen locally on the XO?
>
> Working with the XO apps is something I want to avoid, because it
> forces many steps for the user.
>
> 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, and
> uncomfortable for everyone...
>
> cheers,
>
>
>
> m
> --
>  martin at laptop.org -- School Server Architect
>  - ask interesting questions
>  - don't get distracted with shiny stuff  - working code first
>  - http://wiki.laptop.org/go/User:Martinlanghoff