Browser Widget/HTML5/LC Integration

Richard Gaskin ambassador at fourthworld.com
Sun Jan 29 14:22:37 EST 2017


Sannyasin Brahmanathaswami wrote:

 > 1) SVG requirements
 >
 > rendering this would be a minimum. If here is a way to do it now in
 > LC let me know
 >
 > http://www.himalayanacademy.com/assets/img/khm-logo-full-horizontal.svg
 >
 > resize your browser, it remains perfect!

If the issue that LC won't render the image, or that it does but you 
also want it automatically resized?

If the former, it would be good to know why LC's Skia isn't doing that.

For the latter, see below under 3).


 > More robust example… not currently set to resize, (but could be)
 >
 > http://wiki.hindu.org/uploads/SivaSivaDiagram.svg

I get:

   This page contains the following errors:
      error on line 353 at column 198: Namespace prefix xlink for
      href on image is not defined
   Below is a rendering of the page up to the first error.


 > 2) Yes I am using the browser widget to show pages on our web site.
 > Even that has lots of issues, but we are working with it. and HQ has
 > been responsive on the issue of thecontent rendering in odd rects..
 > though I am still seeing this in 8.1.3  need to do more testing in
 > the next few days… we made be forced out to use launch URL and send
 > the user off the LC app into the browser app on the phone.. (rather
 > not have to do that)

I would imagine the browser widget would provide easier messaging 
integration than dealing with a completely separate app.  If you find 
otherwise I would be interested in learning how to handle those messages 
between apps.


 > 3) HTML Integration has two use cases (in my current purview, there
 > could be more)
 >
 >   i. simple views
 >
 > this can be created in less than 5 minutes the view consists of  a
 > few lines
 >
 > <ul class="flexdiv">
 > 	<li class="flexpanel1"> Mangos</li>
 > 	<li class="flexpanel2"> Mangos</li>
 > 	<li class="flexpanel1"> Papayas</li>
 > 	<li class="flexpanel2"> Chiku</li>
 > <ul>
 >
 > touch of CSS and you get this:
 >
 > http://wiki.hindu.org/uploads/gui-eg.html

The "touch of CSS" is longer than the object definitions:

<style type="text/css">
.flexdiv {
margin:0;
padding:0;
font-size: 200%;
text-align:center;
}
.flexpanel1 {

  width:100%;
  height:25%;
background-color:rgba(200,0,0,0.2);
}
.flexpanel2 {
  width:100%;
background-color:rgba(0,200,0,0.2);
}


Still more concise compared to equivalent LiveCode for doing the same 
thing in script.  But with LC's GUI controls how often to we write code 
to instantiate them and set all of their properties?

I usually drop an object in and only script things that will change 
dynamically.

But on balance there are indeed opportunities here - and here we get to 
the crux of things:

 > responsive, easily tweaked if the content people want another four
 > rows in the panel, cut and paste, changing props, sure, it's a text
 > file, but so what… change one integer value and all rows change.
 >
 > This simply cannot be done that easily created in Livecode. (Please
 > don't respond with "yes we can make this in LC" I know you can, but
 > to scale change and make it responsive change colors on all objects
 > in the group at once etc.. you need to be an old xTalk wizard with
 > toolboxes)

That last paragraph arbitrarily limits the scope of solutions available, 
so I may not be able to help.  After all, once we decide not to enhance 
LC to better serve your workflow needs why have this conversation here 
at all?

So skipping that and looking at actionable possibilities, we can start 
by reviewing the different rendering models in play:


HTML model: Natural Flow
------------------------
HTML has something we don't:  "natural flow", a set of conventions for 
object placement that are implied and do not need to be specified in 
order to get some form of reasonably useful layout.

The natural flow begins rendering block elements at the upper-left, and 
continues wrapping without overlap downward for each successive element. 
  No coordinates need to be specified to get this layout, which avoids 
overlap as it maintains adjacency automatically.

This fits well with the original goal of HTML for laying out research 
papers, and has been extended with admirable backward compatibility for 
all the things done with it today.

It does require, however, a fair bit of learning when you want to 
specify locations or any non-default placement; the differences between 
"absolute", "relative", and "fixed" are rarely clear to the newcomer, 
and results can vary depending on context.


App Model: Explicit Coordinates
-------------------------------
In contrast, LC follows the coordinate systems as defined by modern GUI 
OSes, in which elements use explicitly-defined placement.

Whether using XCode's Interface Builder, MS Visual Studio's form tools, 
GNOME Glade, or LC's IDE (among many others), objects are placed on 
screen at a given size and location.  Any defaults are often similar to 
those in LC's template objects, providing no automatic adjustment to 
prevent overlap or accommodate resizing.

This is not at all a bad display model given the purpose of such tools, 
making GUI apps, in contrast with HTML's original purpose of laying out 
predominantly textual pages optionally augmented with images.

The particular layout you showed above is easier in HTML, but many 
(most?) traditional GUIs will often require more code/definitions to lay 
out in HTML than in GUI app makers.

The app model is very different from HTML, but not necessarily inferior. 
  Each was designed to prioritize different sets of primary goals, and 
with enough flexibility to allow good support for secondary goals with 
reasonably acceptable effort.


REBOL View: a middle path
-------------------------
The distinct benefits of both HTML and app models find expression in 
only one system I'm familiar with, REBOL View:
http://www.rebol.com/docs/view-guide.html

REBOL View allows explicit placement far more easily than is usually 
found in CSS, but unlike most app models it also includes a sort of 
"natural flow" for elements which do not have explicitly-defined 
coordinates.

A simple example from about a third down the way on the page:

view layout [
     vh2 "Layout Definition:"
     text "Layouts describe graphical user interfaces."
     button "Remember"
]

...renders:
http://www.rebol.com/docs/graphics/layout3.png

The excellent design thinking evident in View's features is more than 
I'd want to bastardize through summarization here.  That page is worth 
spending at least 20 minutes with to get the gist of what View offers.



ONE (of hopefully many) POSSIBLE SOLUTION: libCC
------------------------------------------------
Some years ago I started scratching an itch for a simple way to define 
objects in plain text.

The goal was to make defining objects as sparse as possible, which led 
to a set of useful defaults, similar to how the R language handles 
things, with positioning that relies on a natural flow for automatic 
layout similar to HTML and REBOL View.

This was in a library I called CC, allowing things like:

CC:
fld "name"
fld "age"
btn "Submit"
/CC

...which could be placed in any text container (such as an email) so the 
CC lib could parse it out to create the layout.

I could get into more details about CC, and if there's interest I could 
dig around in my archives to find it and make it compatible with modern LC.

But the point here isn't necessarily my old implementation, but that 
such an implementation can be made, and not without too much work.

I shelved CC simply because, as fun as it was to play with at the time, 
I had no practical use for it.

But if there's sufficient interest in something like a library for 
having a sort of REBOL View-inspired way of defining objects and their 
placement/resizing, a sort of LC-flavored solution for providing 
"natural flow", perhaps it may be worth resurrecting and completing.

Or anyone here could create something else that serves those goals.

Just as View is an optional extension to the REBOL core language, this 
need not require any changes to the LiveCode engine to have it.

All it requires is sufficient interest from the community to get the 
time to make it.

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com




More information about the use-livecode mailing list