Jake --- In [email protected], Jacob Beard <jbeard4@...> wrote: > > I agree, it can be a pain to do with SVG 1.1, but it is possible. > > carto.net has had some example of textbox widgets since a long time: > http://www.carto.net/papers/svg/gui/textbox/
Argh! Thank you for reminding me. I had forgotten all about that stuff at carto.net They were very busy folks. It looks a bit long and ugly, but doing it in C would be too :-) > > Lively kernel rolled their own multi-line text editor for editing code: > http://www.lively-kernel.org/ I've seen this, but I don't feel my JavaScript is good enough to get to grips with it. I am doing this SVG+JavaScript project to sharpen my understanding so that I *can* do that kind of stuff :-) > > And it just so happens that I've also been working on an SVG-based text > editor for a course project this semester. I haven't released it yet, > but probably will in the next week or two. I'm still deciding how to > license it. Is your application something that would be compatible with > the GPL? At the moment, it is primarily a vehicle to focus my efforts to get to lively-kernel quality, or OMeta-quality JavaScript'. It is secondarily a demo for some folks. For this sort of stuff, I think in terms of CC-BY-SA-NC (do what you like, except try to make money from my efforts) > > I actually don't think your requirements would be too difficult to > implement. Here are my thoughts: Okay! > > > On 11-01-19 02:37 PM, th_w@... wrote: > > > > > I would like to stretch the shape as they type reach character if > > the text they are entering is approaching one of the other fields on > > the shape, or the edge of the shape. I'd like to shrink the shape, if > > they rub out a character. They should be able to click into the middle > > of the text, and drive left and right with the cursor keys. I don't > > need to support tabbing from one field to the next. > > > > My experience has been that keyboard handling support is good in all of > the major browsers (although I haven't tried IE), so I think you won't > have any trouble attaching listeners and receiving events for each of > the text elements. Good. That would kill the whole idea otherwise. > To resize your shapes, you would basically just get > the bounding box of the text (using element.getBBox()) after every > keyboard event, and then dynamically alter the path, as you suggested, > or simply scale the shape. I can't scale the shapes. They are somewhat like interlocking jigsaw pieces, and scaling would break the interlock. I need to either change the path 'd' attribute dynamically, or carve each whole shape into multiple fragments so that I can scale, or more easily adjust, the piece which grows. I might try both. I am very curious how easy it will be to parse and decompose the path 'd' attribute, and how well it performs. > > You would, however, need to roll your own cursor, I assume there is a glyph which looks like an I beam insertion point. > keep track of its position Yes > and update its representation in DOM on left and right > keypresses. Yes > You would also need to map its position to the index of the > text element's textContent property, and use that to indsert or delete > characters. Yes It was a Looooong time ago, but in principle, I think I can do that because I have done it before (in C++ and Java). > > > > > > > > The shape is quite complex, so expanding or shrinking while they > > type may need the path 'd' attribute value to be changed dynamically. > > Is that an okay idea, or do I need to try to design the shapes' > > geometry to avoid it? > > > I think this depends on what you're trying to represent, and how complex > you want the math to be when updating the shape. An easy way out might > simply be to scale the shape such that its bounding box encompasses the > text's bounding box. This would be very easy to implement. Sadly that would make the shape too big 96% of the time (approximately :-). I can carve it into 'strips' vertically, and adjust the trapezoid or rectangle that needs to grow with the text, them splice that back into the path. I can leave it as separate SVG elements for now, but I am worried that filters won't 'tile' seamlessly later, and the edges of abutting, adjacent elements would be visible, when I want to add filter effects later. Maybe you or someone knows if that is a real concern? If filters *ALWAYS*, or some subset of filters *ALWAYS* produce seamless results when applied to a group of SVG elements, then I can make each shape from, maybe a dozen 'tiles', and just adjust the few that contain 'live' text > > > > > > > I'd also like to support drop-down lists around the text input (for > > 'standard values' or their most recent entries) > > > Again, you would need to roll this widget from scratch, or use an > embedded HTML menu inside a foreignObject. Okay. > > > > > > > > Would someone please point me at the stuff I should be reading or > > googling-for to understand the available approaches to text input? > > Simple searches like "SVG text input" doesn't seem to find anything > > helpful. > > > Take a look at the spec: > > http://www.w3.org/TR/SVG11/text.html > > Especially the scripting interfaces: > > http://www.w3.org/TR/SVG11/text.html#DOMInterfaces Okay. I guess I was hoping I had missed something about text input :-( (Some of the pieces of spec sometimes pop-up in their own documents) okay, getComputedTextLength looks like a place to start (and a few others) Good. > > > > > > > > Do I need to handle every key stroke myself, or are there some > > helper mechanisms that I can hook into? For example, when I used to do > > X-Windows stuff, editing could be handled by a widget, but it was > > possible to look at every character too (both before and after the > > widget saw it, I think; 19 years ago, so I may be wrong). > > > You need to handle every stroke yourself. I'm not aware of a > higher-level mechanism, and I'm also not aware of any developer-facing > GUI libraries that people have written around this low-level mechanism. Interesting. I had assumed this was such a common requirement that there would be libraries somewhere, and I was too ignorant to know that magic google-fu incantation. > > > > > > > > I'd like to get reasonably wide deployment (when Firefox 4, and IE9 > > arrive). > > > Should I be constraining myself to SVG 1.1, and ignore the SVG 1.2 > > (I see that 1.2 seems to have editable text support)? > > > > You will need to constrain yourself to SVG 1.1. Okay. That is critical information. Thank you. > Unfortunately, while SVG > 1.2 does include support for editable text, I think that of all the > browsers, currently only recent versions of Opera supports it. I have to > say though, it's very impressive. They have a demo where you can edit > text on a spiral path. Very cool stuff. That does sound fun. I'll go find that. Presumably, the text can have filters applied too, so the glyphs can look quite active as characters are added/deleted :-) > > > > > > > Or, should I be using XHTML too, and abandon a pure SVG approach? > > > Speaking from experience, if you don't need multiline text editing, I > think you can put together a basic SVG text input widget in less than a day. Okay! It will take me longer (I only started learning this stuff a couple of weeks ago) But that order of effort is fine > > However, using HTML would probably be less work, overall. HTML gives you > text input widgets, which is certainly at a higher level than what SVG > gives you. The thing I'm not sure about is whether it will be possible > for you to get a proper bounding box from the embedded HTML text input > element. That was concern. I have seen some stuff done using a similar technique, and words twitch and change as the text converts to input field and back again. Perfectly usable, but very occasionally looks disconcerting. > This is probably something you would want to prototype. This is all prototype at the moment - "Plan to throw (at least) one away" :-) Thanks again for your help. This is a very helpful forum. I am pleased I stumbled across it!-) Take care, GB-) > > Good luck! > > Jake > > > [Non-text portions of this message have been removed] > ------------------------------------ ----- To unsubscribe send a message to: [email protected] -or- visit http://groups.yahoo.com/group/svg-developers and click "edit my membership" ----Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/svg-developers/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/svg-developers/join (Yahoo! ID required) <*> To change settings via email: [email protected] [email protected] <*> To unsubscribe from this group, send an email to: [email protected] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
