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
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
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
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!
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
use-livecode mailing list
Please visit this url to subscribe, unsubscribe and manage your subscription