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
____________________________________________________________________
ambassa...@fourthworld.com http://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
