"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<m...@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.
_______________________________________________
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
