Tags:
create new tag
, view all tags

Archive of old inputs to TWikiDrawPluginDev

This is an attempt to repackage TWikiDrawApplet as a plugin. The install should consist of simply downloading and unziping over the latest TWiki production release. However it may be necessary to re-attach the files in pub/TWiki//TWikiDraw to TWiki.TWikiDraw if data/TWikiDraw.txt gets corrupted. Note that this zip does not include the src and jar from TWikiDrawApplet twikidraw.zip. I would recommend splitting these into seperate topics in TWikiDrawPlugin.

-- StevenRKroeker - 20 Sep 200

I have a fully-functional TWikiDraw Plugin that I haven't had time to submit - sorry - which includes all the sources etc. Please see ExperiencesSubmittingPlugins for details on how I've packaged it. I'll attach the zip here when I finally make it back to my home machine....

-- CrawfordCurrie - 21 Sep 2001

I have submitted it as a plugin. Just to get a list started, here are some additional development ideas....

  • Update to the latest JHotDraw. Though I think it's now JDK 1.2, which won't work on some browsers.
  • Get the JHotDraw tests from the JHotDraw team and add them into the source package.
  • Fix the problem on Netscape which causes the source page not to get updated when a drawing is saved, and the applet not to be updated when the same drawing is re-edited (something to do with page cacheing?)

-- CrawfordCurrie - 23 Sep 2001

Nice to have TWikiDraw packaged as a plugin. I suggest to add the settings for one line description and debug.

-- PeterThoeny - 24 Sep 2001

TWikiDraw is cool. My only question is: why I am allowed to edit picture, while in view mode? I guess in view mode I should get plain GIF, and updateable picture should be served only in edit mode. It is consistent - and will solve also record-locking - because as it is now, two different persons (or two instances of browser on same PC) might update same picture - and then some changes are lost without warning. Which is Bad Thing, I guess?

-- PeterMasiar - 04 Jan 2002

Small feedback. The following setting is obsolete: "Add the following line to the "TWiki Plugins" section of TextFormattingRules: TWikiDrawPlugin: Drawing Editor Plugin." Each plugin should have a SHORTDESCRIPTION setting so that it will be listed automagically in the TextFormattingRules topic.

-- PeterThoeny - 04 Jan 2002

Before finding the TWikiDrawPlugin, I was looking into various drawing tools and came across the SVG format. Recently I did a small fix to the TWikiDrawPlugin, and it struck me how neat it would be to move from the current .DRAW format to a .SVG format. That way, browsers enabled with something like the Adobe SVG plugin could see a scaleable exact representation of the original image. Non-svg enabled browsers could still be served up a .GIF as at present. If I ever get a chance, I'll take a look into this - but feel free to beat me to it!

-- RobWalker - 11 Feb 2002

  1. No one has answered PeterMasiar's question above (I'm interested also).
  2. Is there a way to create a larger drawing (surface) -- see EmailServerSketches -- I need more drawing surface but I don't know how to create it.

Oops, never mind -- maybe I'm OK -- looks like I have more surface than I thought, just ran into a limit on the size of a single rectangle.

-- RandyKramer - 17 Feb 2002

I'm interested in the answer to PeterMasiar's question as well. When I was porting TWikiDraw to a Plugin I wanted to do this. As well as the obvious conflict with the basic wiki model, the current implementation is not very clean, because it translates the %DRAWING% tag to some horrible HTML. Much better to just translate to an image link.

It would be possible to put editable images on the edit page, but that would involve some very hairy changes to the edit script and template, and is not supported to any degree by the plugins api. I'd stay away from this.

Instead, how about an 'edit drawings' button on the view page, that then serves up a page of images to edit? One easy way to compose this page might be to use a skin. view?skin=images. Use of the skin could be recognised by the plugin which could generate appropriate page text (the existing HTML). Half an hours work.

Regarding Rob's move to SVG format; interesting. One of the big pluses of the current approach is that we use JHotDraw (almost) off the shelf; you are proposing a fairly major departure from the JHotDraw code. I think this should be done under the JHotDraw project, rather than TWiki.

-- CrawfordCurrie - 18 Feb 2002

FYI, regarding disconnecting image editing from the view page; I tried this out. General feedback from the users: "it stinks; leave it like it is". Of course, users have been known to be wrong.

-- CrawfordCurrie - 27 Feb 2002

-- CrawfordCurrie - 01 Oct 2002

SVG on the fly?

Can the SVG graphic file be used to generate a <map> on the fly? It would be really neat to be able to create a sensitive map over a drawing, with links to other pages - for example, a flow diagram. The map should be sensitive to boxes, text, and lines drawn between boxes at the minimum.

-- CrawfordCurrie - 26 Jun 2002

Diffs for drawings?

Thanks a lot to the TWiki and for this Plugin: I find it very useful.

I kindly ask for suugestions on how should I proceed to add the following features:

  • Add the versioning to the .draw file. The final target would be to have a "Diff" button, showing each version of the drawings (as for the text portion).
  • Enhance the "Printable" template to show the drawing as a regular img tag (the .gif as it is already), without any href or alt tags.

-- BrunoFranzini - 17 Jul 2002

Versions: The attachments are already under version control. Click on the action link of the .gif file and you will see all versions. TWiki however does always show the latest image version in a topic, even if you look at an older topic version.

Printable template: There is currently no way of conditionally render content based on a skin. You could however change the TWikiDraw template file to not link the image and add a Edit link at the right hand side of the image.

-- PeterThoeny - 17 Jul 2002

Clickable links

If there was a way to assign links to draw objects this would be an awesome navigation aid for TWiki! Of course, this would require changing the convention of a single click on image to edit the drawing. That doesn't seem like such a great interface to me anyway because it is too easy to do unintentionally. Web users are use to clicking on images to copy them or for links but not to edit them. This combined with the time delay before the edit window pops up can leave the user totally confused as to what is going on.

BTW, I seem to have stretched the demo graphic in this topic by accident when I edited it just now. Strange, because I didn't do anything like that. Also, it did not include the changes I made in the drawing. Perhaps, I just missed something or (hopefully not) this was the result of more odd behavior between Java and my Mac IE browser.

-- LynnwoodBrown - 19 Jul 2002

Stretching: The image size gets adjusted automatically to the size of the objects.

Image map for links in image: I had this idea also:

  • We could change Edit into an Edit link to the right of the image.
  • Any text that has a square bracket link is turned into a link as shown in browsers, for example text [[TWikiDrawPluginDev][TWikiDraw Plugin]] would get rendered as TWikiDraw Plugin.

This means that the topic itself needs to be updated as well, currently only two files are attached. Or wait, it could be done without updating the topic text if a third file gets attached: an HTML file that contains the image map.

-- PeterThoeny - 21 Jul 2002

Cool!

How about this; a box, line or whatever object on the picture would have a 'link' attribute that is put in the image map attachment where the URL would normally (may need to delimit, perhaps by %%). When rendering the drawing, the image map file is expanded into the rendered text and the link attribute strings in the file processed to expand wiki words etc. This would allow sensitive lines etc. which you need when rendering flow diagrams.

-- CrawfordCurrie - 21 Jul 2002

Parallel drawing anyone?

Has anyone used this as a remote collaboration tool, letting two people in different locations sketch on a common image while phone conferencing, for example? Seems like it could work well here. What would really help for this is another menu item under Drawing which would be "Save without Exiting". Then you can simply save your version, and Reload when the other side has saved theirs, without closing the draw applet at all. Would it be easy to add such a menu item?

-- MartinWatt - 05 Sep 2002

We've used it over NetMeeting and SunForum. Our meetings these days tend to be done by sharing a browser instance over netmeeting and then swapping control back and forth. Saving regularly lets those not on netmeeting follow along. Note: sharing just by saving and refreshing works, but not very well; it eats up meeting time waiting for everyone to refresh.

"Save without exiting" should be fairly easy to add. I say should because I'm not certain what restrictions java.net would impose. It would require some experimentation.

-- CrawfordCurrie - 09 Sep 2002

Couple of updates; I don't think "save without exiting" is possible due to the restrictions of the java.net api.

I've implemented the MAP idea above. If you attach a URL to a figure (box or line) then it saves a .map file along with the .draw. This is processed by the plugin. The picture is still editable, but the sensitive region is restricted to a 10-pixel strip around the border.

I also incoporated the SVG saving code from TWikiDrawSVGPlugin, but I don't think it's worth enabling until there are more SVG-enabled browsers out there.

With these changes I've been noticing a problem; sometimes when saving, the applet exits normally but then the browser locks up; using Netscape 4.61 on Linux. I've revisited all the comms code but it looks OK, as per spec. Anyone got any ideas? Seen this sort of behaviour before?

-- CrawfordCurrie - 30 Sep 2002

Okay, first pass attempt at URL support is attached. BIG BIG WARNING because I had to enable support for attributes on lines, the serialized output from the attachment is not readable by older versions of TWikiDraw. So at this stage only install it in experimental installations! Caveat Emptor. Oh, and I removed the SVG support again. Some issues described above are also fixed, though I'll have to do a trawl to record which ones.

-- CrawfordCurrie - 30 Sep 2002

How to display edit link?

Wow, image map support, great! Small suggestion: Making the 10-pixel strip around the border as the hot link to edit the drawing might not be very intuitive. The current spec of making the whole image the edit link can be confusing too.

It is very obvious and not too intrusive if we add a small blue Edit text in the right lower corner of the image as indictaed in the (non functional) example to the right. Alternativelly, show an text Edit link to the right of the image.

editlink.gif

-- PeterThoeny - 01 Oct 2002

Hmmmm. If I did that I'd face open rebellion. Some of our people use the GIFs in static web pages. We even have used GenHtmlAddon to generate actual read-only web sites using TWiki. So they would not be too impressed if every GIF had an edit link in it. I tried putting an edit link alongside/above/below the image but it throws off the formatting and looks really cheap. Is there some way to overlay such a link on top of the gif in the plugin code? Alternatively, maybe we should go to having an "Edit Images" button on the page that pops up a menu of images on the page that can be edited. That shouldn't be too hard.

-- CrawfordCurrie - 01 Oct 2002

Image map implementation off by a few pixels

I installed the beta below, and it looks like the generated client-side map is a little off. For example, my image's properties says it's 887x588. It looks like 10 pixels (too many) are subtracted from the horizontal and vertical. Also, along the bottom edge of the image, the last coordinate pair is transposed, e.g., should be "0,573,877,578":

<AREA SHAPE="RECT" COORDS="0,0,877,5" HREF="%TWIKIDRAW%">
<AREA SHAPE="RECT" COORDS="0,0,5,578" HREF="%TWIKIDRAW%">
<AREA SHAPE="RECT" COORDS="872,0,877,578" HREF="%TWIKIDRAW%">
<AREA SHAPE="RECT" COORDS="0,573,578,877" HREF="%TWIKIDRAW%">

Bug: if you edit a drawing, removing all attached URLs, any previously created .map file should be deleted; old copies can still be found in RCS (and shows up as an attachment at the bottom of topic, unless hidden)

Bug: if the attached URL contains a hash mark, it is encoded in the map file as %23, instead of #, resulting in a broken link (tested under IE5 and Mozilla1.3a).

Bug: for poly shapes, the map file is missing the HREF link.

Nitpick: it would be nice if it didn't report an error that saving the .map file failed (when there aren't any attached URLs).

I've attempted fixes for the above (see MyDiffs.txt).

p.s. Please add my vote to have an Edit button as an alternative -- perhaps as a setting?

-- AnthonPang - 28 Jan 2003

That's terrific Anton. Looking through the diffs the only thing I don't like is catching Exception; I presume you were really seeing an IOException?

The attached zip has all Anton's changes except those to Store.pm and upload which I can't touch.

And it has an Edit 'button' option as well. If someone can give me the HTML to make it a "real" button that sits hard up to the top edge of the image, instead of a text link, I'll incoporate that as well. The edit button is enabled by setting EDIT_BUTTON to 1 in the plugin topic.

-- CrawfordCurrie - 29 Jan 2003

At long last, it's in CVS. The checked-in code is what was used to build the zip, below.

Anthons changes to Store.pm and upload raise some interesting questions about automatic pruning in the pub directory. TWikiCoreTeam, how about a method for pruning unwanted attachments during upload? Fraught with risk, I know.....

-- CrawfordCurrie - 02 Feb 2003

Draw through SSL?

I've run into a problem with the version in twikidraw-applet-src-v1.10.zip on the TWikiDrawPlugin page where saving the drawing won't work if you are accessing TWiki over SSL. The following patch fixes this:

--- TWikiDraw.java.old  Thu Mar 20 20:39:53 2003
+++ TWikiDraw.java      Thu Mar 20 20:39:57 2003
@@ -93,7 +93,7 @@
         // for test
         //URL server = new URL("http", "localhost", 80, savePath);
         URL server = new URL(
-           "http",
+           getCodeBase().getProtocol(),
            getCodeBase().getHost(),
            getCodeBase().getPort(),
            url);

-- MartinLucina - 20 Mar 2003

Thanks Martin. That fix is already in the zip attached below. Since there have been no negative responses, I guess it's time to release it.....

-- CrawfordCurrie - 21 Mar 2003

Support Wiki Word Web Names

TWiki allows now WikiWords for Web names, see Codev.WebNameAsWikiName. With that, twikidraw.tmpl needs to be changed from:

<B>%WIKITOOLNAME% . %WEB% . </B> (etc...)

<b>%WIKITOOLNAME% . <nop>%WEB% . </b> (etc...)

-- PeterThoeny - 22 Mar 2003

NTLM authentication?

When I switched authentication to NTLM - Draw plugin stoped working. It lunches Jave apps and I can create an immage, but I can not save it. I tryed new attached zip version with the same result. It prints "Saved .draw Failed .map Failed .gif Failed" Is there any thing I can do to make it work?

-- LeanidNazdrynau - 19 Jun 2003

Edit | Attach | Watch | Print version | History: r3 < r2 < r1 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r3 - 2003-12-12 - PeterThoeny
 
  • 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-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.