Related page ... [Adding images to local mode wikis] ---- ''There are two issues: getting the image to show up in the HTML, and fetching the image and store it locally for when the wiki is used in local Tk mode. That last one is slightly trickier, because of the need to re-check and update somehow, and to clean up images which are no longer being used. Nothing earth-shattering, but that sort of explains why it's not there yet... -jcw'' As for inline images: they work now... [http://www.equi4.com/images/wikit.png] [Bryan Oakley] writes... perhaps one solution is to have a special wiki page for managing images. Much like there is a magic "recent changes" page and "search" page, there could be an "images" page. It could present a list of known images with buttons to resubmit, rename or delete. And, of course, a New button. This page would be easy to write in the Tk version, and in the HTML version could be done using forms. Another issue is how to represent embedded images in the markup. One suggestion is to overload [] with some additional markup. So, for example [[[[MyImage]]] or [[:MyImage:]] would embed MyImage. Of course, if you added the restriction that images share their namespace with pages, and thus you can't have page and an image with the same name, a simple [[MyImage]] would suffice, as the software would know that it is an image and Do The Right Thing. FWIW, some of the users of my personal wiki are also asking for this feature. What's the liklihood of it happening in the near future? ---- Thanks JC! Of course, now we need a little control over it so we can wrap text properly around images (and conversely be able to stop wraps). - DL ''To avoid wrapping, save as: text - empty_line - bracketed_image_url - empty_line - text'' -jcw ---- It would also be nice to have an option to turn ''off'' inlining. For example, I may actually want to create a link to an image versus inlining it. How hard would it be to overload [[]] somehow; for example, maybe to inline an image we do [[]], so that [[.http://...foo.gif ]] does what it does now (I had to add a dot before the http, or wiki would have changed it to a ref even though I doubled up on the [['s) Sheesh, we're not picky :-) --[Bryan Oakley] ''Sheesh, you said it... :o)'' That's why I avoided image inlining of URL's mentioned ''without'' brackets: http://www.equi4.com/images/wikit.gif ... isn't that good enough? -jcw 'Nother comment: lest you think I'm making this convention up as we go... not so, this was in one of the other wiki designs I looked at (long ago, don't ask mw which one, please). ---- (July 17, 2000) I've been mucking about in the code, trying to figure out how to support storing images in the wiki database. That part I've figured out, and I've learned in the process that metakit is pretty cool. I figured out how to create a "view" for images (ie: a database table), and how to insert and extract the data. I've also figured out how to get wikit to serve images which have their raw data stored in the wiki database. What I'm struggling with is how to seemlessly integrate my changes into the wiki code base. The data path through the code isn't exactly obvious :-| ''(You were so kind to leave my name out, but I'll confess that is really is a bit messy and way too complex - all I can say is that it was written when I knew less about Tcl than I do now... JC)'' Anyway, what I'm thinking is that images should work pretty much like normal pages in that if you embed a reference to an image that doesn't exist you'll get a special "look" (I'm thinking of a special "unknown image" -type image). Click on it and it takes you to a page to edit the image. Only, instead of a text area you get a file input button. I think I've figured out how to do forms within the wiki, so to some degree it's just a matter of putting it all together. The only sticky point (I think...) is that throughout the code the wiki kinda assumes everything it serves is text -- there's no real provision for passing around the page ''type'' in addition to the page ''data''. So, support for self-contained images might be a slight hack. Perhaps once I get it done JC can better integrate it with his stuff.. [[time passes]] Hmmm. I'm almost of the opinion this won't be a very big hack afterall. I can just add special processing in the final rendering of the page based on the name of the page. if it's a .gif, .jpg or .png we simply inline the image. For editing, instead of a textarea we get a file submission box. Hmmmmm.... sounds simple. I'm motivated to make this work and ''might'' have an afternoon to see what I can do. Stay tuned. --[Bryan Oakley] ''Thanks Bryan, for persevering - I am tracking every move you make and will try to help where possible. True: WiKit was never written with forms in mind... (nor even images, to be honest) -- JC'' ---- ok, here's a question: should the image data be stored in the same field in the database as a page (ie: in the pages view) or in its own table? I see that the pages view uses a type of "memo" rather than "binary", but image, I would think, should use "binary"? I'm leaning toward a separate table, which is what I have now. I'm tossing about the idea of having a text page for every image, so something like [foo.gif] would be synonymous with, say, 99.html (the text page, with the image instead of a bunch of text, but with the same links at the bottom to edit, expand, etc. Though it could *also* have text, such as random notes by the person who added the image). A reference to 99.gif would serve the actual image itself (so, internally, the code generated would look like ). There would also be a record in the "images" view with a name of "foo.gif" (and/or 99 as a sort-of foreign key). Sadly, I've run out of free time to work on it, but I still have it back-burnered. I have a proof-of-concept working (I can view and edit images) but it's too hackish. I need to reimplement it before making it public. ---- JC: please use a separate table/view, that way WiKit's text searches will not be affected. As for (M) vs. (B) - these are semantically equivalent (M is better for large amounts of data, but the latest MetaKit 2.3.x now decides itself how to store data - M is about to be deprecated, everything will eventually be converted to B). I suggest keeping image storage very minimal: i.e. no text, since that can be handled by existing Wiki mechanisms (let people add comments *around* the image, on a normal wiki page) and benefits from all the infrastructure there is already. Perhaps a view with just name and image? The "name" could be the entire URL, to avoid problems with duplicate image names. In a way, this name/URL + image-data view then becomes nothing more or less than a cache (maybe a date could be added - note that MetaKit makes it easy to add such extra fields later). Taking this idea further, the wiki page could continue to contain the URL it currently holds - the cache would merely cause the generated HTML page to refer to another wiki page, of the special form "N.{gif,png,jpg}", perhaps. ''I agree completely -- I've already got the image view with the two'' ''fields you suggest, and it is working just dandy. We'll see how '' ''this turns out...'' ([Bryan Oakley]) The benefit and purpose of all this is that the one-file wiki becomes self-contained w.r.t. images as well, and that it would not be hard to support local Tk display as well, right? ''Right.'' ([Bryan Oakley]) For a very different approach to self-contained scripted documents with HTML and embedded images, see [http://www.equi4.com/pub/dok/README] - it is based on Richard Hipp's [Tkhtml] widget. I'm mentioning it, because it could be a way to make WiKit properly support HTML locally one day. ---- '''-EE''' (2001/Jun/14) Corrected the URL reference to ''dok''. Do any of the people who held the above discussion (nearly a year ago) feel like summarising the current state of affairs? '''June 2002''' - another year later: yep, I agree - this needs to be summarized. The development of wikit has picked up again, but the discussion is being moved over to the tclerswiki mailing list at Yahoo Groups, and to the wikit home site [http://www.equi4.com/wikit/]. Inline views are there now, inline storage is planned. Storage of tabular data is high on my wish/todo list, using MK's relational table views and operators. But it needs more thought and mindshare before churning out the code to implement it, IMO. -[JCW] ---- [Category Wikit]