image images drawing scanner scanning process contentrouting process long boring
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:
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).
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?
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.
Let me make sure I understand right:
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.
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?
MoinMoin has this. I have three problems with it:
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
…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. 