LongImageIncorporationProcess

See Also

Discussion

It’s imperative that we are able to easily incorporate images on the wiki.

Sadly, the Visual wiki is down for upgrade right now, it had a bunch of notes describing just how painstaking it is to put images on a wiki. (Or, any web page just in general, as a matter of fact.)

I’m asking here for solutions. We need to tighten this path as much as possible:

  • Drawing an image in Inkscape.
  • Saving the image to the disk.
  • Finding where you want to put the image on a wiki.
  • Picking a name for the page representing the image in SVG.
  • Uploading the image from the space on disk to the page representing the image in SVG.
  • Picking a name for the page representing the image in PNG.
  • Uploading the image from the space on disk to the page representing the image in PNG.
  • Going to the page where you want to actually use the image, and making a reference to the image itself.
  • Checking that it looks right, and saving.

I am omitting details, that can be enumerated. My guess is that there are ~30-100 small steps (“click on this, click on that, enter this URL,…”) that must be correctly entered in sequence in order to place an image on a wiki.

This is too many.

I solicit you for how we’re going to solve this problem.

I have my own ideas, but they tend to be unpopular. ;) Much better to let you commit your belief to something in your own words. I am not really concerned what color the wires are; Just as long as I can easily put images to the wiki with a minimal number of steps from a ready image in Inkscape.

I am happy to contribute my hands to whatever work ends up needing doing.

Off the top of my head, here are a few ways to trim out a few steps. (Alas, they’re not very simple).

  • Don’t make the users translate from SVG to PNG. Add SVG-to-PNG translation code to the wiki software to translate on-the-fly. (perhaps cache the results).
  • Make a plug-in for Mozilla that, on the “upload file” dialog, adds a “sketch image” button that fires up your favorite editor. Instead of open Inkscape – draw – save to hard drive and give it a name – click the upload image button, it becomes click the upload image button – Inkscape pops up; draw in Inkscape – click save.
  • Add code to Inkscape (or your favorite open-source editor) that gives an extra “save as…” option to save directly to a wiki.
  • Make a Java drawing tool applet (perhaps convert Inkscape into an applet?) that never saves files to the local hard drive, always saves files to the remote server.

Surely there’s a better way.

I’m learning a new CAD application this semester. I am astonished to discover that (in this application) it is difficult/impossible to edit certain features once you’ve drawn them. Apparently the programmers decided that was unimportant compared to making something else as simple and easy to do as possible: drawing a feature from scratch. If something is not quite right, it’s usually faster to delete that one feature and draw it from scratch.

This is very different from most software IDE systems and programming languages I’ve seen, that try to make modifying a function as simple as possible, while writing a whole function/method from scratch is more difficult. (But there are a few programming languages that make it easy to write small functions from scratch. I wonder if the programming process would be better if I used an IDE that had different affordances – one that made it easy to write an entirely new function from scratch, but then refused to edit that function – forcing me to write a new function from scratch, and possibly delete the old one.).

Would you rather have a word processor that let you fiddle with each bit in a letter, and let you increment and decrement individual digits, or one that required you to delete the entire letter or digit and type in a new one?

  • Don’t make the users translate from SVG to PNG. Add SVG-to-PNG translation code to the wiki software to translate on-the-fly. (perhaps cache the results).

I totally agree. Inkscape has a command line option to turn an Inkscape SVG into a PNG automatically. I hear it doesn’t work so well for non-Inkscape SVG. On the other hand, the Gimp now can read SVG and output just about anything; I strongly suspect you can tell the Gimp what to do from the command line.

  • Make a plug-in for Mozilla that, on the “upload file” dialog, adds a “sketch image” button that fires up your favorite editor. Instead of open Inkscape – draw – save to hard drive and give it a name – click the upload image button, it becomes click the upload image button – Inkscape pops up; draw in Inkscape – click save.

Let me make sure I understand right:

  • You’re prompted to upload a file, in response to clicking a form element or link.
  • Instead of uploading a file, you press, “sketch image.”
  • It opens up Inkscape, defaulting to some temporary file. (Side note: We can construct this file by saving a blank Inkscape SVG document.)
  • You draw your image.
  • You just hit “save.”
  • It saves to the temporary file, which the plugin then sends to the web server.

I like it! I know some Mozilla Javascript XPCOM foo now, and I think this is doable. I’d have to look at the “upload file” dialog in Firefox, and see if I could overlay it, but I think I can.

  • Add code to Inkscape (or your favorite open-source editor) that gives an extra “save as…” option to save directly to a wiki.

I talked with BryceHarrington? of Inkscape, and he was sympathetic to the idea. We need to figure out how to allow this, though. HTTP PUT? Or some WebDAV magic?

  • Make a Java drawing tool applet (perhaps convert Inkscape into an applet?) that never saves files to the local hard drive, always saves files to the remote server.

MoinMoin has this. I have three problems with it:

  • I can’t get Java to work on my home computer.
  • The drawings are dinky.
  • I don’t like Java.

But, of all approaches so far, it’s been the most successful, so I am somewhat sympathetic to it.

Of all of these, my favorite idea is loading from and saving to the wiki, directly.

The problem is the interface; I haven’t seen much support for PUT or WebDAV extensions lying around.

Why not just POST? But if you want PUT, I’m sure I can implement it in Oddmuse. I really want to make it easier to add images to Oddmuse, so I’m willing to add extra stuff. I just have zero XUL and Javascript fu…

POST is fine, I’m not really too concerned which word is used.

Only: My understanding is that “PUT” is used for putting files onto servers, and that’s what it seems like we’re doing. I would hope that whatever tool we make, it could be used with other servers, for example.

But, I mean: Put it in however you like! I’m really eager to see this.

I think all you need, then, is documentation of how to upload images via POST, right? And I already have that! (Since you said “however you like”.) And there is working code, too. And Python! See Oddmuse:wikiupload. Does that help you write the XUL thing?

I’m almost done with placement scripts.

Follow the work on: Inkscape:WikiExporter was: Inkscape:WikiExporter

…almost there… (for uploading,…)

First half is done!

I present for you, InkscapeToOddmuse.

The second half, is to make the import plugin, so you can load the page from Inkscape.

The third half is to work in a system for scanning the wiki for all SVG pages.

Wow. The time from my first half-baked ramblings to actual code happened much faster than I expected. Good job.

Wow, Lion, you rule!! For part three, I offer you the following URL:

     http://www.emacswiki.org/cw?search=%5E%23FILE+image%2Fsvg;raw=1;context=0

It returns the pagenames of all image/svg files as text/plain.

Rad! But there’s only one problem:

I’m presently uploading as text plain.

Relevant code:

 ...
 cp "$INK_SVG" "$DOCBASE/$DOCNAME.svg"  # okay, we want the .svg, but, ...
 cp "$INK_SVG" "$DOCBASE/$DOCNAME.svg.txt"  # wikiput content-types it 
 ...
 ...
 SRC="$DOCBASE/$DOCNAME.svg.txt"
 TARGET="${URLBASE}${DOCNAME%.odd}Svg"
 "$EXEC_DIR/wikiupload.py" -u "$USERNAME" -s "$SUMMARY" "$SRC" "$TARGET" 2>&1
 ...

When I was uploading just the raw .svg file, I kept getting error messages from the server.

Let me go gather them…

…ah, here:

 [lion@localhost cw]$ more DeleteTest.odd
 Uploading /home/lion/my/img/cw/DeleteTest.odd.svg application/octet-stream
 415 UNSUPPORTED MEDIA TYPE
 
 Traceback (most recent call last):
   File "/usr/share/inkscape/extensions/wikiupload.py", line 134, in ?
     main()
   File "/usr/share/inkscape/extensions/wikiupload.py", line 51, in main
     recent_edit=recent_edit)
   File "/usr/share/inkscape/extensions/wikiupload.py", line 92, in wikiput
     raise RuntimeError, "We weren't redirected - something went wrong!"
 RuntimeError: We weren't redirected - something went wrong!

So, the problem is that it’s thinking it’s supposed to send an application/octet-stream.

So, the script needs to be changed to use content-type:

 image/svg

I’ll see if I can do it the right way (via the mimetype lib,) and if not, do it the wrong way (just hack it.)

Well, this page seems no longer necessary. :)

Alas, it is still necessary, because people still have the perception that:

“the biggest reason I stuck to print is that I want people to mark up the book and fill it with their own experiments and drawings. I want them to engage with the content and enter into a true “visual dialogue” with me and the book. And the sad truth is that the interactivity that’s possible on the internet still does not come close to the friction-free, intuitive interface of a printed book, where you can underline, circle things, draw stick figures, dog-ear pages, etc.” -- "The unbook movement" dave gray

That’s fascinating, and I’m reading through that site; Fantastic.

:think: “Friction-Free.” That is what “Content Routing” is about – being FrictionFree?.

Define external redirect: BryceHarrington FrictionFree

EditNearLinks: MoinMoin

Languages: