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
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
bug MAC OS X NN
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 2.0.0.14
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.
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) {
fStream.print('"');
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.
--
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
Suggestions
- Show file name in applet view
- show diagram space coordinates (the size of the diagram is difficult to determine)
- view source of .draw 'in real time'
- 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
- templating mechanism for object behaviors (double click to add name for example)
- 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)
- 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
- 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 ?
- 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!
- 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 - 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:
73,74c73,74
< my( $attributes ) = @_;
< my $nameVal = TWiki::Func::extractNameValuePair( $attributes );
---
> my( $theAttributes, $theTopic, $theWeb ) = @_;
> my $nameVal = TWiki::Func::extractNameValuePair( $theAttributes );
80c80
< TWiki::Func::getOopsUrl($web, $topic, "twikidraw", $nameVal)."\" ".
---
> TWiki::Func::getOopsUrl($theWeb, $theTopic, "twikidraw", $nameVal)."\" ".
106,107c106,107
< $_[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
EXTRA_COLORS anyone?
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
28c28
< <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
I've not been quite as active maintaining this plugin for a couple of reasons:
- 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.
- 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.
- I'm not particularly convinced there's a broad requirement for this plugin.
- 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...
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:
- Access to any hoopy new features and bugfixes the JHotDraw people have made in 5.3
- 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.
- You will have to install the Java2 plugin (though of course that is semi-automated) - Java1.1 support will be lost.
- I could address some of the fixes above
- 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
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
--
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.
Edit
--
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. 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);
to
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.
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
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:
http://www.wombatinvasion.com/pmwiki/pmwiki.php/AnyWikiDraw/InitialDiscussion
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.
--
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.
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:
- the extra features I added to JHotDraw for TWiki viz. sensitive areas, colour and line end type menus
- The comms with the server
- 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
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
Suggestions:
- 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.
Sneaky fine printed disclaimer: I have got someone from the
PmWikiDraw community helping out in the
AnyWikiDraw project.
- 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!
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?
--
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
Hello,
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)?
Thanks!
--
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