A native svg object that accurately displays all svg files is essential. I strongly support Mark's point on that issue. This is not reinventing the wheel - it's attaching the already invented wheel to the wagon.
Sent from my iPhone > On May 31, 2017, at 4:26 AM, Mark Waddingham via use-livecode > <use-livecode@lists.runrev.com> wrote: > >> On 2017-05-31 09:01, Dan Brown via use-livecode wrote: >> I'll also add that for all the wonderful possibilities that LCB brings >> there is a very real danger that countless hours will be spent using it to >> re-invent the wheel. > > That is true of every language ever implemented ;) > > However, one of the goals of LCB is to allow it to be used as the 'glue' > language allowing LiveCode Script to access 'things written in other > languages' with (eventually) as much syntactic fidelity as you get with > builtin-in engine functionality. Hopefully, reducing the need to re-invent > the wheel to the minimum required to make other-world libraries look more > LiveCode like. > > i.e. One of its main goals is to rid ourselves of the need to 're-invent the > wheel'. > >> Take for instance the displaying of svg's. This is a solved problem in the >> browser and has been for a long time but in native livecode it's still in >> the infant stages of implementation (to put it mildly). The best solutions >> for user interface "widgets" are arguably being created in the form of >> javascript libraries. To me it makes total sense to integrate with that >> ecosystem and free up LCB / livecode developer hours for solving other >> problems > > True - but then if I want SVG icons in my app, and I don't need the browser > widget at all then I might balk at the 70-100Mb bloat I have to add to > Windows / Linux apps to get it. Furthermore, I might balk at the start up > time of my app on mobile devices, whilst I use the browser widget to load all > my SVGs and render them into PNGs at various sizes (unless you instantiate a > browser widget for every SVG icon you want to use and want to put up with the > restrictions that places on you, and the overhead in terms of use). > > Certainly we need to be careful about 're-inventing the wheel' but that just > means making good choices. In this case, the case for 'native' SVG support in > LiveCode is overwhelming - the more lightweight it is, the faster it is, the > more utility it has. (Also, the main problem here is 'SVG as a replacement > for PNG icons' which is a much smaller problem to solve than an editable SVG > canvas - which is what you get if you go the via-browser route). > > In terms of JavaScript 'widgets' in general, then we already have a > reasonable strategy for using them now - you use a browser widget and load it > in there. For example, FileMaker has a BrowserView element and there is a > plugin 'React' which allows you to defined JavaScript controls and have them > rendered in the browser. Admittedly using such things is a little trickier > than we'd like at present - due to the lack of synchronous 'do as javascript'. > > Anyway, I agree that using existing libraries and code as much as possible is > probably the best way to expand LiveCode's capabilities - hence LCB :) > > Warmest Regards, > > Mark. > > -- > Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/ > LiveCode: Everyone can create apps > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.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 use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
