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

[J. Landman Gay via use-livecode]

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 consider adding a mechanism which 
is *card* specific (rather than in full generality). e.g. We add a card 
property which states in which directions a card could be swiped, and it 
uses the standard delays, actions of swiping in the various directions. 
Perhaps you get a swipeBegin message when the swipe starts (where you go 
card or whatever - and a snapshot is taken after - i.e. an implicit lock 
for visual effect); and then a swipeEnd / swipeCancel when it is done.


This would be a very high-level bit of functionality, not that 
configurable.


Thinking about this some more...I'll take whatever we can get. But 
thinking about real-world usage, on Android swiping is very commonly 
used to pull out the sidebar, something almost every Android app has. 
While iOS doesn't indulge in sidebars officially, they are so handy that 
I understand the hamburger menu is being used by iOS developers too 
(Apple frowns on it but looks the other way.)


Since it's possible to get a snapshot of a group that isn't currently 
visible, and since sidebars are commonly LC groups, would that be 
something also easily implemented?


In terms of yak-shaving, I wonder if same-card swipes might even be 
easier to implement than navigation? This type of swipe could be used to 
swipe away lines in lists (provided each line was its own control as per 
datagrids,) or expose controls "under" list items, and so forth. Right 
now there are no visual effects that accurately display this kind of 
animation. I've been struggling to fake an Android toast and have sort 
of made it work by animating within a rectangle, but it isn't perfect 
and requires a very specific card layout to maintain the illusion.


But since I don't know what has to happen under the hood, I'll be happy 
with card navigation if that's a better place to begin.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.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

Compiling LiveCode on Sierra

[Brian Milby via use-livecode]

Is it possible to compile the LiveCode IDE on Mac OS 10.12.6?

I tried to follow the instructions on GitHub.  I have the Xcode versions
downloaded.  I had to use sudo to get the setup_xcode_sdks.sh to finish.
First pass was missing Java, so went back and installed that.  Was able to
configure, but build complains about a missing SDK.  Finally got it to a
point where I saw an error message that the earliest SDK that could be
built against is 10.11 so I tried to edit some files and try again.  It got
further, but failed somewhere in the Skia library.

This was all from the develop branch.  Tried 8.1.6-rc-3 tag and that was
worse.  Also tried 9.0.0-dp-8 with nothing better.

(My goal is to get a build to work so I can try to figure out the missing
AppleScript dictionary... I'm part way there, but not sure if another file
needs to be updated.)

Thanks,
Brian
___
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

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

[J. Landman Gay via use-livecode]

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 you recover from sunstroke I'd be interested to hear about that.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.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

Re: Password Protected stack on the web

[Mark Waddingham via use-livecode]

Yes - the commercial version of LiveCode server (available through your 
LiveCode account area) can use protected stacks.

Warmest Regards,

Mark.

Sent from my iPhone

> On 28 Jul 2017, at 20:36, Todd Fabacher via use-livecode 
>  wrote:
> 
> Can we call a password protected stack from a web server script?
> 
> --Todd
> ___
> 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


___
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

Password Protected stack on the web

[Todd Fabacher via use-livecode]

Can we call a password protected stack from a web server script?

--Todd
___
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

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

[Jonathan Lynch via use-livecode]

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 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) - there are 
> increasing numbers of those which do work and this is set to continue and 
> expand as we have more time to spend on the 'surface' features as opposed to 
> the core.
> 
>> On 2017-07-28 22:22, hh via use-livecode wrote:
>> Probably the "one" (=checking if the mouse is "down") pledged and bought a 
>> HTML5
>> license, the "at least other 2" (=never using it) didn't pledge nor
>> buy a license.
> 
> To be honest, this really is probably not true.
> 
> The thing is that 'the mouse' has long reported the event-asynchronous mouse 
> state, which is almost never what you actually want on modern purely 
> event-driven OSes - so over time its use has diminished as if you use it to 
> do certain things (not all - admittedly), you will end up noticing 
> 'interaction faults' which can be fixed by tracking mouseDown / mouseUp using 
> the event loop. Also, it is generally used alongside 'wait' - which of course 
> does not currently work.
> 
> Obviously you do use it, as do others, so it isn't that it is not important, 
> just that there are lots of other things that we have been working on in the 
> HTML5 engine first which *are* used much more widely.
> 
> It isn't actually possible to get the async mouse state on HTML5, so it will 
> not be 100% the same (although to be fair, the approximation we can use there 
> is probably more correct anyway). It is just a matter of time before we get 
> it to work, not if.
> 
>> I reported to quality center in Dec 2015/Jan 2016, that the state of the 
>> mouse
>> and modifier keys aren't recognized and that all menu buttons crash
>> the standalone.
> 
> Similarly, the modifierKeys. Text entry and keyboard states for the LiveCode 
> engine in HTML5 is another what is a seemingly 'simple' thing from the 
> outside, but is actually not that simple at all under the hood.
> 
> We are still working on solving some issues with text entry - we will solve 
> the problem in time, but again as with other facets of this endeavour some 
> things are taking a lot longer than we had originally anticipated.
> 
>> Since the start of this *395 thousand dollars* project in July 2014 I made at
>> about 60 "successful tests" to show 'oh the HTML5 engine does this' and
>> 'oh it does that'. This wasn't easy at all, needed a _lot_ of workarounds ...
> 
> You've mentioned the amount of money raised several times; however, one thing 
> which everyone has to appreciate is that every project we have crowd-funded 
> has had the value raised matched at least by a factor of 2 from other sources 
> (in some cases significantly more). My point here is not to undervalue the 
> contribution that a good number of you have made, but to illustrate that the 
> scale of the projects we have crowd-funded have been significantly larger 
> than the dollar value we went out to the community to raise would suggest.
> 
> Indeed, we have already spent far in excess of $400k on the HTML5 project 
> when taking into account all work that we have undertake to do it (it isn't 
> just each line of code which is written, but also infrastructure, 
> maintenance, systems and a huge variety of other factors almost all entirely 
> not user/publicly visible).
> 
> There is no problem here (I assure you) - we expected it - we knew it was 
> going to be a large, difficult project. However it is one which was, is, and 
> remains a vital project to finish for our ecosystem as a whole and finish it 
> will shall.
> 
>> So I'll better stop now and wait for the suitable percentage of 'unchanged'
>> LiveCode demos (although "wait" is not allowed in HTML5 deployment).
> 
> I would hope that you will continue to do as you have been - because it has 
> been great to see many of the things you have achieved with the HTML5 engine 
> despite its various obvious omissions in functionality. It also helps us, the 
> engineering team, to see visible progress by users on a project which is 
> large, long and complex (and somewhat frustrating at times!) - particularly 
> when much of the work we are doing, and have been doing is entirely non-user 
> visible!
> 
>> What the team made in HTML deployment until now is *very* good, especially 
>> the
>> "do as javascript" part is excellent. Just put more of the funds (and by that
>> 'bandwidth') into it, so that also basic things (e.g. typing UTF-8 into a 
>> field)
>> do 

Re: HTML5: mixed signals

[Mark Waddingham via use-livecode]

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 suffer me with sunstroke and the somewhat odd effects 
it can have on the mind and this communication was Richard Gaskin - after me, 
Kevin and he spent a night in tents in the Mojave desert!

Sent from my iPhone

> On 28 Jul 2017, at 15:10, Bob Sneidar via use-livecode 
>  wrote:
> 
> 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 
>>  wrote:
>> 
>> 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 remember hearing about such things a few years ago in the UK with regard 
>> education - I didn't say I agreed with it :)
> 
> 
> ___
> 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


___
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

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

[Mark Waddingham via use-livecode]

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) - there are 
increasing numbers of those which do work and this is set to continue 
and expand as we have more time to spend on the 'surface' features as 
opposed to the core.


On 2017-07-28 22:22, hh via use-livecode wrote:
Probably the "one" (=checking if the mouse is "down") pledged and 
bought a HTML5

license, the "at least other 2" (=never using it) didn't pledge nor
buy a license.


To be honest, this really is probably not true.

The thing is that 'the mouse' has long reported the event-asynchronous 
mouse state, which is almost never what you actually want on modern 
purely event-driven OSes - so over time its use has diminished as if you 
use it to do certain things (not all - admittedly), you will end up 
noticing 'interaction faults' which can be fixed by tracking mouseDown / 
mouseUp using the event loop. Also, it is generally used alongside 
'wait' - which of course does not currently work.


Obviously you do use it, as do others, so it isn't that it is not 
important, just that there are lots of other things that we have been 
working on in the HTML5 engine first which *are* used much more widely.


It isn't actually possible to get the async mouse state on HTML5, so it 
will not be 100% the same (although to be fair, the approximation we can 
use there is probably more correct anyway). It is just a matter of time 
before we get it to work, not if.


I reported to quality center in Dec 2015/Jan 2016, that the state of 
the mouse

and modifier keys aren't recognized and that all menu buttons crash
the standalone.


Similarly, the modifierKeys. Text entry and keyboard states for the 
LiveCode engine in HTML5 is another what is a seemingly 'simple' thing 
from the outside, but is actually not that simple at all under the hood.


We are still working on solving some issues with text entry - we will 
solve the problem in time, but again as with other facets of this 
endeavour some things are taking a lot longer than we had originally 
anticipated.


Since the start of this *395 thousand dollars* project in July 2014 I 
made at

about 60 "successful tests" to show 'oh the HTML5 engine does this' and
'oh it does that'. This wasn't easy at all, needed a _lot_ of 
workarounds ...


You've mentioned the amount of money raised several times; however, one 
thing which everyone has to appreciate is that every project we have 
crowd-funded has had the value raised matched at least by a factor of 2 
from other sources (in some cases significantly more). My point here is 
not to undervalue the contribution that a good number of you have made, 
but to illustrate that the scale of the projects we have crowd-funded 
have been significantly larger than the dollar value we went out to the 
community to raise would suggest.


Indeed, we have already spent far in excess of $400k on the HTML5 
project when taking into account all work that we have undertake to do 
it (it isn't just each line of code which is written, but also 
infrastructure, maintenance, systems and a huge variety of other factors 
almost all entirely not user/publicly visible).


There is no problem here (I assure you) - we expected it - we knew it 
was going to be a large, difficult project. However it is one which was, 
is, and remains a vital project to finish for our ecosystem as a whole 
and finish it will shall.


So I'll better stop now and wait for the suitable percentage of 
'unchanged'

LiveCode demos (although "wait" is not allowed in HTML5 deployment).


I would hope that you will continue to do as you have been - because it 
has been great to see many of the things you have achieved with the 
HTML5 engine despite its various obvious omissions in functionality. It 
also helps us, the engineering team, to see visible progress by users on 
a project which is large, long and complex (and somewhat frustrating at 
times!) - particularly when much of the work we are doing, and have been 
doing is entirely non-user visible!


What the team made in HTML deployment until now is *very* good, 
especially the
"do as javascript" part is excellent. Just put more of the funds (and 
by that
'bandwidth') into it, so that also basic things (e.g. typing UTF-8 into 
a field)

do work.


Getting two way communication working in the HTML5 engine has been a 
significant step forward. Particularly as it means we can now do the 
absolute minimum in JavaScript and much more in LiveCode Script (what's 
the point of engineering a language, if one does not use it oneself, 
after all!).


Indeed, I envisage a good deal of the engine functionality we need to 
still implement relative to JavaScript should start being able to be 
done in LiveCode Script - the networking stuff 

Re: controlNames deprecated??

[Richard Gaskin via use-livecode]

Bob Sneidar wrote:

> That [formattedRect] will do the trick, except that while the
> vertical works, the horizontal does not. By that I mean I can
> expand the size of the stack and the top and bottom items do
> not change, but if I expand the stack sideways the right DOES
> change. Further, the left always reports -1.

Is there maybe an object at -1 left?  When I tested here the 
formattedRect returned the bounds of all visible objects reliably.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://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

Re: template stacks

[Mark Wieder via use-livecode]

On 07/28/2017 10:33 AM, Mark Waddingham via use-livecode wrote:


And again, those refinements to the mobile-specific items in the New
Stack menu are a separate matter from settable dimensions for the
Default size.  In practice, new and old users alike will learn as soon
as they start laying out their controls that they will need different
sizes for different windows.


Indeed - they are - I perhaps conflated the two. However, it has 
produced an interesting point of dicussion...


If we can agree that it does make *some* sense to have preconfigured 
sizes in the New Stack menu (for the sake of argument at least - it is 
only real use in a measurable environment which can give us the numbers 
to know whether it does or does not make sense) - what could we do there 
to make it better. i.e. Provide the facility, without the downsides 
which you suggest (which are all entirely valid!).


I've taken a middle route for the Stack Factory in PowerTools:

In addition to a dozen or so predefined sizes there's a menuItem for 
'custom'. That brings up a dialog box that allows you to select the 
desired height and width. And then those values are stored in the 
preferences file. After that point, in addition to the 'custom' menuItem 
there is a 'Most Recent' menuItem for the value you stored in the custom 
setting, so that you don't have to enter them again next time.


--
 Mark Wieder
 ahsoftw...@gmail.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

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

[Mark Wieder via use-livecode]

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

Re: controlNames deprecated??

[Mark Wieder via use-livecode]

On 07/28/2017 01:52 PM, Bob Sneidar via use-livecode wrote:

Duly submitted from Chrome. Something is wrong with Firefox.


I recently had a brief flirtation with Firefox for a few weeks, then 
gave up in disgust and went back to Chrome. Web browsers are such memory 
hogs these days.


--
 Mark Wieder
 ahsoftw...@gmail.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

Re: HTML5: mixed signals

[Bob Sneidar via use-livecode]

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 
>  wrote:
> 
> 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 remember hearing about such things a few years ago in the UK with regard 
> education - I didn't say I agreed with it :)


___
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

Re: HTML5: mixed signals

[Mark Waddingham via use-livecode]

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 remember hearing about such things a few years ago in the UK with regard 
education - I didn't say I agreed with it :)

This is why contracts are important, there are there to protect both employer 
and employee - whether it be in the case of consultants, or full-time employ in 
a company. When we do consulting type work we always clearly define the IP and 
copyright assignments of what we produce - we don't sign until both sides are 
happy.

There's also a different between abstract principals and concrete deliverables. 
Hence the 'wars' over the validity of software patents (as an idea).

A tangible thing which does something is a little different from the abstract 
ideas it embodies. Most countries are still struggling to find out where the 
line is.

Then there are some schools of thought that say that patents in general are 
hurting innovation (they were evolved initially to help ensure it) others which 
still think they are vital. Go figure.

We live in wonderful, imperfect, grey world :)

Mark.

Sent from my iPhone

> On 28 Jul 2017, at 13:45, Bob Sneidar via use-livecode 
>  wrote:
> 
> 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 be of the nature that 
> only the company and those employed by the company is privy to. Even this is 
> shady. What if it is a way to write queries that no one else uses or has 
> thought of? If I employ that in my personal apps does the company own my 
> work? 
> 
> This is why all lawyers (barring any who subscribe to this list) ought to be 
> dragged through the mud and run out of town. 
> 
> Bob S
> 
> 
>> On Jul 28, 2017, at 11:32 , Mark Waddingham via use-livecode 
>>  wrote:
>> 
>> The reason is simple. The programmer is using knowledge and ideas at home 
>> which he did not develop himself - he is using the IP of the company of 
>> which he is part of to do them. He does not own that IP, so he does not own 
>> any derived works of that IP (regardless of where / when / how he derived 
>> said works).
> 
> 
> ___
> 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


___
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

Re: controlNames deprecated??

[Bob Sneidar via use-livecode]

Duly submitted from Chrome. Something is wrong with Firefox. 

http://quality.livecode.com/show_bug.cgi?id=20201

Bob S


> On Jul 28, 2017, at 13:47 , Bob Sneidar via use-livecode 
>  wrote:
> 
> I selected IDE (I did it again) and I cannot see the OS field. The web page 
> is jacked. Or my browser is. Not surprising the latter as Mozilla has been 
> becoming increasingly less usable as the months go by. 
> 
> Bob S
> 
> 
>> On Jul 28, 2017, at 13:39 , Alex Tweedly via use-livecode 
>>  wrote:
>> 
>> It's under item 4 of "enter a bug" ( 
>> http://quality.livecode.com/enter_bug.cgi )
>> 
>> It insists on you filling in this in order - so once you fill in the
>> 
>> "I can see this in ..." (choose IDE vs Desktop vs ...) ,
>> 
>> it will then present you with a box for OS,
>> 
>> then for version,
>> 
>> then for 
>> 
>> -- Alex.
> 
> 
> ___
> 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


___
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

Re: controlNames deprecated??

[Bob Sneidar via use-livecode]

I selected IDE (I did it again) and I cannot see the OS field. The web page is 
jacked. Or my browser is. Not surprising the latter as Mozilla has been 
becoming increasingly less usable as the months go by. 

Bob S


> On Jul 28, 2017, at 13:39 , Alex Tweedly via use-livecode 
>  wrote:
> 
> It's under item 4 of "enter a bug" ( 
> http://quality.livecode.com/enter_bug.cgi )
> 
> It insists on you filling in this in order - so once you fill in the
> 
> "I can see this in ..." (choose IDE vs Desktop vs ...) ,
> 
> it will then present you with a box for OS,
> 
>  then for version,
> 
>  then for 
> 
> -- Alex.


___
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

Re: HTML5: mixed signals

[Bob Sneidar via use-livecode]

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 be of the nature that only 
the company and those employed by the company is privy to. Even this is shady. 
What if it is a way to write queries that no one else uses or has thought of? 
If I employ that in my personal apps does the company own my work? 

This is why all lawyers (barring any who subscribe to this list) ought to be 
dragged through the mud and run out of town. 

Bob S


> On Jul 28, 2017, at 11:32 , Mark Waddingham via use-livecode 
>  wrote:
> 
> The reason is simple. The programmer is using knowledge and ideas at home 
> which he did not develop himself - he is using the IP of the company of which 
> he is part of to do them. He does not own that IP, so he does not own any 
> derived works of that IP (regardless of where / when / how he derived said 
> works).


___
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

Re: controlNames deprecated??

[Alex Tweedly via use-livecode]

It's under item 4 of "enter a bug" ( 
http://quality.livecode.com/enter_bug.cgi )


It insists on you filling in this in order - so once you fill in the

"I can see this in ..." (choose IDE vs Desktop vs ...) ,

it will then present you with a box for OS,

  then for version,

  then for 

-- Alex.


On 28/07/2017 21:14, Bob Sneidar via use-livecode wrote:

I cannot file a bug report. The QCC is saying "A value must be set for the 
'Desktop OS' field, but I am not being presented with a Desktop OS field.

Bob S



On Jul 28, 2017, at 13:11 , Bob Sneidar via use-livecode 
 wrote:


On Jul 28, 2017, at 11:34 , Mark Waddingham via use-livecode 
 wrote:

It is hard to know from this what to expect (as I don't know what structure 
your card has).

Could you file a report in the quality center, with a simple stack which shows 
what you are seeing?

I will file a report, but for those that do not want to dig that up, the 
command:

put the controlnames of card 1 of stack "Passwords"

produces a list of mostly numbers. Note that no lines start with "btn" which 
all my button names begin with. I think Jacque is right, anything in a group gets it's ID 
listed and not it's name.


___
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



___
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

Re: controlNames deprecated??

[Bob Sneidar via use-livecode]

Thanks Jacque and Richard. 

That will do the trick, except that while the vertical works, the horizontal 
does not. By that I mean I can expand the size of the stack and the top and 
bottom items do not change, but if I expand the stack sideways the right DOES 
change. Further, the left always reports -1. 

Bob S


> On Jul 28, 2017, at 12:26 , Richard Gaskin via use-livecode 
>  wrote:
> 
> The formattedRect of the card accounts for object visibility.
> 
> -- 
> Richard Gaskin


___
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

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

[Richard Gaskin via use-livecode]

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 way to give us (well, me, generally) a chance
> to explain various aspects more widely and to a greater audience.

I wish I were so clever.  But the simple truth is I have so little 
contact with folks in the company that I honestly don't know the answers 
to questions like these.  And I do learn a lot from your replies.


> This is, of course, why I sometimes take 1000 words to say things
> which could have been said in 10 ;)

We vie for post length now and then, but you write far less repetitively 
than I do so at least yours are worth reading. :)


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://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

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

[hh via use-livecode]

> 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 percentage  of LiveCode
> stacks which exist *right now* to run in the browser unchanged.
> 
> The problem here is that this is quite subjective - it largely depends on HOW
> you code and use LiveCode (remember my analogy of LiveCode and the elephant 
> and
> the blind men). One thing you have pointed out is that  'the mouse' function 
> does
> not work. It does not, this is true - however, for every person who ever uses
> 'the mouse' function I can be absolutely sure there are probably AT LEAST 2 
> who
> do not. This is true of all LiveCode features to a greater or lesser degree.

Probably the "one" (=checking if the mouse is "down") pledged and bought a HTML5
license, the "at least other 2" (=never using it) didn't pledge nor buy a 
license.

I reported to quality center in Dec 2015/Jan 2016, that the state of the mouse
and modifier keys aren't recognized and that all menu buttons crash the 
standalone.
To have at least two of these three working is for me a basic requirement for
interaction. If I repeat this 'feature request' 20 months later this is 
certainly
no "getting hang up".

And I really didn't take, for nearly three years, this 'negative' easy path as
you decribe, to the contrary:

Since the start of this *395 thousand dollars* project in July 2014 I made at
about 60 "successful tests" to show 'oh the HTML5 engine does this' and
'oh it does that'. This wasn't easy at all, needed a _lot_ of workarounds ...

So I'll better stop now and wait for the suitable percentage of 'unchanged'
LiveCode demos (although "wait" is not allowed in HTML5 deployment).

What the team made in HTML deployment until now is *very* good, especially the
"do as javascript" part is excellent. Just put more of the funds (and by that
'bandwidth') into it, so that also basic things (e.g. typing UTF-8 into a field)
do work. 

p.s. HTML5 standalones can talk to each other, several of them, in one browser
window. I just successfully tested that --- and trashed the demo.


___
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

Re: controlNames deprecated??

[Bob Sneidar via use-livecode]

I cannot file a bug report. The QCC is saying "A value must be set for the 
'Desktop OS' field, but I am not being presented with a Desktop OS field. 

Bob S


> On Jul 28, 2017, at 13:11 , Bob Sneidar via use-livecode 
>  wrote:
> 
>> On Jul 28, 2017, at 11:34 , Mark Waddingham via use-livecode 
>>  wrote:
>> 
>> It is hard to know from this what to expect (as I don't know what structure 
>> your card has).
>> 
>> Could you file a report in the quality center, with a simple stack which 
>> shows what you are seeing?
> 
> I will file a report, but for those that do not want to dig that up, the 
> command:
> 
> put the controlnames of card 1 of stack "Passwords"
> 
> produces a list of mostly numbers. Note that no lines start with "btn" which 
> all my button names begin with. I think Jacque is right, anything in a group 
> gets it's ID listed and not it's name. 


___
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

Re: controlNames deprecated??

[Bob Sneidar via use-livecode]

> On Jul 28, 2017, at 11:34 , Mark Waddingham via use-livecode 
>  wrote:
> 
> It is hard to know from this what to expect (as I don't know what structure 
> your card has).
> 
> Could you file a report in the quality center, with a simple stack which 
> shows what you are seeing?

I will file a report, but for those that do not want to dig that up, the 
command:

put the controlnames of card 1 of stack "Passwords"

produces a list of mostly numbers. Note that no lines start with "btn" which 
all my button names begin with. I think Jacque is right, anything in a group 
gets it's ID listed and not it's name. 

fresh_snow.png
grpControls
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1439
1025
1026
1027
1028
grpPassID
1034
1035
mnuPassType
lblPasswords
fldCustomerName
grpServerName
1047
1048
grpServerPath
1050
1051
grpUseSSL
1055
1056
grpServerPort
1053
1054
grpPassLogin
1037
1511
grpPassword
1040
1041
1512
1514
lblPasswords
dgPasswords
1318
1319
1320
1321
1322
1323
1324
1325
3146
3147
3148
3149
3150
3151
1326
2657
3152
3153
3154
3155
3156
3157
2659
3158
3159
3160
3161
3162
3163
2661
3164
3165
3166
3167
3168
3169
2663
3170
3171
3172
3173
3174
3175
1327
2658
2660
2662
2664
1328
1329
1330
1331
1332
1333
1334
2633
2634
2635
2636
2637
2638
2639
2640
2641
2642
2643
2644
2645
2646
2647
2648
2649
2650
2651
2652
2653
2654
2655
2656
1335
1336
1337
1338
1339
MainMenu
1473
1474
1475
1476
1477
1478
1479
1480
lblSiteName
fldSiteName


___
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

Re: template stacks

[Richard Gaskin via use-livecode]

Richmond Mathewson wrote:

> On 7/28/17 7:01 pm, Richard Gaskin via use-livecode wrote:
>> Am I the only one who doesn't make all of his stacks the same size? :)
>
> No, you're not . . .
>
> *BUT*, imagine working for an employer who had fixated on a set size;
> things would be a lot quicker if everytime one fired up LiveCode to
> knock of a *prototype* (hey, haven't heard that word for a long, long
> time) .

But it's probably not a blank stack they're looking for.  Cloning a 
stack already prepared with the relevant properties, scripts, and 
objects would be much more efficient.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://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

Re: controlNames deprecated??

[J. Landman Gay via use-livecode]

On 7/28/17 1:33 PM, Bob Sneidar via use-livecode wrote:

What I am actually trying to do is get a list of every visible object on a card 
so I can set the windows size to encompass all VISIBLE objects.


In that case, I think you want the formattedRect of the card. It ignores 
invisibles.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.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

Re: Another Browser Widget Question

[Bleiler, Timothy via use-livecode]

Thanks Matthias,

I was working on a bug report and you beat me to it!!


Tim Bleiler, Ph.D.
Instructional Designer, HSIT
University at Buffalo



> On Jul 28, 2017, at 2:35 PM, Matthias Rebbe via use-livecode 
>  wrote:
> 
> I´ve just filed a bug report about the problem that links that should open in 
> a separate tab are not opened in Browserwidget
> 
> Bug 20200 
> 
> 
> 
> Matthias Rebbe
> +49 5741 31
> ‌matthiasrebbe.eu ‌
> 
>> Am 28.07.2017 um 20:22 schrieb Mark Waddingham via use-livecode 
>> >:
>> 
>> On 2017-07-28 20:18, Bleiler, Timothy via use-livecode wrote:
>>> I don’t see any other messages in the dictionary that look applicable.
>>> If one of these was expected to work, then I’ll file the bug report.
>> 
>> Please do file a report - they are the only messages it sends, so if you get 
>> none of them then there is a 'hole' here.
>> 
>> I'm in a different timezone to the UK at the moment so can't just harangue 
>> Ian (who has done most of the work on the browser widget) to ask - so at 
>> least if there's a report, I won't forget about it by Monday :)
>> 
>> Warmest Regards,
>> 
>> Mark.
>> 
>> -- 
>> Mark Waddingham ~ m...@livecode.com  ~ 
>> http://www.livecode.com/ 
>> LiveCode: Everyone can create apps
>> 
>> ___
>> 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
> 
> ___
> 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

___
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

Re: HTML5: mixed signals

[Mark Waddingham via use-livecode]

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 of computing then it really isn't that grey, and 
companies ensure that it is absolutely black-and-white by writing things 
into the contracts of their employees explicitly.


For example, the acceleratedRendering mode of the engine uses a very 
specific method of doing things - it conjoined several ideas together 
which did not (at the time) exist in any open-source product that I 
could find (if it had, I would have been able to probably use that and 
not have to write it myself!).


So, let's say one of my staff had (after seeing and reading the code) 
gone off and written their own version and tried to sell it. We would 
have had a good argument to say that they had stolen our IP. Indeed, 
that staff member would have had to prove that they had acquired the 
knowledge to replicate the functionality from somewhere else or could 
have replicated it without seeing our code. They probably would have 
found it EXCEPTIONALLY difficult to convince a court of this.


So, in generality what you are saying is perhaps not possible. However, 
in pretty much every (very) specific case it is.


Warmest Regards,

Mark.

P.S. I'm not saying this has happened, nor that there is anything 
particular special about acceleratedRendering mode. Just that it is a 
specific example of a small piece of well-defined IP we held (before 
going open-source) which made a good thought experiment.


--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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

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

[Mark Waddingham via use-livecode]

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, generally) a chance to 
explain various aspects more widely and to a greater audience.


This is, of course, why I sometimes take 1000 words to say things which 
could have been said in 10 ;)


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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

Re: HTML5: mixed signals

[Richmond Mathewson via use-livecode]

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 
do it.
His way wasn't better, it was about as silly as my method; BUT his 
pointing the problem out made me see that it was silly and a way to

do the thing I wanted to do in a way that wasn't silly.

OK, OK, I bought him an ice-cream

Richmond.

On 7/28/17 9:32 pm, Mark Waddingham via use-livecode wrote:

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, frankly, stinks, especially as this is NOT during a
period of time for which you are being paid for by your employer.


This does sound familiar - it is probably worth everyone checking the 
fine detail of their contracts in this regard.


I honestly can't remember if (things done at home are your employers 
too) that is a presumption of contract/IP law (i.e. doesn't require 
explicit wording in a contract); or whether it is something which has 
to be explicitly enumerated.


The issue here is actually one of IP and knowledge-in-environment. 
Let's say you have a programmer which is working for a company which 
is doing really bleeding-edge stuff X. The only reason that programmer 
knows anything about X is because he is working for that company. 
Programmer goes home, and starts working on stuff in their own time 
using the knowledge they have about X (or have learnt about X due to 
exposure). The company has to protect itself - and in this case, the 
company would be seen to own the copyright on what the programmer has 
done (as far as I understand it).


The reason is simple. The programmer is using knowledge and ideas at 
home which he did not develop himself - he is using the IP of the 
company of which he is part of to do them. He does not own that IP, so 
he does not own any derived works of that IP (regardless of where / 
when / how he derived said works).


Upshot - best not to do work on things at home which are using 
anything which requires knowledge and ideas you would only been 
exposed to whilst at work, unless you don't mind it being owned by the 
company you work for because it probably will be from the point of any 
court presiding over a case in that fashion, should it come up.


Warmest Regards,

Mark.



___
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

Re: Another Browser Widget Question

[Mark Waddingham via use-livecode]

On 2017-07-28 20:35, Matthias Rebbe via use-livecode wrote:

I´ve just filed a bug report about the problem that links that should
open in a separate tab are not opened in Browserwidget

Bug 20200 


Thanks Matthias.

In this case - I think this isn't something we would want to do 
automatically as the browser width is a single tab (essentially). So the 
solution here is to ensure there is an actionable message.


Now, of course, with that mechanism in place, there's room for a 
property which says 'open new tab requests in this widget' - which might 
cover most cases of this which come up :)


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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

Re: Another Browser Widget Question

[Matthias Rebbe via use-livecode]

I´ve just filed a bug report about the problem that links that should open in a 
separate tab are not opened in Browserwidget

Bug 20200 



Matthias Rebbe
+49 5741 31
‌matthiasrebbe.eu ‌

> Am 28.07.2017 um 20:22 schrieb Mark Waddingham via use-livecode 
> >:
> 
> On 2017-07-28 20:18, Bleiler, Timothy via use-livecode wrote:
>> I don’t see any other messages in the dictionary that look applicable.
>> If one of these was expected to work, then I’ll file the bug report.
> 
> Please do file a report - they are the only messages it sends, so if you get 
> none of them then there is a 'hole' here.
> 
> I'm in a different timezone to the UK at the moment so can't just harangue 
> Ian (who has done most of the work on the browser widget) to ask - so at 
> least if there's a report, I won't forget about it by Monday :)
> 
> Warmest Regards,
> 
> Mark.
> 
> -- 
> Mark Waddingham ~ m...@livecode.com  ~ 
> http://www.livecode.com/ 
> LiveCode: Everyone can create apps
> 
> ___
> 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

___
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

Re: controlNames deprecated??

[Mark Waddingham via use-livecode]

Hi Bob,

On 2017-07-28 19:52, Bob Sneidar via use-livecode wrote:

I can get the controlnames of a card, but at first blush the list does
not include button names. However it *does* list a great many numbers
of 4 digits. So I tried looking up controlNames in the dictionary and
there is no entry for it, at least not by using the find function.


It is hard to know from this what to expect (as I don't know what 
structure your card has).


Could you file a report in the quality center, with a simple stack which 
shows what you are seeing?


It will make it much easier to determine if it is, indeed, a bug, or 
just a strange (but correct) behavior.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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

Re: controlNames deprecated??

[Bob Sneidar via use-livecode]

Hi Jacque. 

My growing consternation is that I have a LOT more lines in the list than show 
up in the application browser. But I suppose I have a lot of groups within 
groups so okay. 

What I am actually trying to do is get a list of every visible object on a card 
so I can set the windows size to encompass all VISIBLE objects. I need to take 
into account group borders though, because a group on one side of the card will 
produce a larger visible distance that the other side (if it contained no 
groups or objects with margins). 

The idea is to have a function which automatically sizes a card to encompass 
all visible objects with extra margins on the 4 sides. I say visible because 
the menuBar is typically invisible on the Mac OS, and I do not want to include 
that, nor do I care about imported graphics I have hidden, like the one I use 
for my background patters for instance. 

It seems there ought to be a way to get the names of all visible objects on a 
card without having to loop through every single field (think datagrids and 
shudder) or button (think menubars and shudder some more) or group (think 
datagrids again containing groups within groups and run screaming naked into 
the hills). 

Bob S


> On Jul 28, 2017, at 11:21 , J. Landman Gay via use-livecode 
>  wrote:
> 
> On 7/28/17 12:52 PM, Bob Sneidar via use-livecode wrote:
>> I can get the controlnames of a card, but at first blush the list does not 
>> include button names. However it*does*  list a great many numbers of 4 
>> digits. So I tried looking up controlNames in the dictionary and there is no 
>> entry for it, at least not by using the find function.
> 
> 
> I just tested this and it looks like the controlNames of a card only return 
> the names of controls whose parent is the card. Controls within a group are 
> listed by ID. I'm not sure if this is correct or not, I can see the logic, 
> but it would seem if the parent has to be the card then controls within a 
> group shouldn't be in the list at all.
> 
> My test card used a background group; it might be different for a card group.
> 
> -- 
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.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

Re: controlNames deprecated??

[panagiotis merakos via use-livecode]

Moreover, the "controlNames" (as well as the "controlIDs") have never been
documented:

http://quality.livecode.com/show_bug.cgi?id=11901

Best,
Panos
--

On Fri, Jul 28, 2017 at 7:30 PM, panagiotis merakos 
wrote:

> Hi Jacque,
>
> Control names within a group can be obtained by:
>
> "the childControlNames of group myGroup"
>
> Best,
> Panos
> --
>
>
> On Fri, Jul 28, 2017 at 7:21 PM, J. Landman Gay via use-livecode <
> use-livecode@lists.runrev.com> wrote:
>
>> On 7/28/17 12:52 PM, Bob Sneidar via use-livecode wrote:
>>
>>> I can get the controlnames of a card, but at first blush the list does
>>> not include button names. However it*does*  list a great many numbers of 4
>>> digits. So I tried looking up controlNames in the dictionary and there is
>>> no entry for it, at least not by using the find function.
>>>
>>
>>
>> I just tested this and it looks like the controlNames of a card only
>> return the names of controls whose parent is the card. Controls within a
>> group are listed by ID. I'm not sure if this is correct or not, I can see
>> the logic, but it would seem if the parent has to be the card then controls
>> within a group shouldn't be in the list at all.
>>
>> My test card used a background group; it might be different for a card
>> group.
>>
>> --
>> Jacqueline Landman Gay | jac...@hyperactivesw.com
>> HyperActive Software   | http://www.hyperactivesw.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
>>
>
>
___
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

Re: HTML5: mixed signals

[Mark Waddingham via use-livecode]

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, frankly, stinks, especially as this is NOT during a
period of time for which you are being paid for by your employer.


This does sound familiar - it is probably worth everyone checking the 
fine detail of their contracts in this regard.


I honestly can't remember if (things done at home are your employers 
too) that is a presumption of contract/IP law (i.e. doesn't require 
explicit wording in a contract); or whether it is something which has to 
be explicitly enumerated.


The issue here is actually one of IP and knowledge-in-environment. Let's 
say you have a programmer which is working for a company which is doing 
really bleeding-edge stuff X. The only reason that programmer knows 
anything about X is because he is working for that company. Programmer 
goes home, and starts working on stuff in their own time using the 
knowledge they have about X (or have learnt about X due to exposure). 
The company has to protect itself - and in this case, the company would 
be seen to own the copyright on what the programmer has done (as far as 
I understand it).


The reason is simple. The programmer is using knowledge and ideas at 
home which he did not develop himself - he is using the IP of the 
company of which he is part of to do them. He does not own that IP, so 
he does not own any derived works of that IP (regardless of where / when 
/ how he derived said works).


Upshot - best not to do work on things at home which are using anything 
which requires knowledge and ideas you would only been exposed to whilst 
at work, unless you don't mind it being owned by the company you work 
for because it probably will be from the point of any court presiding 
over a case in that fashion, should it come up.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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

Re: controlNames deprecated??

[panagiotis merakos via use-livecode]

Hi Jacque,

Control names within a group can be obtained by:

"the childControlNames of group myGroup"

Best,
Panos
--


On Fri, Jul 28, 2017 at 7:21 PM, J. Landman Gay via use-livecode <
use-livecode@lists.runrev.com> wrote:

> On 7/28/17 12:52 PM, Bob Sneidar via use-livecode wrote:
>
>> I can get the controlnames of a card, but at first blush the list does
>> not include button names. However it*does*  list a great many numbers of 4
>> digits. So I tried looking up controlNames in the dictionary and there is
>> no entry for it, at least not by using the find function.
>>
>
>
> I just tested this and it looks like the controlNames of a card only
> return the names of controls whose parent is the card. Controls within a
> group are listed by ID. I'm not sure if this is correct or not, I can see
> the logic, but it would seem if the parent has to be the card then controls
> within a group shouldn't be in the list at all.
>
> My test card used a background group; it might be different for a card
> group.
>
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software   | http://www.hyperactivesw.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
>
___
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

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

[J. Landman Gay via use-livecode]

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 what we need.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.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

Re: Another Browser Widget Question

[Mark Waddingham via use-livecode]

On 2017-07-28 20:18, Bleiler, Timothy via use-livecode wrote:

I don’t see any other messages in the dictionary that look applicable.
If one of these was expected to work, then I’ll file the bug report.


Please do file a report - they are the only messages it sends, so if you 
get none of them then there is a 'hole' here.


I'm in a different timezone to the UK at the moment so can't just 
harangue Ian (who has done most of the work on the browser widget) to 
ask - so at least if there's a report, I won't forget about it by Monday 
:)


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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

Re: controlNames deprecated??

[J. Landman Gay via use-livecode]

On 7/28/17 12:52 PM, Bob Sneidar via use-livecode wrote:

I can get the controlnames of a card, but at first blush the list does not 
include button names. However it*does*  list a great many numbers of 4 digits. 
So I tried looking up controlNames in the dictionary and there is no entry for 
it, at least not by using the find function.



I just tested this and it looks like the controlNames of a card only 
return the names of controls whose parent is the card. Controls within a 
group are listed by ID. I'm not sure if this is correct or not, I can 
see the logic, but it would seem if the parent has to be the card then 
controls within a group shouldn't be in the list at all.


My test card used a background group; it might be different for a card 
group.


--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.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

Re: template stacks

[Mark Waddingham via use-livecode]

On 2017-07-28 20:12, J. Landman Gay via use-livecode wrote:

On 7/28/17 12:35 PM, Mark Waddingham via use-livecode wrote:

On 2017-07-28 19:33, Mark Waddingham via use-livecode wrote:

That being said Ali has been looking at this - we don't want a repeat
of the 8.1.6-RC-2 'balls-up' - and that was entirely down to a
spelling error which *perhaps* would not have happened had we had a
more structured approach to professionals.


Heh - that clearly should have been 'preferences' :)


Autocorrect, I really hate your shirt.


Haha - if only it were autocorrect in this instance (it generally is if 
sending from my iPhone).


In this case (on my laptop) I think it was because I was thinking about 
the next paragraph whilst still writing that one. So more a 
buffering/data transport problem - my fingers are clearly connected to 
my brain by UDP and not TCP/IP ;)


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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

Re: template stacks

[Richmond Mathewson via use-livecode]

Can we all have free T-shirts with "*the 8.1.6-RC-2 'balls-up'**"
on them ?

Love, Richmond.
*
On 7/28/17 9:12 pm, J. Landman Gay via use-livecode wrote:

On 7/28/17 12:35 PM, Mark Waddingham via use-livecode wrote:

On 2017-07-28 19:33, Mark Waddingham via use-livecode wrote:

That being said Ali has been looking at this - we don't want a repeat
of the 8.1.6-RC-2 'balls-up' - and that was entirely down to a
spelling error which *perhaps* would not have happened had we had a
more structured approach to professionals.


Heh - that clearly should have been 'preferences' :)


Autocorrect, I really hate your shirt.



___
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

Re: Another Browser Widget Question

[Bleiler, Timothy via use-livecode]

Thank you Mark,

I'm reluctant to file a bug report if I’m just not handling the appropriate 
message.
I’ve tried catching the following messages in the script of the browser widget 
and none of them appear to be sent when clicking on the example link in a page 
with nothing else defined.
The web page works as expected in my web browser.


BrowserNavigateBegin pUrl, pError

BrowserNavigateFailed pUrl, pError

BrowserDocumentLoadBegin pUrl

BrowserDocumentLoadFailed pUrl, pError

browserUnhandledLoadRequest pURL

browserFrameDocumentLoadBegin pURL

browserFrameDocumentLoadFailed pUrl, pError

I don’t see any other messages in the dictionary that look applicable. If one 
of these was expected to work, then I’ll file the bug report.

Tim Bleiler, Ph.D.
Instructional Designer, HSIT
University at Buffalo

On Jul 28, 2017, at 1:46 PM, Mark Waddingham via use-livecode 
> wrote:

On 2017-07-28 19:30, Bleiler, Timothy via use-livecode wrote:
It’s the browser’s responsibility to handle this html syntax
https://www.w3schools.com; target="_blank">Visit W3Schools
Is there a way to deal with this using the browser widget in Livecode?

In the context of the browser widget, you should get a message when something 
like this occurs, it is then up to your code to decide what to do (it allows 
you to have some control over what happens within the widget).

I must confess I can't remember exactly which message you might need in this 
instance. However, if you take a look in the dictionary under the browser 
widget then there are a fair few to try.

Note: If you find that none of them do work for you in this scenario, file an 
bug in the Quality Center and we'll take a look more deeply.

Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ 
http://www.livecode.com/
LiveCode: Everyone can create apps

___
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

___
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

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

[Richard Gaskin via use-livecode]

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 simply not true. All tools have their limitations, all tools
> have things they are good at and things that they are bad

I think we're closer on this than might have originally seemed:

> Right now JS/HTML5/CSS etc. has the edge over LiveCode in creating
> these rich UIs.
...
> So Swami's approach is the pragmatic one. Use the browser for the
> things it is (currently) SUPERIOR for...

It seems we're both thinking long-term, and in a consistent direction.


>> Related, Jacque's request for swipe transitions was well received,
>> but oddly its status was changed to "Hibernated":
>> http://quality.livecode.com/show_bug.cgi?id=20141
>
> That is the standard process for all enhancement requests.

My apologies, I've only very rarely seen that.  Most of the time 
requests I've submitted or monitored get flagged "Confirmed"; I've only 
seen "Hibernated" a few times, and usually for things we now use "Expert 
Review" for.  If this is the current process no worries.



> Also, that particular request really doesn't in anyway explain how it
> might work ( sorry Jacque :( ) or, indeed, what that syntax is meant
> to  do - so that one has an extra step before moving forward. Actually
> understanding what it is actually about and, indeed, if it even makes
> sense.

Thanks for the interest - I just submitted a first draft spec as comment 
#2 there:

http://quality.livecode.com/show_bug.cgi?id=20141#c2


> There's a huge chasm (I'm mentioning a lot of those lately) between
> an idea, and an actionable idea, and then a huge chasm again between
> an actionable notion and an implementation. (Btw, chasms generally
> require either money or time to cross - or both - it isn't ever that
> they cannot be crossed).
>
> Whilst it might seem that LiveCode's evolution moves at a glacial pace
> at times; it is important to note that when compared to other 4GL
> tools (one mentioned above is a good one) out there (and indeed other
> dev tools in general) we are actually moving at tachyonic pace.

You've known me long enough to know how well that echoes many of my own 
posts here.  Perhaps the only difference is that when I write it some 
call me an "apologist" (I prefer to think of it as "pragmatist"), but as 
with so many things words from the mother ship carry much more weight 
than even the same words posted by anyone else.



> Part of me thinks that we should perhaps slow down a bit (even if just
> a little).

Maybe not a bad idea.  Burning the candle at both ends can result in 
burnout, and burnout can be hard to recover from.  And from time to time 
we see that request from some of the folks here, a desire for a 
maintenance-focused cycle with few of any new features.


Personally, I think v9 is striking a very excellent balance between 
features and fixes, but if you felt slowing down a bit would be 
beneficial I would support that.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://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

Re: template stacks

[J. Landman Gay via use-livecode]

On 7/28/17 12:35 PM, Mark Waddingham via use-livecode wrote:

On 2017-07-28 19:33, Mark Waddingham via use-livecode wrote:

That being said Ali has been looking at this - we don't want a repeat
of the 8.1.6-RC-2 'balls-up' - and that was entirely down to a
spelling error which *perhaps* would not have happened had we had a
more structured approach to professionals.


Heh - that clearly should have been 'preferences' :)


Autocorrect, I really hate your shirt.

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.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

Re: template stacks

[Richmond Mathewson via use-livecode]

On 7/28/17 7:01 pm, Richard Gaskin via use-livecode wrote:

Am I the only one who doesn't make all of his stacks the same size? :)


No, you're not . . .

*BUT*, imagine working for an employer who had fixated on a set size; 
things would be a lot quicker if everytime one fired up LiveCode to knock
of a *prototype* (hey, haven't heard that word for a long, long time) . 
. . .


I generally don't care what size they're created at.  I resize them as 
I work by dragging the edges, as users do.


In those cases where I need a fixed size, the specific dimensions are 
rarely discernible in advance, something I'll need to figure out after 
I've done the layout.


In the rarer case where I need multiple stacks of a specific size, 
chances are I need more common elements than just size, so I'll make 
one how I need it and then clone it.


But those seem pretty rare to me.  On desktop my windows tend to be 
different sizes, and on mobile it's important that they be responsive 
to any screen size; in either case the specific dimensions at the 
moment of creation seem of little value.




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

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

[J. Landman Gay via use-livecode]

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 right now is, quite frankly, always more important 
that work that we might do in the future.


Also, that particular request really doesn't in anyway explain how it 
might work ( sorry Jacque :( ) or, indeed, what that syntax is meant to 
do - so that one has an extra step before moving forward. Actually 
understanding what it is actually about and, indeed, if it even makes 
sense.


I thought you would figure it out. :) Actually, Richard's request here 
on the list was for sample syntax so that's all I suggested. 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.


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, a fast swipe would do a normal visual effect 
swipe, but a slow drag would draw and redraw the effect repeatedly. That 
would allow both regular swipes and also partial swipes that display 
various degrees of the updated display.


I guess we'd also need a message that tells the script whether the swipe 
actually completed fully. If the user changes their mind and doesn't 
complete the gesture (the display snaps back,) the script would have to 
restore the card or navigation to its original state.


Anyone else have a better idea?

--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.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

Re: controlNames deprecated??

[Bob Sneidar via use-livecode]

Sorry, V8.1.5 OS X Sierra

Bob S


> On Jul 28, 2017, at 10:52 , Bob Sneidar  wrote:
> 
> hi all. 
> 
> I can get the controlnames of a card, but at first blush the list does not 
> include button names. However it *does* list a great many numbers of 4 
> digits. So I tried looking up controlNames in the dictionary and there is no 
> entry for it, at least not by using the find function. 
> 
> Bob S
> 
> 


___
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

controlNames deprecated??

[Bob Sneidar via use-livecode]

hi all. 

I can get the controlnames of a card, but at first blush the list does not 
include button names. However it *does* list a great many numbers of 4 digits. 
So I tried looking up controlNames in the dictionary and there is no entry for 
it, at least not by using the find function. 

Bob S



___
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

Re: HTML5: mixed signals

[Richmond Mathewson via use-livecode]

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.




recently, over here: http://community.computingatschool.org.uk/door

there was a discussion to this end:

when I was working at the University of St. Andrews I made 2 RR/LC 
standalones for Chinese and Janapese students to practise English sounds,

at home, in my own time . . .

. . . when I left I asked about this and it was understood that as those 
programs were made in my own time on my own computer they were mine,
although as I had left copies on the server of the University they were 
entitled to full use of them.


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, frankly, stinks, especially as this is NOT during a 
period of time for which you are being paid for by your employer.


Richmond.


___
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

Re: Another Browser Widget Question

[Mark Waddingham via use-livecode]

On 2017-07-28 19:30, Bleiler, Timothy via use-livecode wrote:

It’s the browser’s responsibility to handle this html syntax

https://www.w3schools.com; target="_blank">Visit 
W3Schools


Is there a way to deal with this using the browser widget in Livecode?


In the context of the browser widget, you should get a message when 
something like this occurs, it is then up to your code to decide what to 
do (it allows you to have some control over what happens within the 
widget).


I must confess I can't remember exactly which message you might need in 
this instance. However, if you take a look in the dictionary under the 
browser widget then there are a fair few to try.


Note: If you find that none of them do work for you in this scenario, 
file an bug in the Quality Center and we'll take a look more deeply.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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

Re: Another Browser Widget Question

[Jonathan Lynch via use-livecode]

One point where the LC UI is superior to HTML 

MouseStillDown 

LC has this handler, HTML5 does not - at least not in a simple way.



Sent from my iPhone

> On Jul 28, 2017, at 1:30 PM, Bleiler, Timothy via use-livecode 
>  wrote:
> 
> Hi,
> 
> This has been asked before on this list and in the forums and I’ve never seen 
> even a single reply.
> I assume it’s either blindingly obvious or something we’re "not supposed to 
> do."
> 
> When a web page loaded in the current Livecode browser widget contains a link 
> that should be opened in a tab or new window, clicking on that link does 
> nothing.
> 
> It’s the browser’s responsibility to handle this html syntax
> 
> https://www.w3schools.com; target="_blank">Visit 
> W3Schools
> 
> Is there a way to deal with this using the browser widget in Livecode?
> 
> Thanks,
> Tim Bleiler, Ph.D.
> Instructional Designer, HSIT
> University at Buffalo
> 
> ___
> 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

___
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

Re: template stacks

[Mark Waddingham via use-livecode]

On 2017-07-28 19:33, Mark Waddingham via use-livecode wrote:

That being said Ali has been looking at this - we don't want a repeat
of the 8.1.6-RC-2 'balls-up' - and that was entirely down to a
spelling error which *perhaps* would not have happened had we had a
more structured approach to professionals.


Heh - that clearly should have been 'preferences' :)

Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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

Re: template stacks

[Mark Waddingham via use-livecode]

On 2017-07-28 19:20, Richard Gaskin via use-livecode wrote:

I haven't suggested we get rid of the device-oriented sizes, only
questioning the utility of creating and maintaining a prefs setting
for the Default size.


Heh - well I perhaps got the wrong end of the stick of this thread then 
:)



We already have prefs for controls so maybe it doesn't matter so much.
But the prefs file has become such a source of pervasive brittleness
(how often is ditching the prefs file presented as the answer to a
surprisingly wide range of reported issues?) I just find myself
increasingly pondering whether some of these things need to be
preferences at all.


Geez - tell me about it! Seriously we know its a problem. Like a fair 
few other problems, from the surface it seems like 'it should be easy to 
fix' but when you start pulling on that bit of string, you find it is 
almost never ending (the term 'Yak-Shave' springs to mind).


That being said Ali has been looking at this - we don't want a repeat of 
the 8.1.6-RC-2 'balls-up' - and that was entirely down to a spelling 
error which *perhaps* would not have happened had we had a more 
structured approach to professionals.


As long as preferences are done in a structured manner and you choose 
sensible defaults for them all, then there is no harm in having a lot of 
them. Indeed, I could take Sublime Text as an example. It has a huge 
array of preference settings - however, they have chosen sensible 
defaults for all of them, and they are really easy to modify (they are 
all stored in a JSON file - per user).


Indeed, I'd perhaps say that having fine control (via preferences) over 
all things where a human had to make an explicit choice in design turns 
a good tool into a great tool - particularly for those that consider 
them 'professional' in some manner or means. It allows them to tailor 
the environment to their explicit needs - as they understand more of 
what the environment can do.


Failing to provide such an ability means that you end up appealing to 
the 'lowest common denominator' in some sense - which might be fine when 
you start out in any tool, but as you mature you generally find that 
things start to irk. And as things start to irk, the tool becomes less 
enjoyable to use.



I see good value in providing a general size for phones and another
for tablets.  Having those available in the New Stack submenu is not a
bad thing at all.

Rather than dropping those altogether (which I've never advocated), it
seems more helpful to the new user that we take full advantage of the
opportunity to communicate up front just how useful and flexible
LiveCode is.

One of LC's greatest strengths is the remarkable job you and the rest
of the team do for multi-platform support.  So it seems a shame to
convey to the new user that LiveCode is for iOS exclusively (the only
options provided in the New Stack menu are brand-specific).


Yes - I agree - this is just something we haven't got around to sorting 
out yet. (Okay so it might be a 'simple' thing, however in a sea of 
'simple' things, one still only has so much time so one has to 
prioritise).



And again, those refinements to the mobile-specific items in the New
Stack menu are a separate matter from settable dimensions for the
Default size.  In practice, new and old users alike will learn as soon
as they start laying out their controls that they will need different
sizes for different windows.


Indeed - they are - I perhaps conflated the two. However, it has 
produced an interesting point of dicussion...


If we can agree that it does make *some* sense to have preconfigured 
sizes in the New Stack menu (for the sake of argument at least - it is 
only real use in a measurable environment which can give us the numbers 
to know whether it does or does not make sense) - what could we do there 
to make it better. i.e. Provide the facility, without the downsides 
which you suggest (which are all entirely valid!).


Warmest Regards

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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

Another Browser Widget Question

[Bleiler, Timothy via use-livecode]

Hi,

This has been asked before on this list and in the forums and I’ve never seen 
even a single reply.
I assume it’s either blindingly obvious or something we’re "not supposed to do."

When a web page loaded in the current Livecode browser widget contains a link 
that should be opened in a tab or new window, clicking on that link does 
nothing.

It’s the browser’s responsibility to handle this html syntax

https://www.w3schools.com; target="_blank">Visit W3Schools

Is there a way to deal with this using the browser widget in Livecode?

Thanks,
Tim Bleiler, Ph.D.
Instructional Designer, HSIT
University at Buffalo

___
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

Re: Importing Unicode from MySQL

[Mark Waddingham via use-livecode]

On 2017-07-28 15:24, Trevor DeVore via use-livecode wrote:

SQL Yoga does not. I'm not familiar with the SET NAMES query so I don't
know what the down sides are.


None as far as I can see :)

See:

https://dev.mysql.com/doc/refman/5.7/en/charset-connection.html

Basically SET NAMES and related SET commands in MySQL allow you to 
configure the per-connection attributes which tell the MySQL server what 
charset to send strings to the client in. MySQL 'knows' what charset 
every string in its realm is encoded in, so can happily convert to any 
other for specific clients - you just need to tell it what charset you 
(as a client) are expecting.


In the case of SQLite its UTF-8 all the way down so the problem doesn't 
come up.


Warmest Regards,

Mark.

P.S. I wasn't aware of the SET NAMES statement in MySQL until just now, 
either :)


--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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

Re: template stacks

[Richard Gaskin via use-livecode]

Mark Waddingham wrote:

> On 2017-07-28 18:01, Richard Gaskin via use-livecode wrote:
>> But those seem pretty rare to me.  On desktop my windows tend to be
>> different sizes, and on mobile it's important that they be responsive
>> to any screen size; in either case the specific dimensions at the
>> moment of creation seem of little value.
>
> All of this is very true... However, Richard, how long have you been
> designing/programming/building apps for?

I don't matter.  What matters is how long a new user has been using 
software to want to begin making it.  It doesn't takes long to observe 
that on desktop windows are most frequently different sizes, and mobile 
devices come in different sizes.


I haven't suggested we get rid of the device-oriented sizes, only 
questioning the utility of creating and maintaining a prefs setting for 
the Default size.


We already have prefs for controls so maybe it doesn't matter so much. 
But the prefs file has become such a source of pervasive brittleness 
(how often is ditching the prefs file presented as the answer to a 
surprisingly wide range of reported issues?) I just find myself 
increasingly pondering whether some of these things need to be 
preferences at all.


I won't bother me one way or another, since like Klaus and Mark Wieder I 
make new stacks from a custom plug-in.  If there are enough folks who 
find it valuable to makes desktop windows of a specific size, go for it. 
 I just don't see many apps that need that, so no matter what size the 
stack happens to be created at, most of the time they'll resize it as 
they work.  It doesn't take a seasoned professional to see when you've 
run out of room in a window. :)



> A new user coming to a programming environment (of any kind) is
> usually presented with a wealth of choices. Every choice which can
> at least be parameterised / or constrained as the first step makes
> things 'easier' (in some sense).
>
> This is particularly pertinent to mobile - for sure, all apps should
> be able to adapt to all screen sizes. However, in reality when you
> start out you have to choose one size. Hence the options in the New
> Stack menu.

I see good value in providing a general size for phones and another for 
tablets.  Having those available in the New Stack submenu is not a bad 
thing at all.


Rather than dropping those altogether (which I've never advocated), it 
seems more helpful to the new user that we take full advantage of the 
opportunity to communicate up front just how useful and flexible 
LiveCode is.


One of LC's greatest strengths is the remarkable job you and the rest of 
the team do for multi-platform support.  So it seems a shame to convey 
to the new user that LiveCode is for iOS exclusively (the only options 
provided in the New Stack menu are brand-specific).


Another great thing your team has done is provide wonderful support for 
resolution independence, with good resize messaging for most aops and 
even fullScreenMode for easy implementation of presentation-style apps. 
These allow us to make one good UI that'll work great on all phones or 
tablets.  But rather than guide the user to how we actually do things, 
the Neew Stack menu items imply that they'll need to slavishly copy 
their layouts among any number of device-specific sizes.  Experienced 
users don't do that, and a new user won't stick around long enough to 
become an experienced user if they feel that's what they have to do.


LiveCode is powerful and flexible.  Let's celebrate that in ways that 
guide the user to good practice though enticingly useful UI options.


And again, those refinements to the mobile-specific items in the New 
Stack menu are a separate matter from settable dimensions for the 
Default size.  In practice, new and old users alike will learn as soon 
as they start laying out their controls that they will need different 
sizes for different windows.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://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

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

[Mark Waddingham via use-livecode]

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 allows such UIs to be done. The
problem is that is merely the lowest-level piece. No-one (including
us) has every leveraged it to build a framework like that which we see
in the standard browser stack - they could, it is perfectly possible -
it just has not happened. (Admittedly some of the low-level features
we are adding to AR mode in due course will make this easier but not
really something which could not be achieved before if you worked hard
enough).


Just to clarify this (answering myself again - I know ;)).

This was in no way an 'attack' to say 'oh you guys haven't done it so 
its your own fault' because at the end of the day the fact this hasn't 
happened is OUR (well MY fault).


AcceleratedRendering has been there a very long time - but we've never 
documented it very well, nor really explained how it works. Without 
that, it has languished as a really quite cool thing that no-one has 
ever been given the ability to really learn how to use effectively, and 
more generally (nor be able to tell us that - hmmm it really needs to be 
able to do this and that as well).


Another example of where 'build it and they will come' is a fallacious 
sentiment ;)


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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

Re: Importing Unicode from MySQL

[Bob Sneidar via use-livecode]

Well it wouldn't matter for sqlite, only for mySQL methinks, and if it is 
connection specific, the query can be executed as needed. 

Bob S


> On Jul 28, 2017, at 06:24 , Trevor DeVore via use-livecode 
>  wrote:
> 
> On Wed, Jul 26, 2017 at 3:16 PM, Bob Sneidar via use-livecode <
> use-livecode@lists.runrev.com> wrote:
> 
>> Trevor, does sqlYoga do this automatically? Is there a down side to doing
>> this by default?
>> 
> 
> SQL Yoga does not. I'm not familiar with the SET NAMES query so I don't
> know what the down sides are.
> 
> -- 
> Trevor DeVore


___
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

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

[Trevor DeVore via use-livecode]

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 asynchronicity.
>
> e.g.
>
> on mouseUp
>   async do "..." as javascript into tVar
>   -- implicit wait until tVar has been set
>   put tVar into field 1
> end mouseUp
>
> Note, this is just pseudo-code for the idea. The hardest part about doing
> the callback thing is that it splits up the critical sequence of actions
> you are trying to code into lots of bits separated by cruft (the handler
> definitions). This reduces readability, and maintainability which is
> something we really don't want. i.e. The problem you are trying to solve is
> obfuscated by the technical baggage needed to solve it.
>

To me this is the crux of the issue. Callbacks make the logic more
difficult to follow. Imagine a ui that requires three calls to a web
service before it can display part of the UI. There are three callbacks
that occur. Being able to keep all of the logic in one handler and have the
engine deal with the necessary wait until the async response is received
(or the operation is canceled) would be wonderful.

-- 
Trevor DeVore
ScreenSteps
www.screensteps.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

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

[Mark Waddingham via use-livecode]

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 their limitations, all tools 
have things they are good at and things that they are bad. All tools 
have things they can do, but make it so hard to do so that you can't 
really consider using them for it. In most other endeavours in life we 
don't use a single tool to achieve a goal (to be slightly glib - you can 
only get so far with DIY on your home with JUST a hammer) - so why do we 
absolutely expect this of software development?


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 allows such UIs to be done. The problem is that 
is merely the lowest-level piece. No-one (including us) has every 
leveraged it to build a framework like that which we see in the standard 
browser stack - they could, it is perfectly possible - it just has not 
happened. (Admittedly some of the low-level features we are adding to AR 
mode in due course will make this easier but not really something which 
could not be achieved before if you worked hard enough).


So Swami's approach is the pragmatic one. Use the browser for the things 
it is (currently) SUPERIOR for, but use LiveCode for everything else. 
Each tool on its own is good, but when joined together they become 
great.


This is exactly the angle we have taken with LiveCodeForFM. For 20 
years, FileMaker has been focused on making an easy to use tool which 
makes building database apps (particularly focused around solving 
BUSINESS problems); in contrast we have been focused on making an easy 
to use programming language and app building environment. We've tried to 
solve slightly different problems, so what each tool can do intersects a 
good deal, but mostly does not.


Overall: In isolation, either are good. However, when you put them 
together they complement each other very very well and the combination 
becomes great.



Fortunately it seems some of the work needed for the DG update will
help with some of this.

Related, Jacque's request for swipe transitions was well received, but
oddly its status was changed to "Hibernated":
http://quality.livecode.com/show_bug.cgi?id=20141


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 right now is, quite frankly, always more important 
that work that we might do in the future.


Also, that particular request really doesn't in anyway explain how it 
might work ( sorry Jacque :( ) or, indeed, what that syntax is meant to 
do - so that one has an extra step before moving forward. Actually 
understanding what it is actually about and, indeed, if it even makes 
sense.


There's a huge chasm (I'm mentioning a lot of those lately) between an 
idea, and an actionable idea, and then a huge chasm again between an 
actionable notion and an implementation. (Btw, chasms generally require 
either money or time to cross - or both - it isn't ever that they cannot 
be crossed).


Whilst it might seem that LiveCode's evolution moves at a glacial pace 
at times; it is important to note that when compared to other 4GL tools 
(one mentioned above is a good one) out there (and indeed other dev 
tools in general) we are actually moving at tachyonic pace. Part of me 
thinks that we should perhaps slow down a bit (even if just a little).


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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

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

[Mark Waddingham via use-livecode]

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 with myReturnData
end myCallbackHander

But then again, I’m not a master of javascript, so there may be other 
issues.


I think it is mainly the thought process which goes with having to do 
things in this 'threaded style' - for simple things it is fine, but it 
can get unwieldy pretty quickly for long running sequences of stuff. 
From an abstract perspective, at the very least, it *should* be possible 
to make this more natural (e.g. C# has an 'async' concept - which is 
basically a bit like out wait but more focused) so that is one angle 
here.


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.


It is definitely possible - the fact it is not is related to a technical 
detail in the way the engine interoperates with CEF (and the other 
browsers). However, being possible says nothing about the difficulty of 
getting it to work or ensuring it continues to work!


The HTML5 engine IS synchronous so that gives at least a suggestion that 
is should be possible (although, admittedly, the HTML5 engine IS 
JavaScript so there's no 'world-boundary' to be concerned about in that 
instance).


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


e.g.

on mouseUp
  async do "..." as javascript into tVar
  -- implicit wait until tVar has been set
  put tVar into field 1
end mouseUp

Note, this is just pseudo-code for the idea. The hardest part about 
doing the callback thing is that it splits up the critical sequence of 
actions you are trying to code into lots of bits separated by cruft (the 
handler definitions). This reduces readability, and maintainability 
which is something we really don't want. i.e. The problem you are trying 
to solve is obfuscated by the technical baggage needed to solve it.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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

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

[Richard Gaskin via use-livecode]

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, appears in stores.

Yes, OS-native apps can be made in many languages, including scripting 
languages like LiveCode and JavaScript.


My explorations here are less about the programming languages one might 
use to make them and more about the delivered result, whether the app is 
its own executable or lives within a web browser executable.



> In your quest for understanding,  does your idea of "web app" cover
> this? or are *only* think "delivered runtime from web servers."

More specifically, the distinction is that the app is delivered within a 
browser, since even OS-native apps can have most of their UI and code 
downloaded from a server just like web apps do.



> At any rate, I would re-iterate Jonathan's earlier sentiment, that,
> unless you are a super JS expert, once you get past the presentation
> layer, doing a lot of work that requires manipulation of data, more
> complex framework integration of many elements, Livecode would put
> you far ahead in terms of productivity and transparency.
>
> And even if you *could* you could actually do all that with JS, it
> would be such a horrible snake pit that you and only you could
> possibly maintain it, scale it or refactor it.
>
> 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 LC powerful framework, so that we don't have to
> waste time using JS to get work done, but use it just for "clicking
> here and there" while LC does the heavy lifting in the background.

If the web client technology stack (JavaScript/HTML/DOM/CSS) is a "snake 
pit", do we really want to increase dependency on snakes in LiveCode?


If I want an asynchronous progress indicator like a spinning wheel, 
should it be necessary to include and embed an entire other web 
application process just to get that?  Is that the story we want to tell 
new users?  I'd much rather have an async playback option for the LC 
engine's handling of GIFs, which already covers the other 95% of what we 
need very well.


Same for broader use-cases, like smooth transition effects of the sort 
CSS3 now does so well.  Those are also now so pervasively expected by 
users that it benefits the LC platform more to have as much of that as 
practical right in the engine, rather than limited to one specific 
widget that requires us to leave LiveCode and program it in JavaScript.


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.


Fortunately it seems some of the work needed for the DG update will help 
with some of this.


Related, Jacque's request for swipe transitions was well received, but 
oddly its status was changed to "Hibernated":

http://quality.livecode.com/show_bug.cgi?id=20141

I hope that's only momentary.  Swipe transitions are no longer merely 
optional for mobile UIs, and the level of effort required to work around 
that with groups diminishes many of the advantages of choosing LiveCode, 
lowering LC's score when potential new users do a comparative 
evaluations of tools. I may be a dreamer, but I'd like to see LC match 
or exceed capabilities in such comparisons.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://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

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

[Jonathan Lynch via use-livecode]

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:
> 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 icon.
> end myRequest
> on myCallbackHander myReturnData
>  —do whatever you want with myReturnData
> end myCallbackHander
> 
> But then again, I’m not a master of javascript, so there may be other issues.
> 
> Best,
> Bill
> 
>> On Jul 28, 2017, at 9:16 AM, Jonathan Lynch via use-livecode 
>>  wrote:
>> 
>> 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 are going to rewrite JavaScript AND HTML, how could this be 
>> accomplished?
>> 
>> Sent from my iPhone
>> 
 On Jul 28, 2017, at 11:57 AM, Mark Waddingham via use-livecode 
  wrote:
 
 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 LC powerful framework, so that we don't have to waste
 time using JS to get work done, but use it just for "clicking here and
 there" while LC does the heavy lifting in the background.
>>> 
>>> I can assure you your 'prayer' has been heard - however, there is a slight 
>>> chasm between hearing a prayer and being able to act on it (especially for 
>>> mere mortals, like ourselves ;)).
>>> 
>>> There is a whole (reasonably sized) 'new market' for LiveCode in the space 
>>> of providing the shell into which HTML5/JS webapps can be placed. i.e. The 
>>> creation of a native app which wraps a HTML5/JS web-app which then has 
>>> direct access to all the platform features LiveCode gives you access to (a 
>>> bit like PhoneGap or Cordova or ... - the fact there are so many of these 
>>> things suggests that it is a very useful thing that people actually want to 
>>> do). Now, this works quite well right now - although I do appreciate that 
>>> the asynchronous nature of return values from the host (LiveCode) does make 
>>> some things more difficult to do (*although*, it should be pointed out that 
>>> async something I think *all* other host environments that provide this 
>>> kind of wrapping have to put up with!).
>>> 
>>> However, as you have may have noticed (from various comments - sometimes 
>>> positive, sometimes not, mostly not - about CEF) there is a fair bit of 
>>> technical challenge involved in having a browser widget and keeping it 
>>> working on all platforms. Now, this is not to say we do not like technical 
>>> challenges - we clearly do. However, in general, the greater the technical 
>>> challenge, the greater the resources required to solve it.
>>> 
>>> Such an endeavour *has* to be self supporting - i.e. it needs to generate 
>>> enough revenue in order to justify its existence. The browser widget as it 
>>> stands is already taxing us on that front (it is really important, so 
>>> whilst I sometimes get concerned about the 'money-pit' it sometimes seems 
>>> to be, one has to remind oneself that some things are a long-term 
>>> investment).
>>> 
>>> Of course, the above is entirely related to technical issues - there is 
>>> also the problem of selling LiveCode and this feature into such a space...
>>> 
>>> That old adage of 'build it and they will come' is quite possibly one of 
>>> the biggest load of bovine-backend-excretion that has ever been uttered. 
>>> Build it and, well, most people will walk by it, some might look at it and 
>>> go 'oh that's nice' and walk on, very few will actually take the time to 
>>> visit it without some sort of cajoling. Unfortunately, this kind of 
>>> activity (I'm of course talking about marketing) tends to be a great deal 
>>> more expensive than development (I could make the rather cynical 
>>> observation that there is a reason why marketing consultant's offices tend 
>>> to be a great deal 'nicer' than those of computing consultants - but I 
>>> should probably keep that to myself ;)) and it is only through marketing 
>>> such things that you can make them generate enough revenue to pay for their 
>>> seat at the table.
>>> 
>>> 

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

[Mark Waddingham via use-livecode]

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


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 percentage 
of LiveCode stacks which exist *right now* to run in the browser 
unchanged.


The problem here is that this is quite subjective - it largely depends 
on HOW you code and use LiveCode (remember my analogy of LiveCode and 
the elephant and the blind men). One thing you have pointed out is that 
'the mouse' function does not work. It does not, this is true - however, 
for every person who ever uses 'the mouse' function I can be absolutely 
sure there are probably AT LEAST 2 who do not. This is true of all 
LiveCode features to a greater or lesser degree.


Jacque (for example), clearly has an app that she would really like to 
work in the HTML5 engine. I'd really like this too. Now, I know Jacque 
quite well, I also know her coding style quite well and the way she uses 
LiveCode to solve problems. The app she is talking about should be the 
bread-and-butter of the HTML5 engine however I'm sure it does use a 
number of features which are not the easiest to get working on that 
platform (because I know a bit of Jacque's thought process). Overall, 
without looking at the code in more detail I can't really say how far we 
are from being able to allow it to run well on that platform without 
significant changes. (It might be it is almost there, it might be a very 
long way - but just FOR THAT SPECIFIC app).


In contrast, I've spent a fair bit of time with David Simpson here at 
FileMaker DevCon. Whilst chatting about HTML5 engine, David happened to 
mention that his largest product works perfectly in the current HTML5 
engine - WITH NO CODE CHANGES. This product has (if memory serves me 
correctly) in excess of 100,000 lines of code.


So PLEASE remember, we all have a different view of the elephant. Just 
because something might not yet have reached the point of intersection 
with our OWN view, it does not mean that it has not completely covered 
the view of others. Utility is in the eye of the beholder, and whilst 
our goal is to have the ability to take any LiveCode stack and have it 
run in the browser with no code changes let us not think that just 
because that is not true, it is not actually REALLY useful for many 
cases RIGHT NOW.


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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

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

[William Prothero via use-livecode]

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 icon.
end myRequest
on myCallbackHander myReturnData
  —do whatever you want with myReturnData
end myCallbackHander

But then again, I’m not a master of javascript, so there may be other issues.

Best,
Bill

On Jul 28, 2017, at 9:16 AM, Jonathan Lynch via use-livecode 
 wrote:
> 
> 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 are going to rewrite JavaScript AND HTML, how could this be 
> accomplished?
> 
> Sent from my iPhone
> 
>> On Jul 28, 2017, at 11:57 AM, Mark Waddingham via use-livecode 
>>  wrote:
>> 
>>> 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 LC powerful framework, so that we don't have to waste
>>> time using JS to get work done, but use it just for "clicking here and
>>> there" while LC does the heavy lifting in the background.
>> 
>> I can assure you your 'prayer' has been heard - however, there is a slight 
>> chasm between hearing a prayer and being able to act on it (especially for 
>> mere mortals, like ourselves ;)).
>> 
>> There is a whole (reasonably sized) 'new market' for LiveCode in the space 
>> of providing the shell into which HTML5/JS webapps can be placed. i.e. The 
>> creation of a native app which wraps a HTML5/JS web-app which then has 
>> direct access to all the platform features LiveCode gives you access to (a 
>> bit like PhoneGap or Cordova or ... - the fact there are so many of these 
>> things suggests that it is a very useful thing that people actually want to 
>> do). Now, this works quite well right now - although I do appreciate that 
>> the asynchronous nature of return values from the host (LiveCode) does make 
>> some things more difficult to do (*although*, it should be pointed out that 
>> async something I think *all* other host environments that provide this kind 
>> of wrapping have to put up with!).
>> 
>> However, as you have may have noticed (from various comments - sometimes 
>> positive, sometimes not, mostly not - about CEF) there is a fair bit of 
>> technical challenge involved in having a browser widget and keeping it 
>> working on all platforms. Now, this is not to say we do not like technical 
>> challenges - we clearly do. However, in general, the greater the technical 
>> challenge, the greater the resources required to solve it.
>> 
>> Such an endeavour *has* to be self supporting - i.e. it needs to generate 
>> enough revenue in order to justify its existence. The browser widget as it 
>> stands is already taxing us on that front (it is really important, so whilst 
>> I sometimes get concerned about the 'money-pit' it sometimes seems to be, 
>> one has to remind oneself that some things are a long-term investment).
>> 
>> Of course, the above is entirely related to technical issues - there is also 
>> the problem of selling LiveCode and this feature into such a space...
>> 
>> That old adage of 'build it and they will come' is quite possibly one of the 
>> biggest load of bovine-backend-excretion that has ever been uttered. Build 
>> it and, well, most people will walk by it, some might look at it and go 'oh 
>> that's nice' and walk on, very few will actually take the time to visit it 
>> without some sort of cajoling. Unfortunately, this kind of activity (I'm of 
>> course talking about marketing) tends to be a great deal more expensive than 
>> development (I could make the rather cynical observation that there is a 
>> reason why marketing consultant's offices tend to be a great deal 'nicer' 
>> than those of computing consultants - but I should probably keep that to 
>> myself ;)) and it is only through marketing such things that you can make 
>> them generate enough revenue to pay for their seat at the table.
>> 
>> So TL;DR version. Yes - Kevin and I would both like to do more with the 
>> browser widget as it is actually a really really cool thing (so we hear your 
>> prayers - every one). However, right now, we simply don't feel we have the 
>> bandwidth (to use a Kevinism) to do it properly in a way where the endeavour 
>> can be fully self-supporting. Also, we are already seated at a rather large 
>> dinner at the moment (Infinite LiveCode, 

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

[Jonathan Lynch via use-livecode]

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 are going to rewrite JavaScript AND HTML, how could this be 
accomplished?

Sent from my iPhone

> On Jul 28, 2017, at 11:57 AM, Mark Waddingham via use-livecode 
>  wrote:
> 
>> 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 LC powerful framework, so that we don't have to waste
>> time using JS to get work done, but use it just for "clicking here and
>> there" while LC does the heavy lifting in the background.
> 
> I can assure you your 'prayer' has been heard - however, there is a slight 
> chasm between hearing a prayer and being able to act on it (especially for 
> mere mortals, like ourselves ;)).
> 
> There is a whole (reasonably sized) 'new market' for LiveCode in the space of 
> providing the shell into which HTML5/JS webapps can be placed. i.e. The 
> creation of a native app which wraps a HTML5/JS web-app which then has direct 
> access to all the platform features LiveCode gives you access to (a bit like 
> PhoneGap or Cordova or ... - the fact there are so many of these things 
> suggests that it is a very useful thing that people actually want to do). 
> Now, this works quite well right now - although I do appreciate that the 
> asynchronous nature of return values from the host (LiveCode) does make some 
> things more difficult to do (*although*, it should be pointed out that async 
> something I think *all* other host environments that provide this kind of 
> wrapping have to put up with!).
> 
> However, as you have may have noticed (from various comments - sometimes 
> positive, sometimes not, mostly not - about CEF) there is a fair bit of 
> technical challenge involved in having a browser widget and keeping it 
> working on all platforms. Now, this is not to say we do not like technical 
> challenges - we clearly do. However, in general, the greater the technical 
> challenge, the greater the resources required to solve it.
> 
> Such an endeavour *has* to be self supporting - i.e. it needs to generate 
> enough revenue in order to justify its existence. The browser widget as it 
> stands is already taxing us on that front (it is really important, so whilst 
> I sometimes get concerned about the 'money-pit' it sometimes seems to be, one 
> has to remind oneself that some things are a long-term investment).
> 
> Of course, the above is entirely related to technical issues - there is also 
> the problem of selling LiveCode and this feature into such a space...
> 
> That old adage of 'build it and they will come' is quite possibly one of the 
> biggest load of bovine-backend-excretion that has ever been uttered. Build it 
> and, well, most people will walk by it, some might look at it and go 'oh 
> that's nice' and walk on, very few will actually take the time to visit it 
> without some sort of cajoling. Unfortunately, this kind of activity (I'm of 
> course talking about marketing) tends to be a great deal more expensive than 
> development (I could make the rather cynical observation that there is a 
> reason why marketing consultant's offices tend to be a great deal 'nicer' 
> than those of computing consultants - but I should probably keep that to 
> myself ;)) and it is only through marketing such things that you can make 
> them generate enough revenue to pay for their seat at the table.
> 
> So TL;DR version. Yes - Kevin and I would both like to do more with the 
> browser widget as it is actually a really really cool thing (so we hear your 
> prayers - every one). However, right now, we simply don't feel we have the 
> bandwidth (to use a Kevinism) to do it properly in a way where the endeavour 
> can be fully self-supporting. Also, we are already seated at a rather large 
> dinner at the moment (Infinite LiveCode, LiveCode Connect, LiveCodeForFM, 
> Version 9, Maintenance of 8, ...) so perhaps need to finish *at least* one of 
> those courses before we embark on the next (no-one likes indigestion, after 
> all).
> 
> Warmest Regards,
> 
> Mark.
> 
> P.S. By the way, I'm mainly saying all of this to make it clear that we have 
> been listening, we are just not able to act on it at the moment. Please *do* 
> keep poking us about it - as it keeps the idea in our minds, and each time it 
> comes up it causes a re-evaluation. It also helps to remind people that they 
> CAN use LiveCode for this kind of stuff and so should - which is a precursor 
> to being able to convince people who are not 'LiveCoders' 

Re: template stacks

[Mark Waddingham via use-livecode]

On 2017-07-28 18:01, Richard Gaskin via use-livecode wrote:

But those seem pretty rare to me.  On desktop my windows tend to be
different sizes, and on mobile it's important that they be responsive
to any screen size; in either case the specific dimensions at the
moment of creation seem of little value.


All of this is very true... However, Richard, how long have you been 
designing/programming/building apps for?


A new user coming to a programming environment (of any kind) is usually 
presented with a wealth of choices. Every choice which can at least be 
parameterised / or constrained as the first step makes things 'easier' 
(in some sense).


This is particularly pertinent to mobile - for sure, all apps should be 
able to adapt to all screen sizes. However, in reality when you start 
out you have to choose one size. Hence the options in the New Stack 
menu. It isn't perfect, but at least means a brand new user has some 
chance of choosing a size which will actually fit pixel-for-pixel on the 
device they have next to them to play with.


Now, that menu is not perfect - we know its not - you've pointed that 
out to us often enough ;)


However, we are now actively involved in a process of trying to evaluate 
what 'first-run' things do actually (measurably) make a difference. I'm 
sure that particular menu will be the subject of such 'tests' at some 
point in the process :)


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps


___
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

Re: template stacks

[Richard Gaskin via use-livecode]

Am I the only one who doesn't make all of his stacks the same size? :)

I generally don't care what size they're created at.  I resize them as I 
work by dragging the edges, as users do.


In those cases where I need a fixed size, the specific dimensions are 
rarely discernible in advance, something I'll need to figure out after 
I've done the layout.


In the rarer case where I need multiple stacks of a specific size, 
chances are I need more common elements than just size, so I'll make one 
how I need it and then clone it.


But those seem pretty rare to me.  On desktop my windows tend to be 
different sizes, and on mobile it's important that they be responsive to 
any screen size; in either case the specific dimensions at the moment of 
creation seem of little value.


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 ambassa...@fourthworld.comhttp://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

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

[Mark Waddingham via use-livecode]

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 LC powerful framework, so that we don't have to waste
time using JS to get work done, but use it just for "clicking here and
there" while LC does the heavy lifting in the background.


I can assure you your 'prayer' has been heard - however, there is a 
slight chasm between hearing a prayer and being able to act on it 
(especially for mere mortals, like ourselves ;)).


There is a whole (reasonably sized) 'new market' for LiveCode in the 
space of providing the shell into which HTML5/JS webapps can be placed. 
i.e. The creation of a native app which wraps a HTML5/JS web-app which 
then has direct access to all the platform features LiveCode gives you 
access to (a bit like PhoneGap or Cordova or ... - the fact there are so 
many of these things suggests that it is a very useful thing that people 
actually want to do). Now, this works quite well right now - although I 
do appreciate that the asynchronous nature of return values from the 
host (LiveCode) does make some things more difficult to do (*although*, 
it should be pointed out that async something I think *all* other host 
environments that provide this kind of wrapping have to put up with!).


However, as you have may have noticed (from various comments - sometimes 
positive, sometimes not, mostly not - about CEF) there is a fair bit of 
technical challenge involved in having a browser widget and keeping it 
working on all platforms. Now, this is not to say we do not like 
technical challenges - we clearly do. However, in general, the greater 
the technical challenge, the greater the resources required to solve it.


Such an endeavour *has* to be self supporting - i.e. it needs to 
generate enough revenue in order to justify its existence. The browser 
widget as it stands is already taxing us on that front (it is really 
important, so whilst I sometimes get concerned about the 'money-pit' it 
sometimes seems to be, one has to remind oneself that some things are a 
long-term investment).


Of course, the above is entirely related to technical issues - there is 
also the problem of selling LiveCode and this feature into such a 
space...


That old adage of 'build it and they will come' is quite possibly one of 
the biggest load of bovine-backend-excretion that has ever been uttered. 
Build it and, well, most people will walk by it, some might look at it 
and go 'oh that's nice' and walk on, very few will actually take the 
time to visit it without some sort of cajoling. Unfortunately, this kind 
of activity (I'm of course talking about marketing) tends to be a great 
deal more expensive than development (I could make the rather cynical 
observation that there is a reason why marketing consultant's offices 
tend to be a great deal 'nicer' than those of computing consultants - 
but I should probably keep that to myself ;)) and it is only through 
marketing such things that you can make them generate enough revenue to 
pay for their seat at the table.


So TL;DR version. Yes - Kevin and I would both like to do more with the 
browser widget as it is actually a really really cool thing (so we hear 
your prayers - every one). However, right now, we simply don't feel we 
have the bandwidth (to use a Kevinism) to do it properly in a way where 
the endeavour can be fully self-supporting. Also, we are already seated 
at a rather large dinner at the moment (Infinite LiveCode, LiveCode 
Connect, LiveCodeForFM, Version 9, Maintenance of 8, ...) so perhaps 
need to finish *at least* one of those courses before we embark on the 
next (no-one likes indigestion, after all).


Warmest Regards,

Mark.

P.S. By the way, I'm mainly saying all of this to make it clear that we 
have been listening, we are just not able to act on it at the moment. 
Please *do* keep poking us about it - as it keeps the idea in our minds, 
and each time it comes up it causes a re-evaluation. It also helps to 
remind people that they CAN use LiveCode for this kind of stuff and so 
should - which is a precursor to being able to convince people who are 
not 'LiveCoders' that LiveCode might be something they should check 
out... If only to give them an easier way to ship a 'native' HTML5/JS 
app.


P.P.S. We are also fully away that this 'HTML5/JS' wrapper idea is also 
very much a gorilla activity - they might come for the wrapper, but stay 
because of LiveCode. However, one still needs to capture and tame the 
gorilla first ;)


P.P.P.S. Yes - I know it should have been 'guerilla', it is just that 
using 'gorilla' seemed more fun.


--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
use-livecode mailing 

Re: template stacks

[Klaus major-k via use-livecode]

Hallo Hermann,

> Am 28.07.2017 um 17:18 schrieb hh via use-livecode 
> :
> 
> Of course my "look-up" in the IDE:
> 
>  revIDENewMainstack max(,400),max(,400)
> 
> is quick and dirty compared to the clever plugin-solution of Klaus:
> http://lists.runrev.com/pipermail/use-livecode/2017-July/239883.html

well, that code is from my "tools2" palette I created in the old MetaCard days
about 15 years ago, when there was no revIDE stuff available! :-D

> Sorry Klaus. I overlooked your post. I really write too much and read
> too fast here. I'll better stop it now for a couple of months or so ...

Hey, hey, no need of any excuse really. :-)


Best

Klaus

--
Klaus Major
http://www.major-k.de
kl...@major-k.de


___
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

Re: template stacks

[Mark Wieder via use-livecode]

On 07/28/2017 02:50 AM, Klaus major-k via use-livecode wrote:


Is there a way to edit that menu PERMANENTLY so one
can accommodate one's own sizes?


not permanently, since this will be gone with every new version of LC.

But why not create a plug-in? Nothing easier that that:
Create a stack


Or...
you might find that this is already built into the stack factory feature 
of PowerTools.


http://ahsoftware.net/PowerTools/PowerTools_Objects.lc

--
 Mark Wieder
 ahsoftw...@gmail.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

Re: template stacks

[Brian Milby via use-livecode]

 
 

 Default dimension is 400 (missing value) but if specified then 101 would be 
the smallest (if pHeight  >  100 then...)
 

 
 

 
 
>  
> On Jul 28, 2017 at 10:06 AM,   (mailto:use-livecode@lists.runrev.com)>  wrote:
>  
>  
>  
>  Forget to remark: revIDENewMainstack 40,30 = revIDENewMainstack 400,400 
> because revIDENewMainstack yourWidth,yourHeight sets new width to the maximum 
> of yourWidth and 400 sets new height to the maximum of yourHeight and 400 
> ___ 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 
>
>  
 
 
 
___
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

Re: template stacks

[hh via use-livecode]

Of course my "look-up" in the IDE:

  revIDENewMainstack max(,400),max(,400)

is quick and dirty compared to the clever plugin-solution of Klaus:

http://lists.runrev.com/pipermail/use-livecode/2017-July/239883.html

Sorry Klaus. I overlooked your post. I really write too much and read
too fast here. I'll better stop it now for a couple of months or so ...

___
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

Re: template stacks

[hh via use-livecode]

Forget to remark:

  revIDENewMainstack 40,30 = revIDENewMainstack 400,400

because

revIDENewMainstack yourWidth,yourHeight

sets new width to the maximum of yourWidth and 400
sets new height to the maximum of yourHeight and 400

___
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

Re: template stacks

[hh via use-livecode]

> Richmond wrote:
> From LiveCode 8.0 upwards when one wants a new stack one is given a 
> menu of choices for iPads, iPhones and so on.
> Is there a way to edit that menu PERMANENTLY so one can accommodate
> one's own sizes?

Just type into the messageBox

  revIDENewMainstack ,

for example:

  revIDENewMainstack 400,900
  revIDENewMainstack sqrt(1600),30^2

LiveCode is so wonderful ;-)


___
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

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

[Sannyasin Brahmanathaswami via use-livecode]

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 navigation in our new app, when some 8 year olds and 15 year olds tried it 
and just "had a ball/adventure" with it.

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, appears in stores.

 In your quest for understanding,  does your idea of "web app" cover this? or 
are *only* think "delivered runtime from web servers."

At any rate, I would re-iterate Jonathan's earlier sentiment, that, unless you 
are a super JS expert, once you get past the presentation layer, doing a lot of 
work that requires manipulation of data, more complex framework integration of 
many elements, Livecode would put you far ahead in terms of productivity and 
transparency. 

And even if you *could* you could actually do all that with JS, it would be 
such a horrible snake pit that you and only you could possibly maintain it, 
scale it or refactor it.

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 LC powerful 
framework, so that we don't have to waste time using JS to get work done, but 
use it just for "clicking here and there" while LC does the heavy lifting in 
the background.

BR

___
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

Re: HTML5: mixed signals

[Mark Waddingham via use-livecode]

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 requirements of the GPL then you don't have to worry
about these things too much.


Should have said 'OR the requirements of the GPL' (i.e. attach a 
suitable license to your works if you are using commercial; in the case 
of community, you have to attach the GPL as that is what the GPL 
requires you to do!)


Right - I'm going to stop answering myself now. Promise ;)

Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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

Re: HTML5: mixed signals

[Mark Waddingham via use-livecode]

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 these things too much.


However, if something comes up where it *doesn't* seem entirely 
clear-cut, particularly if the works involved are significant, or the 
money involved is significant (for some definition of significant) it is 
well worth consulting an actual physical lawyer to make sure you aren't 
accidentally stepping on a mine you did not see!


Warmest Regards

Mark.

On 2017-07-28 16:32, Mark Waddingham via use-livecode wrote:

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 license under which you are
receiving it then it is not yours, you cannot touch it, you cannot use
it. If you do, then you could find yourself being subjected to a
copyright-related law suit (depending on how litigious the owner of
the copyright of the source code is). (Generally for very small
'snippets', there is no problem, it is only significant and/or
complete works under which this could be enforced, in general).

If you use the community version, then you are not just obliged, but
you are ABSOLUTELY REQUIRED (by the GPL) to make the full source of
the application you are conveying available UNDER THE GPL (our HTML5
standalone builder makes this easy - as it does it for you :)). This
isn't optional, it is part of the agreement you make by using the GPL
licensed community version in the first place. If you do not do this,
then you are breaking that agreement and in so doing your right to use
the GPL software from which it originated (LiveCode in this case) is
(legally speaking) terminated.

If you use the commercial version, then there are generally no
restrictions on what license you may convey your applications or
source code under. It is reasonable to assume, with the absence of a
license, that if you give someone a software application that they are
allowed to run it. However, that is about as far as you can assume.
The receiver has no right to use any part of the source-code they may
or may not see (this is protected under copyright - the author* of the
source-code of an app is the copyright holder) in any way. So being
able to see source code does not imply a right of use, modification,
distribution or indeed anything. Indeed - even the right to run
received software is necessarily a given (just an implied right, else
why would you send someone it?) - this is why you should always attach
a license to all software you distribute it, explaining the allowed
bounds of use by the receiver.

Of course, the commercial version has password protection built-in, so
you can hide the source of your commercial apps from prying eyes to
give you a level of physical protection; and not just legal. (You have
the legal protection, regardless).

Warmest Regards,

Mark.

* 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. Consulting work is a little more grey - which
is why it is important that you agree the terms of copyright ownership
as part of the contract discussion. Typically this is structured as
'the copyright of code specific to the client project is owned by the
client' but 'any library code not specific to the client which the
consultant has built up to enable her/him to do his work is licensed
under a perpetual license to the client'. Of course, this kind of
thing very much depends on the client - a client is perfectly within
their rights to ask that all code in a project is copyright them...
However, then it is just a question of cost - i.e. if they can afford
to pay for that to be the case!


--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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

Re: HTML5: mixed signals

[Mark Waddingham via use-livecode]

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 license under which you are 
receiving it then it is not yours, you cannot touch it, you cannot use 
it. If you do, then you could find yourself being subjected to a 
copyright-related law suit (depending on how litigious the owner of the 
copyright of the source code is). (Generally for very small 'snippets', 
there is no problem, it is only significant and/or complete works under 
which this could be enforced, in general).


If you use the community version, then you are not just obliged, but you 
are ABSOLUTELY REQUIRED (by the GPL) to make the full source of the 
application you are conveying available UNDER THE GPL (our HTML5 
standalone builder makes this easy - as it does it for you :)). This 
isn't optional, it is part of the agreement you make by using the GPL 
licensed community version in the first place. If you do not do this, 
then you are breaking that agreement and in so doing your right to use 
the GPL software from which it originated (LiveCode in this case) is 
(legally speaking) terminated.


If you use the commercial version, then there are generally no 
restrictions on what license you may convey your applications or source 
code under. It is reasonable to assume, with the absence of a license, 
that if you give someone a software application that they are allowed to 
run it. However, that is about as far as you can assume. The receiver 
has no right to use any part of the source-code they may or may not see 
(this is protected under copyright - the author* of the source-code of 
an app is the copyright holder) in any way. So being able to see source 
code does not imply a right of use, modification, distribution or indeed 
anything. Indeed - even the right to run received software is 
necessarily a given (just an implied right, else why would you send 
someone it?) - this is why you should always attach a license to all 
software you distribute it, explaining the allowed bounds of use by the 
receiver.


Of course, the commercial version has password protection built-in, so 
you can hide the source of your commercial apps from prying eyes to give 
you a level of physical protection; and not just legal. (You have the 
legal protection, regardless).


Warmest Regards,

Mark.

* 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. Consulting work is a little more grey - which is 
why it is important that you agree the terms of copyright ownership as 
part of the contract discussion. Typically this is structured as 'the 
copyright of code specific to the client project is owned by the client' 
but 'any library code not specific to the client which the consultant 
has built up to enable her/him to do his work is licensed under a 
perpetual license to the client'. Of course, this kind of thing very 
much depends on the client - a client is perfectly within their rights 
to ask that all code in a project is copyright them... However, then it 
is just a question of cost - i.e. if they can afford to pay for that to 
be the case!


--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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

Re: HTML5: mixed signals

[hh via use-livecode]

*** 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 protected by the license
you select for that, e.g. an MIT-license.

With an Indy version you can make it more difficult (but *not* disable) to
download the standalone.zip, i.e. avoid the download-source-link.

*** But with an HTML5 license only you can password protect the source code 
(your
scripts) of the standalone. That's the essential effect of the HTML5-license ***

For example I have one script-protected HTML5 standalone: "EasyCrop"
( = selecting by a BezierCurve tool, available on hh.on-rev.com/html5/ )
Just try to hack it ...
All others there have accessible scripts, but you have first to know how to
download the .zip that contains the source (= the "Indy-effect").

With the community version you are obliged to have a download-source-link (it's
generated at bottom right of the standalone canvas) and your scripts are *not*
password-protected.

> Matthias wrote:
> 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.
> Richmondwrote:
> > 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? 
> > 
> > Heather wrote: 
> >> 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. 
> >>> Richmond Mathewson wrote: 
> >>> I just recieved an e-mail from LiveCode central offering me a licence for 
> >>> HTML5 
> >>> for $299/year. 
> >>> And that seems 'normal' considering my Indy licence does NOT include a 
> >>> licence for HTML5. 
> >>> BUT: the Community version allowed me to build an HTML5 thing. 
> >>> That also seems a bit arsy-versy. 

___
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

Re: template stacks

[Mark Waddingham via use-livecode]

On 2017-07-28 11:30, Richmond Mathewson via use-livecode wrote:
From LiveCode 8.0 upwards when one wants a new stack one is given a 
menu

of choices for iPads, iPhones and so on.

Is there a way to edit that menu PERMANENTLY so one
can accommodate one's own sizes?


That is perhaps something we could add to preferences so you could 
configure... Feel free to file an enhancement request for it in the 
quality center :)


Warmest Regards,

Mark.

--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps

___
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

Re: HTML5: mixed signals

[Matthias Rebbe via use-livecode]

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 . . .
> 
> 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:39 pm, Heather Laine via use-livecode wrote:
>> 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 
>>>  wrote:
>>> 
>>> I just recieved an e-mail from LiveCode central offering me a licence for 
>>> HTML5
>>> for $299/year.
>>> 
>>> And that seems 'normal' considering my Indy licence does NOT include a 
>>> licence for HTML5.
>>> 
>>> BUT: the Community version allowed me to build an HTML5 thing.
>>> 
>>> That also seems a bit arsy-versy.
>>> 
>>> Richmond.
>>> ___
>>> 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
>> 
>> ___
>> 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
> 
> ___
> 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

___
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

Re: Importing Unicode from MySQL

[Trevor DeVore via use-livecode]

On Wed, Jul 26, 2017 at 3:16 PM, Bob Sneidar via use-livecode <
use-livecode@lists.runrev.com> wrote:

> Trevor, does sqlYoga do this automatically? Is there a down side to doing
> this by default?
>

SQL Yoga does not. I'm not familiar with the SET NAMES query so I don't
know what the down sides are.

-- 
Trevor DeVore
ScreenSteps
www.screensteps.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

Re: HTML5: mixed signals

[Richmond Mathewson via use-livecode]

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:39 pm, Heather Laine via use-livecode wrote:

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 
 wrote:

I just recieved an e-mail from LiveCode central offering me a licence for HTML5
for $299/year.

And that seems 'normal' considering my Indy licence does NOT include a licence 
for HTML5.

BUT: the Community version allowed me to build an HTML5 thing.

That also seems a bit arsy-versy.

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


___
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


___
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

Re: HTML5: mixed signals

[Heather Laine via use-livecode]

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 
>  wrote:
> 
> I just recieved an e-mail from LiveCode central offering me a licence for 
> HTML5
> for $299/year.
> 
> And that seems 'normal' considering my Indy licence does NOT include a 
> licence for HTML5.
> 
> BUT: the Community version allowed me to build an HTML5 thing.
> 
> That also seems a bit arsy-versy.
> 
> Richmond.
> ___
> 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


___
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

HTML5: mixed signals

[Richmond Mathewson via use-livecode]

I just recieved an e-mail from LiveCode central offering me a licence 
for HTML5

for $299/year.

And that seems 'normal' considering my Indy licence does NOT include a 
licence for HTML5.


BUT: the Community version allowed me to build an HTML5 thing.

That also seems a bit arsy-versy.

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

Re: template stacks

[Klaus major-k via use-livecode]

Hi Richmond,

> Am 28.07.2017 um 11:30 schrieb Richmond Mathewson via use-livecode 
> :
> 
> From LiveCode 8.0 upwards when one wants a new stack one is given a menu
> of choices for iPads, iPhones and so on.
> 
> Is there a way to edit that menu PERMANENTLY so one
> can accommodate one's own sizes?

not permanently, since this will be gone with every new version of LC.

But why not create a plug-in? Nothing easier that that:
Create a stack
Add a pulldown menu (or whtever menu-button you like)
Put this into the menuitems (text of button)
100,100
200,200
400,400
etc. for all wanted sizes, you get the picture

And this is the script for that menubutton:

on menupick which
set the width of the templatestack to item 1 of which
set the height of the templatestack to item 2 of which

##set the loc of the templatestack to the screenloc

## Set some important props first:
set the alwaysbuffer of the templatestack to TRUE
set the destroystack of the templatestack to TRUE
set the destroywindow of the templatestack to TRUE
set the resizable of the templatestack to TRUE
create stack

## Always clean up!
reset the templatestack
end menupick

Put it into you LC plugin folder and that's it! :-)

> Richmond.

Best

Klaus

--
Klaus Major
http://www.major-k.de
kl...@major-k.de


___
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

template stacks

[Richmond Mathewson via use-livecode]

From LiveCode 8.0 upwards when one wants a new stack one is given a menu
of choices for iPads, iPhones and so on.

Is there a way to edit that menu PERMANENTLY so one
can accommodate one's own sizes?

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