HTML5 deployment

[Pi Digital]

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 idea will be to handle as much as possible within the emscripten code and have minimal stuff within the HTML output other than anything the user wants to add in. 

5. Thinking ahead, a way to add in JS functions an LC developer would want included in the HTML output (from within LC) would be useful. Perhaps a stack custom property that can hold the whole JS code that gets inserted at deployment so that it builds as self contained. And/Or a way to access, manipulate and/or set parameters of the HTML from within LC before deployment (not at runtime). This could then include things like custom layouts, loading bars, screen size handlers, php/Ajax/jquery comms, etc. 

Sean Cole
Pi Digital Prod Ltd

> On 1 Feb 2020, at 14:38, hh via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
> * 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 possible
> (see my demo at hyperhh.de/html5).
> 
> My technique is to use ordinary LC fields, hide these (and optionally use
> them as container). Then adjust the native field rects to these hidden field
> rects in the movestack/resizestack handlers.
> 
> * For 3 it would be enough to define ONE 'window'/canvas of id 'menu' for the
> menus with a z-level of say 23121950 and similarly define ONE 'window'/canvas
> for the tooltips of id 'tooltip' with a z-level of say 23121949.
> 
> That implies: do NOT create a new window for each menu/tooltip.
> Probably function createWindow in em-dc.js needs a switch for that (I could
> not find out where this method is called for menus/tooltips).
> 
> Then insert the two lines
> canvas.classList.add('lcStack');
> canvas.id('stack_'+tWindowID);
> after current line 128 of em-dc.js, so one has several methods to get stack
> objects.
> 
> * For 4 one could use the lib I use for htmlPlayer. This needs jQuery but it
> is the only one I've found that works with LC-menus. I added a short script
> to put stacks into a panel.
> 
>> Sean wrote:
>> em-event.js is the one for 1 & 2 causing the problem mainly because of its
>> use of now deprecated event handlers. That's what I am working on right
>> now.
>> 
>> em-dc, em-nativeLayer and em-surface are what is likely to do with 3 & 4.
>> Maybe also em-preamble-overlay.js.
>> 
>> em-clipboard obviously may have some relevance to the clipboard issue but
>> I'm working on the assumption first it is more likely just a keyboard/input
>> event issue.
>> 
>>> Hermann wrote:
>>> 1. *Full* keyboard and mouse (incl. wheel) support. 
>>> 
>>> 2. Support for usual field shortcuts (selectAll, copy, cut, paste, 
>>> undo) and rawkey handlers. 
>>> 
>>> 3. Improve the canvas generation: 
>>> 
>>> Currently LC generates canvases for stacks, tooltips and 
>>> menus that are without querying windowIDs for all stacks 
>>> undistinguishable. Often menus and tooltips are hidden by stacks: 
>>> 
>>> 3a. Menus need to have an own fixed (very high) z-level, 
>>> 3b. Tooltips need to have an own fixed (very high) z-level, 
>>> 3c. Stacks need an own class for easier access in DOM. 
>>> 
>>> 4. Add a draggable, resizable windowing system (adding titlebar, 
>>> decorations) with automatic layering (z-levels). 
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode