create new tag
, view all tags

TWikiDrawPluginDev Discussion: Page for developer collaboration, enhancement requests, patches and improved versions on TWikiDrawPlugin contributed by the TWikiCommunity.
• Please let us know what you think of this extension.
• For support, check the existing questions, or ask a new support question in the Support web!
• Please report bugs below

Discussions around the TWikiDrawPlugin

See TWikiDrawPluginDevArchive for an archive of older discussion.

See TWikiDrawFAQ for answers to frequently asked questions; please check there before adding to this topic.

Known Problems

Memory and redraw problems. If I spend more than a couple of minutes on an enlarged diagram the drawing applet will not respond to save and exit requests. Work is lost frown

It appears that if you try to reuse the applet to often there is problems in the memory (my guess) because even creating/saving very small diagrams the applet does not respond to save and exit.

Here's the java output error

java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
<--perhaps this is from my trying to enlarge the applet by using the growing text workaround?-->
   at java.util.LinkedList.entry(Unknown Source)
   at java.util.LinkedList.get(Unknown Source)
   at sun.net.www.protocol.http.PathMap.get(Unknown Source)
   at sun.net.www.protocol.http.AuthenticationInfo.getAuth(Unknown Source)
<--Stopped asking for my user name and password -->
   at sun.net.www.protocol.http.AuthenticationInfo.getServerAuth(Unknown Source)
   at sun.net.www.protocol.http.HttpURLConnection.getServerAuthentication(Unknown Source)
   at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
   at sun.plugin.net.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
   at sun.net.www.protocol.http.HttpURLConnection.getHeaderFields(Unknown Source)
   at sun.plugin.net.protocol.http.HttpURLConnection.checkCookieHeader(Unknown Source)
   at sun.plugin.net.protocol.http.HttpURLConnection.getInputStream(Unknown Source)
   at CH.ifa.draw.twiki.TWikiDraw.post(Unknown Source)
   at CH.ifa.draw.twiki.TWikiFrame.doSaveDrawing(Unknown Source)
   at CH.ifa.draw.twiki.TWikiFrame$SaveDrawingCommand.execute(Unknown Source)
   at CH.ifa.draw.util.CommandMenu.actionPerformed(Unknown Source)
   at java.awt.MenuItem.processActionEvent(Unknown Source)
   at java.awt.MenuItem.processEvent(Unknown Source)
   at java.awt.MenuComponent.dispatchEventImpl(Unknown Source)
   at java.awt.MenuComponent.dispatchEvent(Unknown Source)
   at java.awt.EventQueue.dispatchEvent(Unknown Source)
   at java.awt.EventDispatchThread.pumpOneEventForHierarchy(Unknown Source)
   at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)
   at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
        at java.awt.EventDispatchThread.pumpEvents(Unknown Source)
   at java.awt.EventDispatchThread.run(Unknown Source)

My sys info
Microsoft(R) Windows 98 se
   (C)Copyright Microsoft Corp 1981-1999.

C:\WINDOWS\Desktop>java -version
java version "1.4.0"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.0-b92)
Java HotSpot(TM) Client VM (build 1.4.0-b92, mixed mode)

IE 6

Workaround restart browser

bug MAC OS X explorer 5.2

tool bar does not appear , cannot save .draw


applet does not load NPE -- DennisDaniels - 21 Mar 2002

From the stack dump, this is nothing to do with TWikiDrawPlugin. It's somewhere in the depths of the network code provided by Sun. I also haven't tested with Java 1.4 plugin.

-- CrawfordCurrie - 11 Dec 2003

bugs MAC OS X 10.5 with FireFox

5/10/2008 RedByer
  • Takes a while to load
  • Tool bar does not appear
  • Cannot Save drawing or close window
  • Replicated with/without Firebug add-on. replicated on multiple macs.
  • NOTE: same machines do not exhibit plugin error when run under Safari

I Can't open my drawing after I saved it

I found a bug, I think. If you get an error when opening your drawing, something like:

Error reading /twiki/pub/Main/NewDatabase/newdatabasediagram.draw: java.io.IOException: String expected in line: 37

I have found that line 37, in this case, contains a new line character like this: \nTexttextext It appears that my multi-line text saves but won't get loaded back into the applet.

Multi-line text? You may ask. I mean if I'm typing in a text box and press enter to make a new line, then I get the above error later on.

I'll do it here as a test example.

Edit drawing `tylertest` (requires a Java 1.1 enabled browser)

You'll see the error at the bottom of the applet, here's the line that is the problem:

        CH.ifa.draw.figures.TextFigure "attributes" "attributes" 1 "FillColor" "Color" 255 199 158 137 55 "Line 1
\nLine 2" "Helvetica" 0 12 0 NULL NULL

-- TylerMitchell - 16 Jul 2003

I just hit the same problem here. Interestingly, it coincides with one of a number of recent upgrades:

  • we've just moved our server to RedHat 9.0 (red herring I think)
  • as part of this we've moved our Web server to Apache 2.0 (not sure, but think this is also red herring)
  • some time back I went to IE6 (possibly red herring)
  • just today, I migrated to the Java 1.4.2 plugin (this I think is where the conflict may come from)

Interestingly one of my colleagues is on same setup, except he uses the 1.4.0 JRE plugin, and he doesn't experience this.

Looking at the file that gets written, it looks to me like there could be some form of "line ending" confusion, since when I hit save I get a "CRLF" aka \r\n combination inserted in the string, causing the above, whereas my colleague just gets an "LF" aka \n combination.

Still investigating ... will report back if I find any more

-- RobWalker - 17 Jul 2003

Ok, I wouldn't call this a full fix, since i've only had a chance to try this in my environment. But it has cured this problem for me and got me working again. Basically, hitting the Enter key seemed to be inserting a \r\n in the String used to hold the text. When written out, this messed up the file such that it wouldn't read back.

In CH.ifa.draw.util.StorableOutput, mod the following method (around line #98 in my version):

    public void writeString(String s) {
        for(int i = 0; i < s.length(); i++) {
            char c = s.charAt(i);
            switch(c) {
                case '\r': break; // suppress the \r being written out
                case '\n': fStream.print('\\'); fStream.print('n'); break;

I used the new switch case to suppress the \r case which was stuffing up my files. There's probably a more elegant and general solution out there!

-- RobWalker - 17 Jul 2003

OK, I put your fix in CVS.


Unfortunately I have no Java development environment installed. Therefore I added a few lines of code to TWikiDrawPlugin.pm. It opens the *.draw file, removes all line break characters (\n and \r) immediately preceding the text '\n'. After that the file is written back. I uploaded a patch for this adaption TWikiDrawPlugin.pm-linebreak.patch. Greetings to FJ who helped me.

-- AlexanderStedile - 15 Dec 2003

Potential problem with IE/Win2K/Java-SDK-1.4.1_02

Whenever I attempted to save (or simply exit) a drawing with IE 5.50 on Win2K using the sun Java SDK 1.4.1_02 the browser would hang (I had to kill it with the CTRL-ALT-DEL/TaskManager).

When I upgraded to Java SDK 1.4.2 this problem has disappeared (I have alas not changed the IE or Win2K).

-- StephenGaito - 23 Jul 2003

Saved .draw Failed .map Failed .gif Failed

One cause of this error that I've found is that the draw plugin (23 Sep 2001) as we've installed it doesn't stop you from attempting to edit a drawing if you're not already logged in to TWiki. (Presumably the uploads then fail). Once you're in this situation you can't save your work (as far as I know).

The workaround is to ensure you're authenticated before attempting to edit a drawing.

A fix could be to add to .htaccess in appropriate places. I'm not sure what the correct way to to this is. I bodged it locally by adding .htaccess to pub/Plugins/TWikiDrawPlugin to require authentication for twikidraw.jar, but that only stops the window from popping up (inscrutable, but avoids a big waste of time) rather than actually prompting the user to log in.

-- JacobNevins - 02 Dec 2003

Because of the way it works, edit is invoked simply by following a link rendered on a page. There's no "edit script" that can be used to check authentication, only the download of the drawing will invoke that. But authentication should occur when the drawing is subsequently uploaded; the standard upload script is used. There shouldn't be any need to finagle .htaccess.

-- CrawfordCurrie - 11 Dec 2003

TWikiDrawBadMagic resulting from hardwired ref to Plugins web in TWikiDraw.tmpl

The TWikiDrawPlugin archive installs the plugin into the Plugin web by default. Moving the TWikiDrawPlugin topic to the TWiki web (along with corresponding files in pub directory) results in problems described in TWikiDrawBadMagic. Fortunately, the fix is pretty simple and is described in ChangeInstallationOfTWikiDrawPlugin. Although the required changes to the twikidraw.tmpl file are trivial, I've gone ahead and attached the revised tmpl file to save folks the trouble. smile

-- LynnwoodBrown - 03 Feb 2004

Connecting groups of objects

Lines and arrows do not stick to group of objects. To make a connection one have to ungroup the group, connect line to one of the objects from the group and group all again. Pretty anoying, moreover there is no icon drawing support so one have to make the icons by drawing by hand and creating groups.

-- JakubJagielka - 03 Nov 2005


  • Show file name in applet view
    • Good idea
  • show diagram space coordinates (the size of the diagram is difficult to determine)
    • Good idea
  • view source of .draw 'in real time'
    • Why?
  • convert .draw data to xml based format
  • enable hotkeys for tools (T for Text, C for cursor etc.*)
    • tried that, had horrible problems. Will try again.
    • Try at least Control+C for copy, paste, etc. - 06 Oct 2005
  • templating mechanism for tool behaviors
    • Explain?
  • templating mechanism for object behaviors (double click to add name for example)
    • Explain?
  • changes to drawings are registered as Changes in the Wiki
    • Drawings are just attachments....
  • UmlSupport (imagine what that could do for group ware in a development environment)
    • Go buy visio, or integrate JRefactory, or something!
  • Link support in the draw
    • Huh? Something other than image maps?
  • naming of objects in the drawing (each line circle box etc.* should have the option of having a textual name accessible through a double click (for example)
    • Why?
  • support for SVG (proto SVG?) see SVGWiki group http://www.protocol7.com/svg-wiki/ See TWikiDrawSvgPlugin
  • support for including images in the draw
    • Good idea
    • I agree - would be killer app for our use to allow annotation of an image file (ie, load .TIF or .JPG as a 'background' image, use TWikiDrawPlugin to annotate images) -- BillFarmilo - 03 Oct 2006
  • right click access to lines to change the arrow shape and direction
    • Good idea
  • Please embed the textual information from the drawn object into the HTML page inside a comment tag. This would allow one to Search against the text information in the image. -- MikeBytnar - 5 Jun 2002
    • Good idea, but hard to do.
  • ideas from JHotDraw 5.3 and JGraph's JGraphPad ?
    • Be specific, please
  • Hide .draw, .gif, .map topic attachments by default -- JacobNevins - 02 Dec 2003
    • Good idea; one for the core team
  • It would be nice if rdiff could be tweaked to show "old" and "new" versions of drawings, rather than the metadata changes. -- JacobNevins - 02 Dec 2003
    • or a "graphical diff"? There's a masters project in there for someone! hehe!
  • I added indexed PNG support, proper xhtml maps, corrected map area order (needs to be reversed) and a basename parameter to return correct filenames to the wiki. You can get them on http://moinmoin.wikiwikiweb.de/OliverGraf/TWikiDrawPlugin -- Oliver Graf - 07 Feb 2004
  • http://www.pmwiki.org/wiki/Cookbook/PMWikiDraw is based on JHotDraw! -- WonKyuPark - 23 Nov 2004
  • There should be a Duplicate option also in Edit menu. - 06 Oct 2005
  • There should be a contextual right-click popup menu with basic tools (or all tools) like the gimp wink - 06 Oct 2005
  • Text items should go edit mode when double clicked (even if you have arrow tool selected). - 06 Oct 2005
  • Window close icon "X" should do something (perhaps ask to save not saved and/or close).
  • Add functionality to rotate objects such as text or box’s
    • This would allow one to do a flow diagram as they would then be able to rotate box’s into diamonds
    • Also would allow for vertical text

Pending fixes

The following changes should be done to the plugin to fix PluginProblemWithIncludes:

<     my( $attributes ) = @_;
<     my $nameVal = TWiki::Func::extractNameValuePair( $attributes );
>     my( $theAttributes, $theTopic, $theWeb ) = @_;
>     my $nameVal = TWiki::Func::extractNameValuePair( $theAttributes );
<       TWiki::Func::getOopsUrl($web, $topic, "twikidraw", $nameVal)."\" ".
>       TWiki::Func::getOopsUrl($theWeb, $theTopic, "twikidraw", $nameVal)."\" ".
<     $_[0] =~ s/%DRAWING{(.*?)}%/&handleDrawing($1)/geo;
<     $_[0] =~ s/%DRAWING%/&handleDrawing("untitled")/geo;
>     $_[0] =~ s/%DRAWING{(.*?)}%/&handleDrawing( $1, $_[1], $_[2] )/geo;
>     $_[0] =~ s/%DRAWING%/&handleDrawing( "untitled", $_[1], $_[2] )/geo;

For the fix you need also the latest TWikiAlphaRelease or PluginProblemWithIncludes patch.

-- PeterThoeny - 07 Jun 2002

Fixed in CVS -- CrawfordCurrie 11 Dec 2003

Recent Developments, Discussion and Questions

Image map issues

I've just installed the latest version of the plugin so that we can use image maps. We've spotted a few issues:

  • It takes a page refresh to see any changes.
  • You can add a URL to text but it won't be in the image map.
  • You can't tell where the links are without hovering. This will be particularly relevant to text links when they are working. We could add lines underneath them and colour them but it would be nice if it was automatic. Perhaps via TEXT_LINKS_UNDERLINE and TEXT_LINKS_COLOR variables in the plugin topic?
  • It's not obvious that clicking the sides edit the image. There used to be a tool tip to indicate that clicking would edit the image but there isn't for the now. Is this possible with image maps and could it be extended to the URLs?
  • Could an edit link as part of the image map be an option that could be turned on, perhaps by setting EDIT_BUTTON = 2?

-- SamHasler - 04 Sep 2003

I'll investigate these.

-- CrawfordCurrie - 11 Dec 2003

Stand-alone version?

I'm glad to see that the SVG draw plugin is making progress. I'll have to install it.

I'm using the TWikiDrawPlugin a bit. I'm finding that I often want to use it off-line, on my laptop, with no webserver or twiki server running. Is there a version that will put .draw into a file? Similarly for the SVG version: is there a standalone version? Or can any SVG editor producer SVG code that the SVG draw plugin can handle?

Overall, however, while the draw plugin is nice, it really is much harder to use than fancy drawing tools. See ThoughtsAboutUsingExternalApplications.

(Copying this comment to both TWikiDrawSvgPluginDev and TWikiDrawPluginDev.)

-- AndyGlew - 23 Sep 2003

I got an offline (J)HotDraw by downloading twikidraw.zip from TWikiDrawApplet and recorded (some of) my experiences on Wikilearn.JHotDraw. I also recorded some of my experiences with the "online" TWikiDraw on the WikiLearn web — see (IIRC) Wikilearn.EditingATWikiDrawSketch — feel free to modify those pages appropriately based on your experiences.

-- RandyKramer - 23 Sep 2003

Can't open drawing after save problem?

Is there patched version of plugin available, which contains fix for "I Can't open my drawing after I saved it" -problem?

-- HarriVartiainen - 19 Nov 2003


The %EXTRA_COLORS feature does not work for me, and I don't find any reference in the code. How is it supposed to work?

-- PeterKlausner - 04 Dec 2003

BTW, %EXTRA_COLORS. It works by setting the applet parameter "extracolors" which is then interpreted in CH/ifa/draw/twiki/TWikiDraw.java. If you can't make sense of this, check you have the latest version of the plugin.

-- CrawfordCurrie - 10 Dec 2003

Argh. Again stumbled over TWiki's odd precedence of preference definitions: WebPreferences does not override the shipped Plugins.TWikiDrawPlugin defaults. And I only looked at the code, not the template. Here's a patch, which adds the web's background color to the picklist:

RCS file: /var/cvs/twiki/templates/twikidraw.tmpl,v
retrieving revision 1.2
diff -r1.2 twikidraw.tmpl
< <param name="extracolors"  value="%TWIKIDRAWPLUGIN_EXTRA_COLORS%">
> <param name="extracolors"  value="%WEB% background=%WEBBGCOLOR%,%TWIKIDRAWPLUGIN_EXTRA_COLORS%">
Rationale: I guess the draw plugin is not appropriate for full blown drawings, but useful for simple, web related maps. For this scenario, the colour palette should blend into the web's colour scheme.

-- PeterKlausner - 11 Dec 2003

Switch to JHotDraw?

I've not been quite as active maintaining this plugin for a couple of reasons:

  1. The Java codebase has diverged from JHotDraw (the original drawing package) and I have been debating re-aligning. JHotDraw has since moved on, and it's a not-insignificant piece of work to re-align. JHotDraw had to be recoded in several places to support non-IE browsers better. JHotDraw now uses swing and requires the latest Java plugin, and I'm still reluctant to limit it's appeal this way.
  2. Some of the problems described above are exceptionally difficult to test for. JHotDraw doesn't have a test suite, and I don't have all the browsers, so reproducing them reliably is very difficult. If I was provided with unit tests that reproduce the problems, maybe I could make progress. otherwise, it's like jousting in the dark.
  3. I'm not particularly convinced there's a broad requirement for this plugin.
  4. I haven't had the time recently.

-- CrawfordCurrie - 09 Dec 2003

It might be in greater use than you think. A google for TWikiDrawPlugin JHotDraw comes back with around 130 public installs, and probably higher for non-public installs. I install it on all the wiki's I install... wink Also it travels further than you think - the MoinMoin people are using it too. (Try googling for MoinMoin TWikiDrawPlugin )

-- MS - 09 Dec 2003

See what you mean. Gosh, you don't realise how far this stuff spreads! I think the MoinMoin folks are using a very old version.

OK, but still no answer to that key question; should I upgrade JHotDraw? If I do:

  1. Access to any hoopy new features and bugfixes the JHotDraw people have made in 5.3
  2. I think it is now possible to unthread the changes in the JHotDraw sources that were necessary to support TWiki in previous versions. If so, then it should be possible in future to upgrade JHotDraw independently of the twikiplugin - though I still favour packaging it with the plugin.
  3. You will have to install the Java2 plugin (though of course that is semi-automated) - Java1.1 support will be lost.
  4. I could address some of the fixes above
  5. I can look at incoporating SVG saving (no promises; when I looked at the code in TWikiDrawSvgPlugin I didn't consider it reusable)

Now I write it all down it sounds like a fair amount of work. Oh well, if needs must...

-- CrawfordCurrie - 10 Dec 2003

The following questions come to mind before incorporating the latest JHotDraw code into the Plugin:

  • Is it justifiable to require a software install on the client? This would be un-TWikish
  • Browser/platform compatibility?
  • Download time for each edit? The applet with swing and other libs might be much bigger.

If the gained functionality is not that large it might be better to backport some features into the existing Plugin (if that is an option at all). Yet an alternative is to fork and maintain two versions, this TWikiDrawPlugin with low requirements on the client side, and a TWikiJHotDrawPlugin that has more features but requires a software install and that might be slower.

BTW, this topic is getting very long, time to move some stuff to TWikiDrawPluginDevArchive.

-- PeterThoeny - 11 Dec 2003

I concur.

On reflection and review of the codebase, we'd actually lose in some respects by "upgrading". The main feature that would have to be reverse engineered is the image map stuff. As I recall, the main reason I wanted to upgrade was to get at Swing's image handling. The Swing applet is not significantly bigger, and the startup time is similar. The main advantage of upgrading would be to realign with the JHotDraw code base, so reverse porting updates to JDK1.1 would rather defeat the object. The main disadvantage would be that nasty software install.

I think The idea of supporting a fork had occurred to me, but unless the user base demands it I don't think it's worthwhile.

I've lightened this topic a bit, archiving old discussion & fixed issues and moving the FAQ to a new topic.

-- CrawfordCurrie - 11 Dec 2003

Has anyone looked into an implementation which allows "drawing" over an existing picture (gif?) using the applet and draw file? I'm not so familiar with the programming, but it seems to me that given a gif and, let's saw a draw file that codes for a few circles and text, the program should be able to overwrite the gif or make a 'new' one off the 'template/original'. This came to mind as I scanned in a map of my campus and was going to use the TWikiDrawPlugin to circle hotspots when I discovered I'd have to draw the gif myself smile oy

-- BenjaminFleischer - 19 Dec 2003

Benjamin, this is an interesting idea. One of the improvements made to JHotDraw since we forked the TWiki version is the ability to include pre-existing artwork. Since this was done using Swing, it's not directly re-usable, but it shows that what you want, can be done. All it needs is a motivated Java programmer with some time.

-- CrawfordCurrie - 03 Jan 2004

Is it possible to add a possibilty to change width and style of the line? Such an addition could make the plugin much more useful.

-- AndrzejGoralczyk - 07 Mar 2004

Yes, indeed, I think it should be quite straightforward for someone to code.

-- CrawfordCurrie - 07 Mar 2004

What are the differences between the TWikiDrawPlugin.zip attached to this topic, the main TWikiDrawPlugin topic and the version in CVS?

-- MattWilkie - 02 Apr 2004

Has this plugin really not been tested since the Athens release, as indicated in TWikiDrawPlugin? -- ThomasWeigert - 19 May 2004

Matt, I couldn't swear to it but I think the only difference is the optional edit button.

Thomas, I have not personally tested the plugin since the Athens release, apart from a quick run-up and run-down. Because I inherited most of the code, there has never been an automated test suite for it either.

-- CrawfordCurrie - 19 May 2004

I wonder whether others are as conscientious as you are when they mark "tested in version X". Probably we should not hold your plugin to a higher standard than others. Probably what most mean by "tested" is "tried the main features and it worked".

-- ThomasWeigert - 19 May 2004

Cairo-ready version with MAP support uploaded to the main topic. Please report any problems in the Support web.

-- CrawfordCurrie - 16 Aug 2004

Crawford, twikidraw.tmpl.txt is an XHTML validated version. Not tested with the Plugin though.

-- PeterThoeny - 17 Aug 2004

Thanks, Peter, I'll incorporate it! I have to confess I didn't run the validator.

-- CrawfordCurrie - 17 Aug 2004

Minor bugfix to the drawing package uploaded; it was getting the encoding of URLs wrong in MAPs.

-- CrawfordCurrie - 11 Sep 2004 Sep 2004

Plugin zipfile appears to be missing the empty.gif file used on the topic page

-- GeoffJohnston - 27 Sep 2004

No, empty is meant to be just that - empty. It's meant as an example of creating a new drawing. example is the only drawing that should have attachments.

-- CrawfordCurrie - 27 Sep 2004

Small annoying bug. When you enter text in a box with a couple of lines and center the text this works fine when you save the drawing. But when you open the drawing next time all text is left justified again. So each time you edit a drawing you have to re-center all text again before you save it.

-- KennethLavrsen - 17 Oct 2004

Won-kyu Park contributed unicode changes:

> I made a unicode patch against TWikiDraw Plugin
> This patch enable to save unicode character as \uac00\uac01 etc. and
> read it properly.
> this is a quick hack and you can easily adopt it to the JHotDraw.
> Regards,
> Won-kyu Park

I applied the changes and generated a new zip. Please, someone with Unicode experience give it a shot and if it works, I'll build a release.

-- CrawfordCurrie - 22 Nov 2004

DeleteMe It works fine smile -- WonKyuPark - 23 Nov 2004

Problem with SSL (certificate)

We have a problem running TWikiDrawPlugin in our corporate network where we use SSL-enabled server and user certificates to access it. I believe it is related exactly with the user certificate - see below stack trace. Maybe you could help on how we can add the certificate for the applet ?

Caused by: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure at com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.a(DashoA6275) at com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.b(DashoA6275) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.b(DashoA6275) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA6275) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.j(DashoA6275) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.startHandshake(DashoA6275) at sun.net.www.protocol.https.HttpsClient.afterConnect(DashoA6275) at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.setNewClient(DashoA6275) at sun.net.www.protocol.https.PluginDelegateHttpsURLConnection.superConnect(PluginDelegateHttpsURLConnection.java:318) at sun.net.www.protocol.https.PluginDelegateHttpsURLConnection.connect(PluginDelegateHttpsURLConnection.java:146) at sun.net.www.protocol.https.PluginDelegateHttpsURLConnection.getInputStream(PluginDelegateHttpsURLConnection.java:357) at java.net.HttpURLConnection.getResponseCode(HttpURLConnection.java:272) at sun.net.www.protocol.https.HttpsURLConnectionImpl.getResponseCode(DashoA6275) at sun.applet.AppletClassLoader.getBytes(AppletClassLoader.java:263) at sun.applet.AppletClassLoader.access$100(AppletClassLoader.java:43) at sun.applet.AppletClassLoader$1.run(AppletClassLoader.java:152) at java.security.AccessController.doPrivileged(Native Method) at sun.applet.AppletClassLoader.findClass(AppletClassLoader.java:149) ... 9 more

-- JarekPotiuk - 13 Dec 2004

Just following the earlier thread about upgrading to a more recent JHotDraw version and noted someone had mentioned about possible integration of JGraph/JGraphpad along similar lines. Noticed whilst working with JGraph that there's quite a nice example of how this might look: http://www.jgraph.com/wiki/bin/view/Sandbox/TestTopic1. I'm digging into this to see if I can find more. At present:

  • It's JNLP/WebStart based - although JGraphpad has an applet mode, so it's possible both could be supported
  • It seems (I think) to use a mapping to an external drawing XML filename from the topic name rather than storing the drawing as an attachment (have posted in the JGraph forums to confirm this and see how easily this could be changed)

Other than that, it could be a nice alternative (which I guess means maybe a new/different plugin topic). Will add more as I find it.

-- RobWalker - 21 Mar 2005

Excellent - go for it, Rob. If you find a good alternative to JHotDraw we should grab it with both hands, especially if it has an SVG mode. I have no objection at all to the idea of replacing this plugin (including the name) with another editor that works better. I've never been happy with the JHotDraw codebase. Though I have heard a lot of negative vibes about the reliability/portability of JNLP/WebStart.

-- CrawfordCurrie - 21 Mar 2005

Problem with Border Tool

I have found one nasty bug and one annoyance.

The bug. If you use the border tool on a rectangel the URL tool no longer works. You can attach the URL but the rectangel is no longer an area with a link. I just discovered this by accident. We now have many process maps created where people think they created a link but it does not work. This is really nasty.

And the annoying detail. If you use the border tool there is no way you can remove the border again as far as I can see. You have to delete the object and do it over again.

TWikiDrawPluginEdit drawing `Borderbugexample` (requires a Java 1.1 enabled browser)Edit drawing `Borderbugexample` (requires a Java 1.1 enabled browser)Edit drawing `Borderbugexample` (requires a Java 1.1 enabled browser)Edit drawing `Borderbugexample` (requires a Java 1.1 enabled browser)

-- KennethLavrsen - 05 Jul 2005

-- LilianBUZER - 14 Dec 2005

I try to set up the Plugin today... The applet desperately does not want to load. I download the last version of the plugin, so I suppose the probleme with TWiki directory is fixed. When I deleted the XX.draw file, the applet launched with an empty screen. You can see here : http://www.dreamm.net/bin/view/TWiki/TWikiDrawPlugin

-- LilianBUZER - 14 Dec 2005

I install java runtime 1.5. This works well now. I used IE 6.02, I supposed that it had java 1.1 plugin installed...

-- LilianBUZER - 15 Dec 2005

Just tried with TWiki 4.0.1 running on Red Hat 3 and using IE 6. Works fine when drawing is first created, but applet doesn't appear when trying to subsequently edit the drawing. Any ideas?

Note that it does work with Firefox.

-- JohnTalintyre - 10 Feb 2006

BTW: Why wasn't TWikiDrawPlugin included with 4.0.0 or did I miss something? Wasn't this Plugin usally prepackaged?

-- FranzJosefSilli - 21 Feb 2006

No, this Plugin was never included by default. It is a popular Plugin though and c/should be included, but I foresee some resistence from some community members (see AddHeadlinesPluginToDistribution)

  • There's no need for prepackaging as long as the concerned Plugin is up-to-date and easily downloadable. Have been just curious. smile FJ

-- PeterThoeny - 22 Feb 2006

The latest Plugin version runs on Cairo and Dakar codebase, but there is a visual problem: The file content table has leading spaces instead of tab:

   * Download the ZIP file from the Plugin web (see below). Contents:
   | *File:* | *Description:* |
   | ==data/TWiki/TWikiDrawPlugin.txt== |  |
   | ==lib/TWiki/Plugins/TWikiDrawPlugin.pm== |  |

-- PeterThoeny - 28 Feb 2006

Can someone confirm that the example map look messed up for the 2/28 release? I have an older copy of the plugin and that looked fine.

  • Yep, image was distorted due to mime type set to text in SVN. Should be fixed with latest release.

-- JohnnyKwei - 28 Feb 2006

I am not sure which issues are because of Mac OS X or the Java version on my computer (1.4.2), but I noticed serious usability problems:

  • When I write %DRAWING{test}% on a page, I first get a broken image icon.
  • Clicking on the broken image, I get the applet, with an error message at the bottom: =Error reading /devtwiki/pub/Sandbox/DrawTest/test.draw: java.io.FileNotFoundException: http://visiblearea.com/devtwiki/pub/Sandbox/DrawTest/test.draw= (note this text was not selectable for copy/paste!)
  • When I draw or edit, there is no Save button
  • I cannot close the window
  • The only link available is on the oops page: the Cancel link
  • Clicking on Cancel does not save the image

See bug entry Bugs.Item1779.

-- ArthurClemens - 06 Mar 2006

I had a template problem with TWikiDrawPlugin (8154) and Dakar 4.0.2. I use the pattern skin.

The generated link for the oops template did not work. I changed in TWikiDrawPlugin.pm line 69 from

TWiki::Func::getOopsUrl($web, $topic, "twikidraw", $nameVal);
TWiki::Func::getOopsUrl($web, $topic, "twikidraw.tmpl", $nameVal);
. It works now. But the original problem with the skin ignorance still exists. Any idea?

-- StefanSchmidbauer - 04 Apr 2006

Hmmmm; you definitely shouldn't have to do that. It should realise there is no twikidraw.pattern.tmpl and fall back to the default.

Can you give instructions on how to reproduce the problem?

-- CrawfordCurrie - 20 Apr 2006

The current version of TWikiDrawPlugin will only work with the PatternSkin version shipped in 4.0.2 and later, as it depends on oops.pattern.tmpl.

If you're on 4.0.1 or 4.0.0 you should use v1.12 instead of latest release.

-- SteffenPoulsen - 02 May 2006

Thank you. I copied the template dir from a clean TWiki 4.0.2. Now it works with the latest TWikiDrawPlugin.

-- StefanSchmidbauer - 15 May 2006

Configuration or Compatibility Problem

I'm getting strange platform/browser compatibility problems. The draw plugin that is installed on this website (twiki.org) works fine with IE, Firefox, and Safari; however, the "save" function for the installation on our server only works with the latest version of IE running on Windows XP. All browsers and platforms are able to open existing images for editing. That leads me to believe that there is a browser configuration problem somewhere, but that wouldn't explain why Firefox & Safari work properly on twiki.org. The server we have twiki installed on is RedHat Linux, and the JVM's for all of the systems we tested it on are up-to-date. All of the systems are all behind the same firewall.

-- KevinCraft - 08 May 2006

We think we have found the answer to the problem. The JVM's on the systems were up-to-date, but the browsers weren't using the installed JVM. Apparently most browsers come with their own JVM and ignore any JVM's that are already installed. You have to explicitly tell the browser to point to the installed JVM; otherwise it will use its own (likely out of date) JVM. This still doesn't explain why non-IE browsers were still able to work properly on twiki.org and not our server. We think it may have something to do with the server's O/S.

-- KevinCraft - 09 May 2006

I just installed the plugin from the .tgz archive, but the templates/twikidraw.pattern.tmpl appears to be broken. Adding %TMPL:INCLUDE{"twiki"}% line fixed the problem.

TWikiDrawPlugin filename=TWikiDrawPlugin.tgz version=1.2

-- JadeCravy - 14 May 2006

Relating to my comment from 02 May 2006 which version of TWiki are you using, Jade?

-- SteffenPoulsen - 14 May 2006

I just downloaded and installed plugin. Also enabled it through configure (I am running Dakar). But it doesnt seem to install as I dont see placeholder box in TwikiDrawPlugin topic. My browser is java compatible and I can edit drawings on twiki site. What can be missing!

-- GauravSharma - 24 May 2006

Gaurav..Is it possible that you have Dakar 4.0.0 or 4.0.1 with patternskin? If so read above remarks from Paolsen and Schmidbauer. Pity, I fixed the bug after 4 hours of fooling with template files only to learn it was a CSS problem.

-- JpSabini - 25 May 2006

-- StenDahlgren - 02 Jun 2006

Configuration problem?

I'm trying to work with TWikiDraw but have som real problems that makes this tool much less useful to me.

  • Lost edit button

I need the editbutton to get url's to work but it does not exist. I printed the value of %EDIT_BUTTON% and it shows as 1. The wicked thing is that when i visit the installed TWikiDraw page the exampleimages as an editbutton! but why not my page?

  • Updateing an image results in a uncomplete draw file. the gif is ok but my draw file is the same as before but with new timestamp.

  • In our installation it was neccesary to hard force classic skin otherwise the editor didn't start

Anyone understand whats happening ?

running twiki "sep 2004"

-- StenDahlgren - 02 Jun 2006

another twiki user looking at the same page sees the gif as i created it and when he edits the image it shows up the same as the gif. when he edits it and saves it i see the new image but the draw file is my old version?? hmmm... this is weird.

-- StenDahlgren - 02 Jun 2006

one thing found. i clicked on the draw file(was may old content) and did a "shift reload" and there it was!! (i have done shift reloads on the other pages but not when visiting the draw file. And after this i can edit the image save and edit it again and draw file and gif is the same.

-- StenDahlgren - 02 Jun 2006

Solved edit button problem smile One has to put an URL in the drawing otherwise no edit button. I think it's not that good to start the editor by clicking anywhere in the image (makes it a bit weird for the uneducated twiki surfer)

-- StenDahlgren - 02 Jun 2006

Is it possible to look back on older TWikiDrawRevisions ?

-- KeithHelfrich - 06 Aug 2006

File format?

Is the .draw file format documented anywhere? I'm using TWikiDrawPlugin in MoinMoin ... and MoinMoin don't have the file format, I can't find anything on twiki.org that has the file format, I can't even find anything on a JHotDraw page that has the file format. Is it actually documented anywhere at all that anyone knows about? -- DavidGerard - 01 Sep 2006

Not that I have found. I reverse-engineered it from the JHotDraw code the one time that I needed it. It's basically just a trivial serialisation of the data structures.

-- CrawfordCurrie - 03 Sep 2006

Dear TWiki developers,

We are currently discussing a new universal Wiki drawing plugin based on the upcoming JHotDraw 7 here:


Please let me know, if you are interested in making it interoperable with TWiki.

-- WernerRandelshofer - 09 Nov 2006

I am sure someone in the TWiki community will pick it up. One important part is to stay upward compatible since TWikiDraw is used for a number of years in corporate settings: Existing .draw files should be upgraded to new format automatically on first edit.

For a broad deployment, I'd recommend to stick with the Java applet approach; and if a Java WebStart application is used, design for a fallback to regular applet.

-- PeterThoeny - 09 Nov 2006

Dear PeterThoeny,

I agree, upward compatibility is very important. To ensure upward compatibility with TWikiDraw, I am looking to find someone from the TWiki developer team which is willing to help us out.

For deployment, my idea is to support all Java deployment options in AnyWikiDraw: Applet, JavaWebStart and a standalone .jar application file.

Thank you for your feedback. smile

-- WernerRandelshofer - 10 Nov 2006

What about creating a brand new TWiki plugin based on TWikiDrawPlugin but using the latest JHotDraw 7 and worrying about format conversion later or while doing it? Integrating JHotDraw 7 into a TWiki plugin sounds fun to me. Format conversion from TWikiDrawPlugin to JHotDraw 7 sounds more tedious. Maybe that format conversion work could be commissioned by one of the major company running TWiki and interested in moving to JHotDraw 7.

-- StephaneLenclud - 22 Nov 2006

Werner, it depends what "willing to help us out" actually means. I'd be happy to help you with requirements, help you upgrade the existing TWikiDraw perl module to support your improved drawing editor, and also to create a distribution bundle. Unfortunately I can't offer assistance with the Java code, and I also can't commit to timescales (this would be purely skunk work at my expense unless someone funds it).

-- CrawfordCurrie - 23 Nov 2006

Stephane, that's exactly my intention. I want AnyWikiDraw to grow in small incremental steps, and I want to hand off the integration of AnyWikiDraw into TWiki to stakeholders of TWiki. - Everybody is supposed to get to do the fun parts he/she is interested in.

I just want to make sure, that there is no confusion about JHotDraw 7 and AnyWikiDraw: * JHotDraw 7 is a framework for drawing editors. JHotDraw 7 can't read/write a specific file format, nor can it be integrated into a Wiki of any kind. It is just a pile of building blocks, that a software developer can use to build lots of different drawing editors with. * AnyWikiDraw will be a drawing editor based on the JHotDraw 7 framework. It will support a (number of) specific file format(s), it will provide hooks that allow to integrate it into Wiki's. Hopefully - with support by Wiki stakeholders - it will work out of the box for a number of Wiki's.

Crawford, that's a nice and generous offer. I think this would do for a prototype integration of AnyWikiDraw into TWiki. Maybe once this is done, someone will jump on the bandwagon, and help us out with backwards-compatibility and bells and whistles. smile

btw. I am currently not funded either. So, for now, I am aiming at delivering a prototype of AnyWikiDraw only.

-- WernerRandelshofer - 23 Nov 2006

OK, sounds good. I looked at the JHotDraw 7 code a while ago, and decided it would be fairly easy to port. The gotchas are:

  1. the extra features I added to JHotDraw for TWiki viz. sensitive areas, colour and line end type menus
  2. The comms with the server
  3. The move to the more recent Java plugin (the current impl is Java 1.1, which runs on just about anything, including many phones)
I don't have any great love for the current implementation. If the data format has to change, so be it. We can always code up an on-the-fly compatibility conversion on the server side.

Note that some work was done on an SVG-saving TWikiDraw, but the code was never finished properly.

-- CrawfordCurrie - 24 Nov 2006

Dear Crawford,

1. I like these extra features very much. 2. The communication with the server is likely to be different for every Wiki platform. Hopefully, we can make most of the drawing code agnostic to the underlying Wiki platform. 3. I would like to have a modern and forward-looking design in AnyWikiDraw. In case, mobile computing needs to be supported, I would like to base the support on recent editions of Java Micro Edition only. IMO, mobile phones aren't suited for drawing images and diagrams.

I have just opened a new project at Sourceforge. I invite everybody to continue the discussion abut AnyWikiDraw there. https://sourceforge.net/projects/anywikidraw/

-- WernerRandelshofer - 26 Nov 2006

I've updated the answer in TWikiDrawRevisions.

-- KeithHelfrich - 27 Nov 2006

At least when using ShorterUrls, it seems as if you can't use Web.WikiWord syntax in the embedded URL to create proper links. The links are rendered verbatim, like http://somehost/Web/DrawTopic/Web.WikiWord . TWikiDrawPlugin claims that you can put wikiwords in there.

-- WoutMertens - 16 Jan 2007

I have implemented now a first working prototype of AnyWikiDraw for MediaWiki. https://sourceforge.net/projects/anywikidraw/

The prototype can draw images in the formats SVG, PNG and JPEG. It can create new image files or act on images that were uploaded using the regular file upload page of MediaWiki. To include an editable image within a MediaWiki page, a special drawing tag needs to be inserted into the page.

In future versions, (i.e. when I figure out how to do this), installing AnyWikiDraw on MediaWiki might make all images in a page editable, without the need of a special drawing tag. This way, it will be possible to install and uninstall it, without breaking pages or image files.

Let me know, if someone is interested in doing a similar prototype for TWiki. I don't know how to write extensions for TWiki, but I can definitely help you with the Java part.

-- WernerRandelshofer - 12 Apr 2007

This is very interesting, Werner! Easy use of images to help convey a message is important to any wiki.

For interested parties there's a screenshot of the applet available and the mediawiki extensions (the funtionality that would also be needed include in a TWiki plugin) is avaialble in sf SVN (direct links).

Thanks for letting us know, and please report back on your progress - I hope our community will be able to pick up on your initiative.

-- SteffenPoulsen - 12 Apr 2007

Gruezi Werner, and many thanks for sharing your progress here on twiki.org. Great progress! We'd love to get the TWikiDrawPlugin updated (preferred), or a new AnyWikiDrawPlugin for TWiki. See TWikiPlugins and PluginsHowTo on how to get started with TWiki plugins. Feel free to drop by in #twiki if you have any questions. It would be nice if someone in the PluginsCommunity could support the integration.

Here is the ideal spec for a new version of TWikiDrawPlugin:

  • Ablility to read the old .draw format and convert it to the new format on load, then save it in the new format.
  • Run as a standard Applet on old Java 1.1 version
  • Generate gif or png image for representation (so that no SVG or Java enabled browser is needed to look at and print a page with a drawing.

-- PeterThoeny - 13 Apr 2007

Dear Steffen, I gladly post updates about the AnyWikiDraw project here from time to time.

Dear Peter,

  • Ability to read and convert old .draw format. I can implement that, but, how about providing a conversion tool instead? The new format is going to have a different extension than .draw anyway. So, if we change the format, we may require some reorganisation on the Wiki server anyway. If the applet does not need to support the old .draw format, it will become smaller by about 20 to 30 kilobytes.

  • Java applet version: The new applet needs Java 1.5. In my opinion, there is not that much of a benefit, if we go back to older Java versions. Java 1.5 is released since 2004. It is available for Windows 98 and higher, Mac OS X 10.4 and higher, Linux, Solaris, ... .
    Besides, Microsoft has removed their Java 1.1 plugin from newer versions of Windows. So, people who want to use any Java applet on Windows need to go and install Java beforehand anyway.
Also, if the current applet would be rewritten to work wit Java 1.1, it would become huge. The AnyWikiDraw applet is compressed with pack200, it already has a download size 120 KByte, and yet, it is still very far from being feature complete. The same applet with the old jar file format is 8 times larger. If this applet were to be rewritten to Java 1.1, it would certainly become again larger by factor 2.

  • Generation of displayable images: The AnyWikiDraw applet supports this already. (I haven't figured out yet though, how to properly store the rendered image in MediaWiki.)

-- WernerRandelshofer - 13 Apr 2007

A conversion script is not user friendly. If you inherit TWiki content from somewhere else (merger etc) or restore content from backup you'd need to run conversion script A, B, C each time. Possible solution to keep applet size small: Package two applets, one with converter and one without. The plugin can determine which applet to call based on the file extension of the drawing file (when rendering %DRAWING{...}%.)

-- PeterThoeny - 14 Apr 2007

You are right about the conversion not being user friendly. I am going to integrate support for the .draw format into the applet.

If the applet becomes too big, I will split it up into one for each of the supported formats, as you have suggested - that's a great idea.

-- WernerRandelshofer - 15 Apr 2007

Nice to see you are making progress on that Werner. I'm dying for that plug-in smile I can only hope I get a chance to get involved with the development at some point. Looking at my schedule it seems unlikely that I can do that in the coming months. Maybe in August. Would be nice though to have some prototype of AnyWikiDrawPlugin. It should not take more than a day or two to bring together TWikiDrawPlugin and AnyWikiDraw in a AnyWikiDrawPlugin prototype.

-- StephaneLenclud - 18 May 2007

Werner, don't worry about applet size for the format conversion. The format should be converted server-side.

-- CrawfordCurrie - 19 May 2007

Dear Stephane, I would greatly appreciate your help in August. My own time fed up by the SVG file format, and the server-side code for MediaWiki. You could give us a hand for a first TWiki prototype of AnyWikiDraw.

Dear Crawford. I am currently very tempted to have client-side code for the format conversion - or at least - Java code. Because this would allow to write a stand-alone version of the editor which could be used to convert files from TWikiDraw and PMWikiDraw to SVG and ODG.

-- WernerRandelshofer - 21 May 2007

I favor on-the-fly-update on read so that users have a seamless experience. The client side approach sounds simple and should not add that much size to the jar file.

-- PeterThoeny - 21 May 2007

I have started a discussion about on-the-fly conversion of .draw files in the AnyWikiDraw development mailing list. Here is the first post of the discussion. The discussion is currently about PmWikiDraw, but it might be interesting for TWikiDraw too.

-- WernerRandelshofer - 28 May 2007

Full (selfish) disclosure: The TWikiCommunity would like to get your support for the prototype first on the original TWikiDrawPlugin, then on clones on other wikis smile


  • Do the on-the-fly conversion only once, e.g. if an old .draw format is encountered, convert it to the new format and save it only in the new format.
  • If needed you can do conditional stuff in the plugin part that expands the %DRAWING{something}%, such as checking for file type and passing different parameters to the applet based on it.

-- PeterThoeny - 28 May 2007

Thanks for fixing the link in my post above. smile

Sneaky fine printed disclaimer: I have got someone from the PmWikiDraw community helping out in the AnyWikiDraw project. wink

  • Unfortunately, we can't do one time conversion yet, because we haven't yet a feature-equivalent drawing format in AnyWikiDraw. (SVG doesn't support connected lines.)
  • For PmWiki and MediaWiki I am currently using filename extensions to determine the desired conversion. For TWiki, we could use the same approach too. For example something.svg will convert to SVG, if we find a something.draw file on the server.

-- WernerRandelshofer - 29 May 2007

Could a TWikiCommunity member help out Werner?

-- PeterThoeny - 29 May 2007

I have just released version 0.10 of AnyWikiDraw. I have implemented support for TWiki in this version. It would be great if someone had time to try it out. http://sourceforge.net/projects/anywikidraw/

-- WernerRandelshofer - 04 Jun 2007

For developers it is not nice to mix an SVN checkout installation with manually installed plugins. it messes up things when the plugin later gets added to the SVN repository. Can I kindly ask you to check your current version into our MAIN branch. I assume you have checkin rights. Otherwise we will get you that quickly.

With the plugin in SVN developers can write one command and enable the plugin in configure and we are testing it.

-- KennethLavrsen - 04 Jun 2007

Dear Kenneth, I am hoping that someone from the TWikiCommunity is going to help me out with this.

-- WernerRandelshofer - 04 Jun 2007

Werner, nice to see progress on the integration! smile

It does not look like you have SVN access. Please ReadmeFirst and read PluginsInSubversion, then create the WernerRandelshoferWouldLikeToCheckIn topic as described.

-- PeterThoeny - 04 Jun 2007

You can be sure that many of us will help you out with this Werner. Come by the #twiki IRC channel on the Freenode network and you will get help almost any time.

-- KennethLavrsen - 06 Jun 2007

I have just committed AnyWikiDraw into SVN. Can someone please take a look at the files? I haven't made a MANIFEST file, do I need to create one? (I tried to use #twiki IRC, but browser access has been disabled.)

-- WernerRandelshofer - 11 Jun 2007

On Mac OSX using Firefox 2.0, the toolbar for saving, choosing the fill colour, etc. doesn't show up. I tested with Safari and it seems work just fine - the toolbar simply appears as more menu headings next to the standard menus. Has anyone else observed this behavior on OSX w/ Java 1.5? Is there a workaround?

-- AaronHoover - 21 Jun 2007

Aaron, I am seeing this too. This is probably a bug in Firefox. In Safari the menu items of the applet are attached to the right of the menu items of Safari. I find this is very confusing.

I don't know of a workaround, other than doing changes in the way the applet creates its menu bar: instead of using a regular menu bar, the appled could create a JMenuBar, and add it like a regular component to its content pane.

-- WernerRandelshofer - 22 Jun 2007

New Inspiration?

I developed a drawing applet for children on the base of the TWikiDrawPlugin for my diploma thesis. I just used the loading and saving routines, there are no vectors anymore and you need to have java 1.4 or even higher, but it might help building a new plugin. If anybody is interested in, just let me know.

Here is the link to the sandbox http://w01.devweb.mwn.de/sys/cgi/twiki/bin/view/Sandbox/WebHome Patience: unfortunately the loading time is very high.

-- CarmenEisendle - 26 Jul 2007

Dear Carmen, This is a beautiful applet. I am interested in supporting multiple applets for the AnyWikiDraw project. Please contact us at the AnyWikiDraw project, If you are interested in sharing server-side code with us based on streamlined applet parameters and on a streamlined client-server protocol. For instance, you could reduce the download-time of your applet, by using our pack200 scripts, and you could make your applet make to work with MediaWiki and PmWiki as well.

-- WernerRandelshofer - 26 Jul 2007

Carmen, nice to see that TWiki code is used in all kind of places! Thanks for sharing.

-- PeterThoeny - 26 Jul 2007

Has anyone had the time to try out the AnyWikiDraw plugin in SVN? The discussion on this page is very long already. Would it make sense to create a AnyWikiDrawPluginDev page?

-- WernerRandelshofer - 03 Aug 2007

Is there an AnyWikiDrawPlugin downloadable from twiki.org? wink

-- FranzJosefGigler - 07 Aug 2007

Hi Franz, Of course there is an AnyWikiDrawPlugin! 8) Its there for two months by now. See my posts from June. You can either check it out from the SVN repository, or you can download it from the AnyWikiDraw project page.

-- WernerRandelshofer - 07 Aug 2007

Werner, could you please package it and post it on twiki.org to make it more accessible?

-- PeterThoeny - 12 Aug 2007

Peter, I couldn't figure out how to post it on twiki.org. I have included the AnyWikiDraw package for TWiki into the AnyWikiDraw releases since release 0.10 of AnyWikiDraw: http://sourceforge.net/project/showfiles.php?group_id=183470 I am not sure, if I made the package correctly. Do I need to zip it, even if it is already part of a zipped package?

-- WernerRandelshofer - 13 Aug 2007

You can create an AnyWikiDrawPlugin topic, starting from PluginPackageHowTo. Read plugin packaging details in TWikiPlugins.

-- PeterThoeny - 28 Aug 2007

Hi, is there a way to draw on a transparent layer on top of another image with this tool?

-- JensHofmann - 03 Jul 2008

I can't seem to get this to work with Mac OS X 10.5. The Java applet window opens and I can edit, but the menu bar doesn't appear (Drawing, Edit, Selection, Fill, etc.) I've scoured the internet to no avail for answers. What about AnyWikiDraw? Is it stable enough yet?

-- TomTownsend - 20 Aug 2008

Noticed this also. You need to click on the launch window to get the menu back.

-- PeterNixon - 14 Sep 2008

Slightly odd - the extra colours weren't showing. When I looked at the TWiki Draw template, there wasn't a space after the comma for the web background colour. Adding this restored the extra colours list

-- ChrisHogan - 2009-09-12

The Latest Plugin with fix to Bug:Item6333 is released

-- SopanShewale - 2009-10-30

For some reason, since upgrading from TWiki 4.3.0 to 4.3.2 I get the following message when I try to save a drawing "Saved .draw Failed .map Failed .gif Failed". I am authenticated before attempting to do the save. Any help would be appreciated.

-- TimJacob - 2009-12-14

Known issue. Update the TWikiDrawPlugin or turn off the {CryptToken}{Enable} configure setting.

-- PeterThoeny - 2009-12-14


trying to install as root via the enclosed TWikiDrawPlugin_installer.pl I get a series of permission error messages like

WARNING: cannot set permissions on pub/TWiki/TWikiDrawPlugin/example.draw

Probaly some stupid mis-configuration ... but where? %BR%TWiki running here 4.1. Or is it really not supported (4.0.0 is, 4.2 also)?


-- DetlefMarxsen - 2010-02-09

Make sure that all files and directories below twiki/data and twiki/pub are owned by your webserver user, such as apache.apache.

-- PeterThoeny - 2010-02-10

Hello, I am having an issue and I can't find the same problem in the list above. But I have verified that www-data is the owner of my Twiki directories. But when I try to edit a drawing it says "Error Reading /twiki/pub/pubname/pagename/untitled.draw java.io.FileNotFoundException: http://twiki/twiki/pub/pubname/pagename/untitled.draw. It doesn't look like it can create the file. Not sure what else to do as far as permissions go. Thanks for any help anyone can provide.

-- CurtisTaylor - 2012-09-12

Just to update I am running Ubuntu 12.04 Server 64-bit and installed Twiki 5.1.1. Has apache 2.22 if that matters. Let me know if any other info is needed.

-- CurtisTaylor - 2012-09-12

Nice recent enhancements MahiroAndo!

-- Peter Thoeny - 2013-05-20

anyone tested with twiki behind a proxy that terminates SSL? i can load the drawing, but when saving the app crashes: "denied access outside a permitted URL subpath"

-- ivo schindler - 2013-11-25

Topic attachments
I Attachment History Action Size Date Who Comment
Unknown file formatdraw Borderbugexample.draw r3 r2 r1 manage 2.0 K 2005-12-26 - 23:11 JoergWeichelt TWiki Draw draw file
GIFgif Borderbugexample.gif r3 r2 r1 manage 2.7 K 2005-12-26 - 23:11 JoergWeichelt TWiki Draw GIF file
Mapmap Borderbugexample.map r3 r2 r1 manage 0.5 K 2005-12-26 - 23:11 JoergWeichelt TWiki Draw map file
Texttxt MyDiffs.txt r1 manage 8.6 K 2003-01-28 - 22:37 AnthonPang My diffs to TWikiDrawPlugin.zip 08 Jan 2003
Unknown file formatpatch TWikiDrawPlugin.pm-linebreak.patch r1 manage 0.7 K 2003-12-15 - 14:42 AlexanderStedile Hack removes the malicious linebreaks from applet.
Compressed Zip archivezip TWikiDrawPlugin.zip r6 r5 r4 r3 r2 manage 366.6 K 2004-11-22 - 18:48 CrawfordCurrie With Won-kyu Park's unicode changes
Compressed Zip archivezip TWikiDrawSvgPlugin.zip   manage 380.6 K 2002-06-14 - 15:11 UnknownUser  
Unknown file formatdraw canvastretch.draw r9 r8 r7 r6 r5 manage 5.2 K 2003-02-21 - 15:38 RandyKramer  
GIFgif canvastretch.gif r9 r8 r7 r6 r5 manage 16.1 K 2003-02-21 - 15:38 RandyKramer  
GIFgif editlink.gif   manage 1.7 K 2005-02-19 - 01:59 UnknownUser  
Compressed Zip archivezip twikidraw-applet-src-v1.10.zip r1 manage 175.5 K 2003-02-19 - 10:12 BertrandDelacretaz TWikiDraw applet V1.10, see comment on this page
Texttxt twikidraw.tmpl.txt r2 r1 manage 2.3 K 2004-08-17 - 01:37 PeterThoeny XHTML valid version
Unknown file formatdraw tylertest.draw r7 r6 r5 r4 r3 manage 0.7 K 2006-05-25 - 18:47 JpSabini TWiki Draw draw file
GIFgif tylertest.gif r6 r5 r4 r3 r2 manage 1.6 K 2006-05-25 - 18:47 JpSabini TWiki Draw GIF file
Edit | Attach | Watch | Print version | History: r224 < r223 < r222 < r221 < r220 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r224 - 2013-11-25 - IvoSchindler
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2018 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.