Re: Players in HTML5 - ETA for Full Functionality?

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

Re: Players in HTML5 - ETA for Full Functionality?

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

Re: Players in HTML5 - ETA for Full Functionality?

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

Re: Players in HTML5 - ETA for Full Functionality?

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

Re: Players in HTML5 - ETA for Full Functionality?

> 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

Re: Players in HTML5 - ETA for Full Functionality?

ndings. -- 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 lis

Re: Players in HTML5 - ETA for Full Functionality?

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

Re: Players in HTML5 - ETA for Full Functionality?

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

Re: Players in HTML5 - ETA for Full Functionality?

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

Re: Players in HTML5 - ETA for Full Functionality?

> 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

Re: Players in HTML5 - ETA for Full Functionality?

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

Re: Players in HTML5 - ETA for Full Functionality?

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

Re: Players in HTML5 - ETA for Full Functionality?

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

Re: Players in HTML5 - ETA for Full Functionality?

> 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

Re: Players in HTML5 - ETA for Full Functionality?

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

Re: Players in HTML5 - ETA for Full Functionality?

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

Re: Players in HTML5 - ETA for Full Functionality?

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:

Re: Players in HTML5 - ETA for Full Functionality?

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

Re: Players in HTML5 - ETA for Full Functionality?

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

Re: Players in HTML5 - ETA for Full Functionality?

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

Re: Players in HTML5 - ETA for Full Functionality?

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

Re: Players in HTML5 - ETA for Full Functionality?

> 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

Re: Players in HTML5 - ETA for Full Functionality?

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)

Re: Players in HTML5 - ETA for Full Functionality?

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

Re: Players in HTML5 - ETA for Full Functionality?

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

Re: Players in HTML5 - ETA for Full Functionality?

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.

Re: Players in HTML5 - ETA for Full Functionality?

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

Re: Players in HTML5 - ETA for Full Functionality?

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,

Re: Players in HTML5 - ETA for Full Functionality?

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

Re: Players in HTML5 - ETA for Full Functionality?

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

Re: Players in HTML5 - ETA for Full Functionality?

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

Re: Players in HTML5 - ETA for Full Functionality?

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. > >

Re: Players in HTML5 - ETA for Full Functionality?

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

Re: Players in HTML5 - ETA for Full Functionality?

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

Re: Players in HTML5 - ETA for Full Functionality?

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

Re: Players in HTML5 - ETA for Full Functionality?

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

Re: Players in HTML5 - ETA for Full Functionality?

> 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

Re: Players in HTML5 - ETA for Full Functionality?

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

Re: Players in HTML5 - ETA for Full Functionality?

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

Re: Players in HTML5 - ETA for Full Functionality?

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

Re: Players in HTML5 - ETA for Full Functionality?

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

Players in HTML5 - ETA for Full Functionality?

  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