Vector images?

[Brahmanathaswami]

"However it is important to remember that not everyone uses LiveCode to 
the same ends - there will probably be as many people on this list who 
would see SVG as a much lower priority than <insert feature which would 
help their particular problem domain and endeavours with LiveCode>."


With all due respect for the team, your business goals, roadmap and 
planning:

IMHO calling SVG "lower priority" this is again symptomatic of LC 
Headquarters/Leadership, not realizing how significant "the presentation 
layer" is  in today's world and this goes to the long delays in the 
image and media processing and delivery features we have been asking for 
nearly 15 years.

FIRST: At the upper end of the software business (think JP Morgan UX 
designers using Axure for prototyping) the whole world of software 
waking up to the how things work, there is a huge shift to the 
"discovery" process in a client/software vendor relationship. This also 
includes how things are done in house.  This also goes to the Agile mode 
of development.  I (we) have to build a prototype of things to show 
people whose response is going to be highly "biased to the presentation 
layer of the "product"  and this has to be done "now" at the beginning 
of the cycle.
and that whole "up front" design process is built on images, sound and 
video with no code.

The consensus "get your front end clarified, signed of on by stack 
holders first *then* start coding" is very broad.

if we cannot include vector graphs in the mix  from the get go, then 
Livecode is seen as incompetent for the job, even it that job may be, 
later, a full enterprise suite of tools for management, database, global 
business etc.

So, excuse me for saying it, but I think it is a seriously flawed 
concept to think that LC's, graphics, audio and video layers are somehow 
second place in the over all scheme of what you need to do to make LC 
successful in the future.

I do, really, have, on my team a UX designer for JP Morgan, and if I 
were to ask her to play with LiveCode and she not could easily import 
Vector graphics, or show video on all platforms easily;  she would have 
to tell her boss that "Livecode will useless for our 1/2 million dollar 
business project, we have to choose another platform."


SECOND: low end market: Richmond's "kiddie" world = 100,000's potential 
adopters of the community platform at a very young age (I have a real 
case here where I encouraged this man to have his grandson try LC to 
learn programming) But as soon as the kid discovers he cannot import any 
vector graphic of "Garfield the Cat" from his clip art web world... he 
will ask his grandfather to suggest some other platform.


Ergo, please [my old, old rant] do not underestimate the importance of 
the media delivery requirements, or think these are somehow "different" 
from your business requirements. Yes, they may be for some client like 
the water works of Seattle, but that is a small subset of your potential 
future adopters through all levels, from million $ enterprise... all the 
way down to teachers deciding "what shall I get for my class to  use to 
tinker with code"

If the media delivery channel of the product (images, all formats, 
video, sound) is sub par... you are out of the running on day one.

BR

Mark Waddingham wrote:
> On 2015-10-21 16:53, Terence Heaford wrote:
>>> On 21 Oct 2015, at 10:28, Mark Waddingham<mark at livecode.com>  wrote:
>>>
>>>   It is very similar to CoreGraphics (but actually has a number of
>>> features beyond which CG offers). e.g.
>>>      MCGContextCreate(->  myContext)
>>>      MCGContextSetRGBAFillColor(myContext, 1, 0, 0, 0.5)
>>>      MCGContextAddRectangle(myContext, [0, 0, 400, 400])
>>>      MCGContextFill(myContext)
>> Does this not do it? or similar?
>>
>> -(void) drawRect: (CGRect) rect
>> {
>>      CGContextRef context = UIGraphicsGetCurrentContext();
>>
>>      UIColor * redColor = [UIColor colorWithRed:1.0 green:0.0 blue:0.0
>> alpha:1.0];
>>
>>      CGContextSetFillColorWithColor(context, redColor.CGColor);
>>
>>      CGContextFillRect(context, self.bounds);
>> }
>>
>
> Yes - that would be the CG API version of the LibGraphics API - I did
> say it was similar :)
>
> I wasn't suggesting that ssmple code example was an example of features
> LibGraphics has which CoreGraphics does not (although I can see how it
> could be read like that - oops).
>
> LibGraphics incorporates various features relating to bitmap effects in
> its API. CoreGraphics only has 'drop-shadow' abilities - LibGraphics
> does the whole stack of bitmap effects you see exposed via the
> bitmapEffects property. It also has a number of gradient types which
> CoreGraphics does not support.
>
> Eventually LibGraphics will (hopefully) have APIs added to enable the
> range of filter processing operations SVG allows - in order to expand
> SVG support in the future (again, something CoreGraphics does not have).
>
> Warmest Regards,
>
> Mark.
>