Re: Players in HTML5 - ETA for Full Functionality?

[Terry Judd]

On 2/03/2016 9:28 am, "use-livecode on behalf of Peter TB Brett"
 wrote:

>
>
>On 01/03/2016 22:17, Peter TB Brett wrote:
>> On 25/02/2016 06:28, Terry Judd wrote:
>>> Apologies for hijacking this thread somewhat but Peter could you
>>>possibly
>>> comment on the likelihood of clipboard support being added to HTML5 in
>>> the
>>> near (or middle) future. I understand there are potential security
>>> concerns around use of the clipboard but it would be good to hear your
>>> thoughts on how these might be accommodated (or not).
>>
>> It basically depends on two things:
>>
>> 1) A suitable JavaScript API being available in browsers
>> (http://caniuse.com/#feat=clipboard).  Since I first started looking at
>> HTML5 support, this aspect has actually come on leaps and bounds.  Using
>> the appropriate HTML5 JavaScript API, correctly, should
>
>Note in particular, from the website I've linked above, that many
>browsers won't provide "paste" at all, or won't provide it without a
>focussed, editable HTML form text field.  These are a the security
>considerations I mentioned previously.

Thanks for the explanation Peter - in my case I¹m looking to paste a
simple report (plain text) into an editable text field on another page, so
possible at least.

Regards,

Terry...


___
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

Re: Players in HTML5 - ETA for Full Functionality?

[Peter TB Brett]

On 01/03/2016 22:17, Peter TB Brett wrote:

On 25/02/2016 06:28, Terry Judd wrote:

Apologies for hijacking this thread somewhat but Peter could you possibly
comment on the likelihood of clipboard support being added to HTML5 in
the
near (or middle) future. I understand there are potential security
concerns around use of the clipboard but it would be good to hear your
thoughts on how these might be accommodated (or not).


It basically depends on two things:

1) A suitable JavaScript API being available in browsers
(http://caniuse.com/#feat=clipboard).  Since I first started looking at
HTML5 support, this aspect has actually come on leaps and bounds.  Using
the appropriate HTML5 JavaScript API, correctly, should


Note in particular, from the website I've linked above, that many 
browsers won't provide "paste" at all, or won't provide it without a 
focussed, editable HTML form text field.  These are a the security 
considerations I mentioned previously.


  Peter

--
Dr Peter Brett 
LiveCode Open Source Team

LiveCode 2016 Conference https://livecode.com/edinburgh-2016/

___
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

Re: Players in HTML5 - ETA for Full Functionality?

[Peter TB Brett]

On 25/02/2016 06:28, Terry Judd wrote:

Apologies for hijacking this thread somewhat but Peter could you possibly
comment on the likelihood of clipboard support being added to HTML5 in the
near (or middle) future. I understand there are potential security
concerns around use of the clipboard but it would be good to hear your
thoughts on how these might be accommodated (or not).


It basically depends on two things:

1) A suitable JavaScript API being available in browsers 
(http://caniuse.com/#feat=clipboard).  Since I first started looking at 
HTML5 support, this aspect has actually come on leaps and bounds.  Using 
the appropriate HTML5 JavaScript API, correctly, should


2) Someone who's comfortable simultaneously working in 3-4 different 
programming languages having time to hook it up to the LiveCode engine.


  Peter

--
Dr Peter Brett 
LiveCode Open Source Team

LiveCode 2016 Conference https://livecode.com/edinburgh-2016/

___
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

Re: Players in HTML5 - ETA for Full Functionality?

[Peter TB Brett]

On 25/02/2016 19:23, Matt Maier wrote:

That was too abstract and hypothetical for me to be sure I followed
correctly.

In the approach the Livecode team is taking now, is it accurate to say that
the html5 standalone bundles up the livecode engine with any app-specific
objects/scripts and pushes the whole thing into the client browser, such
that all of the (supportable) functionality runs client-side?


Just to clarify: yes, that's exactly correct.

  Peter

--
Dr Peter Brett 
LiveCode Open Source Team

LiveCode 2016 Conference https://livecode.com/edinburgh-2016/

___
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

Re: Players in HTML5 - ETA for Full Functionality?

[[-hh]]

> BR wrote:
> This could work for me also. I think that we are talking about
> Javascript interactions ... 

It's all said, but not yet by all ... ;-)

"Es ist schon alles gesagt, nur noch nicht von allen."
(Karl Valentin)

___
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

Re: Players in HTML5 - ETA for Full Functionality?

[Robert Mann]

supporting the company. 
Maybe I'm just strange. :)

No dirk, you're not strange to me :: we share exactly the same feeling that
goes back to the earlier times of HYPERTALK. We like the idea of supporting
such a more approachable language.
And we're still humans, reacting with emotions and particularly when we
spend time with a tool, language to program a few things we come to think
about in our dreams.


   **   * 

Regularly, the startups of the silicon valley have the blues :: there are
regular waves of hopes huge investments in view of a revolution followed by
dis-investment.
The yearly license is one of these recent revolutions/trend :: every new
apps gets into the license renewal train. But nobody knows for sure how that
will live up.

it's a bold trend because in effect it cost a lot more to the
"normal/standard"  customer.. ( the super super geek volatile astute geek
can find it interesting with a little bit of planning) so in a while people
will realize, and use less and less apps, or only open sourced and prefer to
sponsor open source.
So there could feel be a kind of boomerang cutting down the great revenues
expected from yearly licenses.

So it could be wise to think more in terms of EVOLUTION and try out new
schemes without getting rid of the old things which somehow did work.

Now, if livecode mothership (or fathership rather!) does not want us to be
around, no problem :: thanks, time and NRJ is the most precious thing we
have. And can be used for other causes than live code. Love affairs have
their endings.



--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Players-in-HTML5-ETA-for-Full-Functionality-tp4700852p4701606.html
Sent from the Revolution - User mailing list archive at Nabble.com.

___
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

Re: Players in HTML5 - ETA for Full Functionality?

[J. Landman Gay]

I think your attitude is noble. I would encourage you to donate an 
affordable yearly amount for the community version. That way you have 
supported the company according to your conscience and the company receives 
funds to increase their productivity.


In fact, I would hope anyone who takes advantage of the OSS edition would 
give at least a little something, whether that is money or software 
contributions. That is how it is supposed to work.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com



On February 26, 2016 6:35:47 PM Dirk prive  wrote:


Yes, you got it exactly right. I think the community version is fine, but I
like the company and the idea behind the product. That is why I have been
paying for this for all this time. I can afford 999$/yr, so the company
will lose a sale. Not just one sale, but a yearly sale. Don't forget I kept
up to date since 2007. It'll be strange to not pay and use the community
version, since that really is not how I want to use the product. I actually
prefer supporting the company.
Maybe I'm just strange. :)

Dirk Cleenwerck.
On Feb 26, 2016 21:15, "J. Landman Gay"  wrote:


On 2/26/2016 1:38 PM, stephen barncard wrote:


I don't understand why the OSS version won't work for you if it's a
'hobby'
thing



I understand what he means. The OSS version would work fine, but that's
not the point. His point is that he thinks LC is losing money from those
who would like to contribute by purchasing a license at a reduced rate
(possibly restricted to personal use only, or something similar I'm
guessing.)

It isn't that there is no path forward, but rather that he thinks the
current licensing model is costing the company some sales. I don't know if
that's true or not, I'm just playing interpreter.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
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




___
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

Re: Players in HTML5 - ETA for Full Functionality?

[Dirk prive]

Yes, you got it exactly right. I think the community version is fine, but I
like the company and the idea behind the product. That is why I have been
paying for this for all this time. I can afford 999$/yr, so the company
will lose a sale. Not just one sale, but a yearly sale. Don't forget I kept
up to date since 2007. It'll be strange to not pay and use the community
version, since that really is not how I want to use the product. I actually
prefer supporting the company.
Maybe I'm just strange. :)

Dirk Cleenwerck.
On Feb 26, 2016 21:15, "J. Landman Gay"  wrote:

> On 2/26/2016 1:38 PM, stephen barncard wrote:
>
>> I don't understand why the OSS version won't work for you if it's a
>> 'hobby'
>> thing
>>
>
> I understand what he means. The OSS version would work fine, but that's
> not the point. His point is that he thinks LC is losing money from those
> who would like to contribute by purchasing a license at a reduced rate
> (possibly restricted to personal use only, or something similar I'm
> guessing.)
>
> It isn't that there is no path forward, but rather that he thinks the
> current licensing model is costing the company some sales. I don't know if
> that's true or not, I'm just playing interpreter.
>
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
>
> ___
> 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

Re: Players in HTML5 - ETA for Full Functionality?

[Trevor DeVore]

On Friday, February 26, 2016, J. Landman Gay 
wrote:
>
>
> But we don't have any data to show whether the splash approach actually
> increased sales by much, or whether there are enough users who would buy a
> hobbyist version to warrant the development time.


Not to mention the marketing resources and support costs. It all factors
in.

-- 
Trevor DeVore
___
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

Re: Players in HTML5 - ETA for Full Functionality?

[[-hh]]

> Dirk wrote:
> I still hope that a niche can be created for the less demanding hobby
> group. Not all of us want to feel like freeloaders.

> jacque wrote:
> It isn't that there is no path forward, but rather that he thinks the 
> current licensing model is costing the company some sales. I don't
> know if that's true or not, I'm just playing interpreter.

> Peter H. wrote:
> I agree, I think that's what he means.  Wasn't there a personal use
> license at one point?  I seem to recall that standalones built with it
> displayed a splash screen for 10 seconds at startup.

That's it (whether the possible solution reminder or not).

** I think moreover, that Dirk is right with that consideration. **
The company loses additional available money.
In economics, more exactly in microeconomics, this is a pricing strategy,
called "price discrimination".

___
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

Re: Players in HTML5 - ETA for Full Functionality?

[J. Landman Gay]

Yes, there used to be an edition like that. Graphic Converter made a lot 
of sales by forcing a 10-second splash on its free version. It was just 
annoying enough. Many mobile apps force ads on the user, which is even 
more annoying, but that may be going too far.


But we don't have any data to show whether the splash approach actually 
increased sales by much, or whether there are enough users who would buy 
a hobbyist version to warrant the development time.


On 2/26/2016 2:24 PM, Peter Haworth wrote:

I agree, I think that's what he means.  Wasn't there a personal use license
at one point?  I seem to recall that standalones built with it displayed a
splash screen for 10 seconds at startup.

On Fri, Feb 26, 2016 at 12:15 PM J. Landman Gay 
wrote:


On 2/26/2016 1:38 PM, stephen barncard wrote:

I don't understand why the OSS version won't work for you if it's a

'hobby'

thing


I understand what he means. The OSS version would work fine, but that's
not the point. His point is that he thinks LC is losing money from those
who would like to contribute by purchasing a license at a reduced rate
(possibly restricted to personal use only, or something similar I'm
guessing.)

It isn't that there is no path forward, but rather that he thinks the
current licensing model is costing the company some sales. I don't know
if that's true or not, I'm just playing interpreter.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
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




--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
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

Re: Players in HTML5 - ETA for Full Functionality?

[Peter Haworth]

I agree, I think that's what he means.  Wasn't there a personal use license
at one point?  I seem to recall that standalones built with it displayed a
splash screen for 10 seconds at startup.

On Fri, Feb 26, 2016 at 12:15 PM J. Landman Gay 
wrote:

> On 2/26/2016 1:38 PM, stephen barncard wrote:
> > I don't understand why the OSS version won't work for you if it's a
> 'hobby'
> > thing
>
> I understand what he means. The OSS version would work fine, but that's
> not the point. His point is that he thinks LC is losing money from those
> who would like to contribute by purchasing a license at a reduced rate
> (possibly restricted to personal use only, or something similar I'm
> guessing.)
>
> It isn't that there is no path forward, but rather that he thinks the
> current licensing model is costing the company some sales. I don't know
> if that's true or not, I'm just playing interpreter.
>
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.com
>
> ___
> 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

Re: Players in HTML5 - ETA for Full Functionality?

[J. Landman Gay]

On 2/26/2016 1:38 PM, stephen barncard wrote:

I don't understand why the OSS version won't work for you if it's a 'hobby'
thing


I understand what he means. The OSS version would work fine, but that's 
not the point. His point is that he thinks LC is losing money from those 
who would like to contribute by purchasing a license at a reduced rate 
(possibly restricted to personal use only, or something similar I'm 
guessing.)


It isn't that there is no path forward, but rather that he thinks the 
current licensing model is costing the company some sales. I don't know 
if that's true or not, I'm just playing interpreter.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
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

Re: Players in HTML5 - ETA for Full Functionality?

[Terence Heaford]

> On 26 Feb 2016, at 19:38, stephen barncard  
> wrote:
> 
> The Community version is NOT  a 'weenie' or 'light' version - mainly it's
> the licensing and code protection that's different.


Would someone enter this as a reminder somewhere, to be revisited in 12-18 
months?

I’m thinking:

A add on cost for some “Professional!” widgets/extensions produced by 
LiveCode or not available in the community version.

If for example (and this is why I said revisit in 12-18 months) a fantastic 
DataGrid widget is produced and it becomes a paid add on,
otherwise your stuck with the existing solution then I would deem the community 
version as “light"

I suppose I’ll have to be patient and wait and see.

All the best

Terry
___
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

Re: Players in HTML5 - ETA for Full Functionality?

[stephen barncard]

I don't understand why the OSS version won't work for you if it's a 'hobby'
thing (a term that seems belittling to me).
The Community version is NOT  a 'weenie' or 'light' version - mainly it's
the licensing and code protection that's different.
It's pretty clear that either one is selling the result of your work or one
is not... either / or.

Up-to-date? The OSS versions are continually keeping up with all the
improvements...and many come from the OSS community itself.

So what's the beef?

If one wants to be on the bleeding edge with LC... then one has to step up
to the plate...
but I doubt if you've mastered livecode to the point where you really need
the paid versions if you are experimenting
 what can you not build?

On Fri, Feb 26, 2016 at 10:41 AM, Dirk prive 
wrote:

> I still hope that a niche can be created for the less demanding hobby
> group. Not all of us want to feel like freeloaders.
>
> And yes, I can donate, but
>



Stephen Barncard - Sebastopol Ca. USA -
mixstream.org
___
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

Re: Players in HTML5 - ETA for Full Functionality?

[Dirk prive]

Ok, since I see that my point was hard to understand, I'll try to make it a
bit more clear.

I would be willing to pay about 300$/year to have a hobby programming tool.
I think that is good money the company could use. I don't expect some pro
features, for instance HTML, iOS,...

The cross platform tool I use for work every day costs 699$/yr and give me
a license I can keep using if I don't renew. It also gives me Web, iOS,
Windows, Mac and Linux. (32 and 64 bit). They have a single desktop version
for 99$/yr, a desktop target edition for 299$/yr, web for 299$/yr and iOS
for 299$/yr. That seems reasonable to me. Their tool is more mature than
LiveCode in my opinion, but as you can see does not support Android.

Since I love keeping up with platforms, I think it's important to also have
knowledge of Android, hence my support for LiveCode.

As you can see from my earlier description, this is not just empty talk.
Ive had a current license since 2007 and paid for quite a few things,
including the Kickstarter.

As a pro developer (but a hobby user of LiveCode) I know how important
income is to a company. 999$ is too much for what I use LiveCode for
though. I can't afford to pay that much/yr to support my hobby of learning
and keeping up with android. I can of course use the community version, but
I think that is a win for me and a loss for the company.

Just like you had  a hard time understanding me, I have a hard time
understanding why the company would not be interested in the money of the
hobby user. They don't have professional needs and don't require
professional support. It's good money for the company.

I responded earlier, because Robert had the same feelings as me. Livecode
is pushing away the hobby programmer. I find that sad.
I grew up with a ZX Spectrum (and just ordered the new Vega) and started as
a hobby programmer. We had enthousiasm and some of us grew into
professional programmers. Even in those days I paid for my tools.

I still hope that a niche can be created for the less demanding hobby
group. Not all of us want to feel like freeloaders.

And yes, I can donate, but a donation does not have the same feel as up to
date license.
I guess it all boils down to how I feel about it. You can't agrue with
feelings.
Unfortunately my feelings aren't worth 999$/yr.

I hope I expressed it a bit clearer now.
I'm actually surprised there have not been more hobby people to speak up
about this.

Kind regards,
Dirk Cleenwerck



On Fri, Feb 26, 2016 at 6:31 PM, Richard Gaskin 
wrote:

> Dirk Cleenwerck wrote:
>
> > Now the price of Indy will double to 999.
>
> Everything old is new again:  When I bought by MetaCard license it was
> $995 (and that was in 1998 dollars).
>
> I'd love it if the price were lower, but having been in the dev tools
> business myself I know it's a tough game:  smart people who demand a lot
> and for good reasons, but given the percentage of people in the gene pool
> inclined to find programming fun (and the subset of those who aren't, as we
> are, already so immersed in a language that switching to another is very
> difficult), the total addressable market isn't very large, at least not
> when compared to consumer software.
>
> If we were at a point more mature open source projects are, where we had a
> mix of giant corporate funders paying dev team salaries and a large pool of
> ongoing code contributions from the community, overhead would plummet and
> likely licensing fees along with it.
>
> But in the meantime we are where we are, and for commercial ventures the
> price still favorably compares with many alternatives, and is by far the
> smaller of many expenses needed to run a viable business.
>
>
> > The community version is nice and all, but you entirely miss the point
> > that you have hobby people that are willing to pay for a license, and
> > donations that don't give us anything are not an option either.
>
> I'm not sure I understand, esp. given:
>
> > PS: according to the GPL if the code is for your use only I don't
> > think you need to publish any source code at all. It's only when your
> > program is released externally that you need to release the source.
>
> That's true - as a distribution license, its terms apply only to works
> that are distributed.  And even then we're seeing an ever-growing number of
> projects choosing open source licenses in order to diversify and grow the
> code base to accommodate a wider range of use cases than the original
> developer could afford to support alone.
>
> Personally, I don't believe it's possible in the 21st century for any
> programming language to reach any sort of critical mass without being open
> source.  There are just too many FOSS alternatives; we haven't seen strong
> growth for proprietary languages since the '90s.  The very few that remain
> on the TIOBE list may be holding steady, but only for historical reasons
> unmatchable by any newcomer, and are not experiencing growth.
>
> 

Re: Players in HTML5 - ETA for Full Functionality?

[Richard Gaskin]

Dirk Cleenwerck wrote:

> Now the price of Indy will double to 999.

Everything old is new again:  When I bought by MetaCard license it was 
$995 (and that was in 1998 dollars).


I'd love it if the price were lower, but having been in the dev tools 
business myself I know it's a tough game:  smart people who demand a lot 
and for good reasons, but given the percentage of people in the gene 
pool inclined to find programming fun (and the subset of those who 
aren't, as we are, already so immersed in a language that switching to 
another is very difficult), the total addressable market isn't very 
large, at least not when compared to consumer software.


If we were at a point more mature open source projects are, where we had 
a mix of giant corporate funders paying dev team salaries and a large 
pool of ongoing code contributions from the community, overhead would 
plummet and likely licensing fees along with it.


But in the meantime we are where we are, and for commercial ventures the 
price still favorably compares with many alternatives, and is by far the 
smaller of many expenses needed to run a viable business.



> The community version is nice and all, but you entirely miss the point
> that you have hobby people that are willing to pay for a license, and
> donations that don't give us anything are not an option either.

I'm not sure I understand, esp. given:

> PS: according to the GPL if the code is for your use only I don't
> think you need to publish any source code at all. It's only when your
> program is released externally that you need to release the source.

That's true - as a distribution license, its terms apply only to works 
that are distributed.  And even then we're seeing an ever-growing number 
of projects choosing open source licenses in order to diversify and grow 
the code base to accommodate a wider range of use cases than the 
original developer could afford to support alone.


Personally, I don't believe it's possible in the 21st century for any 
programming language to reach any sort of critical mass without being 
open source.  There are just too many FOSS alternatives; we haven't seen 
strong growth for proprietary languages since the '90s.  The very few 
that remain on the TIOBE list may be holding steady, but only for 
historical reasons unmatchable by any newcomer, and are not experiencing 
growth.


LiveCode's dual-licensing seems to offer a good balance of interests, 
supporting serious commercial ventures with a rare scope of platforms 
and (really, check out the rest of the world) level of quality and 
completeness across those platforms that makes development uncommonly 
productive.  And along the way, everyone else who doesn't require a 
proprietary license can enjoy the same engine in a context where they 
can build and share and enhance their work and others' freely in both 
senses of the word, gratis and libre.


When self-described hobbyists says the price is too high but won't 
accept a price of zero, or voluntarily offering any price they want 
through donations, I'm being earnest when I admit I'm having a hard time 
understanding that.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com


___
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

Re: Players in HTML5 - ETA for Full Functionality?

[Dirk prive]

I think the lack of interest in supporting the hobby programmers will hurt
the company in the not too distant future. As a hobby user myself I have
paid for a license for a long long time. I have a founder account on
on-rev. I paid for several academies. I supported the kickstarter. Not to
long ago we moved to Indy. This changed is to a license that is no longer
ours to keep. The license is only ours as long as we keep paying. That was
already a massive step backwards if you ask me. Not so long ago there was
already a price rise which you could avoid if you paid a yearly amount up
front. Now the price of Indy will double to 999. Again you can avoid it if
you pay 499 up front. I'm sorry but I don't have that amount of money
laying aside for my hobby. I can afford small monthly fees, but not 499 in
one go. This means I'll have to revert to whatever the last version was
that we had a license for that you can keep. The community version is nice
and all, but you entirely miss the point that you have hobby people that
are willing to pay for a license, and donations that don't give us anything
are not an option either. Therefore the company misses out on the money
that hobby programmers used to pay. I can't afford 999/year, so I think
I'll be out if a solution is not available.

PS: according to the GPL if the code is for your use only I don't think you
need to publish any source code at all. It's only when your program is
released externally that you need to release the source.

Kind regards,
Dirk Cleenwerck.
On Feb 26, 2016 17:28, "Richard Gaskin"  wrote:

> Robert Mann wrote:
>
> >>> a revamped audio implementation that simply allows to use COMPRESSED
> >>> audio within stacks, and not be obliged to develop external
> >>> solutions (which I did, but is then trick y to use for products
> >>> because of the more complex installation and external libraries to
> >>> be installed, that some users do not like at all).
> >
> > So, Although I did support as a hobbyist live code for a long time
> > and spent quite a few euros to support, I will personally NOT spend
> > one more euro until that is actually DONE.
> >
> > (i understand it is somewhat done "obliged" in the iOs context, has
> > it been added meanwhile into macOS?? That would be bad news for my
> > purse..!!)
>
> OS X has gotten far more attention for media playback than any other
> platform, now using Apple's latest AV APIs.
>
> What do you want to do that's been difficult in v7 or v8?
>
>
> > And should you need more people to contribute financially, perhaps
> > you could review the new paradigm of yearly licensing and also give
> > a standard "old" ways of just holding to a version. i will just hold
> > on to my version 7.5 for my hobbits usage. And I would be as a
> > hobbyist willing to spend a few bucks every 3 years or so... but with
> > the yearly licensing scheme, it's just too expensive for just a
> > hobist and there is no security to be able to play on with new
> > acquired features.
>
> Good news: unless you have a commercial interest that requires a
> proprietary license, you can use the GPL-governed Community Edition. The
> GPL does require that your stack source be available, but unless you're
> running a commercial venture that's usually not prohibitive, and many
> prefer to share their source so the software can be enhanced by others.
>
> The benefits for your situation are two-fold:
>
> 1. LiveCode requires no payment for the Community Edition, so you can
> enjoy the latest version at no cost.
>
> 2. If you want to make a financial contribution to the project you can
> choose any amount on the Donation page:
> 
>
> --
>  Richard Gaskin
>  Fourth World Systems
>  Software Design and Development for the Desktop, Mobile, and the Web
>  
>  ambassa...@fourthworld.comhttp://www.FourthWorld.com
>
>
> ___
> 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

Re: Players in HTML5 - ETA for Full Functionality?

[Richard Gaskin]

Robert Mann wrote:

>>> a revamped audio implementation that simply allows to use COMPRESSED
>>> audio within stacks, and not be obliged to develop external
>>> solutions (which I did, but is then trick y to use for products
>>> because of the more complex installation and external libraries to
>>> be installed, that some users do not like at all).
>
> So, Although I did support as a hobbyist live code for a long time
> and spent quite a few euros to support, I will personally NOT spend
> one more euro until that is actually DONE.
>
> (i understand it is somewhat done "obliged" in the iOs context, has
> it been added meanwhile into macOS?? That would be bad news for my
> purse..!!)

OS X has gotten far more attention for media playback than any other 
platform, now using Apple's latest AV APIs.


What do you want to do that's been difficult in v7 or v8?


> And should you need more people to contribute financially, perhaps
> you could review the new paradigm of yearly licensing and also give
> a standard "old" ways of just holding to a version. i will just hold
> on to my version 7.5 for my hobbits usage. And I would be as a
> hobbyist willing to spend a few bucks every 3 years or so... but with
> the yearly licensing scheme, it's just too expensive for just a
> hobist and there is no security to be able to play on with new
> acquired features.

Good news: unless you have a commercial interest that requires a 
proprietary license, you can use the GPL-governed Community Edition. 
The GPL does require that your stack source be available, but unless 
you're running a commercial venture that's usually not prohibitive, and 
many prefer to share their source so the software can be enhanced by others.


The benefits for your situation are two-fold:

1. LiveCode requires no payment for the Community Edition, so you can 
enjoy the latest version at no cost.


2. If you want to make a financial contribution to the project you can 
choose any amount on the Donation page:



--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com


___
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

Re: Players in HTML5 - ETA for Full Functionality?

[stephen barncard]

On Fri, Feb 26, 2016 at 7:05 AM, Robert Mann  wrote:

> I know that I will not be able to support a version I can use as a hobbits
> for several years.
>

Hobbits?

http://www.thehobbit.com



Stephen Barncard - Sebastopol Ca. USA -
mixstream.org
___
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

Re: Players in HTML5 - ETA for Full Functionality?

[Robert Mann]

Just for information... I must not be the single one that has sort of waited
10 years for JUST :

>> a revamped audio implementation that simply allows to use COMPRESSED
>> audio within stacks, and not be obliged to develop external solutions
>> (which I did, but is then trick y to use for products because of the more
>> complex installation and external libraries to be installed, that some
>> users do not like at all).

So, Although I did support as a hobbyist live code for a long time and spent
quite a few euros to support, I will personally NOT spend one more euro
until that is actually DONE.

(i understand it is somewhat done "obliged" in the iOs context, has it been
added meanwhile into macOS?? That would be bad news for my purse..!!)

And I fully support Sannyasin Brahmanathaswami in the view that audio/video
media functionalities are just basic functions that need to be addressed and
perhaps in greater priority than a sophisticated MCV framework.

And should you need more people to contribute financially, perhaps you could
review the new paradigm of yearly licensing and also give a standard "old"
ways of just holding to a version. i will just hold on to my version 7.5 for
my hobbits usage. And I would be as a hobbyist willing to spend a few bucks
every 3 years or so... but with the yearly licensing scheme, it's just too
expensive for just a hobist and there is no security to be able to play on
with new acquired features. 

So as a result I just do not take time to keep up with new features because
I know that I will not be able to support a version I can use as a hobbits
for several years. 
And the time that a hobbyist will take to dig and become friendlier with
live code is the best investment you can make to maintain a good
relationship with.. you.. clients.. in the long run. 

For me that precious line has been broken by the new licensing scheme.
Robert






--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Players-in-HTML5-ETA-for-Full-Functionality-tp4700852p4701506.html
Sent from the Revolution - User mailing list archive at Nabble.com.

___
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

Re: Players in HTML5 - ETA for Full Functionality?

[[-hh]]

> Scott R. wrote:
> ... That said, does an HTML5 standalone have the ability to
> interact with the HTML of the surrounding page?
> If yes, it would seem to be relatively straightforward to do
> what most HTML apps do, which is displaying video content in
> an iFrame, or embedded video on the same page...

Mark Wadd. said recently, freely out of my brain:
'LC uses emscripten only to render into the canvas'.
I suggested the use of other HTML5 objects already in November
and got a strict "NO": The HTML5 standalone will not have
features that are not in the engine.
The other way is already somehow possible: One can have a
webpage with actions that work on the LC canvas like on every
other canvas, for example get mouseActions or keyboardActions
if over the canvas.
But for that the LC canvas is a "dead" drawn object, like a
still image, you can't go 'deeper'. Except LC would allow to
attach js handlers alike the browser objects do.

Hope that was not too theoretical, the HTML5 people in general
have their own special wording what builds (intentionally?)
a barrier to simple HTML3 users like me and, as you wrote,
also you ...

hh


___
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

Re: Players in HTML5 - ETA for Full Functionality?

[Mark Waddingham]

On 2016-02-25 20:23, Matt Maier wrote:
In the approach the Livecode team is taking now, is it accurate to say 
that
the html5 standalone bundles up the livecode engine with any 
app-specific
objects/scripts and pushes the whole thing into the client browser, 
such

that all of the (supportable) functionality runs client-side?


Yes - building an HTML5 standalone is equivalent to building a 
standalone for another platform, it gives you an app which runs locally 
on the client. Any server access you do using similar techniques as 
those other platforms - for example, by using url requests.


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

Re: Players in HTML5 - ETA for Full Functionality?

[Scott Rossi]

Two qualifications: I haven't followed this thread closely, and I haven't
played a great deal with the HTML5 build.  That said, does an HTML5
standalone have the ability to interact with the HTML of the surrounding
page?

If yes, it would seem to be relatively straightforward to do what most
HTML apps do, which is displaying video content in an iFrame, or embedded
video on the same page.  Perhaps this is even how player support will
eventually by provided by the LiveCode guys.  But if you need a solution
now, maybe this route is an option.

Regards,

Scott Rossi
Creative Director
Tactile Media, UX/UI Design




On 2/6/16, 7:57 PM, "use-livecode on behalf of Sannyasin Brahmanathaswami"

wrote:

> 
>Are players expected to work in HTML5? I created a really simple stack
>with a button to fetch a remobe URL to an MP3 file, set the filename of a
>player on the card to that URL and start playing.
>
>really simpleŠ works on desktop like a charm.
>
>Fails in HTML5 standalone made with LC 8dp14
>
>I already bug reported this, but thought to ask here.
>
>streaming remote audio/video will be mission critical for us.
>
>BR



___
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

Re: Players in HTML5 - ETA for Full Functionality?

[Richard Gaskin]

Matt Maier wrote:
> Thanks for that overview Richard, it helped me!

If you read that post to the end you should get a medal. :)  More 
long-winded than even my user group presentations.  Glad it was useful.



> Given option (b), will the entire livecode engine have to run
> client-side, or will there be a way to let the engine run on a server?

That's a deep question.

An old friend of mine suggested, "The key to programming is finding the 
right dividing lines."


That applies to so much, from factoring code to managing teams, and with 
client-server apps I don't believe there's a single best answer.


Consider three example apps:  calculator, animated greeting card, and 
RSS aggregator.


With the calculator you could go either way, depending on the nature of 
the calculation.  If it's just arithmetic it probably makes the most 
sense to do it all in the client, But I have one medical app where the 
caluclations are based on values in lookup tables that would be 
cumbersome if we had to first download them to the client, so for that 
the client is pretty slim and it just sends the input values to the 
server who does the lookups and the arithmetic on them and sends back 
the answer.


An animated greeting card could conceivably be done on a server using a 
canvas object on the client side with web sockets or other method by 
which the canvas gets updated from the server for every frame.  But 
animations are computationally expensive, and if serving a lot of user 
the server would have to maintain quite a high load, and pushing out 
each frame is a lot of ongoing traffic, so for that one I'd put 
everything on the client.


With an RSS aggregator, all the client really wants is a list of news 
stories, but to get those news stories requires some process to download 
them (and hopefully politely, within the update limits specified by the 
publisher in the feed), parse them, sort them, filter out the irrelevant 
ones, rank the rest, and then wrap 'em up in HTML for display.   If the 
client had to do all the work it would put more load on the publishers 
than is truly needed, and require a lot of work making for a slow UI. 
If you had a server-side process that maintained the feeds in question 
then most of the work is done only once, publisher servers aren't 
overtaxed, and the client gets only the final output HTML (or perhaps 
XML or JSON in which the client could do the HTML wrapping itself).


Three simple and fairly common uses cases, but only one of them has 
anything close to a simple answer.  Like so much in life, we just have 
to look at the problem at hand, pick our dividing lines as best we can 
with what we can know at the outside, and be willing to revise as we 
learn more.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com


___
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

Re: Players in HTML5 - ETA for Full Functionality?

[Richard Gaskin]

Sannyasin Brahmanathaswami wrote:

>  We *can* fulfill our media delivery "vision"  on LC/Mobile and we
> can build a web UI using Rev igniter... so I'll be content to develop
> in that space for now.

A web UI is just text - HTML and CSS.  LiveCode is uncommonly good for 
processing text.  Whether using RevIgniter or any other framework or 
just task-specific code, what gets delivered to the browser is text of a 
sort LiveCode is very good at helping to produce.



>  This is more than you need to know, but part of the "back story"
> and "urgency" here was a hope  to keep LiveCode at the forefront of
> our in house toolbox. Another new young person -- who already went
> thru the Livecode University has switched to learning Python and will
> soon be developing HTML5 on that platform, because  it needs to run
> in a browser/WordPress iFrame.

Python doesn't run in a browser any more than LiveCode does.  An iFrame 
isn't at all Python-specific, it's an HTML tag (though for compatibility 
with iOS browsers he may want to use scrolling DIVs with XMLHttpRequest 
instead; last time I had frame-dependent content iPads didn't render it 
well so per Apple's tech notes I revised it with DIVs loaded via XHR).


Web UIs are just text - HTML and CSS.  Both Python and LiveCode are good 
for processing text, but there's an argument that it's a little easier 
and perhaps even faster in LiveCode.  Whether using Python or LiveCode 
or anything else, what gets delivered to the browser is text.


Python's a fine language.  But so is LiveCode.  Both have similar use 
cases, though given the early state of Python deployment packages for 
mobile I think it's safe to suggest LC is more mature for native mobile 
apps.   And given the integration of GUI elements as native objects in 
LC compared to the traditional approach Python takes in which GUIs are 
an afterthought, I'd say LC has at least a modest edge there too.


But for delivering web UIs, both do well at text processing and that's 
really all that task is as far as the work done on the server.  And 
although I'd love to see more head-to-head benchmarks, what little I've 
seen suggests LC may be slightly more efficient in some areas than 
Python (chunk expressions are truly wonderful).


The one area where Python has an unquestionable advantage is the size 
and engagement of its audience.  Sooo many libraries available for it.


We'll get there too, but in the meantime all work in either language 
means a lot of unique code, and LC is every bit as solid a choice as Python.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://www.FourthWorld.com


___
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

Re: Players in HTML5 - ETA for Full Functionality?

[Sannyasin Brahmanathaswami]

On February 25, 2016 at 9:02:29 AM, Richard Wrote:
> I don't know if any of this rambling post is helpful, but my aim here is
> just to point out the very difficult task being undertaken here. And while
> we can expect Peter's excellent work to continue to make big strides, I
> think it may be helpful to keep expectations in check, since we're
> attempting to bridge two very different worlds. Not all life forms that
> thrive on one planet can survive at all on another.


Agreed. I guess I was being naive in the understanding of the level of changes 
required to encompass media delivery, and I will certainly keep my expectations 
in check... My apologies for banging the drum.

 We *can* fulfill our media delivery "vision"  on LC/Mobile and we can build a 
web UI using Rev igniter... so I'll be content to develop in that space for now.

I hereby officially switch hats  to "infinite patience"

Richard Wrote:

"These  are very different worlds; there is no magic pony. >

> Option a) would allow us to export LC player controls as HTML5 player
> objects, but would require you to write any scripts you need in JavaScript.

That's kind of what I thought could work, even as an interim solution. Our use 
case doesn't really require the full spectrum of native LiveCode player 
parameters. Open, play, pause and stop and dismiss would suffice for 95% of the 
requirements. In my naivete, targeting the innerHTML with a small html5 Video 
tag seemed trivial... obviously I am wrong.

 This is more than you need to know, but part of the "back story" and "urgency" 
here was a hope  to keep LiveCode at the forefront of our in house toolbox. 
Another new young person -- who already went thru the Livecode University has 
switched to learning Python and will soon be developing HTML5 on that platform, 
because  it needs to run in a browser/WordPress iFrame.  Of course I have to 
shake my head at how many hours it will take him to do the smallest 
framework... and the scope of what he will be able to accomplish relative to a 
full LC stack will be highly compromised...even the scope on the spec of that 
project was chopped down by 85%...as "not doable now..."  when the whole 
original spec could have been done in LiveCode in a week(s)... (except for the 
video streaming)

We had to reach out to a HTML5 pro in Belarus, to get a leg up on how to do the 
first one and now we hope to learn how to do it ourselveshaving Python 
skills on the team I suppose will be userful, I would have much preferred he 
focused on LiveCode because I believe it would have been to our greater 
advantageands more "fun" for him in the long run.  But, I can run his modules 
inside the browser widget in our next LC Mobile app... so we are OK for now.  
And it's going to take him s long to get to where he wants to be that 
probably the HTML5 thing in LC will be ready even before he can think about 
module #2...

Officially now wearing the hat of "infinite patience."

BR


___
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

Re: Players in HTML5 - ETA for Full Functionality?

[Matt Maier]

That was too abstract and hypothetical for me to be sure I followed
correctly.

In the approach the Livecode team is taking now, is it accurate to say that
the html5 standalone bundles up the livecode engine with any app-specific
objects/scripts and pushes the whole thing into the client browser, such
that all of the (supportable) functionality runs client-side?

On Thu, Feb 25, 2016 at 11:11 AM, Mark Waddingham  wrote:

> I think most modern web apps you see run ui locally (client side) and then
> use an http-based server API to manage the 'cloud' side.
>
> The advantage of this approach is that you end up with a good separation
> between client and server, meaning the client can be implemented on any
> platform (and using the same code - at least when using LiveCode).
>
> I wouldn't, however, rule out some means of defining server side behavior
> alongside the client side behavior and have LiveCode 'do the right thing'.
> However, that is perhaps a bit further down the line... We have a fair bit
> more work to do on the html5 port first!
>
> Mark.
>
> Sent from my iPhone
>
> > On 25 Feb 2016, at 19:02, Matt Maier  wrote:
> >
> > Thanks for that overview Richard, it helped me!
> >
> > Given option (b), will the entire livecode engine have to run
> client-side,
> > or will there be a way to let the engine run on a server?
> >
> > On Thu, Feb 25, 2016 at 10:23 AM, Richard Gaskin <
> ambassa...@fourthworld.com
> >> wrote:
> >
> >> Sannyasin Brahmanathaswami wrote:
> >>
> >>> So if we can run Landstat Satellites and entire Universities
> >>> (vienna), I humbly submit that it's time to realize "you did it" when
> >>> it comes to data management...and to put media delivery at the
> >>> forefront of the agenda not at the end of the agenda.
> >>>
> >>> The current generation is all about audio and video. "expect... all
> >>> at once" Many of us have been asking for audio/video improvements
> >>> for well over the past ten years. So it's not as if we are coming out
> >>> of the blue
> >>
> >> We still don't have point-and-click data binding with a built-in MVC
> >> framework.
> >>
> >> But in all fairness those are things the community can do in script,
> >> whereas multimedia playback is very much an engine concern.
> >>
> >> I bring up MVC only to suggest that your priorities may not be mine, and
> >> mine may not be others'.
> >>
> >> As a Linux user I haven't been able to even just play a video at all in
> >> several years, while it's possible (with some codec/format limitations)
> on
> >> Windows and Mac users enjoy support for the latest OS media APIs.
> >>
> >> Since most of my current work is in data-intensive productivity apps
> this
> >> hasn't held me back; I share the story only to point out that priorities
> >> are as broad and varied as this community.
> >>
> >>
> >>> "difficult port" ?? there are any number of media player frameworks
> >>> built on JS... Perhaps I'm very dense, but JS is use for media
> >>> deliver *everywhere*... It's not about a player exactly.. but just to
> >>> be able to stream audio and video.
> >>>
> >>> So back to my question: is there another way to play media using
> >>> other means beside a player?
> >>
> >> Yes: let the browser do it.
> >>
> >> But to do that, you'd need to let the browser do it all.
> >>
> >> There are two very different worlds here:  the desktop, run with OS APIs
> >> on binary structures and machine code; and the web, run with browser
> specs
> >> on textual data and JavaScript.
> >>
> >> These worlds do not collide.  They are fundamentally different, designed
> >> for very different tasks.
> >>
> >> Before LC's HTML initiative, the two worlds were for the most part quite
> >> separate.  No one expects to use XCode to write C++ apps in Cocoa and
> >> somehow run them in a browser.
> >>
> >> What LC is attempting here is a significant departure from a long
> history
> >> in which the two worlds, desktop and web, are very separate from one
> >> another.
> >>
> >> Given that the only execution engine commonly available in browsers is
> >> JavaScript, to migrate applications made in LiveCode into the confines
> of a
> >> web browser requires either of two approaches:
> >>
> >> a) Translate LC-native objects to browser-native HTML/CSS, and LC-native
> >> scripts to JavaScript.
> >>
> >> b) Translate the LC engine to JavaScript so LC-native objects and
> scripts
> >> need no translation.
> >>
> >> Either is a difficult task.
> >>
> >> Option a) makes it relatively easy to get appearances, but for
> >> functionality requires translating every line of LiveCode script into
> >> JavaScript.
> >>
> >> The appearance part isn't that hard:  with a few hours it's possible to
> >> translate native LC objects into their HTML/CSS equivalents rather
> >> satisfyingly, with the result being lean browser-native layouts.
> >>
> >> But the functionality is not so easy. LiveCode and JavaScript are so
> very
> >> different in 

Re: Players in HTML5 - ETA for Full Functionality?

[Mark Waddingham]

When it comes down to it, there is a direct parallel between wanting to use 
native html5 elements in a LiveCode html5 app and wanting to use native (system 
provided) controls on mobile.

There are still a couple of technical hurdles to overcome to make this possible 
in the html5 port, but for the most part it comes down to having a bridge 
between LCB and JavaScript when running in a browser. You can view the JS APIs 
as no different from system APIs on any other platform and in the same way as 
LCB can bridge (albeit in a very low-level way right now) to C APIs directly, 
the Html5 engine will eventually be able to bridge to JS APIs.

Mark.

Sent from my iPhone

> On 25 Feb 2016, at 18:23, Richard Gaskin  wrote:
> 
> Sannyasin Brahmanathaswami wrote:
> 
> >  So if we can run Landstat Satellites and entire Universities
> > (vienna), I humbly submit that it's time to realize "you did it" when
> > it comes to data management...and to put media delivery at the
> > forefront of the agenda not at the end of the agenda.
> >
> > The current generation is all about audio and video. "expect... all
> > at once" Many of us have been asking for audio/video improvements
> > for well over the past ten years. So it's not as if we are coming out
> > of the blue
> 
> We still don't have point-and-click data binding with a built-in MVC 
> framework.
> 
> But in all fairness those are things the community can do in script, whereas 
> multimedia playback is very much an engine concern.
> 
> I bring up MVC only to suggest that your priorities may not be mine, and mine 
> may not be others'.
> 
> As a Linux user I haven't been able to even just play a video at all in 
> several years, while it's possible (with some codec/format limitations) on 
> Windows and Mac users enjoy support for the latest OS media APIs.
> 
> Since most of my current work is in data-intensive productivity apps this 
> hasn't held me back; I share the story only to point out that priorities are 
> as broad and varied as this community.
> 
> 
> > "difficult port" ?? there are any number of media player frameworks
> > built on JS... Perhaps I'm very dense, but JS is use for media
> > deliver *everywhere*... It's not about a player exactly.. but just to
> > be able to stream audio and video.
> >
> > So back to my question: is there another way to play media using
> > other means beside a player?
> 
> Yes: let the browser do it.
> 
> But to do that, you'd need to let the browser do it all.
> 
> There are two very different worlds here:  the desktop, run with OS APIs on 
> binary structures and machine code; and the web, run with browser specs on 
> textual data and JavaScript.
> 
> These worlds do not collide.  They are fundamentally different, designed for 
> very different tasks.
> 
> Before LC's HTML initiative, the two worlds were for the most part quite 
> separate.  No one expects to use XCode to write C++ apps in Cocoa and somehow 
> run them in a browser.
> 
> What LC is attempting here is a significant departure from a long history in 
> which the two worlds, desktop and web, are very separate from one another.
> 
> Given that the only execution engine commonly available in browsers is 
> JavaScript, to migrate applications made in LiveCode into the confines of a 
> web browser requires either of two approaches:
> 
> a) Translate LC-native objects to browser-native HTML/CSS, and LC-native 
> scripts to JavaScript.
> 
> b) Translate the LC engine to JavaScript so LC-native objects and scripts 
> need no translation.
> 
> Either is a difficult task.
> 
> Option a) makes it relatively easy to get appearances, but for functionality 
> requires translating every line of LiveCode script into JavaScript.
> 
> The appearance part isn't that hard:  with a few hours it's possible to 
> translate native LC objects into their HTML/CSS equivalents rather 
> satisfyingly, with the result being lean browser-native layouts.
> 
> But the functionality is not so easy. LiveCode and JavaScript are so very 
> different in their syntax, logic, event and object models, that translation 
> from one to the other is a mind-bendingly difficult task.
> 
> Option b) is where we're headed instead, moving the entire LC engine into the 
> browser by translating roughly three quarters of a million lines of C++ into 
> JavaScript.
> 
> This allows LiveCode scripts and objects to be handled more or less how 
> they're handled in the desktop engine, without needing to translate LiveCode 
> scripts.
> 
> But given that the desktop and the web are such fundamentally different 
> platforms, neither approach can be expected to be a seamless move. These are 
> very different worlds; there is no magic pony.
> 
> Option a) would allow us to export LC player controls as HTML5 player 
> objects, but would require you to write any scripts you need in JavaScript.
> 
> Option b) lets all your LC objects scripts go along for the ride since the LC 
> engine 

Re: Players in HTML5 - ETA for Full Functionality?

[Mark Waddingham]

I think most modern web apps you see run ui locally (client side) and then use 
an http-based server API to manage the 'cloud' side.

The advantage of this approach is that you end up with a good separation 
between client and server, meaning the client can be implemented on any 
platform (and using the same code - at least when using LiveCode).

I wouldn't, however, rule out some means of defining server side behavior 
alongside the client side behavior and have LiveCode 'do the right thing'. 
However, that is perhaps a bit further down the line... We have a fair bit more 
work to do on the html5 port first!

Mark.

Sent from my iPhone

> On 25 Feb 2016, at 19:02, Matt Maier  wrote:
> 
> Thanks for that overview Richard, it helped me!
> 
> Given option (b), will the entire livecode engine have to run client-side,
> or will there be a way to let the engine run on a server?
> 
> On Thu, Feb 25, 2016 at 10:23 AM, Richard Gaskin > wrote:
> 
>> Sannyasin Brahmanathaswami wrote:
>> 
>>> So if we can run Landstat Satellites and entire Universities
>>> (vienna), I humbly submit that it's time to realize "you did it" when
>>> it comes to data management...and to put media delivery at the
>>> forefront of the agenda not at the end of the agenda.
>>> 
>>> The current generation is all about audio and video. "expect... all
>>> at once" Many of us have been asking for audio/video improvements
>>> for well over the past ten years. So it's not as if we are coming out
>>> of the blue
>> 
>> We still don't have point-and-click data binding with a built-in MVC
>> framework.
>> 
>> But in all fairness those are things the community can do in script,
>> whereas multimedia playback is very much an engine concern.
>> 
>> I bring up MVC only to suggest that your priorities may not be mine, and
>> mine may not be others'.
>> 
>> As a Linux user I haven't been able to even just play a video at all in
>> several years, while it's possible (with some codec/format limitations) on
>> Windows and Mac users enjoy support for the latest OS media APIs.
>> 
>> Since most of my current work is in data-intensive productivity apps this
>> hasn't held me back; I share the story only to point out that priorities
>> are as broad and varied as this community.
>> 
>> 
>>> "difficult port" ?? there are any number of media player frameworks
>>> built on JS... Perhaps I'm very dense, but JS is use for media
>>> deliver *everywhere*... It's not about a player exactly.. but just to
>>> be able to stream audio and video.
>>> 
>>> So back to my question: is there another way to play media using
>>> other means beside a player?
>> 
>> Yes: let the browser do it.
>> 
>> But to do that, you'd need to let the browser do it all.
>> 
>> There are two very different worlds here:  the desktop, run with OS APIs
>> on binary structures and machine code; and the web, run with browser specs
>> on textual data and JavaScript.
>> 
>> These worlds do not collide.  They are fundamentally different, designed
>> for very different tasks.
>> 
>> Before LC's HTML initiative, the two worlds were for the most part quite
>> separate.  No one expects to use XCode to write C++ apps in Cocoa and
>> somehow run them in a browser.
>> 
>> What LC is attempting here is a significant departure from a long history
>> in which the two worlds, desktop and web, are very separate from one
>> another.
>> 
>> Given that the only execution engine commonly available in browsers is
>> JavaScript, to migrate applications made in LiveCode into the confines of a
>> web browser requires either of two approaches:
>> 
>> a) Translate LC-native objects to browser-native HTML/CSS, and LC-native
>> scripts to JavaScript.
>> 
>> b) Translate the LC engine to JavaScript so LC-native objects and scripts
>> need no translation.
>> 
>> Either is a difficult task.
>> 
>> Option a) makes it relatively easy to get appearances, but for
>> functionality requires translating every line of LiveCode script into
>> JavaScript.
>> 
>> The appearance part isn't that hard:  with a few hours it's possible to
>> translate native LC objects into their HTML/CSS equivalents rather
>> satisfyingly, with the result being lean browser-native layouts.
>> 
>> But the functionality is not so easy. LiveCode and JavaScript are so very
>> different in their syntax, logic, event and object models, that translation
>> from one to the other is a mind-bendingly difficult task.
>> 
>> Option b) is where we're headed instead, moving the entire LC engine into
>> the browser by translating roughly three quarters of a million lines of C++
>> into JavaScript.
>> 
>> This allows LiveCode scripts and objects to be handled more or less how
>> they're handled in the desktop engine, without needing to translate
>> LiveCode scripts.
>> 
>> But given that the desktop and the web are such fundamentally different
>> platforms, neither approach can be expected to be a seamless move. These
>> 

Re: Players in HTML5 - ETA for Full Functionality?

[Matt Maier]

Thanks for that overview Richard, it helped me!

Given option (b), will the entire livecode engine have to run client-side,
or will there be a way to let the engine run on a server?

On Thu, Feb 25, 2016 at 10:23 AM, Richard Gaskin  wrote:

> Sannyasin Brahmanathaswami wrote:
>
> >  So if we can run Landstat Satellites and entire Universities
> > (vienna), I humbly submit that it's time to realize "you did it" when
> > it comes to data management...and to put media delivery at the
> > forefront of the agenda not at the end of the agenda.
> >
> > The current generation is all about audio and video. "expect... all
> > at once" Many of us have been asking for audio/video improvements
> > for well over the past ten years. So it's not as if we are coming out
> > of the blue
>
> We still don't have point-and-click data binding with a built-in MVC
> framework.
>
> But in all fairness those are things the community can do in script,
> whereas multimedia playback is very much an engine concern.
>
> I bring up MVC only to suggest that your priorities may not be mine, and
> mine may not be others'.
>
> As a Linux user I haven't been able to even just play a video at all in
> several years, while it's possible (with some codec/format limitations) on
> Windows and Mac users enjoy support for the latest OS media APIs.
>
> Since most of my current work is in data-intensive productivity apps this
> hasn't held me back; I share the story only to point out that priorities
> are as broad and varied as this community.
>
>
> > "difficult port" ?? there are any number of media player frameworks
> > built on JS... Perhaps I'm very dense, but JS is use for media
> > deliver *everywhere*... It's not about a player exactly.. but just to
> > be able to stream audio and video.
> >
> > So back to my question: is there another way to play media using
> > other means beside a player?
>
> Yes: let the browser do it.
>
> But to do that, you'd need to let the browser do it all.
>
> There are two very different worlds here:  the desktop, run with OS APIs
> on binary structures and machine code; and the web, run with browser specs
> on textual data and JavaScript.
>
> These worlds do not collide.  They are fundamentally different, designed
> for very different tasks.
>
> Before LC's HTML initiative, the two worlds were for the most part quite
> separate.  No one expects to use XCode to write C++ apps in Cocoa and
> somehow run them in a browser.
>
> What LC is attempting here is a significant departure from a long history
> in which the two worlds, desktop and web, are very separate from one
> another.
>
> Given that the only execution engine commonly available in browsers is
> JavaScript, to migrate applications made in LiveCode into the confines of a
> web browser requires either of two approaches:
>
> a) Translate LC-native objects to browser-native HTML/CSS, and LC-native
> scripts to JavaScript.
>
> b) Translate the LC engine to JavaScript so LC-native objects and scripts
> need no translation.
>
> Either is a difficult task.
>
> Option a) makes it relatively easy to get appearances, but for
> functionality requires translating every line of LiveCode script into
> JavaScript.
>
> The appearance part isn't that hard:  with a few hours it's possible to
> translate native LC objects into their HTML/CSS equivalents rather
> satisfyingly, with the result being lean browser-native layouts.
>
> But the functionality is not so easy. LiveCode and JavaScript are so very
> different in their syntax, logic, event and object models, that translation
> from one to the other is a mind-bendingly difficult task.
>
> Option b) is where we're headed instead, moving the entire LC engine into
> the browser by translating roughly three quarters of a million lines of C++
> into JavaScript.
>
> This allows LiveCode scripts and objects to be handled more or less how
> they're handled in the desktop engine, without needing to translate
> LiveCode scripts.
>
> But given that the desktop and the web are such fundamentally different
> platforms, neither approach can be expected to be a seamless move. These
> are very different worlds; there is no magic pony.
>
> Option a) would allow us to export LC player controls as HTML5 player
> objects, but would require you to write any scripts you need in JavaScript.
>
> Option b) lets all your LC objects scripts go along for the ride since the
> LC engine they depend on is now a JavaScript object, but it means you don't
> have access to browser-native objects like HTML5 media support.
>
> If one were inclined to pursue option a), it could be possible to take the
> approach Toolbook and others have, in which functionality targeted for web
> deployment is limited to calls in LC libraries for which matching
> JavaScript libraries are provided.  I first suggested this as a solution
> here in 2003, but no one was interested enough to help see it through.
> Could still be done, though, just 

Re: Players in HTML5 - ETA for Full Functionality?

[Richard Gaskin]

Sannyasin Brahmanathaswami wrote:

>  So if we can run Landstat Satellites and entire Universities
> (vienna), I humbly submit that it's time to realize "you did it" when
> it comes to data management...and to put media delivery at the
> forefront of the agenda not at the end of the agenda.
>
> The current generation is all about audio and video. "expect... all
> at once" Many of us have been asking for audio/video improvements
> for well over the past ten years. So it's not as if we are coming out
> of the blue

We still don't have point-and-click data binding with a built-in MVC 
framework.


But in all fairness those are things the community can do in script, 
whereas multimedia playback is very much an engine concern.


I bring up MVC only to suggest that your priorities may not be mine, and 
mine may not be others'.


As a Linux user I haven't been able to even just play a video at all in 
several years, while it's possible (with some codec/format limitations) 
on Windows and Mac users enjoy support for the latest OS media APIs.


Since most of my current work is in data-intensive productivity apps 
this hasn't held me back; I share the story only to point out that 
priorities are as broad and varied as this community.



> "difficult port" ?? there are any number of media player frameworks
> built on JS... Perhaps I'm very dense, but JS is use for media
> deliver *everywhere*... It's not about a player exactly.. but just to
> be able to stream audio and video.
>
> So back to my question: is there another way to play media using
> other means beside a player?

Yes: let the browser do it.

But to do that, you'd need to let the browser do it all.

There are two very different worlds here:  the desktop, run with OS APIs 
on binary structures and machine code; and the web, run with browser 
specs on textual data and JavaScript.


These worlds do not collide.  They are fundamentally different, designed 
for very different tasks.


Before LC's HTML initiative, the two worlds were for the most part quite 
separate.  No one expects to use XCode to write C++ apps in Cocoa and 
somehow run them in a browser.


What LC is attempting here is a significant departure from a long 
history in which the two worlds, desktop and web, are very separate from 
one another.


Given that the only execution engine commonly available in browsers is 
JavaScript, to migrate applications made in LiveCode into the confines 
of a web browser requires either of two approaches:


a) Translate LC-native objects to browser-native HTML/CSS, and LC-native 
scripts to JavaScript.


b) Translate the LC engine to JavaScript so LC-native objects and 
scripts need no translation.


Either is a difficult task.

Option a) makes it relatively easy to get appearances, but for 
functionality requires translating every line of LiveCode script into 
JavaScript.


The appearance part isn't that hard:  with a few hours it's possible to 
translate native LC objects into their HTML/CSS equivalents rather 
satisfyingly, with the result being lean browser-native layouts.


But the functionality is not so easy. LiveCode and JavaScript are so 
very different in their syntax, logic, event and object models, that 
translation from one to the other is a mind-bendingly difficult task.


Option b) is where we're headed instead, moving the entire LC engine 
into the browser by translating roughly three quarters of a million 
lines of C++ into JavaScript.


This allows LiveCode scripts and objects to be handled more or less how 
they're handled in the desktop engine, without needing to translate 
LiveCode scripts.


But given that the desktop and the web are such fundamentally different 
platforms, neither approach can be expected to be a seamless move. 
These are very different worlds; there is no magic pony.


Option a) would allow us to export LC player controls as HTML5 player 
objects, but would require you to write any scripts you need in JavaScript.


Option b) lets all your LC objects scripts go along for the ride since 
the LC engine they depend on is now a JavaScript object, but it means 
you don't have access to browser-native objects like HTML5 media support.


If one were inclined to pursue option a), it could be possible to take 
the approach Toolbook and others have, in which functionality targeted 
for web deployment is limited to calls in LC libraries for which 
matching JavaScript libraries are provided.  I first suggested this as a 
solution here in 2003, but no one was interested enough to help see it 
through.  Could still be done, though, just not by myself.  And while 
the functionality such libraries provide would be limited, the 
intersection of things we need to do on both desktop and web is somewhat 
limited by nature anyway, so for some apps it may not be a bad option.


With option b), the one being pursued at the moment, there is the 
possibility that the LC engine code that handles media playback could be 
replaced 

Re: Players in HTML5 - ETA for Full Functionality?

[Sannyasin Brahmanathaswami]

Points taken.. sorry to be a burr in the side...

Thanks for listening.  I'll look at the budgets and see what we can do from 
here.

All the best to the team.

On February 24, 2016 at 8:11:33 PM, Peter TB Brett 
(peter.br...@livecode.com) wrote:
You don't need to "bang the drum" about HTML5 Player control support.
*I KNOW*. I will implement it as soon as 1) it becomes technically
possible to do so and/or (2) a developer has time to work on it.

If you want it sooner: you can accelerate (1) by contributing the open
source project; and you can accelerate (2) by contributing to the open
source project or giving us more money (e.g. by buying an HTML5
deployment license, or by getting a Business license and purchasing
dedicated developer time).

By the way, the same considerations apply to all the other "critically
important feature requests" you so frequently put into the bug tracker,
Brahmanathaswami.
___
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

Re: Players in HTML5 - ETA for Full Functionality?

[Terry Judd]

Apologies for hijacking this thread somewhat but Peter could you possibly
comment on the likelihood of clipboard support being added to HTML5 in the
near (or middle) future. I understand there are potential security
concerns around use of the clipboard but it would be good to hear your
thoughts on how these might be accommodated (or not).

Regards,

Terry...

On 25/02/2016 5:10 pm, "use-livecode on behalf of Peter TB Brett"
 wrote:

>On 25/02/2016 05:59, Sannyasin Brahmanathaswami wrote:
>
>> So back to my question: is there another way to play media using
>> other means beside a player?
>
>Not that I'm aware of.
>
>> I will test the browser widget myself (I'm assuming it will work in
>> an HTML5 standalone.)
>
>No, the browser widget is not available in HTML5 standalones (and indeed
>actually *can't* be for the time being due to the way that it works).
>
>I posted recently-ish about the problems making certain types of
>LiveCode features (such as "wait" and the "URL" chunk) work in the HTML5
>engine.  I'm sure you can find the e-mail in the list archives.  Those
>same considerations apply to many of the other yet-to-be-implemented
>features.
>
>If you'd like to see multimedia and network connectivity in Community
>HTML5 standalones, you can speed up their delivery by finding a solution
>to those problems other than "redefine half the LiveCode Script
>language" or "rewrite the entire LiveCode engine".
>
>You don't need to "bang the drum" about HTML5 Player control support.
>*I KNOW*.  I will implement it as soon as 1) it becomes technically
>possible to do so and/or (2) a developer has time to work on it.
>
>If you want it sooner: you can accelerate (1) by contributing the open
>source project; and you can accelerate (2) by contributing to the open
>source project or giving us more money (e.g. by buying an HTML5
>deployment license, or by getting a Business license and purchasing
>dedicated developer time).
>
>By the way, the same considerations apply to all the other "critically
>important feature requests" you so frequently put into the bug tracker,
>Brahmanathaswami.
>
>Peter
>
>
>-- 
>Dr Peter Brett 
>LiveCode Open Source Team
>
>LiveCode 2016 Conference https://livecode.com/edinburgh-2016/
>
>___
>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

Re: Players in HTML5 - ETA for Full Functionality?

[Peter TB Brett]

On 25/02/2016 05:59, Sannyasin Brahmanathaswami wrote:


So back to my question: is there another way to play media using
other means beside a player?


Not that I'm aware of.


I will test the browser widget myself (I'm assuming it will work in
an HTML5 standalone.)


No, the browser widget is not available in HTML5 standalones (and indeed 
actually *can't* be for the time being due to the way that it works).


I posted recently-ish about the problems making certain types of 
LiveCode features (such as "wait" and the "URL" chunk) work in the HTML5 
engine.  I'm sure you can find the e-mail in the list archives.  Those 
same considerations apply to many of the other yet-to-be-implemented 
features.


If you'd like to see multimedia and network connectivity in Community 
HTML5 standalones, you can speed up their delivery by finding a solution 
to those problems other than "redefine half the LiveCode Script 
language" or "rewrite the entire LiveCode engine".


You don't need to "bang the drum" about HTML5 Player control support. 
*I KNOW*.  I will implement it as soon as 1) it becomes technically 
possible to do so and/or (2) a developer has time to work on it.


If you want it sooner: you can accelerate (1) by contributing the open 
source project; and you can accelerate (2) by contributing to the open 
source project or giving us more money (e.g. by buying an HTML5 
deployment license, or by getting a Business license and purchasing 
dedicated developer time).


By the way, the same considerations apply to all the other "critically 
important feature requests" you so frequently put into the bug tracker, 
Brahmanathaswami.


   Peter


--
Dr Peter Brett 
LiveCode Open Source Team

LiveCode 2016 Conference https://livecode.com/edinburgh-2016/

___
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

Re: Players in HTML5 - ETA for Full Functionality?

[Sannyasin Brahmanathaswami]

I realize my tone is a bit "strident" ... sorry about that.

Of course we don't expect something all at once, my problem and the problem of 
many here is that while the rest of the digital revolution has forged head with 
huge advances in multi-media delivery. LC is still many years behind.

 So if we can run Landstat Satellites and entire Universities (vienna), I 
humbly submit that it's time to realize "you did it" when it comes to data 
management... and to put media delivery at the forefront of the agenda not at 
the end of the agenda.

The current generation is all about audio and video.  "expect... all at 
once" Many of us have been asking for audio/video improvements for well 
over the past ten years. So it's not as if we are coming out of the blue

"difficult port" ?? there are any number of media player frameworks built on 
JS... Perhaps I'm very dense, but JS is use for media deliver *everywhere*... 
It's not about a player exactly.. but just to be able to stream audio and video.

So back to my question: is there another way to play media using other means 
beside a player?

I will test the browser widget myself (I'm assuming it will work in an HTML5 
standalone.)

BR...



On February 24, 2016 at 5:18:00 PM, Monte Goulding 
(mo...@appisle.net) wrote:

Did you expect such a major and technically difficult port of the platform to 
all arrive in one blob without any progressive development? As is HTML5 
deployment will be quite functional for quite a number of apps. It seems 
reasonable to me that those that don’t need or can work around some of the 
currently un-ported features should have the opportunity to use it.

Cheers

Monte
___
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

Re: Players in HTML5 - ETA for Full Functionality?

[Monte Goulding]

> On 25 Feb 2016, at 1:09 PM, Sannyasin Brahmanathaswami  
> wrote:
> 
> Not having this capability in LC  seems... well (I will refrain from 
> explicatives...)

Did you expect such a major and technically difficult port of the platform to 
all arrive in one blob without any progressive development? As is HTML5 
deployment will be quite functional for quite a number of apps. It seems 
reasonable to me that those that don’t need or can work around some of the 
currently un-ported features should have the opportunity to use it.

Cheers

Monte
___
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

Re: Players in HTML5 - ETA for Full Functionality?

[stephen barncard]

On Wed, Feb 24, 2016 at 6:09 PM, Sannyasin Brahmanathaswami <
bra...@hindu.org> wrote:

> Not having this capability in LC  seems... well (I will refrain from
> explicatives...)
>

if a monk swears in the woods, will anyone hear?  (ducking...)

Stephen Barncard - Sebastopol Ca. USA -
mixstream.org
___
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

Re: Players in HTML5 - ETA for Full Functionality?

[Sannyasin Brahmanathaswami]

So there is no way to play audio or video via *any* method in an HTML5 
standalone?

In a world of YouTube, iTune, Pandora etc..

Not having this capability in LC  seems... well (I will refrain from 
explicatives...)

Any other options to play besides the player? Leverage web kit? Create a  mini 
web page on our server for display of video/audio and then use the browser 
widget in an HTML5 app? (TBD) ?

This is a critical mass function/requirement...


On February 24, 2016 at 12:12:45 AM, Peter TB Brett 
(peter.br...@livecode.com) wrote:

Hi Martin and Brahmanathaswami,

There is no current ETA for implementing player support in the HTML5
engine. I can confirm that it *won't* be in LiveCode 8.0, however.

Peter
___
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

Re: Players in HTML5 - ETA for Full Functionality?

[Peter TB Brett]

On 08/02/2016 14:37, Martin Koob wrote:

I tried the same thing with a remote URL to an mp4 video file.  Same result
it plays in the IDE but not in HTML5.

I checked your bug report http://quality.livecode.com/show_bug.cgi?id=16870
and see that the response from Peter Brett that 'Player support has not yet
been implemented in the HTML5 engine'.

Hopefully Peter can respond here with an ETA for Player support in the HTML5
engine.

What types of video and audio files will it be expected to play?


Hi Martin and Brahmanathaswami,

There is no current ETA for implementing player support in the HTML5 
engine.  I can confirm that it *won't* be in LiveCode 8.0, however.


 Peter

--
Dr Peter Brett 
LiveCode Open Source Team

LiveCode 2016 Conference: https://livecode.com/edinburgh-2016/

___
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

Re: Players in HTML5 - ETA for Full Functionality?

[Martin Koob]

I tried the same thing with a remote URL to an mp4 video file.  Same result
it plays in the IDE but not in HTML5.

I checked your bug report http://quality.livecode.com/show_bug.cgi?id=16870 
and see that the response from Peter Brett that 'Player support has not yet
been implemented in the HTML5 engine'.

Hopefully Peter can respond here with an ETA for Player support in the HTML5
engine. 
 
What types of video and audio files will it be expected to play?

Thanks.

Martin





--
View this message in context: 
http://runtime-revolution.278305.n4.nabble.com/Players-in-HTML5-ETA-for-Full-Functionality-tp4700852p4700894.html
Sent from the Revolution - User mailing list archive at Nabble.com.

___
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

Players in HTML5 - ETA for Full Functionality?

[Sannyasin Brahmanathaswami]

 
Are players expected to work in HTML5? I created a really simple stack with a 
button to fetch a remobe URL to an MP3 file, set the filename of a player on 
the card to that URL and start playing.

really simple… works on desktop like a charm.  

Fails in HTML5 standalone made with LC 8dp14  

I already bug reported this, but thought to ask here.  

streaming remote audio/video will be mission critical for us.  

BR
___
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