Re: HTML5 Deployment

Paul, if you open the Livecode Dictionary, then you can see 2 tabs in the left upper corner. One is labeled "API" and one is labeled "Guide". Click on "Guide" and then select "Deploying Your Application" and then "HTML5 Deployment settings". There you should find a bunch of information. Hope t

Re: HTML5 deployment

> Sean wrote: > > 4. As with 3 also, emscripten itself has capabilities built in that will > allow for this so I will more likely utilise these rather than use JQuery. > The idea will be to handle as much as possible within the emscripten code > and have minimal stuff within the HTML output other

Re: HTML5 deployment

1&2 I am already implementing that way but thanks for the affirmation. 3. Good idea regarding keeping them all on one predetermined layer. 4. As with 3 also, emscripten itself has capabilities built in that will allow for this so I will more likely utilise these rather than use JQuery. The ide

Re: HTML5 deployment

* There are some things relating 1 & 2 one could think about: Start with mouseEvents (incl. wheel) and modifier keys. Then one could use native fields so that the browser does the keyboard job and executes all shortcuts for fields. To get/set field values is easy. A native styled field is also po

Re: HTML5 deployment

That's perfect, thank you. 1&2 were already at the top of my high priority list. 3 & 4 I fully appreciate. Certainly, 3a and 3b should be relatively easy to achieve. 3c and 4 slightly less so although I would be happy to hear your guidance on this. I'm assuming you already know where to find the cu

Re: html5-IDE v100_alpha

> Tom G. wrote: > Is it to have an easier time testing html 5 features?. is it to turn it > into a product? The SE and the messaging between the standalones is already basically done in earlier parts of my html5 samples. To improve the scriptEditor (which is 80% codeMirror) and build the mess

Re: html5-IDE v100_alpha

I should left out the world "defense"... A big compliment for making this. This project shows the potential of the HTML5 LiveCode builder beside all your other contributions related to HTML5 LiveCode which is a great help for others. On 27/11/2019, 00:03, "use-livecode on behalf of hh via us

Re: html5-IDE v100_alpha

Wow. very impressive..may I ask the reason why you created this? Is it to have an easier time testing html 5 features?. is it to turn it into a product? On Tue, Nov 26, 2019 at 6:03 PM hh via use-livecode < use-livecode@lists.runrev.com> wrote: > A few more words in defense of the

Re: HTML5

Possibly the server of your webpage is very slow. I need here at most 9-10 seconds to load a standalone the first time from http://hyperhh.de/html5 . You could load one of the latest (9.5.0 created) there and compare. Or you have conflict with SOP (same origin policy). Is your standalone trying t

Re: HTML5

Hi Alain I’m sorry to hear you are having this issue. Do you have access to the server settings to enable gzip compression. When enabled the server will compress the js files substantially so that the browser does not have to download so much and décompresses it in the client (which is much qui

Re: HTML5 Focus-Move-Resize v_100

Sorry, the correct download link (if not from "Sample Stacks") is http://livecodeshare.runrev.com/stack/945/ The one below loses the stack name (downloads as "rev" only). > I wrote: > Download "HTML5 Focus-Move-Resize" > from "Sample Stacks" of the LC toolbar or > > http://livecodeshare.runrev.c

Re: HTML5 and Copy and Pasting of graphics?

Thanks Richard! That works :) http://jpatten.on-rev.com/circletest1/circletest.html > On Sep 22, 2017, at 12:41 PM, Richard Gaskin via use-livecode > wrote: > > JOHN PATTEN wrote: > > > I am pretty sure I did a copy and paste from car

Re: HTML5 and Copy and Pasting of graphics?

JOHN PATTEN wrote: > I am pretty sure I did a copy and paste from card 2 to card 1 in a > HTML5 project. I may have been dreaming though :) > > I have two cards. First card has a button with this script: > > on mouseUp > copy grc "circle" of cd 2 > do paste > set the loc of last grc of cd 1 to 1

Re: HTML5 - Playing Audio files tutorial?

Hi Collin, No, the mp3 will not play either. I must be missing a step. :( http://jpatten.on-rev.com/sylvan/HTNML5%20Test.html . (no audio plays) http://jpatten.on-rev.com/sylvan/ TestAudio2.mp3. (plays fro

Re: HTML5 - Playing Audio files tutorial?

Normally you would play MP3 or OGG in HTML5. Do MP3 files play ok? > On Aug 25, 2017, at 11:06 AM, JOHN PATTEN via use-livecode > wrote: > > Hi All, > > I have followed the tutorial here on playing audio files, > http://lessons.livecode.com/m/4071/l/742506-how-do-i-play-sound-files-in-html5

Re: Web vs Native (was Re: HTML5 limitations?)

Wow! Quite the discussion! and here I was away from the list adding one last (hehe maybe not) feature to V1 of the SivaSiva app (hope to release by Aug 15) which was to create a "news channel" of course the obvious way to do this is have an HTML page on line, that you call into a browser widge

Re: Web vs Native (was Re: HTML5 limitations?)

On 2017-07-29 13:10, Jonathan Lynch via use-livecode wrote: So... if we use the wait command, and deploy to HTML5, the engine converts it to JavaScript with extra functions because the engine added in asynchronous timeouts? And you preserve all the variable values of the source LC script across t

Re: Web vs Native (was Re: HTML5 limitations?)

Hi Jim, One can have interruptible animations by using a handler that progresses the movement a single step, then calls itself using a send-in-time construction to initiate the next step. I recently posted a momentum scrolling script on this list that uses this technique. Does that help? Sent

Re: Web vs Native (was Re: HTML5 limitations?)

On 7/28/17 1:14 PM, Mark Waddingham via use-livecode wrote: > > I think the first thing we would need would be builtin > gesture support. In this case, this isn't even 'a gesture has happened' > but 'it looks like a swipe is just starting' (I think at least). e.g. > swipeBegin / swipeContinue /

Re: Web vs Native (was Re: HTML5 limitations?)

Hey, Mixed answer below: > - when the app needs access to the phone's functions (notifications, GPS, > screen dimming, text messages, etc) > There are Web APIs for: * Geolocation https://developer.mozilla.org/en-US/docs/Web/API/Geolocation * Notification (both local and push): - Local: https

Re: Web vs Native (was Re: HTML5 limitations?)

Hey, I think I am on a special position to talk about this as I have been on the bleeding edge of the Web trenches for a while. Instead of boring everyone here to death, I will do a quick TL;DR first with the actual info and then digress a bit about the current situation. = WEB: * The we

Re: Web vs Native (was Re: HTML5 limitations?)

Here is an example of using wait in my app... It seems to work better if I first load the map, then add markers from my database, rather than doing both at once. There is not a good trigger to detect when the map is fully loaded and displayed. So, I set an event listener for the page load, to

Re: Web vs Native (was Re: HTML5 limitations?)

You are right, Hermann - did not mean that to be mean-spirited to my home country, which I actually rather love. My apologies. I do think that "wait" can be useful sometimes, but not often. I was just surprised at the effort they are taking to reproduce "wait" in HTML deployment. Sent from m

Re: Web vs Native (was Re: HTML5 limitations?)

Hi I took that to be a self-deprecating comment and not anything to be offended by unless your comment hermann is supposed to be ironic in some sense? Regards Lagi On 29 July 2017 at 13:51, hh via use-livecode wrote: > #wait > I don't miss the "wait" handler in HTML5 and I wouldn't miss it in

Re: Web vs Native (was Re: HTML5 limitations?)

#wait I don't miss the "wait" handler in HTML5 and I wouldn't miss it in LC Script. I even don't know of any use case where "send in " (which works perfectly in HTML5) isn't superior to "wait". Especially when connected to move/animation. Also I don't miss "wait" in LC Builder. There OnTimer() is

Re: Web vs Native (was Re: HTML5 limitations?)

So... if we use the wait command, and deploy to HTML5, the engine converts it to JavaScript with extra functions because the engine added in asynchronous timeouts? And you preserve all the variable values of the source LC script across these multiple functions? This was the easy solution? Eith

Re: Web vs Native (was Re: HTML5 limitations?)

On 2017-07-29 07:11, J. Landman Gay via use-livecode wrote: On 7/28/17 7:29 PM, Mark Waddingham via use-livecode wrote: P.S. At some point I'll write at length about the 'wait' problem in HTML5. Whilst I try not to let myself be kept awake at night by engineering problems related to work - if e

Re: Web vs Native (was Re: HTML5 limitations?)

Indeed! That is the crux of the problem. Neither Android nor iOS have 'wait' (or the underlying OS feature you need to implement it) either. However those platforms have general threads so you can emulate it. HTML5 does not have general threads (although it probably will in about 2-3 years - a

Re: Web vs Native (was Re: HTML5 limitations?)

On 7/28/17 1:14 PM, Mark Waddingham via use-livecode wrote: What specific problem do we really need to solve... i.e. Is card-level swiping generally important enough to warrant an approach which isn't quite so general (very specific, one might say!)? The thing here is that we could well consid

Re: Web vs Native (was Re: HTML5 limitations?)

On 7/28/17 7:29 PM, Mark Waddingham via use-livecode wrote: P.S. At some point I'll write at length about the 'wait' problem in HTML5. Whilst I try not to let myself be kept awake at night by engineering problems related to work - if ever there was one which did, it would be that one! When yo

Re: Web vs Native (was Re: HTML5 limitations?)

I thought that JS/HTML5 did not have a wait function? One can loop the engine, which is horrible, or one can set timeouts for functions. What functionality do you access to induce a wait? Sent from my iPhone > On Jul 28, 2017, at 8:29 PM, Mark Waddingham via use-livecode > wrote: > > Hi Herm

Re: HTML5: mixed signals

Hehe - well I wasn't entirely sure I had managed to abstract what I think about such things compared to pragmatic reality. I also seem to be suffering a touch of sun stroke - so my 'tilt at windmills' level is slightly higher than normal ;) Warmest Regards, Mark. P.S. The last person to suffe

Re: Web vs Native (was Re: HTML5 limitations?)

Hi Hermann, First of all please don't take any offence at my email as none was intended. I was mainly trying to explain that whilst there are many things the HTML5 engine does not do, which means many stacks will not work without changes/workarounds (indeed, somewhat significant ones) - ther

Re: Web vs Native (was Re: HTML5 limitations?)

On 07/28/2017 11:41 AM, Mark Waddingham via use-livecode wrote: This is, of course, why I sometimes take 1000 words to say things which could have been said in 10 ;) Wouldn't have it any other way -- Mark Wieder ahsoftw...@gmail.com ___ use-live

Re: HTML5: mixed signals

Sorry I didn't mean it was an unfortunate way for you specifically to see things, I also meant generally how things are perceived by those who litigate such matters. You must pay closer attention to what I am thinking. ;-) Bob S > On Jul 28, 2017, at 14:14 , Mark Waddingham via use-livecode >

Re: HTML5: mixed signals

Again this is general and not specific. The case Richmond put forward is very much a case of over-reach from my point of view (it is quite possible that there was something in his contract there - probably obscurely worded, or it was the universities lawyers interpretation of statute). I rememb

Re: HTML5: mixed signals

What an unfortunate way of looking at things, because what knowledge do ANY of us have that we developed "on our own"? Any program I write I use knowledge I "developed" from any number of sources. Should they all have a claim on what I do? For this to really work, the knowledge would have to b

Re: Web vs Native (was Re: HTML5 limitations?)

Mark Waddingham wrote: > On 2017-07-28 20:17, Richard Gaskin via use-livecode wrote: >> I think we're closer on this than might have originally seemed: > > Indeed - on this and most things I think. > > I've always assumed that you tend to ask certain questions, or phrase > things in a certain in

Re: Web vs Native (was Re: HTML5 limitations?)

> Mark wrote: > However, there is one VERY important point I do need to make. It is easy > to get hang up on saying 'oh the HTML5 engine doesn't do this, and oh it > doesn't do that' - and this might well be true. *However* the only important > metric in this regard is - does it allow a suitable

Re: HTML5: mixed signals

On 2017-07-28 20:40, Richmond Mathewson via use-livecode wrote: Ooer . . . and how, pray tell, does one tease out what one learnt in one loaction from what one learnt in another? I appreciate that in the realm of teaching (the example you gave) the area is a little grey. However, in the area

Re: Web vs Native (was Re: HTML5 limitations?)

On 2017-07-28 20:17, Richard Gaskin via use-livecode wrote: I think we're closer on this than might have originally seemed: Indeed - on this and most things I think. I've always assumed that you tend to ask certain questions, or phrase things in a certain in way to give us (well, me, generall

Re: HTML5: mixed signals

Ooer . . . and how, pray tell, does one tease out what one learnt in one loaction from what one learnt in another? I was teaching some kiddos 2 weeks agao and showed one of them a stack of mine; and he said, "That's a silly way to do that." and then showed me what he thougth was a better way to

Re: HTML5: mixed signals

On 2017-07-28 19:49, Richmond Mathewson via use-livecode wrote: It turns out that teachers who make software at home, in their own time, do NOT own the copyright to their work if they are under contract to schools unless this has been explicitly "sorted out" in advance . . . a situation that, fr

Re: Web vs Native (was Re: HTML5 limitations?)

On 7/28/17 12:53 PM, J. Landman Gay via use-livecode wrote: I think we could discuss here on the list how it might work and then add to the feature request if we come up with something. After writing my response, I see that Richard has provided a nice description in the bug report that covers

Re: Web vs Native (was Re: HTML5 limitations?)

Mark Waddingham wrote: > On 2017-07-28 18:34, Richard Gaskin via use-livecode wrote: >> A sense of smooth liquid flow is the hallmark of modern UI. If >> support for this were limited to one widget that requires JavaScript, >> we might as well use the other tools you mentioned above. > > This is

Re: Web vs Native (was Re: HTML5 limitations?)

On 2017-07-28 19:53, J. Landman Gay via use-livecode wrote: One thought: locking the screen "for swipe effect" might lock the screen while any navigation or card changes are made, and then the unlock command would track the gesture until mouseUp (or touchEnd.) While the tracking is taking place,

Re: Web vs Native (was Re: HTML5 limitations?)

On 7/28/17 12:01 PM, Mark Waddingham via use-livecode wrote: That is the standard process for all enhancement requests. They are HIBERNATED until we have the time to evaluate and prioritise - if we were to do anything else, we would end up never getting any work done - and work we are doing rig

Re: HTML5: mixed signals

On 7/28/17 5:32 pm, Mark Waddingham via use-livecode wrote: * It is really important to note that in the UK, and most other countries, if you write code during periods of time you are being paid for by your employer, then the copyright is implicitly owned by the company *and not* you.

Re: Web vs Native (was Re: HTML5 limitations?)

On 2017-07-28 19:01, Mark Waddingham via use-livecode wrote: Right now JS/HTML5/CSS etc. has the edge over LiveCode in creating these rich UIs. Now, to be honest, the acceleratedRendering mode of LiveCode (which has been around for years) is no different from the underlying tech in browsers which

Re: Web vs Native (was Re: HTML5 limitations?)

On Fri, Jul 28, 2017 at 11:43 AM, Mark Waddingham via use-livecode < use-livecode@lists.runrev.com> wrote: > > At the end of the day, it might not be that making it synchronous *is* the > solution, but instead tweaking engine syntax and semantics to make it > easier to deal with this asynchronicit

Re: Web vs Native (was Re: HTML5 limitations?)

On 2017-07-28 18:34, Richard Gaskin via use-livecode wrote: A sense of smooth liquid flow is the hallmark of modern UI. If support for this were limited to one widget that requires JavaScript, we might as well use the other tools you mentioned above. This is simply not true. All tools have the

Re: Web vs Native (was Re: HTML5 limitations?)

On 2017-07-28 18:28, William Prothero via use-livecode wrote: on myRequest —send a POST or GET request, whatever, with a callback handler specified. —display a mask that inhibits new mouse clicks and sets a busy icon. end myRequest on myCallbackHander myReturnData —do whatever you want

Re: Web vs Native (was Re: HTML5 limitations?)

Sannyasin Brahmanathaswami wrote: > As for web app vs native app, @Richard Gaskin You *can*, obviously, > build a "web app" (html5+js+css) and package it in the app and run > it off line. another lad here on our team builds in ionic/React > /Angular. But his app is "native" to the phone, appear

Re: Web vs Native (was Re: HTML5 limitations?)

It requires setting up chained handlers on both the LC and JS side, but as long as you structure it well, it is not that bad. I can tell you that for working with maps, it is essential. Sent from my iPhone > On Jul 28, 2017, at 12:28 PM, William Prothero via use-livecode > wrote: > > Folks:

Re: Web vs Native (was Re: HTML5 limitations?)

On 2017-07-26 23:06, hh via use-livecode wrote: There are, sadly, still very basic things missing, which make the HTML5 standalone builder, TMHO, not yet ready for "beta"-state. Well - yes - the 'beta' state as I mentioned was a slip (mainly in that we don't do 'beta' in our dev process as I e

Re: Web vs Native (was Re: HTML5 limitations?)

Folks: As a long term Director developer, I found the use of listeners and callbacks to be quite easy to implement. I don’t see the problem. on myRequest —send a POST or GET request, whatever, with a callback handler specified. —display a mask that inhibits new mouse clicks and sets a busy

Re: Web vs Native (was Re: HTML5 limitations?)

Although I am one of the people calling for more browser widget development... I have my doubts about the ability to make it synchronous with LC. JavaScript is not even reliably synchronous with HTML5, forcing JS developers to use callbacks and event listeners in weird places. Unless you guys a

Re: Web vs Native (was Re: HTML5 limitations?)

On 2017-07-28 16:47, Sannyasin Brahmanathaswami via use-livecode wrote: Hence oft-repeated prayer that we get the browser "widget" to become a true member of the LC message hierarchy, they we can leverage the web apps eye candy layer (easy to build, responsive, CSS is already done for us…) with L

Re: Web vs Native (was Re: HTML5 limitations?)

Matt wrote: Except that they've aged out of the phase where it's easy to learn new things. So they feel like an idiot baby and it takes way too much effort to push through the learning curve. LOL, hence my surprise after listening to some complaints by older folks about the navig

Re: HTML5: mixed signals

On 2017-07-28 16:36, Mark Waddingham via use-livecode wrote: Oops - I forgot to say 'I am not a laywer but'... At the start of this. I should say that most of this stuff is pretty standard, in general as long as you always use attach a license to your commercial works, and always follow the requ

Re: HTML5: mixed signals

Oops - I forgot to say 'I am not a laywer but'... At the start of this. I should say that most of this stuff is pretty standard, in general as long as you always use attach a license to your commercial works, and always follow the requirements of the GPL then you don't have to worry about thes

Re: HTML5: mixed signals

Hermann has the 'the right' of it here. Basically it is important to remember that just because you *might* be able to see source-code it doesn't mean you have the right to copy, use or do anything with it. If there is no license attached to it, or if there is not a clear declaration of a lice

Re: HTML5: mixed signals

*** The following is how I judge this, not based on any 'official document'. *** Depends a little bit upon what you are doing. The javascript part of the calling web page is always accessible, no matter the license. So, important parts that you have as javascript in the standalone's webpage are pr

Re: HTML5: mixed signals

No, that means, that you have to release your source code to the public when using the community version, while you don´t have to do it when you have a commercial license. Matthias > Am 28.07.2017 um 15:12 schrieb Richmond Mathewson via use-livecode > : > > Well, that is reasonably obvious . .

Re: HTML5: mixed signals

Well, that is reasonably obvious . . . Presumably (?) that means that HTML5 things hived-off the Community version of LiveCode are in readable Java-script and may be opened and edited as such, while the version of HTML5 available for $299/year hives-off protected code? Richmond. On 7/28/17 2

Re: HTML5: mixed signals

Um. Like every other platform for LiveCode, there is an open source Community version of HTML5. Not seeing the problem here? You pay for commercial, closed source. You use Community free and share your code. Regards, Heather > On 28 Jul 2017, at 12:07, Richmond Mathewson via use-livecode >

Re: Web vs Native (was Re: HTML5 limitations?)

> On Jul 27, 2017, at 10:48 AM, Matt Maier via use-livecode > wrote: > High market penetration of smartphones doesn't mean anyone actually has any > idea how to use their smartphone. Most people are at about the > Fischer-Price My First Shapes and Colors level. Except that they've aged > out of

Re: Web vs Native (was Re: HTML5 limitations?)

Word. I barely have any experience and I've already run into multiple users/customers who think that "add to homescreen" is impossible hacker magic. High market penetration of smartphones doesn't mean anyone actually has any idea how to use their smartphone. Most people are at about the Fischer-Pr

Re: Web vs Native (was Re: HTML5 limitations?)

Which point illustrates something I'm sure seasoned developers have known for a long time: There is no way to write an app so that it will satisfy everyone, especially these days with all the ways to deliver an app! To illustrate, I had a gal here in the office lose some documents, because I h

Re: Web vs Native (was Re: HTML5 limitations?)

hh wrote: >> RG wrote: >> - What are the use-cases where a native app is a better choice than >> a web app? >> - What are the perceived benefits of web apps and native apps? >> The first question is about actual capabilities, and the second >> is about the psychological drivers of clients and c

Re: Web vs Native (was Re: HTML5 limitations?)

Add to list as necessary. I've already pulled in a few items from other posts. We can come up with a referendum/consensus on the topic. Traditional Apps: UP SIDE Better performance No dependent on an internet connection (if server is not installed locally) Many people still prefer to own product

Re: Web vs Native (was Re: HTML5 limitations?)

On Wed, Jul 26, 2017 at 5:27 PM, Richard Gaskin via use-livecode < use-livecode@lists.runrev.com> wrote: > hh wrote: > >> RG wrote: > >> My bigger question here is what needs to be delivered specifically > >> in a web browser window vs a native app, and why? > > > > This questions browsers ("the w

Re: Web vs Native (was Re: HTML5 limitations?)

> RG wrote: > - What are the use-cases where a native app is a better choice than a web app? > - What are the perceived benefits of web apps and native apps? > The first question is about actual capabilities, and the second is about the > psychological drivers of clients and customers, which may or

Re: Web vs Native (was Re: HTML5 limitations?)

hh wrote: >> RG wrote: >> My bigger question here is what needs to be delivered specifically >> in a web browser window vs a native app, and why? > > This questions browsers ("the web") as platform in general. > TMHO, you are too late with that question, by 25 years. Perhaps just poor writing on

Re: HTML5 limitations?

On 2017-07-26 00:43, Mark Wieder via use-livecode wrote: On 07/25/2017 01:43 PM, hh via use-livecode wrote: The HTML5 standalone builder is still "experimental". Has been "very experimental" until July 2017. It's in process to becoming "beta". My fault! I wasn't paying attention when Heather

Re: Web vs Native (was Re: HTML5 limitations?)

> RG wrote: > My bigger question here is what needs to be delivered specifically > in a web browser window vs a native app, and why? This questions browsers ("the web") as platform in general. TMHO, you are too late with that question, by 25 years. ___

Re: Web vs Native (was Re: HTML5 limitations?)

hh wrote: >> Mike K. wrote: >> My perception is that the web experience is very close to a desktop- >> native experience, and the two are almost interchangable. Running an >> app in a browser feels and works almost the same as a native one >> does. > > The HTML5 standalone builder... ... > @Mike.

Re: Web vs Native (was Re: HTML5 limitations?)

> Mike K. wrote: > My perception is that the web experience is very close to a desktop-native > experience, and the two are almost interchangable. Running an app in a > browser feels and works almost the same as a native one does. The HTML5 standalone builder has greatly improved within the last y

Re: HTML5 limitations?

Thanks for all the responses. I'll discuss with the client but my guess is that we're not suited for HTML5 yet on this project. -- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.com

Re: Web vs Native (was Re: HTML5 limitations?)

My perception is that the web experience is very close to a desktop-native experience, and the two are almost interchangable. Running an app in a browser feels and works almost the same as a native one does. However, once you get to mobile, the web app experience is nowhere on par. Even mobile w

Re: Web vs Native (was Re: HTML5 limitations?)

> JLG wrote: > In my case, the app is courseware and students are complaining they want it > to work on their mobile devices. Some don't have laptops and don't want to > use the computer lab. The options are to create mobile apps or alternately > run it in the mobile browser. There is currently

Re: Web vs Native (was Re: HTML5 limitations?)

J. Landman Gay wrote: > In my case, the app is courseware and students are complaining they > want it to work on their mobile devices. Some don't have laptops and > don't want to use the computer lab. That's an interesting subset. Do you have a feel for what percentage of that audience doesn't

Re: Web vs Native (was Re: HTML5 limitations?)

On July 26, 2017 9:20:17 AM Richard Gaskin via use-livecode wrote: I believe Rick's "Why" here is key to much of what we may be doing over the next couple years. In my case, the app is courseware and students are complaining they want it to work on their mobile devices. Some don't have lapt

Re: Web vs Native (was Re: HTML5 limitations?)

Roger Eller wrote: > As for in-house or "corporate" mobile, they seem to also want > everything to be web based as well. I tried real hard to get > LiveCode accepted for mobile development... Well at least they're consistent in their desire for web apps. I keep coming across people who insist

Re: Web vs Native (was Re: HTML5 limitations?)

As for in-house or "corporate" mobile, they seem to also want everything to be web based as well. I tried real hard to get LiveCode accepted for mobile development, but they only wanted a tool that could create secure html5 apps. This was back when LC html5 was only in early planning. ~Roger O

Web vs Native (was Re: HTML5 limitations?)

I believe Rick's "Why" here is key to much of what we may be doing over the next couple years. We developers currently find ourselves in a very strange place: On desktop, the requests are "Web! Web! Web!" On mobile, they're "Apps! Apps! Apps!" If the web offers advantages that can't be matche

Re: HTML5 limitations?

> Mark wieder wrote: > It's in process to becoming "beta" ... ... while "the mouse" still always reports "up". It's a miracle. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your s

Re: HTML5 limitations?

Why does the client want to move the project over to HTML5? What advantage does he/she think it is going to provide that the current setup does not? Based on the complexity of what you already have going I think it could be a very serious waste of time and energy. It’s easier to just have a websi

Re: HTML5 limitations?

On 07/25/2017 01:43 PM, hh via use-livecode wrote: The HTML5 standalone builder is still "experimental". Has been "very experimental" until July 2017. It's in process to becoming "beta". -- Mark Wieder ahsoftw...@gmail.com ___ use-livecode mailing

Re: HTML5 limitations?

The 5MB limit is on mobile, and each time you exceed the previous limit the user can give permission to increase it, at least to 50 MB. Also it’s possible to use multiple databases. > On Jul 25, 2017, at 5:16 PM, Jonathan Lynch via use-livecode > wrote: > > The size limit on data in local sto

Re: HTML5 limitations?

The size limit on data in local storage is 5 to 10 mb per origin, depending on browser. Not sure if that would be an issue. Local storage seems to work pretty well in my experiments, if the limitations are not an issue. Sent from my iPhone > On Jul 25, 2017, at 5:07 PM, Colin Holgate via use-l

Re: HTML5 limitations?

> JLG wrote: > I have a client that wants to move our project to HTML5. I have > some doubts about the capabilities, could someone tell me what is > currently possible and what is not? Wait until Mark Waddingham's talk about HTML5. Even he will probably not be able to answer the "what is not"-part

Re: HTML5 limitations?

Can LiveCode HTML5 include or call Javascript? If so you could use local storage InedxedDB for the database. Or WebSQL. If the data isn’t too big. > On Jul 25, 2017, at 3:28 PM, Matthias Rebbe via use-livecode > wrote: > > And direct db access is also not possible. For that you´ll need some k

Re: HTML5 limitations?

The HTML5 standalone builder is still "experimental". Has been "very experimental" until July 2017. ___ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: htt

Re: HTML5 limitations?

No problem, but thanks for replying. That is really interesting. I know that setting up such a structure in traditional HTML/JS would be a big pain, because I have looked into something similar before for other reasons. It must have been quite a bit of work to duplicate that structure in the HT

Re: HTML5 limitations?

That concept would be great as a lesson. ~Roger On Tue, Jul 25, 2017 at 4:21 PM, Kevin Miller via use-livecode < use-livecode@lists.runrev.com> wrote: > Yes you can. I'm at a conference just now but hopefully someone > knowledgable on our team can jump in with more info. > > Sent from my iPhone

Re: HTML5 limitations?

Yes you can. I'm at a conference just now but hopefully someone knowledgable on our team can jump in with more info. Sent from my iPhone > On 25 Jul 2017, at 13:07, Jonathan Lynch via use-livecode > wrote: > > Kevin, > > Can you have a structure similar to having multiple stacks controlled b

Re: HTML5 limitations?

Kevin, Can you have a structure similar to having multiple stacks controlled by an LC engine? I am really curious how you guys set that up? Using localstorage and cookies are the only methods I know of for doing that in regular html5 with multiple tabs/windows. Sent from my iPhone > On Jul

Re: HTML5 limitations?

Go in window of stack works You can download stacks just fine Sent from my iPhone > On 25 Jul 2017, at 12:46, Jonathan Lynch via use-livecode > wrote: > > In HTML the browser is the engine that runs both HTML and JavaScript. It is > possible to have multiple tabs and there are some functions

Re: HTML5 limitations?

In HTML the browser is the engine that runs both HTML and JavaScript. It is possible to have multiple tabs and there are some functions for communicating between tabs and windows, but it isn't pretty. You have to use localstorage and storage events. This could be made to work similar to an LC e

  1   2   3   4   >