Improving image drawing

The way editable images are handled in MoinMoin should be changed. At the moment (Versions up to 1.8.x) MoinMoin offers only one way to create and edit images: the TWikiDrawApplet.

Because this applet is rather old fashioned we should provide a more modern approach to handle drawings / image editing. It would also be nice to support the choice between different image editors. So each user can take the editor he likes. E.g. if the user doesn't have Java installed on his machine and isn't able to use a cool Java image editor applet, then he can use an image editor which is based on JavaScript instead.

In 1.9 the TWikiDraw support code was refactored to an action twikidraw and also an anywikidraw action was added.

A nice thing to have now would be a twikidraw .draw to .svg converter (anywikidraw can't read .draw).

Repository

http://hg.moinmo.in/moin/1.9-draw/

Plan for anywikidraw

• add a src folder moinwikidraw as an initial copy of twikidraw (this is needed to track changes)

• change the logo and title

• add an ant build script for moinwikidraw (http://hg.moinmo.in/moin/1.9-draw/rev/9558a3c34043)

use ant

For developing create a .keystore directory by keytool with an alias moinmoin and the password moinmoin below 1.9-draw toplevel dir.

• The applet becomes created, signed and copied to the deployed applet dir.

• jcontrol can be used to clear the java cache

converter for draw

• search the codebase for an on the fly converter from draw to svg
• implement an on the fly converter
  • do this in the applet
  • or do this in the migration scripts

There are only 2 choices that make sense:

• do a one-time conversion of all .draw to .svg by a migration script

  • after that, everything is .svg and we can kill twikidraw and .draw support in that release

  • this is likely the only way to have all .draw content converted deterministically

• have an applet (e.g. anywikidraw) that is able to read/write .draw AND .svg (with that, we can also kill twikidraw, because anywikidraw could read/write all existing data)
  • that applet will have to support both formats for a really long time (because it does not enforce conversion, not even when editing some drawing)
  • or, that applet needs to auto-convert to svg (like load foo.draw, save foo.svg, delete foo.draw)
  • no matter what, these options do not deterministically convert all content at some specific time

TextCha

We need to add TextChas to the applet. see http://hg.moinmo.in/moin/1.9-draw/rev/4cb70541fe85

session cookie

On twikidraw and anywikidraw we have to implement handling of session cookie

language header

On twikidraw and anywikidraw we have to implement sending of language header

improve ideas (one patch per feature)

please add a subpage when you start working on one of them

AnyWikiDrawforMoinMoin applet:

• crop white border of png file (http://hg.moinmo.in/moin/1.9-draw/rev/c32e1ff86c25)

  • I'm trying to find a solution for that JosefMeier

• improve image map links. at the moment only internet links work intuitive. wiki or interwiki links are hard to create

  • needs to be fixed in the action, slightly better now action anywikidraw

• support for smart connectors (link objects with arrows like visio does it). This is planned for future releases of AnyWikiDraw (takes approx. one year)

• make transparent colors work in the resulting png file

Handling of images for the image editor:

• GUI editor should be able to create empty and insert editable images
• editing an image should be possible without changing to the attachment page before
  • Possible ways to do that:

    • Way 1: click on the border of the image to edit it

      • + no edit buttons
      • - if you use image maps which span the whole picture, the edit region could be overridden by it
      • Question: currently there is one map always created by the editor without user interaction. Can we use this map to point to the action itselfs?

    • Way 2: insert a static edit button beneath the image which switches to edit mode if you click on it

      • + edit button is totally independent of the content of the image map
      • - edit button consumes space
      • (- can be printed, but could also be hidden in print.css)
      • Question: Can we add a dot (always on the bottom layer) with a map entry which points to the action link for editing?
        • You mean a dot in the SVG image? This also could be printed
          • Yes
          • Nobody wants to mess his images with dots (especially if they are in the wiki for documentation purposes). Dots are also meaningless. An icon bar underneath the image is better.

    • Way 3: dynamically insert an edit link text when mouse pointer hovers over the drawing (http://hg.moinmo.in/moin/1.9-draw/rev/a1cd862a5362 and changesets before)

      • + no visible edit button

      • - does JavaScript work in every browser?

        • we use JQuery for dynamically showing/hiding the edit link text. This should guarantee that it works in the major browsers

      • All in all: from the point of view of accessibility this solution needs carefully to be checked, see http://www.webaim.org/techniques/javascript/. IMHO its too "fancy" and thus problematic. In the long run and from the point of view of accessibility, Way 2 (achieved by rewritting/enhancing Arnica, see FeatureRequests/EnhanceTransclusionSyntaxForImages) should be the best solution (by hiding icon bar e.g. in print css)

        • that JQuery implementation is annoying, the content moves away if I move the mouse over the image. I prefer a less problematic implementation similiar to the icon tool bar on one of the images at FeatureRequests/EnhanceTransclusionSyntaxForImages. -- ReimarBauer 2009-09-12 10:06:39

    • Way 4: Click on the white between image map urls action anywikidraw

    • Way 5 (changeset: http://hg.moinmo.in/moin/1.9-draw/rev/2676bd1ea632): A combination between Way 2 and Way 3.
      In dependence of a configuration variable called 'accessibilityLevel' either the static edit link is drawn (works without JavaScript) or a modified sliding effect (content will be not moved anymore if the edit link text slides out of the drawing) from Way 3 is used. Set the accessibility level to "everything allowed" by setting 'accessibilityLevel = 0' in "wikiconfig.py" to see the sliding effect. If you don't set this variable, then the accessibility level is set to the maximum and only static edit texts are shown below the drawings.
      In the future 'accessibilityLevel' should be set in the user settings page. See also http://www.moinmo.in/FeatureRequests/AccessibilityVersusUsability for more info. [JosefMeier]

• Question: it should be possible to address images on other pages than the current (not sure if this still works)

• Answer: it does, see

Import of twikidraw files:

• because of the complexity I have introduced a new extension .adraw for the anywikidraw container

• currently I think we should not autoconvert tdraw files. anywikidraw should get a new import format for tdraw (draw + map) files.

• Not converted files are accessible in 1.9 by link syntax, e.g. {{WikiSandBox||&action=AttachFile,&do=box,&target=mytest.tdraw,&member=mytest.png}} and {{WikiSandBox||&action=twikidraw,&target=mytest}} independent from the default drawing action.

  • markup should not depend on configuration. configuration may change.

    • may be we should replace drawing by something else and add a paramter e.g. {{extension:anywikidraw,}} because one could also write a midi editor plugin and we probably don't want to invent new markup for each plugins.

  • noone will find/use that, too complex

General thought

• It is mentioned above that "anywikidraw should get a new import format for tdraw (draw + map) files". However, does AnyWikiDraw support the creation of image maps at all?

  • It does. svg also can do url mapping for objects. The internal format is svg. because svg-web isn't finished yet we use png / map currently to satisfy ie users.

• Usability issue: I don't like, when you hover (with the mouse over) an image, you get the "hand icon" in the case of "image links" and "editable images". So the user doesn't know what will happen, if he clicks on the image: will he get redirected to another page, to the item's homepage or will he run an image editor. Therefore I suggest the following:

  • Don't allow image editing by clicking/double clicking on an image. Instead provide in the markup for links/transclusion of images a parameter which shows beneath the image an extra link "edit this image" or and icon "edit". See FeatureRequests/EnhanceTransclusionSyntaxForImages how it could look like. That's also a good way to better integrate fabelous Anirca Pulgin by ReimarBauer. As far as I know, Arnica has already an abstract "Image class" implemented.

  • If you do this the other 50% want it different solved. I myself don't want something which can be printed. 2.0 will become much more svg and arnica must be refactored. Currently we plan on this page for 1.9. Also I am only sure about that we don't have the best solution applied for 1.9 or purposed yet. In 2.0 it is already different solved.

    • It shouldn't be a problem to put a div around the icon toolbar and hide that in the print.css

    • we also could use one of the popular JavaScript libraries like DOJO or Script.aculo.us for dynamically showing / hiding the buttons

  • All images in Moin should be editable! So please add to the item's homepage next to "Download" also and "Edit" button. Hitting the edit button then runs the image editor. Every image (svg, png, jpg) can be edited by visiting the item's homepage and clicking on "edit". User must know this. But for the sake of simplicity/usability, there should also be ways (e.g. with an icon) to directly link to an image editor.

  • that is also a feature for moin-2.0. And not only for images, every mimetype item is editable in 2.0 if we have something to edit it with.

• Maybe one could also think of a more general approach of creating image maps. We have e.g. ParserMarket/ImageMap (not well written) and we have a java-applet one has written for that parser so as to be able to easily mark interesting regions, see http://moinmo.in/ParserMarket/ImageMap/ReleaseNotes and the MoinMoin WikiMapper at http://sourceforge.net/projects/wikiimagemapper/.

• by using linksyntax and writing similiar actions it is possible to add much more applets or javascript plugins as in the past also for 1.9

CategoryFeatureRequest