This is good news!! Is there any reason not to call the control “SVG?” Why create another abstraction in the name from what the control actually is?
e.g. Set the fileName of SVG “My Picture” to …. Tim Bleiler, Ph.D. Instructional Designer, HSIT University at Buffalo > On Nov 3, 2017, at 9:19 AM, Mark Waddingham via use-livecode > <firstname.lastname@example.org> wrote: > > Hi all, > > My most recent talk at LCG (in October) was 'Building an SVG Widget' and in > order to talk about such a thing, I needed to actually build one - so I did :) > > So, we are now firmly on the road to full SVG support in LiveCode! > > At the moment the implementation only supports geometric shape tags, paths, > and solid color fills. However, it supports the standard fill/stroke > attributes and should work with any SVG file - anything which isn't supported > just doesn't get rendered (so you have a modicum of graceful degradation in > terms of features). In particular, you don't need to preprocess your SVG file > to pull out incompatible tags / attributes, or just extract the path (as you > do for the SVGIcon widget). > > The current implementation successfully renders quite a wide range of simple > SVGs (simple in the features they use, rather than how they look!). Indeed, > it happily renders the (quite widely known) Tiger and Lion SVGs, and has been > tested on quite a few random SVGs I managed to find on Wikipedia. It is > certainly more than capable if you want to use simply coloured multi-path > SVGs. > > LCG attendees got a prototype of a widget to play with - called vectoricon - > and integrating this initial version this into the product has now got to the > top of my work-list :) > > The principal thing which I'd like some feedback on right now is the name of > the widget/control - I think we have a good one, but wanted to see what you > all thought before committing us to it forever and a day. > > Before getting to that though, I should perhaps explain what a potential path > for the evolution of this new feature in LiveCode could look like. > > SVG as a concept allows arbitrary collections of vector shapes, images and > text to be represented in a single high-level way as XML - in particular, you > can express geometric shapes, raster images and text all in one unified form. > > Previously we had proposed producing a 'shape' object which would be a > 'graphic object on steroids' - allowing affine transformation, higher > fidelity specification of geometric objects and groups of them; providing an > 'svgText' interface similar to htmlText on the field. Essentially, the > proposed 'shape' object would have used a subset of SVG to allow easy > interchange of what it represents. > > That notion of 'shape' object (and thus the current 'graphic' object) can be > subsumed into the SVG implementation in an obvious way - if you ask your SVG > object to be a rectangle, it creates (notionally) the SVG for a rectangle > internally and uses that - which you would see via the svgText. > > Similarly, as SVG can represent raster images too, we can fold the current > behavior of the 'image' object into it to - in a similar way. > > The end result here would be a single object which is a generalization of two > existing objects - image and graphic - but without the > backwards-compatibility baggage we currently have. > > In terms of using this new object in a consistent way to our current model, > we propose (subsequently) to generalize the types of objects which can be > referenced by imageSource and icon properties - allowing them to use any > object which 'knows how to be used as an icon'. Currently, only the image > object has this knowledge - but we can extend to other objects by getting > them to implement the appropriate internal interface. This would mean that > you could just replace the images you use currently for icons and such, with > the new control which supports SVG and use SVG instead. > > Given the potential future path of this particular feature, we also propose > to eventually give it an actual control type - rather than widget (although > it will still be a widget). i.e. We think it is has such future potential > that being able to do '<noun> "foo"' in script will be very useful (this is > almost a requirement if it is to eventually 'replace' the image and graphic > objects). [ Note: we have also been considering this for the browser widget > too! ]. > > Thus with all that in mind - we are proposing 'picture' as the name of the > new SVG capable control, with the following ideal roadmap: > > a) we would integrate the 'prototype' implemented for SVG as > 'com.livecode.widget.picture' > > b) we would add a 'picture' noun to the language as the control type for > that widget > > c) we would add icon reference support, allowing it to be used in place of > an image > > d) we would add graphic-like shape properties, allowing you to use it in > place of a graphic > > e) we would add support to the image tag in svg, and image-like image > properties, allowing it to be used in place of an image > > f) we would gradually expand support for the range of SVG it can directly > render (gradients and layers are high on the hit list here) > > In terms of timescale, we are currently looking at delivering 'just' (a) for > 9.0 (although I do have my eye on at least (c) too - we'll have to see how > other things we still need to finish for 9 go). The rest all break down into > bite-sized chunks which I'd hope we could iterate on it periodically after > that. > > It goes without saying that we are interested in any and all feedback you > might have on this idea; however, right now, our top priority is naming. > > As I said above 'picture' is our current top (and perhaps only!) contender - > it says what SVG does (it represents pictures of things), can subsume the > idea of image and graphic naturally, and is human-friendly. It is also a > single word which is a current requirement if it is to be used as a chunk > noun (like 'image', and 'graphic' etc.). > > I look forward to reading any feedback you might have! > > Warmest Regards, > > Mark. > > -- > Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/ > LiveCode: Everyone can create apps > > _______________________________________________ > use-livecode mailing list > email@example.com > Please visit this url to subscribe, unsubscribe and manage your subscription > preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode _______________________________________________ use-livecode mailing list firstname.lastname@example.org Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode