Re: Re Pulldownmenu button bug on Windows

[Richard Gaskin via use-livecode]

Klaus wrote:

> Am 11.05.2022 um 20:27 schrieb Richard Gaskin wrote:
>> ... make sure the buttons you're using in the menu stack have
>> their autoArm set to true, ...
>
> Hint:
> that property "autoarm" did not make it into the inspector somehow,
> so you need to do this by script!

It's far from the only one.  LC objects have a LARGE number of 
properties we can work with. The Inspector shows only a subset of the 
most commonly-used ones.


Inspectors are great for consumer tools, but dev tools tend to provide 
Property Sheets so they can expose a much larger range of properties 
developers will want to work with.


LC attempts to straddle the space between consumer tool and dev tool, in 
both marketing and IDE design, and it sometimes leads to things one camp 
or the other may find confusing.


I threw together a quick Property Sheet a while back:
http://fourthworld.net/revnet/devolution/4W_Props.rev.gz

--
 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: Sqlite and Monterey on M1

[Richard Gaskin via use-livecode]

Bob Sneidar wrote:

> I don't think the latest Apple operating systems allow the writing
> to the App Support folder, even if you have explicit write
> permissions.

Where are we supposed to write application support files if not to 
Application Support?


First they demanded control of the file format apps use for Prefs, now 
this...


--
 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: Re Pulldownmenu button bug on Windows

[Richard Gaskin via use-livecode]

Neville Smythe wrote:
> Thanks again Richard
>
> In my case I don’t actually need a workaround. Once I had corrected
> my own error, the only effect of the inconsistent event order is that
> on Windows and Linux the colour coding of the selection turns off a
> fraction of a second earlier than on a Mac. I am not so obsessive as
> to need to fix that.

Glad you have a solution.

Hopefully the demo I posted will be of use to others. Using stacks as 
menus are a poor substitute for text menus when all you need is text, 
but a wide range of graphical pickers can be made which can be very 
attractive and super-simple to make:


Set the menuName property of a menu button to the short name of the 
stack you want to use as a menu, make sure the buttons you're using in 
the menu stack have their autoArm set to true, and all the normal menu 
behaviors you'd expect just work.


Imagine icons used to represent a set of templates, or sample report 
output, or graphical effects, or anything else that lends itself well to 
a graphical picker menu.


I just updated the example stack this morning to include a simple 
graphical picker so folks could get a clearer idea of how it can be very 
useful:


http://fourthworld.net/lc/MenuMessaging.livecode

--
 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: Re Pulldownmenu button bug on Windows

[Richard Gaskin via use-livecode]

What a very kind thing of you to say. Thank you.

After 30 years as a recipient of so much wisdom and lore shared with me, 
I've felt compelled to share some of that forward. In recent years most 
of what I write seems ignored, so I've been spending my time elsewhere. 
Your encouragement may see me checking in on LC stuff more often. Thank you.


--
 Richard Gaskin
 Fourth World Systems


Craig Newman wrote:


Richard.

So glad to have you in this world.

Craig


On May 7, 2022, at 5:35 PM, Bob Sneidar via use-livecode  wrote:

Well put. I wonder what the real world effect of the order of messages is, and 
whether or not it could be compensated for by send in time?

Sent from my iPhone


On May 7, 2022, at 13:44, Richard Gaskin via use-livecode  wrote:

It's definitely an inconsistency, but the bug's status as requiring "EXPERT REVIEW" prompts us to 
consider why these differences exist, and which, if any, should be considered "wrong" or 
"right".  It may not be as simple as it seems at first glance.


Background:
--
MetaCard (the engine we now call LiveCode) was born on Unix, later ported to 
Windows, Linux, and then MacOS.

On all platforms menus are implemented as selector buttons, buttons which 
provide the appearance and behavior of OS-provided menu objects.

And until the port to MacOS, all platforms behaved consistently.

So why the Mac change?

Mac is unique among popular GUI OSes in its use of a global menu bar, attached 
to the top of the display; other OSes place the menu bar attached to the top of 
the window.

Internally, LC menus are implemented as temporary dynamically-instantiated 
nameless stacks, which may seem counterintuitive until you realize that a menu 
is in essence a highly specialized form of window, a viewport independent of 
other windows with its own buffer, contents, and like all windows needs to use 
a common compositor for rendering them all together. (Indeed you can even use 
stacks as menus explicitly when you need a non-standard look, like a graphical 
picker, but that's another topic).

So the engine's method of using a subclass of the stack object for rendering 
menus worked well and consistently for a great many years - until the port to 
MacOS.

The Mac global menubar required a deep rethink on how menus are handled, not 
only in terms of detaching them from the window but also in terms of the 
nuances of display and interaction.

So Dr Raney special-cased menus on MacOS, so the engine uses OS routines to 
render those, fed by the menu button properties for things like the menu name 
as parameters to those OS routines. On every other platform you're interacting 
with a LiveCode object, but on Mac you're interacting with a system object into 
which the engine has inserted some hooks to tie it in with your scripting so 
you can at least know when an item has been selected.

This rewiring of properties and messages is no small feat, and has pervasive effects.  So from time 
to time you'll find Mac-specific things needed to conform to that platform like adding an 
"About" item to a menu that doesn't exist in your stack (the Mac's 
"Application" menu belongs to the OS).

It's not surprising that messages related to menu objects also have some 
inconsistencies along with everything else.

If we consider that on all other platforms the menu object we're interacting 
with is a button, and the menus that appear are a stack, the messaging you see 
with Windows and Linux is consistent with other button object messaging: once 
the mouse leaves the control the mouseLeave message is sent.

On Mac we have an exception to LC's normal button messaging because we're not 
interacting with an LC button at all, but with a system object, into which the 
engine devs have grafted just enough messaging to trigger actions from scripts.

I have no opinion on qualitative labels like "right" or "wrong" on this; that 
seems a matter of personal familiarity and taste. It may even be somewhat philosophical: is a menu 
a single thing that expands, or two things (menu and items) where one triggers the appearance of 
the other?

All I can do is help describe the under-the-hood parts to help makes sense of 
how the difference came about.



The Here-And-Now:

Whether or not we prefer it, the menu architecture is what it is, at least at 
the moment. Changing the behavior on all other platforms to be like Mac, or Mac 
to be like all other platforms, would be a scope of work that I'd guess the 
team would not be in a position to make a priority any time soon, even if they 
felt strongly about this one way or another.

They have a lot on their plates, and for all the questions we see regarding Mac-specific menu differences 
(like the auto-migration of the "About", "Help" and "Preferences" items to 
system menus separate from the menu objects where we're asked to put them), I can't

Re: Decrypting (and encrypting) Large files

[Richard Gaskin via use-livecode]

Mark Clark wrote:

> Wondering if anyone has used LiveCode for encrypting-decrypting large
> files?
...
> I’m thinking about using LC for decrypting zip compressed log files
> that can be multiple gigabytes in size. I’d like to use just LC vs.
> resorting to shell if possible.

What is behind the preference to roll your own rather than call existing 
purpose-built command-line tools from LC with shell()?


Your chunking described in your latest post seems the way to go, AFAIK 
pretty much how other tools would handle it.


Another option:  if you're in an environment where even log files 
require strong encryption, could you pipe log data to a separate secured 
log server instead?


--
 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: Re Pulldownmenu button bug on Windows

[Richard Gaskin via use-livecode]

Neville Smythe wrote:

> My use-case was as follows. I have a pulldownmenu, not an application-
> wide menu, which applied to only certain selected items in a field.
> On mouseEnter, the selection changed colour, as a visual cue to the
> user that these menu items could be applied to the selection. On
> mouseLeave the colour changed back. At some point I inadvertently
> added a line of code to the mouseLeave handler which had the effect
> of killing the selection; this line was supposed to go into the
> menuPick handler. On my Mac the app continued to work as intended,
> but on a user's Windows PC the effect was to change a very minor
> cosmetic difference into a major bug because the menu no longer
> did anything. This was quite difficult to track down.

Thank you for that description.  Just to make sure I understand this, 
the menu button in question is on the card and does not appear in the 
menu bar, is that correct?


I think what you're seeing there is a side effect of the special 
handling LC uses for Mac menus, using OS routines rather than internal 
routines which emulate menus from temporary stacks. On Mac it seems the 
engine is suspending other mouse messages while it lets the OS handle 
the popped up menu, whereas on other platforms the normal mouseLeave is 
happening as soon as the mouse leaves the menu button.


At the moment the only solution I can think of is a bit kludgy, but 
seems to work:


Use stack menus on all platforms, with a timer to track when the menu 
stack has been closed.


It takes more to explain than to demonstrate, so here's a demo - feel 
free to ask any follow-up questions:


http://fourthworld.net/lc/MenuMessaging.livecode


If you want to make the stack menu look less kludgy you could embrace 
the kludge: add a preview pane or other elements that clearly show this 
is a non-standard menu, but in a good way. :)


I sometimes use stack menus for graphical pickers. They're kinda nice 
when you need 'em.


--
 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: Re Pulldownmenu button bug on Windows

[Richard Gaskin via use-livecode]

It's definitely an inconsistency, but the bug's status as requiring 
"EXPERT REVIEW" prompts us to consider why these differences exist, and 
which, if any, should be considered "wrong" or "right".  It may not be 
as simple as it seems at first glance.



Background:
--
MetaCard (the engine we now call LiveCode) was born on Unix, later 
ported to Windows, Linux, and then MacOS.


On all platforms menus are implemented as selector buttons, buttons 
which provide the appearance and behavior of OS-provided menu objects.


And until the port to MacOS, all platforms behaved consistently.

So why the Mac change?

Mac is unique among popular GUI OSes in its use of a global menu bar, 
attached to the top of the display; other OSes place the menu bar 
attached to the top of the window.


Internally, LC menus are implemented as temporary 
dynamically-instantiated nameless stacks, which may seem 
counterintuitive until you realize that a menu is in essence a highly 
specialized form of window, a viewport independent of other windows with 
its own buffer, contents, and like all windows needs to use a common 
compositor for rendering them all together. (Indeed you can even use 
stacks as menus explicitly when you need a non-standard look, like a 
graphical picker, but that's another topic).


So the engine's method of using a subclass of the stack object for 
rendering menus worked well and consistently for a great many years - 
until the port to MacOS.


The Mac global menubar required a deep rethink on how menus are handled, 
not only in terms of detaching them from the window but also in terms of 
the nuances of display and interaction.


So Dr Raney special-cased menus on MacOS, so the engine uses OS routines 
to render those, fed by the menu button properties for things like the 
menu name as parameters to those OS routines. On every other platform 
you're interacting with a LiveCode object, but on Mac you're interacting 
with a system object into which the engine has inserted some hooks to 
tie it in with your scripting so you can at least know when an item has 
been selected.


This rewiring of properties and messages is no small feat, and has 
pervasive effects.  So from time to time you'll find Mac-specific things 
needed to conform to that platform like adding an "About" item to a menu 
that doesn't exist in your stack (the Mac's "Application" menu belongs 
to the OS).


It's not surprising that messages related to menu objects also have some 
inconsistencies along with everything else.


If we consider that on all other platforms the menu object we're 
interacting with is a button, and the menus that appear are a stack, the 
messaging you see with Windows and Linux is consistent with other button 
object messaging: once the mouse leaves the control the mouseLeave 
message is sent.


On Mac we have an exception to LC's normal button messaging because 
we're not interacting with an LC button at all, but with a system 
object, into which the engine devs have grafted just enough messaging to 
trigger actions from scripts.


I have no opinion on qualitative labels like "right" or "wrong" on this; 
that seems a matter of personal familiarity and taste. It may even be 
somewhat philosophical: is a menu a single thing that expands, or two 
things (menu and items) where one triggers the appearance of the other?


All I can do is help describe the under-the-hood parts to help makes 
sense of how the difference came about.




The Here-And-Now:

Whether or not we prefer it, the menu architecture is what it is, at 
least at the moment. Changing the behavior on all other platforms to be 
like Mac, or Mac to be like all other platforms, would be a scope of 
work that I'd guess the team would not be in a position to make a 
priority any time soon, even if they felt strongly about this one way or 
another.


They have a lot on their plates, and for all the questions we see 
regarding Mac-specific menu differences (like the auto-migration of the 
"About", "Help" and "Preferences" items to system menus separate from 
the menu objects where we're asked to put them), I can't recall seeing a 
message here before about mouseLeave.


I'm not saying it isn't important. It might well be. But observably this 
affects few; AFAIK this is the first such request in the 23 years I've 
been using this engine and participating in its communities. Just the 
same, let's roll up our sleeves and see what can be done:




Looking Forward:
---
Edge case or not, let's see what we can do to get a solution for you 
sooner than the engine team would be able to even thinking about 
revisions as sweeping as would be needed to satisfy the engine request.


What do you need from mouseLeave during a menu drop? What are you doing 
in response to that message?


There are some clever people on this list. I'll bet we can find a 
solution for your need once we more fully understand the goals.


--
 Richard Gaskin
 Fourth 

Re: devcon 2022 recap

[Richard Gaskin via use-livecode]

Mark Talluto wrote:

> I am happy to say that Richard Gaskin is our first 3rd party provider.
> He wants to make connections for many things external. Databases is
> top on the list the last time we spoke. I’ll ping him to chime in with
> more details.


Thank you, Mark.

The current vision for the plugin is to provide at least basic CRUD 
operations for SQL DBs, which would of course mean MySQL with postgreSQL 
and MariaDB coming along for the ride. Some form of this could become an 
LC tool as well as an Appli component.


The opportunity is obvious: it's nice to have a convenient UI for 
accessing organizational data ponds.


The challenges are two-fold: providing consistent access across what may 
be a wide range of DB API styles depending on IT habits within 
prospective orgs, and authentication methods those orgs support.



DB Access:

The challenge with this is identifying applicable use cases. Where orgs 
using Appli or LiveCode may allow internal direct access to DBs, this is 
a relatively simple matter, as the socket comms for those are consistent.


But most orgs use HTTP-based APIs for DB operations. This is popular 
even for internal use, and usually consider necessary for all 
connections from the open Internet.


Over the coming months we'll be discussing needs with prospective 
customers to identify API patterns to see where we can provide a UI that 
allows them to easily drop in URLs needed for access.  It may be that 
we'll have to offer a setup service to get less technically-inclined 
customers going, but some orgs may not provide external API access for 
internal APIs. We'll see how that unfolds as we learn more about use cases.



Authentication:

Where API authentication is done through httpBasic or OAuth2, LC's 
excellent support for both makes those straightforward.  But many larger 
orgs use LDAP for authentication.


So far I've not seen an LDAP library for LC, and having reviewed the 
LDAP specs it seems a task worth thinking about very carefully before 
committing to delivery.


If any of you know of an LDAP authentication library for LC Script that 
would be very helpful.



More to come as research on this unfolds...

--
 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: Native Android input field

[Richard Gaskin via use-livecode]

J. Landman Gay wrote:

> In the after-party that Richard set up on the last day of the
> conference, the question came up whether the native Android
> field widget would scroll. The answer is, yes it does.
>
> There is one little glitch. If the widget is editable, and your
> finger lifts inside the widget after scrolling, the keyboard pops
> up. If you end the scroll while your finger is outside the
> field area, it does not.
>
> This doesn't happen if the field is not editable. Also in either case,
> the scroll isn't as smooth as it is when constructed in a script.
>
> 


Good find with that bug report.  Thanks for submitting it.

The circumstance I introduced in the chat was something far more common: 
just scrolling a field, a normal non-editable LC field used to display text.


Doing that without jittery motion and with appropriate scroll-end 
indication in LiveCode for mobile requires following the steps in this 
tutorial:


https://lessons.livecode.com/m/4069/l/94412-creating-a-native-scroller-to-scroll-a-field

Seems pretty fiddly just to scroll a field.

Makes me wonder how many of us would be using LC if those steps were 
required to have normal scrolling in our desktop apps when we were first 
considering this platform.


--
 Richard Gaskin
 Fourth World Systems

___
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: devcon 2022 recap

[Richard Gaskin via use-livecode]

Yes, but that's something of an "expert feature" in that intended 
market, much like coding externals for LC.


In terms of general product flavor and intent, LC is "low code" and 
Appli is "no code".


Given the clear mission for each, they seem good compliments.

--
 Richard Gaskin
 Fourth World Systems



Mark Wieder ahsoftware at sonic.net
Thu Apr 28 16:08:44 EDT 2022

Previous message (by thread): devcon 2022 recap
Next message (by thread): devcon 2022 recap
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

On 4/28/22 12:54, Richard Gaskin via use-livecode wrote:

To clarify:

"low code" is just a modern term for what LC's been providing the whole 
time.


"no code" is what Appli does, an adjacent but very different market for 
those whose needs can be satisfied without the nuance scripting provides.




I think what I saw in Mark's keynote is the ability in appli do some 
coding, just not to any extent the deep capabilities of LiveCode. Thus 
"low code".



___
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: devcon 2022 recap

[Richard Gaskin via use-livecode]

Mike Kerner wrote:

> * This wasn't discussed, but there is supposed to be some
> fixing coming in dp's of 10 for behaviors, especially
> nested behaviors

I missed a bug report: what are the issues with nested behaviors?


> * Still nothing on dealing with the way groups are handled.

What aspects of group handling, and how should they be different?

--
 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: devcon 2022 recap

[Richard Gaskin via use-livecode]

To clarify:

"low code" is just a modern term for what LC's been providing the whole 
time.


"no code" is what Appli does, an adjacent but very different market for 
those whose needs can be satisfied without the nuance scripting provides.


--
 Richard Gaskin
 Fourth World Systems


Mark Wieder wrote:


On 4/28/22 12:02, Mike Kerner via use-livecode wrote:


* The whole low-code piece...meh. It feels like they're chasing another
dead end.


Oh, I gotta disagree there. Just a different target audience.

Maybe not for those of us already in the flock, but I think what's been 
missing from LiveCode is that first-user experience. The one when you 
first launched HyperCard and were able to connect a button to a new card 
without doing anything more than point and click and bang! you had a 
working application. I think appli can be the gateway drug to LC that 
expands the subscriber base, and that's good for everybody.


--
  Mark Wieder
  ahsoftware at 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

You're invited: LC DevCon After-Party

[Richard Gaskin via use-livecode]

The LC DevCon is so much fun it seems fitting to add one more session 
off-schedule and completely informal: a Zoom after-party.


Come and hang out anytime today (Weed, 27 April)  from 6:00 PM EDT until 
6:40 PM EDT.


That gives us an hour after the close of the last session to take a 
moment to breathe and catch up on emails and stuff before hanging out 
with pals to discuss the conference and anything else that comes up.


Here's the Zoom invite - zoom will grant access for the first 100 
attendees, and we'll have 40 minutes to hang out:


--

Richard Gaskin is inviting you to a scheduled Zoom meeting.

Topic: LiveCode DevCon After-Party
Time: Apr 27, 2022 03:00 PM Pacific Time (US and Canada)

Join Zoom Meeting
https://us02web.zoom.us/j/88049771247?pwd=VUVPdVJBQnYwT09pdThzdE04djVMZz09

Meeting ID: 880 4977 1247
Passcode: 1q8uGx


--
 Richard Gaskin
 Fourth World Systems

___
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: Pixel 5

[Richard Gaskin via use-livecode]

Mike Kerner wrote:

> I am on my second droid phone, and I agree, I probably could never
> go back - but, for corporate app deployment and deployment, ios is
> happier place.

What have I been missing?  Last time I did native mobile Apple was still 
making devs jump through hoops just to install apps that aren't even 
going into their app store. On Android we just turn off the sideloading 
protection, install, and turn it back on again - no 
handholding/gatekeeping from the  OS provider needed, no contact with 
them needed at all.


All this time I thought Apple's message for orgs making apps for 
internal use was to use Android. I sometimes do medical apps, where iOS 
is strongly represented. I'd love it if Apple has a way to beat Android 
for ease of deployment.


--
Richard Gaskin
Fourth World Systems


___
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: Using LiveCode with Mac Photos App

[Richard Gaskin via use-livecode]

David Epstein wrote:

> Is there any way from within Photos to gain access to the file
> locations for convenient use by LiveCode?

Apple's Photos app stores all the metadata in an SQLite file, no?

If so, you may be able to poke around in the DB file directly.

If Apple prevents that, you may be able to query it via AppleScript.

--
 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: Encountering slow navigation to a card containing very large fields? Do this one simple trick.

[Richard Gaskin via use-livecode]

David V Glasgow wrote:

> On 16 Apr 2022, at 8:20 pm, Richard Gaskin wrote:
>>
>> How many is "many many thousands of lines"?  10k? 100k? More?
>
> Typically 30,000 to 800,000.

What is the user asked to do with 800,000 lines of data?

That is, does this need to be displayed?


>> Is the data displayed in list fields, or must the line wraps be
>> calculated?
>
> The wrapped line field is locked and doesn’t change after import
> and is unaffected by the  keyword-containing-lines process.  I
> suppose a good question is are line wraps recalculated on navigation
> to the card.

I'd guess that the card record is unpacked before rendering, which would 
include the controls, such as fields, and their contents.


--
 Richard Gaskin
 Fourth World Systems

___
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: Encountering slow navigation to a card containing very large fields? Do this one simple trick.

[Richard Gaskin via use-livecode]

David Glasgow wrote:

> I have a card (A) with two fields in separate groups.  Field 1
> contains many many thousands of lines of text which are filtered
> for keywords and the results displayed in field 2 (which can also
> be many thousands of lines).  The user can navigate to a separate
> card (B) to view summary statistics and a bar chart.
>
> I found that worked fine, but navigating back from B to A always
> took many seconds and looked like a hang.  The delay seemed to be
> in some way proportional to the number of lines in field 1 and
> field 2.

How many is "many many thousands of lines"?  10k? 100k? More?

Is the data displayed in list fields, or must the line wraps be calculated?

--
 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: Widget properties

[Richard Gaskin via use-livecode]

Thank you for your reply, Monte. Comments inline:

Monte Goulding wrote:
>> On 7 Apr 2022, at 11:25 am, Richard Gaskin wrote:
>> Can you help me understand how it's better than "the properties",
>> and why this superior method isn't used for engine controls?
>
> Because the array created by export and used by import contains
> the state of the widget as is saved when saving the stack. The
> content may or may not be the same as the property names exposed
> to user scripts but a widget created with that state should be
> the same as if it were saved in the stack and the stack re-opened.

I've never used a widget in production yet, so I can't say I have an 
opinion there.  If the uses for widgets are viewed as sufficiently 
different from engine-based controls that "the properties" so many of us 
enjoy wouldn't apply, I'm okay with that. Just looking to understand.



>> That the company has such a narrowly specific view of the
>> applicability of "the properties" is indeed helpful. Thank
>> you for chiming in.
>
> I’m not the company.

Pardon my imprecision. I think the readers here are likely aware that 
the company is comprised of many people, and there are likely many 
different opinions on a wide range of topics, including this.  Please 
read that as "a significant member of the company".



> Mark may spend a lot more time pondering the utility of `the
> properties` than I do and indeed may have a different opinion.
> Indeed my opinion was much closer to yours is now when I sent
> in a PR for LC 6.1 all those years ago ;-)

One of the challenges with a tool as vastly capable as LiveCode is 
wrapping one's head around all the use-cases, and all the perceived 
priorities.  Various members of the company and the community have 
expressed a wide range of opinions on many things.


If "the properties" winds up being like the pointer tool requests I used 
to ask about, no worries. I stopped asking about those years ago.


Indeed, even with "the properties" I've had a few discussions on this 
with different team members going back to Dr Brett, back when LCB was in 
its earliest stages.


In my own mind having two different methods for obtaining property data 
for two classes of objects is akin to having two different words for 
"rect" or other basic features.  Where a useful implementation has been 
chosen and established so long ago, it seems worth mirroring in new 
implementations.


But TBH, since I haven't used widgets in production at all, the only 
time it comes to mind is when someone asks me about it for one of my 
tools, or in discussions like this one. This seemed a good time to see 
what the current vision is. I appreciate the clarity provided.



>> How hard would it be for the team to map the existing means of
>> extracting widget properties to "the properties”?
>
> I don’t think it would be particularly tricky to iterate the exported
> property definitions to come up with a list of property names then
> turn that into a key/value array. Whether it would provide the utility
> you are looking for is a separate question.

If it does what "the properties" does it would suit my needs.

--
 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: Widget properties

[Richard Gaskin via use-livecode]

Mark Wieder wrote:

> On 4/6/22 16:39, Richard Gaskin via use-livecode wrote:
>
>>  > ...there has never been any intention of supporting the properties
>>  > for widgets as far as I’m aware...
>>
>> If the company wants widgets to be seen as first-class citizens, a
>> little more conformity with existing object syntax would go a long
>> way to making that happen.
>
>
> Adding to that is the incoming LCS widget architecture, so I'm not
> putting deep learning time into something I'll just have to unlearn
> when the next wave hits.

Succinctly put.


Back when Ben was fleshing out the "before" and "after" messaging 
options, and the object-local mirror of the selectGroupedControls 
property for groups, and other such things that have made the DataGrid 
such a joy to work with, I had high hopes that this effort to 
encapsulate compound objects durably would continue.


I'm very excited by the choice to return to that effort.  LCB is a fine 
language, and I'm as envious of its indexed arrays as I am mystified why 
they haven't found their way into LCS.  But it's so easy to make 
compound objects in LCS I haven't been able to justify the time to learn 
a similar-but-incompatible language.


So soon we will have three classes of objects: engine-native, widgets, 
and whatever the LCS-based widgets are called.


It would be great to have a single robust, uniform serialization for 
their attributes.


--
 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: Widget properties

[Richard Gaskin via use-livecode]

Monte Goulding wrote:

> It seems a stretch to imply the lack of support for a property that
> has little to no use case outside the IDE means the company doesn’t
> take widgets seriously but I’m not going to argue with you about that.

A reasonable choice, given that "seriously" is a colloquialism with no 
specific quantifiable meaning.


Here I used it to try to elicit LC's vision for widgets.  I had the 
(quite possibly mistaken) notion that widgets were a way to craft 
reusable controls that would look and feel like engine objects, but with 
the advantage that they could be created from a scripting language.


We see many queries here about messages common to all other controls not 
working with widgets, and now and then we see queries about properties 
and functions too.


"The properties" is just the latest of these, and your view of that here 
is helpful:


> I will say there’s two main use cases for `the properties` and neither
> of them it serves very well:
>
> - Getting the properties of an object to apply to recreate the object
> elsewhere. export widget does a much better job of this and was
> designed specifically for that use case.

Can you help me understand how it's better than "the properties", and 
why this superior method isn't used for engine controls?



> - Introspecting what properties an object has in order to create an
> editor without maintaining your own lists of properties. It has never
> been good at this. It doesn’t tell you anything about acceptable
> values for those properties, it doesn’t tell you the importance of
> the property, it doesn’t tell you about alternative object properties
> that may be more useful to edit (text, styledText, htmlText, rtfText
> etc) or whether it’s potentially risky to present a UI that can edit
> it. Really this use case is served best by a well documented library
> that covers all objects. Currently you would need to dig the details
> out of the IDE scripts

That seems to answer the first question, though while the metadata about 
types and options is useful for some things, it would still be useful to 
get just the name-value pairs as "the properties" does.


That the company has such a narrowly specific view of the applicability 
of "the properties" is indeed helpful. Thank you for chiming in.


I use "the properties" in a great many things, even outside the IDE 
tools, though those are about half of everything I've been doing as one 
of the few people outside the company working full-time with LC for as 
long as I have.


Much of what I do is bespoke authoring systems, and frequently they're 
implemented as plugins.  This is something I love about xTalks, and the 
SC/MC/LC philosophy that's driven the post-HC world. SC's Bill Appleton 
summed it up well when he once said:


"HyperCard is a multimedia authoring system. SuperCard is a tool
 you can use to build multimedia authoring systems."

For myself, and a good many others I know, the value of making tools is 
not limited to the IDE team, but a core value and key differentiator of 
choosing LiveCode.


I have lot of ways to make software. But few of them let me redefine the 
workflow as flexibly as an xTalk. And no xTalk has been as flexible as 
LiveCode.


It's like the difference between a drawing program and a scriptable 
drawing program, or between Wordpress and Drupal, or between a sculpture 
and modeling clay.


I appreciate your team making an IDE, but for most of us who make our 
living with it it's only part of the toolset we use.



On the more consumer-facing side which may better fit a view in which 
tooling is seen as for the engine team only, consider styling:


When we set "the properties" of an object, it affects only the keys 
present, leaving everything else alone.


This means we can make arrays with any subset of relevant attributes we 
want, and apply them almost like style sheets with just one line.  We 
can even save these prop subsets to disk as LSON files if we like, so we 
can reuse them, mixing and matching from screen to screen and project to 
project as we like.


In fact, using "the properties" has become such a habit across so much 
of what I do I have to admit that I need to think about it to list them 
all, in the way a fish struggles to define water.



Arrays are a great foundational data type, and being able to express 
controls with them efficiently and uniformly is a godsend.


From my perspective, perhaps no less limited than someone who works all 
day on the IDE but coming at it from a different angle, the question 
seems less interesting as "Why is this useful?" than "How could it not be?"



Let me simplify the question:

How hard would it be for the team to map the existing means of 
extracting widget properties to "the properties"?


--
 Richard Gaskin
 Fourth World Systems
 Software Design and Development for the Desktop, Mobile, and the Web
 
 

Re: Widget properties

[Richard Gaskin via use-livecode]

Monte Goulding wrote:

> ...there has never been any intention of supporting the properties
> for widgets as far as I’m aware...

If the company wants widgets to be seen as first-class citizens, a 
little more conformity with existing object syntax would go a long way 
to making that happen.


It's possible for the engine to derive a set of widget properties. If 
it's not also possible to map that into how "the properties" works that 
would be very enlightening.



FWIW I've had requests to update my 4W Property Sheet tool to 
special-case for widgets. I tell people I'll take widgets seriously when 
the company does, and if they do I won't need to update my tool because 
the existing call to "the properties" that works for everything else 
will work for widgets.


Maybe I've been overestimating the importance of widgets to LC Ltd. 
Guidance welcome.


--
 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: Text overwriting itself in non wrapping field

[Richard Gaskin via use-livecode]

David V Glasgow wrote:

> Fixed line height didn’t fix the problem but thanks for the
> suggestion.
>
> However, looking more closely there are 3 visible characters where cr
> should be.   They are â9u except 9u is constant and the first
> character is almost always there, but varies wildly.  Often an
> underscore but also accented a, e or u.  Even more weirdly, if
> I search the field for ‘9u', several lines are found, but not any
> in the mutant line.
>
> And yet more weirdly again, when the line is displayed in a field
> with wrap true, the weird three characters appear at the beginning
> of ‘new lines’ except they are not actually new lines because they
> highlight as a single block.  An invisible form feed?  or something
> else between 9 and u  that a wrapping field decides is a wrap point
> but confuses the hell out of a non-wrapping field?
>
> If I thought this was just a weird one off, I would shrug my shoulders
> and move on.
>
> Shall I do that, and we will never speak of this again?

That would deny us a satisfying ending to a good mystery.  Let's see if 
we can address it.


I think there are two issue here: display rendering, and errant data.


The display rendering may be caused by the length of the line. As you 
noted, it's unusually long (thanks to the errant data), and I know 
there's a limit to how many characters can reliably be rendered on a 
single line. My understanding is that it's much shorter than the 64k 
limit for performing operations on lines in variables.


Maybe display limits rendering to the magic 32k limit imposed on other 
rendering like groups?  If the m-square of the text is > 3px (likely 
more like 10), and there's 10k of text in that line, the resulting width 
would exceed 32k px to render.


You can test that hypothesis by attempting to display a single line of 
the same with using the same font and size but with clean characters to 
see how it renders. If it doesn't appear similarly munged, please let us 
know.



That would leave us with the second item, the errant characters in that 
data, which appear to be the reason that one line is so unusually long.


Where does the data come from, and how it is assembled?  Is there any 
way to check the data source to see if erroneous data was somehow 
introduced there, and merely carried forward to your LC app?


--
 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: Solution for how to allow LC 9.6.6 and up standalones to control other apps in macOS - was:Excel_Lib on Mac

[Richard Gaskin via use-livecode]

Thank you for submitting that report, Matthias.

Those of us who do consulting understand that there's been a huge 
transition over the last several years away from custom development of 
complete systems to integrating between existing systems.


On macOS, AppleScript plays a key role in integration.

Given the state of the market for tools like LC, anything that makes it 
easier to use LC in an integration role bodes well for us, the company, 
and end-users alike.


--
 Richard Gaskin
 Fourth World Systems



Matthias wrote:

Ups, forgot to add the link to the bug report

https://quality.livecode.com/show_bug.cgi?id=23576


Am 18.03.2022 um 20:17 schrieb matthias rebbe via use-livecode :

First of all there is a bug report already. Unfortunately LC stuff is not able to reproduce the problem. 
But there a some users who reported that it is not possible in LC 9.6.6 and up to control an other app from within a LC script using Apple script if the app was not already listed under Livecode  in System preferences/Security/Automation. For whatever reason there was not the typical security pop up asking for confirmation. 


As a workaround it is possible to run the stack first with LC 9.6.3. With that 
version the dialog pops up and the user can confirm. After that the stack works 
also with 9.6.6 and up and is able to control that other app.

But what about standalones created with LC 9.6.6 and up? They will not show up 
the dialog.

To get this working, the standalones need some additional information in the info.plist and they need to be code signed with entitlements. At least with the entitlement 
	com.apple.security.automation.apple-events


So after you've created the macOS standalone you have to modify the info.plist 
of that standalone and then you have to codesign it with entitlements. After 
that your app created with 9.6.6 will show that security dialog.

Is that easy? No.

I've solved it this way as a workaround, so i do not have to do this manually 
after each standalone building process.


1. I created a folder 'entitlements' in the folder   'My Livecode/resources/'

2. I copied an entitlements file into that folder and named it 
'entitlements.plist'.
	My entitlements.plist file contains all entitlements as suggested by the following lesson. 
	https://lessons.livecode.com/m/4071/l/1293515-entitlements-for-signed-and-notarized-apps


3. I edited the sample info.plist file in the Livecode App bundle  
Livecode...app/Contents/Tools/Runtime/Mac OS 
X/x86-64/Standalone.app/Contents/info.plist
   I added the following two lines to it
NSAppleEventsUsageDescription
This app needs permission to use Apple Script

I placed it directly under the line
  This app requires permission to access your Media Library

4. I edited the stack script of the stack revSaveAsStandalone, better said i 
modified the handler performAdHocCodesign pAppBundle

I commented out the line 
put "codesign --deep -f -s -" && quote & pAppBundle & quote into tShell

and put the following lines after that line

if there is a file 
revEnvironmentUserResourcesPath()&"/entitlements/entitlement.plist"

then

put "codesign --deep --entitlements" && quote ()&"/entitlements/entitlement.plist" 
& Quote && "-f -s -" && quote & pAppBundle & quote into tShell

else

put "codesign --deep -f -s -" && quote & pAppBundle & quote into tShell

end if


Now when i create a macOS standalone the standalone contains the needed 
information in the info.plist and LC does an adhoc codesigning, as it did 
before, but now with entitlements.
With this created app the security dialog pops up right away.
If i want, for whatever reason, to create an macOS without that modification, 
then i just have to rename my entitlements.plist file and LC does the normal 
adhoc code signing as it did before.

The above steps 3 and 4 have to be done for each LC edition that does have this 
'problem'. But if you are like me then you need to do this only for the most 
current version.


Hope this helps the one or other.

Matthias



___
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: revOpenDatabase over SSH tunnel?

[Richard Gaskin via use-livecode]

matthias wrote:

> As more and more servers do not allow remote MySQL access due to
> security restrictions...

It's almost like experienced hosting vendors and even the MySQL team 
itself are trying to tell us something...


How does most of the world outside of the LC community handle remote DB 
CRUD operations?


--
 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: Speed up a slow loop

[Richard Gaskin via use-livecode]

Jacque wrote:

> so I'm not really looping through the keys, just looking for
> a matching one. The loop is for each user word I need to find.
> If there's no key, then the word isn't legal.

What is the ratio of keys whose values are "true" and those which are 
"false"?


And what is the ratio of writes to that array vs reads?

--
 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: Loading a LONG list with images

[Richard Gaskin via use-livecode]

You seem to have good progress toward a workable solution already, but 
FWIW here's how I handled a similar case:



I was building a bespoke authoring system which included an image 
library. There were some 2600 images in the collection when we started, 
and at the rate of new additions we didn't expect that to exceed 5,000 
through the anticipated lifecycle of the system.


With such relatively modest constraints, when it came to making the list 
view with thumbnails and image file metadata, I sent all of them over at 
once. :)


But the key is *how*:

On the server, when an image is added to the collection a thumbnail is 
generated along with it.


But rather than storing the thumbnail as a separate file, we add that 
image data to an array keyed by file name. Then the array is encoded, 
and the resulting LSON written to disk.


When the user opens the image library list view, that LSON file is 
downloaded in one HTTP GET, deserialized, and stored in a variable where 
it's used to populate the DataGrid as needed.


Of course that makes populating the DG satisfyingly instantaneous, but 
at what download cost?


Turns out it's pretty minor in our case.  2600 thumbnails about an inch 
square, compressed with a JPEG quality of about 80%, take up very little 
space. And at 1", differences in JPEG compression quality make far less 
difference to the eye than they do to the resulting size.


All in all, IIRC the download time was just a couple seconds, since the 
whole LSON archive was just about 1MB  - and that was on the crappy

"U-Verse" connection I had at the time, slower than even my 4G phone.

One thing worth keeping in mind with remote storage is the impact of 
multiple HTTP connections.  HTTP is a great protocol, far leaner than 
most give it credit for.  But its overhead is not zero, and TCP in 
general carries a certain overhead, and even just the connection latency 
adds up too.


With 2600 images, that could have been 2600 GET requests, with all the 
overhead incumbent in each.


But trading off a barely noticeable load time to reduce 2600 requests to 
just one paid off handsomely in the smooth-flowing user experience of 
traversing the image collection.


Indeed, at the same company in a separate department a team of Java 
developers were tasked with a similar UI challenge. Not only was the 
implementation much more expensive, but they didn't batch requests like 
I did. Authors who've used both cite the one I delivered as a more 
productive experience. Bonus that it was delivered at 1/4 the dev cost, 
and ran on twice as many platforms. :)


--
 Richard Gaskin
 Fourth World Systems



Dan Friedman wrote:

> Richard,
>
> Probably not over a couple thousand.  The images are square -- they
> need to be resized to the DG template image size, but not scaled (H
> vs W).
>
> On 2/21/22, 12:14 PM, Richard Gaskin wrote:
>
>>  How many images?
>>
>>
>>  Dan Friedman wrote:
>>> Does anyone have any answers to the issue of loading a long list
>>> with images so that it loads images "as needed" like a webpage does.

___
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: [ANN] Release 10.0.0 DP-2

[Richard Gaskin via use-livecode]

Pi Digital wrote:

> It’s so frustrating because I just spent the last week making my own
> widget to make bar and pi charts. LOL! Now it feels like a futile
> gesture with something far superior ‘just around the corner’. Your
> teams have done a really good job of making them.
>
> I’ll get back to making more futile tools that will likely get
> superseded by more of your work ;)

This problem is as old as platforms themselves. Indeed much of Apple's 
early dev-facing communications (circa Mac v1.0-4.0) centered around 
clarifying their interests and their intentions for keeping the 
third-party opportunity as wide open as practical.


Later on a form of Konfabulator was included as Widgets, a form of 
Delicious Library was included as iBooks, and the boundaries have been 
blurred forever since.


This is understandable, whether we're looking at a vendor whose platform 
is an OS or a dev tool, as it's incumbent on them to provide a strong 
sense of feature-completeness wherever practical.


When evaluating third-party opportunities, consider not only the LC 
world but also JavaScript.  Integration between any GUI toolkit and web 
views is likely only going to increase going forward.


As LC Ltd notes in their blog post, the new charts widget wraps 
chart.js, an open source package under MIT license.


Many key ingredients in LC make use of open source code, and given the 
vast-and-growing range of open source packages for JavaScript we can 
expect more using that language over time.


So next time you're thinking of an add-on for LC, also take a moment to 
see if such a thing is already available in JavaScript. If it is you 
just saved yourself the time otherwise needed to write it from scratch.


--
 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: Loading a LONG list with images

[Richard Gaskin via use-livecode]

How many images?

I once made a solution for 3,000 images, but it may not scale well above 
8,000 or so depending on memory and connection speed.


--
 Richard Gaskin
 Fourth World Systems




Dan Friedman wrote:

> Does anyone have any answers to the issue of loading a long list with
> images so that it loads images "as needed" like a webpage does.
>
> I have a DataGrid with several hundred rows.  Each row has a specific
> image that is to be displayed with that row (like a list of songs).
> The image is loaded from the web.   Is there a method to load the
> DataGrid and only load the images for the rows that are shown?   And,
> when you scroll the grid, the images for the newly shown rows are then
> loaded.  The loading need to happen somehow without halting the
> scrolling or making it stutter.
>
> I hope that makes sense!
> -Dan



___
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: Reviving CD-ROM material [was: Re: Livecode and interactive video]

[Richard Gaskin via use-livecode]

Thank you for the mention, Jeff. Without your adding that here I would 
have missed Richmond's reference; he's among a small number of members I 
generally don't read anymore (so much to learn, so little signal in a 
noisy world...)


FWIW I agree with what you wrote, and felt it was important enough to 
quote it in whole below. Thank you for taking the time to write that.



Richmond's original comment about me was:
> Richard Gaskin will probably now come after me with the castrating
> irons.?

How you arrive at your legal and ethical choices is entirely up to you. 
Unless it involves my work it doesn't affect me. Knock yourself out.



For the other readers here, I don't mind sharing a personal opinion on 
copyright law:



There are some details of US copyright statutes I don't much care for, 
particularly the control one giant American corporation has held over US 
copyright expiration ("Steamboat Willy", I'm looking at you).


But overall I not only do my best to conform to US and applicable 
international copyright law per the terms of the contracts I sign, I 
wholeheartedly celebrate it.


IMO the Berne Convention, which lies at the heart of most copyright law 
among signatory nations, exemplifies a profound wisdom we all benefit 
from, esp the readers here, since most of us earn our living from 
intellectual property.


It holds that at the very moment of the creation of any original 
creative work, the creator of that work has sole authority over it.


Let that sink in. Savor it. It's wonderfully delicious.

It recognizes that creative effort is a uniquely valuable human 
activity, and maintains as a matter of international legal guidance the 
sanctity of the act of creation.


Man, if nations could agree on anything else so beautifully principled 
our Spaceship Earth might be a paradise. :)


I love it so much that when I come across old works I'm interested in 
that appear to be abandoned, I try to reach the creator or current 
rights holder to see what can be done to re-use it.


It's the least I can do. If I am to embrace the excitingly bold spirit 
of the Berne Convention, I'm obliged to not only enjoy its fruits but to 
also honor its responsibilities.


It is not for me to assume control of any other creator's work.

In honoring copyright, I'm creating of a world where copyright is honored.

--
 Richard Gaskin
 Fourth World Systems



Jeff Reynolds wrote:


Richmond,

And I’ll be right there with Richard.

Just because it’s not being supported does not remove copyrights. You know 
that’s a stupid argument. Maybe fine with your own morals but it’s not how 
copyright works. As a content creator for over 4 decades of my professional 
life I really hate that attitude of self justification. Fine for your own use 
but if you want to redistribute it then get the rights. Not for profit label 
has nothing to do with the rights involved.

I have experience working in and with media companies and licensing others’ materials and having others licensing ours. We were told all the time by management and legal to not respond to requests to license unless management was interested in the proposal and they would handle that. I thought it pretty strange that a denial letter could cause any issues and may have just been paranoia or don’t waste your time but those were the instructions. 


Getting an odd bob out out of relicensing an old project involves figuring out 
who you are getting in bed with and if you even want to get into bed with them 
in the first place, time to come to an agreement, research out the original 
projects licensing (media projects are rife with licensed media that at times 
are not transferable or require additional permission and/or payments), create 
and agree on a contract, deliver the goods, then make sure everything is being 
done as contracted. That’s not simple and all the steps cost time and money and 
usually folks are not willing to pay much for the rights to cover these costs, 
let alone a profit.

I’ve done this process a couple of times with old projects and it was way more 
work than I thought it would be and that was with a very good relationship with 
the rights holder (I built the original product for them) and in good rights 
situations. One was easy and owner was happy with a handshake on the deal until 
I had a product to sell and then we would pen a contract. I totally trusted him 
he would honor the handshake (and I’m still absolutely sure he would have, very 
good chap), but a year and a half later he ended up having to sell the rights, 
so our handshake of course was no longer good. He was transparent about all 
this and I just did the hand shake as it would have been a good chunk of change 
with lawyer to pen the rights contract and I didn’t have a publisher onboard 
yet. So even in the best of situations things can go sideways on these kinds of 
things and life is not as simple as you think it is Richmond.

I was approached by an old employer about 

Re: scripted Show tooltip not a thing?

[Richard Gaskin via use-livecode]

Tooltips can be a solution, but the mechanism has some limitations in 
this context.


First, tooltips are a sort of hidden feature, where the user discovers 
them only after moving the mouse over the object.  Prior to that moment 
they're invisible, offering no guidance at all.


And in this case, the good explanatory text you're offering can't be 
seen until after the user commits to a choice, but that explanation 
would seem helpful to guide them to making that choice.


If space permits, you could consider adding the explanatory text in 
parentheses after the symbol directly in the control:


  -
  | = (Equals)|
  | ≤ (Is at least)   |
  | ≅ (Is approximately)  |
  -

This would allow users to fully grasp the implications of a choice 
before making it.


--
 Richard Gaskin
 Fourth World Systems


avid Glasgow wrote:


I have an app in which tooltips are generally off.  I also have a button menu 
which allows the selection of equality/inequelity.  Users are non technical, 
and on selection (i.e. not the usual hover) I wanted to pop up a brief tooltip 
describing the selected item in ordinary language (irrespective of whether 
tooltips are globally on or off):

on menuPick pChosenItem
   set the label of me to pChosenitem
   switch
  case pChosenItem = "="
 set the tooltip of me to "Equals"
 break
  case pChosenItem = "≤"
 set the tooltip of me to  “Is at least"
 break
  case pChosenItem = "≅"
 set the tooltip of me to “Is approximately"
 break
   end switch
   set the tooltipdelay to 500
   show the tooltip of me
   set the tooltip delay to 0
end menuPick

It seems  show the tooltip of me isn’t a thing.  I appreciate that I could show and hide an ordinary field, but I wondered if I have overlooked a suitable message and/or syntax that will enable what I want. 



Best Wishes,

David Glasgow




___
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: Creating a simple menu

[Richard Gaskin via use-livecode]

David Squance wrote:

> I want to create a mock-up of a web site...

How will this LC stack be used in the web dev process?

--
 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: How to extract whole text from a PDF file with the PDF

[Richard Gaskin via use-livecode]

Richmond wrote:

> On 12.12.21 21:33, Richard Gaskin wrote:
>> Stam Kapetanakis wrote:
>> > i presume the pdf widget in pro is the opensource xpdfReader but
>> > don’t know for sure.
>>
>> If it is that would be problematic, as the open source edition of
>> xpdfReader is licensed under GPL, and LC no longer has an edition
>> compatible with GPL.
>
> The consequences are endless.

Note my "if".

In the next message in this thread Paul clarified that the component is 
not derived from a GPL-governed work, so the rights and responsibilities 
of the GPL do not apply here:

http://lists.runrev.com/pipermail/use-livecode/2021-December/266435.html

--
 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: Ghost in the Machine?

[Richard Gaskin via use-livecode]

Peter Reid wrote:

> We want a way to upload a group of new members by 'driving' the input
> fields, i.e. our app would click into each field, checkbox, radiobox
> and 'type' in the details.

If the goal is to submit new member info you can do that with a single 
POST command.


Examine the source HTML. Look for the action URL.  Look at the input 
names. Package up the input data as name-value pairs form-encoded, send 
it to the URL via POST, and you're done.


--
 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: How to extract whole text from a PDF file with the PDF

[Richard Gaskin via use-livecode]

Stam Kapetanakis wrote:

> i presume the pdf widget in pro is the opensource xpdfReader but
> don’t know for sure.

If it is that would be problematic, as the open source edition of 
xpdfReader is licensed under GPL, and LC no longer has an edition 
compatible with GPL.


--
 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: Control of Text Fields.

[Richard Gaskin via use-livecode]

Possibly memory corruption, but unlikely.  More likely a plugin or IDE 
element with test code hanging around.


If only there was a way to trace message handlers so you could see where 
the culprit lies...


http://lists.runrev.com/pipermail/use-livecode/2021-October/266125.html

:)

--
Richard Gaskin
Fourth World Systems


Bob Sneidar wrote:


I just searched for Carol in ANYTHING in ALL OBJECTS in my stack. The word 
Carol is in nothing. Memory corruption anyone???

Bob S



On Nov 4, 2021, at 15:22 , Bob Sneidar via use-livecode  wrote:

OK I tried sending put the selectedChunk in one second in an openField handler in a field. What I get... (you may want to sit down for this...) is: 


Bob
Carol

That exists precicely NO WHERE IN MY APPLICATION! 


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: Message Tracer

[Richard Gaskin via use-livecode]

Bob Sneidar wrote:

> Has anyone written something that will trace the flow of a command
> or procedure and create some kind of rudimentary flow diagram? It
> can be text based something like:
>
>stack "Main Form"
>Openstack
>setSubscriptions
> subGetMainData, getMainData
> subSetMainGrids, setMainGrids
>broadcast subGetMainData
>broadcast subSetMainGrids
>
> etc.

Yes. 4W Flight Recorder provides a display for logging messages and 
subsequent handler calls, indented for readability and with relative 
performance metrics.


Double-clicking a line in the display opens the script where that 
handler is defined, and the list can also be saved to a file.


Bonus: messages logged can be filtered, with preset filters for IDE and 
other tools.


You can download 4W Flight Recorder from within the Stacks section of 
LiveNet, or directly at this URL:

http://fourthworld.net/revnet/devolution/4W_FlightRecorder.livecode.gz

--
 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: Keep stack proportions when resizing

[Richard Gaskin via use-livecode]

I had a similar request from a client a few years ago.  We couldn't find 
any apps from the 21st century that do that, so instead we opted for 
what we see in apps from Apple and many others:


We leave the user in control of their desired window size, and adjust 
our media in the content region proportionately, with a dark gray 
background filling in any edge gaps.


Bonus that it's also super easy to implement.

--
 Richard Gaskin
 Fourth World Systems



Devin Asay wrote:

> I asked this question several years ago and what I gathered is that
> it’s not easy because window> resizing is under the control of the
> operating system, and LiveCode can’t really override it.
>
> My attempts were not completely satisfactory:
...
> On Oct 8, 2021, at 1:18 PM, Peter Bogdanoff wrote:
>
> Does anyone have a script to keep a stack’s proportions constant when
> the user is changing the stack size by dragging the lower right
> corner? This is a stack with a control containing a video or image.
> I’ve used the geometry manager for the objects within the stack but
> the stack itself needs to be shaped correctly.




___
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: OT: Priorities (was: Re: Stack with the same name loop)

[Richard Gaskin via use-livecode]

Curry Kenworthy wrote:

> (I never have, and never will,
> quote the entire post. Misguided trend.)

I edit down to the relevant portions, so people have the opportunity to 
know what I'm replying to.


--
 Richard Gaskin
 Fourth World Systems

___
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: OT: Priorities (was: Re: Stack with the same name loop)

[Richard Gaskin via use-livecode]

Curry:

> Richard:
>>   Heather politely called cheese on this topic some time ago.
>>   May we please respect the wishes of the list owner?
>
> I propose reducing the attempts to silence one another?
>
> That cheese remark doesn't sound like a very accurate portrayal;
> that license change topic had simply been discussed enough.

Agreed, of course, as is clear when you read my reply to see what I was 
-- and wasn't -- replying to.


For the avoidance of doubt, I included the full text of both replies I 
was responding to - my complete post is here:

http://lists.runrev.com/pipermail/use-livecode/2021-October/265845.html

Relevant portions include:
> IMO the open source initiative was the single biggest mistake LC Ltd
> made.
...
> +1. Gave me the heebie jeebies when they announced the Open Source
> model.
>
> I survived the age of freeware. There were a LOT of people back then
> who opined that ALL software ought to be free! It was staggering.


LC's open source is gone, and cannot return. What's done is done.

All I'm asking is that we leave the past where it is, behind us, and 
live in the here-and-now.


And in this here-and-now, I don't have an opinion on the conversation 
between Jacque and Sean, which is why I didn't reply to them.


Lumping my comment in with theirs suggests a more complete reading may 
be useful before rushing to reply.



> My apologies if I'm wrong (been sick going on 2 months,
> haven't read everything) ...

I hope you're feeling better soon.

--
 Richard Gaskin
 Fourth World Systems


___
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: Stack with the same name loop

[Richard Gaskin via use-livecode]

Thank you for confirming that the engine does not throw an error when 
encountering stacks of the same name.


At the heart of the issue seems to be a difference in how short stack 
names are resolved vs things like topstack.


Though related to the duplicate stack name issue, the core underlying 
cause is a separate item logged here:

https://quality.livecode.com/show_bug.cgi?id=18793

If brought into parity with so many of the functions we safely rely on 
like topstack (instead of the load order that's been there since the old 
MC days), so much IDE code and our workflows could become simplified.


Your notes in Comment 9 in that report are especially helpful.  Thanks 
for the recon.


--
 Richard Gaskin
 Fourth World Systems




Brian Milby wrote:


Yes, but it does not add anything else.  If you do it two times you end up with 
2 identically named stacks.  You can save them to disk with different long 
names and end up with multiple stacks with the same short name but different 
long name.  My demo is on bug 18793.  It works in the IDE.

Sent from my iPhone


On Oct 7, 2021, at 1:58 PM, Richard Gaskin via use-livecode  wrote:

Brian Milby wrote:

> Clone stack avoids the check.  It is not that hard to get
> multiple stacks with the same short name but different
> long names in memory (in a standalone).

Clone alters the name of the new clone stack.  The engine prepends it with "Copy of 
".

AFAIK it's done that since 1998.


FWIW I did some extensive research on duplicate stack names issues about four 
years ago, attempting to pin down how the engine behaves and what the IDE does.
https://quality.livecode.com/show_bug.cgi?id=1061#c20

TL/DR: The engine has no problem with duplicate short stack names, but some IDE 
needs will be compromised until there is an adjustment to how the engine 
internally resolves short stack name references;

Currently the old MC implementation remains in place in which those are 
resolved by load order (which is almost never what any scripter needs), but 
more useful would be layer/message path order (which is what most scripts and 
esp IDE tools need).

--
Richard Gaskin
Fourth World Systems



___
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: Stack with the same name loop

[Richard Gaskin via use-livecode]

Brian Milby wrote:

> Clone stack avoids the check.  It is not that hard to get
> multiple stacks with the same short name but different
> long names in memory (in a standalone).

Clone alters the name of the new clone stack.  The engine prepends it 
with "Copy of ".


AFAIK it's done that since 1998.


FWIW I did some extensive research on duplicate stack names issues about 
four years ago, attempting to pin down how the engine behaves and what 
the IDE does.

https://quality.livecode.com/show_bug.cgi?id=1061#c20

TL/DR: The engine has no problem with duplicate short stack names, but 
some IDE needs will be compromised until there is an adjustment to how 
the engine internally resolves short stack name references;


Currently the old MC implementation remains in place in which those are 
resolved by load order (which is almost never what any scripter needs), 
but more useful would be layer/message path order (which is what most 
scripts and esp IDE tools need).


--
 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: Stack with the same name loop

[Richard Gaskin via use-livecode]

Standalone building needs to be a separate process.


In the olden days, standalones were build by merging the stack file on 
disk with the engine, with no changes or additions to objects inside the 
stack.


When new features were introduced which requiring adding library button 
inside a newly-created group on the mainstack's first card, then later 
adding more options to add and separate substacks/other stack files, the 
build process became much more complex.


In the olden days you could be deep in your work context, running your 
app with specific windows open with certain data set up just as you need 
it to observe what you're working on, then select "Build Standalone" and 
nothing you've so carefully arranged is at all altered; the standalone 
is quickly built in a second or so and you can continue with what you're 
doing.


Accommodating the newer stack-altering features has created a world in 
which you lose your work context, windows appear and disappear in a 
dizzying display, it sometimes takes a very long time, and when 
everything settles down if it all goes well and the jostling finally 
subsides, you're left with a work context that has your mainstack open 
but everything else you've carefully arranged is gone.


Tons of code have been added to the IDE to account for the many 
implications that come along with attempting to make copies of stacks in 
memory, initializing them to be able to add/modify them, doing those 
mods, and then attempting to restore at least the bare minimum of the 
work context you'd had.


Along the way, all that added IDE code has led to side-effects, like 
those discussed in this thread.


As a separate process, the Standalone Builder need not bother with any 
concern about duplicate stacks at all, because there wouldn't be any.


But the biggest benefit is restoring the smooth, enjoyable workflows we 
once had, back when we didn't have to pause to ask ourselves if we 
really need to make that test build, because doing so will dramatically 
alter our workspace.


Bonus that new users won't have to watch the parade of stacks flashing 
about during the sometimes-lengthy process.


--
 Richard Gaskin
 Fourth World Systems


Bob Sneidar wrote:

> Yes, building standalones is a huge problem. I think that when a
> single platform standalone is created, the state Livecode ends up
> in ought to be the state Livecode started in before you built the
> standalone. This does not seem to be the case. Stacks opened during
> the build process seem to remain open, but are the versions that were
> saved when building the standalone, and NOT the ones belonging to the
> project. Try building a Windows AND a MacOS standalone in a single
> pass.
>
> Of course, it's easy for me to imagine how this could be done, but I
> suppose like most things, it's harder than I imagine.




___
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: OT: Priorities (was: Re: Stack with the same name loop)

[Richard Gaskin via use-livecode]

Heather politely called cheese on this topic some time ago.  May we 
please respect the wishes of the list owner?


--
 Richard Gaskin
 Fourth World Systems




Bob Sneidar wrote:

+1. Gave me the heebie jeebies when they announced the Open Source model. 

I survived the age of freeware. There were a LOT of people back then who opined that ALL software ought to be free! It was staggering. There were great repositories of commerial titles, and I mean the big stuff, that had been cracked so that they no longer required a license key. I knew people I worked with back then who made ample use of these. 

Maybe in the imaginary world of Star Trek, there is no more money and everyone just works for the joy of it, receiving nothing more than food, shelter, clothing and gratitude, but in the real world, people need to obtain those things for themselves. 

I say the people at Livecode LTD. deserve all the recompense they can get, and by the way, we should be thankful to Steve Jobs who gave us Hypercard (and actually convinced Apple to give it away for free!) 


Bob S


On Oct 7, 2021, at 03:04 , Bernard Devlin via use-livecode  wrote:

At least the new licensing model should allow LC to prioritise based on
what customers use.

IMO the open source initiative was the single biggest mistake LC Ltd made.
With that drain on resources over hopefully they can get to work on fixing
some of the outstanding deficiencies.





___
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

Alternative to Nabble for RSS for this list

[Richard Gaskin via use-livecode]

The old Nabble RSS feed for this died some time ago. So far the only 
alternative I've found is the RSS from mail-archive.com, which is darn 
near useless because it contains no body info from a post, not even the 
first sentence or two, just the title and the sender.


Is there another RSS feed for the use-livecode list?

--
 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: AW: List fields question...

[Richard Gaskin via use-livecode]

Paul Dupuis wrote:

>  Using the message watcher is practically useless unless I took the
>  time to filter out all the existing messages I am not looking for.


How about in addition to filtering by message name you could also filter 
by any part of the long name of the object containing the called handler...


And have results listed in indented outline format so you can easily see 
the calling chain from user event all the way down...


And optionally save the session log to a file...

And have profiling info provided with relative timing and frequency of 
calls...


And didn't want to wait for an enhancement request to find its way 
through the company work queue...



Here I took a moment to outline 4W Flight Recorder, a free tool I wrote 
some time ago and rely on every week:


https://forums.livecode.com/viewtopic.php?f=6=35496=207822#p207822

4W Flight Recorder is available in the Stacks section of the GoLiveNet 
plugin in the IDE.


--
 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: workaround for cut-off text in native scroller?

[Richard Gaskin via use-livecode]

J. Landman Gay wrote:

> Richard wrote:
>> Alternatively, you could handle your layout
>> the way most apps on your phone do, with
>> responsive design.
>
> That would manage the overall layout but wouldn't fix the error in
> the native scroller.

Seems I'd misunderstood the two bug reports and Brian Milby's suggestion 
in this thread.  This scroll calculation issue is not specific to the 
changed metrics from fullScreenMode?


--
 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: workaround for cut-off text in native scroller?

[Richard Gaskin via use-livecode]

Klaus wrote:

> Am 01.06.2021 um 22:49 schrieb Richard Gaskin:
>> No worries. All GUI OSes have had resizable windows since 1984.
>> If you've ever scripted for them on the desktop you already have
>> 90% of the habits needed to do the same on mobile.
>
> I never needed to do so in the last 21 years! :-D

I'm glad you mentioned that.

Resizable windows have been such a staple in software for so long, and 
so well supported in MetaCard, SuperCard, Toolbook, Gain, and most other 
GUI scripting tools, I've just taken for granted that anyone who's been 
in the biz for a while has written plenty of resizeStack handlers.


But I've been learning recently that's not the case. A lot of very 
experienced scripters have worked with dialogs, palettes, fixed-sized 
windows, and all manner of menus, but somehow have never been asked to 
make an app with resizable windows.


If I ever get around to writing an article on resizing strategies I'll 
keep that in mind.  Helpful to learn about one more xTalk veteran in the 
same boat.


--
 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: workaround for cut-off text in native scroller?

[Richard Gaskin via use-livecode]

Klaus wrote:

>> This quickie responsive setup took me about 5 minutes, less time
>> than spent working around the bug, and now with a UI that works
>> on all device types and screen ratios, with fixed predictable control
>> sizes, and no cropping, padding, or distortion.
>
> yes, thank you, but please bear with me, this is my very first mobile
> app after owning my first cell phone for a couple of weeks. 8-)

No worries. All GUI OSes have had resizable windows since 1984. If 
you've ever scripted for them on the desktop you already have 90% of the 
habits needed to do the same on mobile.



>> Bonus: Another few minutes on the cd 1 buttons group would even 
allow both orientations to be supported.

>
> Not neccessary for this app.
> But as a bonus I'd rather see this bug fixed. ;-)

Indeed.

I'm still wondering why we're still scripting scroll regions at all.

If the engine knows which objects it considers scrollable, and it knows 
how to provide access to OS handling of those interactions, put one 
engine capability with the other and scripters are liberated from this 
silly needless (and tragically LC-specific) tedium forever.


I'm also wondering why I'm alone in wondering 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: workaround for cut-off text in native scroller?

[Richard Gaskin via use-livecode]

Alternatively, you could handle your layout the way most apps on your 
phone do, with responsive design.



1. Add this to your stack script:

on ResizeCommon x,y
   -- Header:
   set the rect of grc ID 1003 to 0,0,x,92
   set the rect of fld ID 1005 to 0,19,x,90
   --
   -- Footer:
   set the rect of widget "navigation" to 0,y-57, x, y
end ResizeCommon



2. Add this to cd 1 after grouping your buttons:

on resizeStack x,y
   ResizeCommon x,y -- see stack script
   set the loc of grp "btns" to item 1 of the loc of this cd, \
 item 2 of the loc of this cd + 20
end resizeStack



3. Add this to cd 2:

on resizeStack x,y
   ResizeCommon x,y -- see stack script
   set the rect of fld "spielanleitung" to 0, \
 the bottom of grp "top", \
 x, the top of grp "navibar"
   scrollererstellen
end resizeStack


This quickie responsive setup took me about 5 minutes, less time than 
spent working around the bug, and now with a UI that works on all device 
types and screen ratios, with fixed predictable control sizes, and no 
cropping, padding, or distortion.


Bonus: Another few minutes on the cd 1 buttons group would even allow 
both orientations to be supported.



Play with the resizing right in the IDE here:
go url "http://fourthworld.net/lc/scrollbugRD.livecode;

--
 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: Stacks not removed from memory?

[Richard Gaskin via use-livecode]

Thanks.

So many things can legitimately change the value of "this" I generally 
prefer more explicit references.


Maybe with this apparent bug there's one more reason I'm grateful to 
have adopted this habit.


--
 Richard Gaskin
 Fourth World Systems



When you close a stack that has its destroyStack set to true, it should not remain in memory. In my case it 
also seems to get stuck as the default stack. Even if my preference stack did not remove from memory as it 
should, specifically going to stack "XYZ" and setting it as the defaultStack, one would expect 
"this stack" to be be "XYZ" but it is not.

As mentioned I am now querying revLoadedStacks and manually deleting from 
memory the preference stack and that seems to have taken care of it. But it 
makes me nervous that the same issue may unexpectedly arise elsewhere in my 
code. This is an app that has been working fine for years and this has not been 
an issue till now.

Marty



___
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: Stacks not removed from memory?

[Richard Gaskin via use-livecode]

Thanks, Marty.

I used to use stacks for preferences, but I found arrays to be simpler 
in addition to being slightly faster.


But it seems the core of your issue isn't so much about LC's cache 
management as with object referencing with "this" - do I understand the 
issue correctly?


--
 Richard Gaskin
 Fourth World Systems



In my case it's not a name conflict. Lets say I have a main stack "XYZ" and 
then I query a separate Preference stack:

put the cpCustomProperty of stack "full_path_to_pref_stack" into tPref
close stack "pref_stack"

(my preference stack has destroyStack set to true)

Now thinking that I'm back in my main stack "XYZ" I do something like:
put tPref into fld "123" of this stack

This worked fine for me for years. In LC 9.6.2 rc 5, it would fail most of the time. 
Curious, I inserted code to find out what LC thought was "this stack" only to 
discover that *sometimes* it's the preference stack that I just closed.

Then after closing the preference stack, I tried "go stack "XYZ" and "set the default stack to 
"XYZ" But "this stack" would still (most of the time) report my supposedly closed preference stack.

So now I'm having to query for revLoadedStacks and if my preference stack is 
listed then I delete it from memory.

I did file a bug report (#23194 ) but as it does not always happen I have not 
provided a test stack.

Marty



___
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: Stacks not removed from memory?

[Richard Gaskin via use-livecode]

Devin Asay wrote:

> I have seen what you’re describing on all of the recent releases—9.5 -
> 9.6.x; i.e., a stack with destroyStack set to true, then closed, is
> not always removed from memory. Sometimes this has caused an infinite
> loop with the Save - Purge - Cancel dialog. I would report it, but I
> haven’t been able to come up with a reliable recipe. It’s a problem
> that I would like to nail down and squash.

Is this to avoid stack name conflicts, or is there some other reason to 
use this feature?


Because if it's just the stack name conflict thang, I'd rather we solve 
that at the root by being done with that IDE-imposed limitation that 
doesn't actually exist in the engine:


https://quality.livecode.com/show_bug.cgi?id=1061

--
 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: Problems with Multiple Monitors

[Richard Gaskin via use-livecode]

Thanks, Paul, and the others who chimed in.

I'm familiar with the documented features for screen metrics, just 
trying to determine if the rect of the main screen no longer being the 
reference point for metrics is a change/bug I need to be concerned about?


And this got me thinking about screenLoc: if the main screen isn't the 
reference point, then is the screenLoc adjusted for the non-0,0 corner 
or is it based on the sum boundary of all connected monitors?


And is any of this platform-specific?

Or different from how it's been since the plural screenRects was introduced?

--
 Richard Gaskin
 Fourth World Systems


Paul Dupuis wrote:

On 5/4/2021 8:20 PM, Richard Gaskin via use-livecode wrote:

Paul Dupuis wrote:


With multiple monitor, zero vertical is the top of the top most
monitor  - regardless of whether it is the primary monitor or not.


If the screenRect is no longer based on the main monitor, what is the 
screenloc?


In a multi-monitor setup, with metrics like that how can one be 
expected to center a window?




screenRect still returns the rect of the main monitor
and
the first line of the screenRects is still the rect of the main or 
primary monitor (the one with the menubar/taskbar)


however, you can not count on its left,top of the primary monitor being 
0,0 in a multiple monitor configuration. It may be or it may not be 
depending of where the second (or more) monitors are in relation to the 
primary one. Took me a while to figure this one out based on a 
customer's reported symptoms!


Also, if you think you may have customers with multiple monitors, the on 
desktopChanged message is your friend. I ran into a customer who would 
often leave HyperRESEARCH running, minimized or hidden, and then remove 
a external monitor from their laptop to go. LiveCode still thinks the 
monitor is attached and when they placed HR windows on that external 
monitor, those windows were no visible or accessible (unless they quit 
and restarted HR). Now I have a desktopChanged handler that gets the 
screenRects and checks to see if every open window is inside a current 
screenRect and moves the windows if needed.


___
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: Problems with Multiple Monitors

[Richard Gaskin via use-livecode]

Paul Dupuis wrote:

> With multiple monitor, zero vertical is the top of the top most
> monitor  - regardless of whether it is the primary monitor or not.

If the screenRect is no longer based on the main monitor, what is the 
screenloc?


In a multi-monitor setup, with metrics like that how can one be expected 
to center a window?


--
 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: Complete Crash or Engine Hang: which is better?

[Richard Gaskin via use-livecode]

Mark Smith wrote:

> Frightening and wonderful at the same time. When I did these exercises
> and then copy pasted a styledText string from LC into TextEdit, it was
> interesting to see what they agreed on, and what they didn't. For
> example, when colouring “numbers” both fields ignored numbers followed
> by “,” but not by a “.” So they were in agreement there. However,
> words containing a “y” were italicized in LC (that was the request)
> but interpreted as bold/underlined in TextEdit?
>
> More remarkably, I have no idea how they can stuff that much style
> info into a text string 


It might be interesting to see the htmlText from the source LC field to 
see how the style info is nested, if you're in a position to share it, 
or a sanitized version of it.


--
 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: Complete Crash or Engine Hang: which is better?

[Richard Gaskin via use-livecode]

Mark Smith wrote:

> Thanks Richard, that probably explains it. There are style runs in
> the TextEdit text (and not, say, in Atom or some other editor). It
> was just odd to me because I think (quite simplistically) of text
> being text and not expecting them to have style runs, but of course
> they can.

Here's a fun exercise, well worth a few minutes of playing around: make 
a field, style some text in it, make a tree widget, and run this in the 
Message Box:


  set the arrayData of widget 1 to the styledText of fld 1

The styledText array is a great representation of field contents, much 
faster to work with than most HTML-parsing methods, and offering good 
insight into the internals of LC fields, being the closes match we have 
from a scripting interface to the underlying field structures.


The v5.something engine added some super-awesome text properties, with 
paragraph-level formatting and more.  Seeing them laid out in array 
format (the tree widget is great for that) really illuminates how things 
are laid out.



> This also began because not only could I not change my text, someone
> else previously had this problem and eventually fixed it by deleting
> the fields and starting over
> (https://forums.livecode.com/viewtopic.php?f=7=32727)

Yeah, I posted pretty much the same comment there, but like much of what 
I used to write in the forums it was ignored in favor of doing a lot of 
unnecessary work. :)



> I now suspect it may have been style runs in their text as well.

When things show up that look like extreme problems that would affect 
nearly every user, it's probably not a regression.  Not that the team's 
automated testing can catch everything (though it catches a lot), but 
just that bugs that affect large numbers of people in ways that prevent 
core use of the product generally don't live long, if they live long 
enough to get past early beta at all.


So if we truly had mysteriously immutable text styling, chances are good 
it would be caught in a Preview build, long before RC.  Good enough to 
check style runs, anyway. :)



> I don’t tend to run into this sort of problem because I’m rarely
> concerned with the style of text, but in this particular case I
> actually did want to change the font size and color and couldn’t,
> and that had me puzzled. Ok good, I think you've solved this.
> Thanks for weighing in.

Happy to help others avoid pitfalls I've run into myself. I hope that 
solves it for you.


I had a head-scratching moment over exactly this many years ago.  Just 
sharing what I've learned, so others don't have to replicate my mistakes.


--
 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: Complete Crash or Engine Hang: which is better?

[Richard Gaskin via use-livecode]

Tom Glod wrote:

> when the clibpboardData["html"] is set ...and then you paste into
> VSCode... the spaces are unrecognized characters.

All spaces, or just multiple spaces being rendered as a single space?

If the latter, that would seem a design choice by the host app for that 
data format type, since it's customary for HTML to render only one space 
and ignore any others.


--
 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: Complete Crash or Engine Hang: which is better?

[Richard Gaskin via use-livecode]

Mark Smith wrote:

> here’s an odd pasting issue I ran into the other day. To cut to the
> chase, basically I can make a field become unmodifiable with respect
> to TEXT parameters (excluding align) by pasting anything from Apples
> TextEdit tool into the field.

By what means were you attempting to modify the text styles?

If you modify the text styling properties of the field object itself, 
remember that style runs within the field will override those.


You could have your script paste with putting the clipboardData["text"] 
into the selection, and you can strip style runs to inherit field 
properties with "put fld X into fld X".


--
 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: What exactly does "put" do on Server?

[Richard Gaskin via use-livecode]

Postman shows a single reply to the client from Apache.

strace on the server shows each "put" implemented at the system level as 
a write to stdout.


So it looks to me like Apache buffers writes it receives and sends all 
of it to the client in one go, with a header that accurately accounts 
for the total size of multiple "put"s in the Content-Length.


I'm still curious to know how Apache knows when to send to the client - 
does it wait for the CGI to terminate?


But for now, at least it seems we have an answer to the question of 
whether LC Server or Apache buffers the writes.


--
 Richard Gaskin
 Fourth World Systems



Tom Glod wrote:


Following, I've wondered this, but never had enough motivation to test it.

On Tue, Apr 20, 2021 at 4:00 PM Richard Gaskin via use-livecode <
use-livecode at lists.runrev.com> wrote:


Normally, HTTP is used for request-reply patterns, where the server
receives the request, does some processing to it, and then sends back
the reply.

In a faceless environment like Server, "put" goes to stdout, yes?  So
when we say "put tData", then the contents of tData are handed back to
Apache which then sends them along to the client.

So what happens when I have a script that uses multiple "put" statements?

Does LC Server buffer all "put" output together and send it as one
string back to the client?

If so, why do I see faster results if I collect data myself and use only
one "put"?

If not, how does it write a meaningful header, since the length can't be
known in advance?

What exactly is the Server engine doing with "put"?

--
  Richard Gaskin




--
Tom Glod
Founder & Developer
MakeShyft R.D.A (www.makeshyft.com)
Mobile:647.562.9411



___
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

What exactly does "put" do on Server?

[Richard Gaskin via use-livecode]

Normally, HTTP is used for request-reply patterns, where the server 
receives the request, does some processing to it, and then sends back 
the reply.


In a faceless environment like Server, "put" goes to stdout, yes?  So 
when we say "put tData", then the contents of tData are handed back to 
Apache which then sends them along to the client.


So what happens when I have a script that uses multiple "put" statements?

Does LC Server buffer all "put" output together and send it as one 
string back to the client?


If so, why do I see faster results if I collect data myself and use only 
one "put"?


If not, how does it write a meaningful header, since the length can't be 
known in advance?


What exactly is the Server engine doing with "put"?

--
 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: Snapshot image density

[Richard Gaskin via use-livecode]

David V Glasgow wrote:

> On 16 Apr 2021, at 4:17 pm, Richard Gaskin wrote:
>>
>> Is the metadata["density"] settable?
>>
>> I haven't used it so I can't say, but given how snapshotting works
>> I'd be surprised if it lets us control the pixel density of LC's
>> imaging buffer. My hunch is that it's there to inform other programs
>> which may be used to display the image. I'd love to be wrong on that.
>>
>
> Hmmm maybe I have just completely misunderstood. The parameters
> dictionary entry for export snapshot says:
...
> metadata   array:  The metadata is an array of metadata. Currently
> the only key supported is "density" with a value in pixels per inch
> (ppi).
...
> no mention of a metadata array

What did I miss?

The formatting of some Dict entries are still being tidied for Browser 
display so I sometimes overlook details there.



>>> are temp folders always available irrespective of the severity of
>>> security restrictions which might be imposed?)
>>
>> Good question. I don't know; I'd always had the impression that tmp
>> is a sort of free-for-all where sensitive data is understood to be
>> inappropriate.  Maybe modern systems sandbox tmp by app?
>
> Thanks for the information Richard, I will just have to try it out I
> guess.  Maybe at the weekend.

Please keep us posted with what you find.

--
 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: Snapshot image density

[Richard Gaskin via use-livecode]

David V Glasgow wrote:

> Is it right that import snapshot doesn’t offer image density options
> as export snapshot does?

Is the metadata["density"] settable?

I haven't used it so I can't say, but given how snapshotting works I'd 
be surprised if it lets us control the pixel density of LC's imaging 
buffer. My hunch is that it's there to inform other programs which may 
be used to display the image. I'd love to be wrong on that.



> should I just export to the temp folder, immediately import, copy to
> clipboard and proceed as before?  Or is there a more elegant route?

As of v7 or so you can also export to a variable, which can then be used 
to set the data of an image object without the intermediary file I/O.



> are temp folders always available irrespective of the severity of
> security restrictions which might be imposed?)

Good question. I don't know; I'd always had the impression that tmp is a 
sort of free-for-all where sensitive data is understood to be 
inappropriate.  Maybe modern systems sandbox tmp by app?


--
 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: Positioning object in a loclocked group

[Richard Gaskin via use-livecode]

Klaus Major wrote:

I have a group set to 600*600 pixel and loclocked.
Inside of the group there are two invisible objects, 
a button and a graphic.


Now if I:
...
create btn "b1" in grp "THE group"
## and
set the loc of btn "b1" of grp "THE group" to whateverX,wahteverY
...
where whateverX and Y are definitively inside of that group!

Then the button stays however in the topleft corner of the group.
Even moving the button some pixels to right or down does not work.
Why, oh, why? :-)


This is counter to my experience, but I may not be understanding the issue.

If you have a simple sample stack that evidences this, I can take a 
moment tonight to poke around and adjust the properties to set it right, 
and report back what was needed.


--
 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: On the dangers of automated refactoring

[Richard Gaskin via use-livecode]

Andre Garzia wrote:

> What I didn’t realise was that there was variable shadowing happening
> in which handler arguments were named with the same name as script-
> local variables, my smart replacing removed those arguments because
> there was no need to redeclare the script-local vars. I didn’t realise
> at that time, that those variables were real arguments being passed to
> the handlers, they just happened to have the same name as script-local
> vars in the same script and were in fact shadowing them.

Is this a case where "Strict Compilation Mode" or Hungarian-lite* 
notation may have been useful?



* http://www.fourthworld.com/embassy/articles/scriptstyle.html

--
 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: Intermittent typing delay in script editor.

[Richard Gaskin via use-livecode]

Based on the sum of anecdotal evidence, it would appear contributory 
factors may be primarily outdated/suboptimal Win timer APIs, coupled 
with overzealous file I/O from frequent DB (Dict?) accesses, perhaps others.


The workaround would be time spent focusing on just those specifics.

The solution would be to commit the IDE team to spending at least one 
full work day each week to doing their work on Windows (bonus points if 
they spend one day a fortnight on Linux).


As a multi-platform tool, scripting work should be robustly productive 
regardless of platform.  Wherever it isn't merits attention.


Direct first-hand experience within the core team will bring about 
immediate awareness, and thereby resolution, of issues long before 
potential new users uninstall LC for its uncommon slowness on Windows 
(or UI anomalies/feature abandonment on Linux).


--
 Richard Gaskin
 Fourth World Systems


thompsonmichael wrote:

> I am using LC Indy 9.6.1 Build 15522 in Windows 10 on a Dell XPS -
> 15-9570 with a Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz   2.21 GHz
> Processor, with 16.0 GB (15.7 GB usable) RAM, and a Toshiba 256GB
> Solid State Drive.
>
> LC normally works lightning fast on this setup but over the last
> couple of years I would occasionally experience a sudden slow down
> in the script editor for no apparent reason. (Delays of seconds
> sometimes between typing and the type appearing on the screen) I would
> close everything and restart Livecode and all would be well again. It
> didn't happen very often so I tolerated it.  Eventually I noticed this
> only happened when I used the 'Message Box'. I usually put results
> into a text field rather than use the message box but on occasion when
> I wrote a 'Put' command with out a destination (in error) the result
> the message box would appear. It was only after that that the slowdown
> would occur. I am still tolerating it and closing LC when it happens
> but wonder if anyone else has experienced this and if there is a work
> around. I have given up on using the Message Box deliberately unless
> absolutely necessary.



___
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: Find Replace in Script Editor with cr

[Richard Gaskin via use-livecode]

#cheese

If a post is offensive, delete it.

If a poster is frequently offensive, add a filter to have it delete 
automatically.


May we please discuss LiveCode?

--
 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: [ANN] Release 9.6.2 RC-4

[Richard Gaskin via use-livecode]

At the turn of the century, so soon after HyperCard's death, it was 
understandable that Mac users would be disproportionately represented 
among LC customers.


For this to remain the case more than two decades later -- long past the 
time when most devs have never heard of HyperCard, Windows maintains 
it's 80+% market share, and Linux has a strongly disproportionate usage 
among professional developers -- would seem to evidence the difference 
between marketing and remarketin, between seeking growth and seeking 
remonitization of a fixed audience.


--
 Richard Gaskin
 Fourth World Systems



Andre Garzia wrote:

> LC is quite neglected on Windows and Linux. I understand that mac
> is the money making machine, but the kind of hiccups I see can only
> be explained by no one at HQ using Windows, or they’d have noticed
> it by now.


___
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: Help! I'm stuck

[Richard Gaskin via use-livecode]

Standalone building needs to be moved to a separate process.

Handling it within the IDE process was fine as long as the only thing 
the Standalone Builder did was bind a copy of the engine to a copy of 
the stack file.


But today, building a standalone means deep modifications to the stack 
file, and this has resulted in multiple successive layers of knock-on 
effects where design complications are needed to compensate for design 
complications put in place to compensate for earlier design complications.


The end result of attempting to build standalones within the current IDE 
process is not merely cumbersome, but disruptive, confusing, and even 
requires CODE CHANGES from EVERY USER to compensate even further just 
for the build sequence.


LC has gone from the simplest way to build apps to something no less 
onerous than most, and more confusing than many.


Standalone building needs to be moved to a separate process.

With that, LC can begin the return journey back on its path to the 
simplest way to build apps.


--
 Richard Gaskin
 Fourth World Systems



Ralph DiMola wrote:

> I never built a non-mobile standalone for the first 5 years of using
> LC. For a mobile build nothing gets closed and gets built from the
> stack(s) files on disk. What a surprise I got when I built my first
> desktop standalone. I initially thought that something was very wrong
> with the IDE and restarted.
> After some searches I found that this is the correct behavior??? I
> guess there is a reason for closing the stack(s) but I find it very
> odd indeed.
>
> Ralph DiMola


___
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: Find Replace in Script Editor with cr

[Richard Gaskin via use-livecode]

The Find feature in the Script Editor is limited to the script being viewed.

For larger-scope searches type Cmd-F in any other window.

--
 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: autohilite FUBAR?

[Richard Gaskin via use-livecode]

Thanks for the feedback, Clarence and Jim.

I found a report for this originally specifying Android only (where I 
first noticed it), and added a note about the scope affecting both 
Windows and Linux too:


https://quality.livecode.com/show_bug.cgi?id=22965#c6

--
 Richard Gaskin
 Fourth World Systems



chipsm themartinz.com chipsm at themartinz.com
Sat Apr 3 13:47:48 EDT 2021
Hi Jim. I agree that this should be the behavior on all Os's. On Windows, as you move the mouse across a button, the buttons exhibit a slight flashing effect. It's as though there are some kind of Zones in the button. 
I've never noticed this until Richard made mention of this activity. It is slightly noticeable, but it is definitely there.


Sincerely,

Clarence Martin
Email: chipsm at themartinz.com
Phone: 626 6965561

-Original Message-
From: use-livecode  On Behalf Of Jim 
Lambert via use-livecode

Richard,

On Mac when I hold the mouse down on a LC button, I can move the cursor around 
within the button and the button remains hilited.
As soon as the cursor exits the button the hilite disappears.
To me this is the desired behavior one should see on all platforms.

Jim Lambert



___
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: "tsnet (1) Received HTTP/0.9 when not allowed"?

[Richard Gaskin via use-livecode]

curl is reporting the default because the data it's receiving is zero 
length:

http://lists.runrev.com/pipermail/use-livecode/2021-April/264146.html

--
 Richard Gaskin
 Fourth World Systems



Andre Garzia wrote:> Are you using the time travel external? HTTP/0.9 
has been historical for a long while, you can see more about this 
protocol at:


https://medium.com/platform-engineer/evolution-of-http-69cfe6531ba0 
<https://medium.com/platform-engineer/evolution-of-http-69cfe6531ba0>

To what server you’re connecting?


On 31 Mar 2021, at 20:29, Richard Gaskin via use-livecode  wrote:

I have an LC app that recently started reporting this error when calling a web 
service we wrote:

 tsnet (1) Received HTTP/0.9 when not allowed


Searching around the web I see many varied descriptions of how one might remedy 
that, but none seem to fit our circumstance.

Anyone else seen this? What was needed to resolve it?

--
Richard Gaskin
Fourth World Systems



___
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

autohilite FUBAR?

[Richard Gaskin via use-livecode]

I recently noticed that if you hold the mouse down on a button and move 
it, the button doesn't stay highlighted, but instead the highlight  flashes.


Anyone else seeing this?  Anyone have a clue as to when it first went south?

--
 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: "tsnet (1) Received HTTP/0.9 when not allowed"?

[Richard Gaskin via use-livecode]

Ralph DiMola wrote:

> Richard,
>
> I also have a problem when requests come too fast. This might be
> related? I'm on an on-rev server. My problem was that using sessions
> caused the LC server to choke about 50% of the time when sending back-
> to-back requests. I confirmed this when stress testing by sending 2 or
> more requests to LC server from the from the QCC demo client stack
> back-to-back. I'm wondering if these two are connected?
> https://quality.livecode.com/show_bug.cgi?id=22560

Thanks, Ralph.  I do use persistent session data, but in this app I use 
a custom store, not LC Server's session handling. That's an interesting 
report, though, and I've added myself to the CC there.


This loading-fonts-unnecessarily issue seems to be more related to my 
circumstance:

https://quality.livecode.com/show_bug.cgi?id=14115

I'll know more if I get a chance I put the funky-font-fix workaround in 
place, but TBH I'm more likely to just move the app to a VPS instead. 
So it'll be a question of making the time for a funky setup test, and 
while that might narrow down root causes it won't fix anything since 
it's unlikely to be addressed anytime soon:  two community members 
who've looked at the engine code believe IF-DEFing the font init would 
be prohibitively cumbersome given the imported subsystems that would 
need it (like Skia), and the core team has other priorities.



> I want to use LC Server sessions for some website work but am
> reluctant to do so because if 2 users happen to hit the server
> too close together then LC server locks up for any future requests
> that uses sessions.

How certain are you the issue you're seeing is specific to sessions? 
I've skimmed your report but haven't tested it, so forgive me if this 
should be obvious, but have you found any other circumstances where file 
I/0 may be the trigger, rather than session storage specifically?



> If you find a solution I'll be interested to see
> if it helps me also.

If your issue is session-specific, I got nothing.

If it may be general resource consumption (mostly memory), the 
funky-font-fix may do the trick.  But setting it up is not for the feint 
of heart.  If you're comfortable with bash I can provide instructions to 
try it.



Kinda sad. LC's chunk expressions make our beloved language a nearly 
ideal fit for so many server tasks.  General performance is more or less 
on par with Python and Ruby where CGI stuff has been a famously good 
fit- LC can do anything they can do, and with more readable code that's 
more enjoyable to write. But we need to tighten it up and bring down the 
resource consumption before I'll stake my reputation evangelizing it 
beyond the current community of LC diehards.


--
 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: "tsnet (1) Received HTTP/0.9 when not allowed"?

[Richard Gaskin via use-livecode]

Good morning, Charles -

Thank you for your assistance, and your offer to look into it.

TL/DR:

As work progresses I'm increasingly convinced this isn't a client-side 
issue at all, but a side-effect of how LC Server's insistence on loading 
fonts that aren't needed triggers some host's CGI resource constraints.


The tsNet part of this fits that hypothesis: the HTTP version assumption 
is happening because the data coming back is literally 0 length - 
there's nothing there, fitting a pattern I've seen before on this host 
when CGIs are cut off.


At the moment I think I have a handle on the situation, and a plan for 
addressing it.  If I'm going to take advantage of your expertise let me 
queue up those points for when I truly need them. :)




More complete:

I found that this was only happening when two calls are made to the 
server within a short span of time, usually when first downloading a 
stack and then the stack requests the data it uses to display for the user.


Simply putting a pause of just under 2 secs between the stack download 
and its request for data has at least allowed users to get back to work.


I'm reluctant to pester DH support for more details on how their 
resource constraints are so frequently triggered by LC Server because I 
became familiar with the issue after spending weeks with them diagnosing 
an issue a few years ago, and I don't want them to think of LC as a 
problem and ban it altogether.


Part of what I learned from that experience was a workaround Mark 
Waddingham and Peter Brett came up with, essentially tricking LC Server 
into using a local folder with just one font instead of the whole set of 
system fonts.  Where I've used that workaround on Dreamhost everything's 
run well (indeed LiveCodeJournal.com uses it for every page and its 
performance is indistinguishable from static pages).


For myself, I have other reasons to migrate the app to a VPS, and we're 
provisioning one soon. Shared hosting is great for low-value low-traffic 
stuff, but with VPSes priced on par these days it's the better choice 
when predictable loads are useful.


My LiveCode, the language is so well suited for server work (chunk 
expression make short work of most of what we do on servers), it's a 
shame to see LC's performance and sometimes reputation take a hit by a 
loading sequence that favors initializing fonts that are never used by 
99+% of scripts.  Hopefully one day BZ#14115 will be addressed, and LC 
can be used with all the beautiful efficiency it's capable of.


DH is a popular host, and I've seen this occasionally on at least one 
other shared hosting company before using the workaround.  So this isn't 
just a Dreamhost issue, and may show itself at just about any time on 
perhaps any shared host that's successful enough to have resource 
constraints.


In the meantime, for those who enjoy server admin there are always VPSes.

--
 Richard Gaskin
 Fourth World Systems



Charles Warwick wrote:

Hi Richard,

The curl version that is used in tsNet is regularly updated.  The latest 
version of tsNet is using curl 7.74.0.

My understanding of that particular issue is that if the first data line that 
is received back from the HTTP server doesn't match an appropriate response, it 
will assume HTTP/0.9.

Is there a test URL you can post that shows this problem so I can see what is 
coming back from the server?  Can you post what you are getting in the libURL 
debug?

Also, have you tried a version of LC that has a different version of tsNet 
included - just in case this happens to be a new bug in the curl library.

Thanks,

Charles


On 1 Apr 2021, at 10:37 am, Richard Gaskin wrote:

Matthias wrote:


was there a change in the configuration of your web server recently?
Is your web service using php or LC server?


LC Server.  Hosting likely had changes, since this app has been in production 
for a long time without issue.

I believe the change most significant here is business success: Dreamhost 
apparently has a lot of customers and runs pretty packed shared servers  these 
days (reason #48 why I prefer VPSes). I'm guessing part of this is a noisy 
neighbor problem.

But I'd guess at least some of this is the interaction between Dreamhost's 
resource quotas and LC's wasteful boot process, in which most of the resources 
it consumes are for font init that I'd guess 99.9% of server scripts never need:
https://quality.livecode.com/show_bug.cgi?id=14115

Another contributing factor may be the curl version tsNet has embedded. Some of 
the discussions I came across reference older curl versions that assume HTTP 
0.9 by default and misreport that under certain error conditions if header info 
isn't parsed just so.

Is tsNet's curl version documented somewhere?
Does LC keep tsNet updated with the latest curl with each release?



I am not sure if this is of help, but there is a debug stack
available for tsNET. Maybe the debug information gives you
some more information.

Re: "tsnet (1) Received HTTP/0.9 when not allowed"?

[Richard Gaskin via use-livecode]

Matthias wrote:

> was there a change in the configuration of your web server recently?
> Is your web service using php or LC server?

LC Server.  Hosting likely had changes, since this app has been in 
production for a long time without issue.


I believe the change most significant here is business success: 
Dreamhost apparently has a lot of customers and runs pretty packed 
shared servers  these days (reason #48 why I prefer VPSes). I'm guessing 
part of this is a noisy neighbor problem.


But I'd guess at least some of this is the interaction between 
Dreamhost's resource quotas and LC's wasteful boot process, in which 
most of the resources it consumes are for font init that I'd guess 99.9% 
of server scripts never need:

https://quality.livecode.com/show_bug.cgi?id=14115

Another contributing factor may be the curl version tsNet has embedded. 
Some of the discussions I came across reference older curl versions that 
assume HTTP 0.9 by default and misreport that under certain error 
conditions if header info isn't parsed just so.


Is tsNet's curl version documented somewhere?
Does LC keep tsNet updated with the latest curl with each release?


> I am not sure if this is of help, but there is a debug stack
> available for tsNET. Maybe the debug information gives you
> some more information.
>
> https://downloads.techstrategies.com.au/tsnet/debug_liburl.livecode

Thanks.  It's using libURLSetStatusCallback and libURLSetLogField, so 
it's more or less like the one I'd already built into my tooling.


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

"tsnet (1) Received HTTP/0.9 when not allowed"?

[Richard Gaskin via use-livecode]

I have an LC app that recently started reporting this error when calling 
a web service we wrote:


  tsnet (1) Received HTTP/0.9 when not allowed


Searching around the web I see many varied descriptions of how one might 
remedy that, but none seem to fit our circumstance.


Anyone else seen this? What was needed to resolve it?

--
 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: [bug] strange memory leak in LC

[Richard Gaskin via use-livecode]

Andre Garzia wrote:

> The stack that was opened is a project that has many mainstacks in
> it’s stackfiles. Some of those stacks make use of the browser
> widget...

Don't know if this may be related to the leak, but worth heeding anyway 
- apparently WebKit has some serious issues, including an uncommonly 
nasty vulnerability:



   Apple releases emergency update for iPhones, iPads, and Apple Watch
   ...
   The vulnerability, discovered by Google's Threat Analysis Group,
   affects Apple's WebKit browser engine, and what makes this an
   urgent update is the fact that Apple claims the vulnerability
   is being actively exploited.

https://www.zdnet.com/article/apple-releases-emergency-update-for-iphones-ipads-and-apple-watch/

--
 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: mouseenter/mouseleave and pointer tool

[Richard Gaskin via use-livecode]

Jim Lambert wrote:

> Every time I click on a button in the IDE with the pointer tool
> in order to select and, say, move it, I'd prefer if the mousedown/up
> scripts didn't fire off because I'm editing the UI not running it.
> If I recall correctly this was not how LC/Revolution originally
> behaved.

It still does. I don't believed anything with mouse message handling has 
changed in many years, if at all.


I haven't seen how Klaus came across the mouseEnter message, so I can't 
begin to guess how this is only coming to his attention now.


Either way, with the engine having worked as it does with tool messages 
since 1992 I'm not expecting change.



> Richard, remember SuperEdit? Very much about authoring.

I remember it well, as does John Balgenorth and perhaps some others here.

It was surprisingly polarizing: some loved it, some hated, but I never 
met anyone who'd used it who was indifferent about it.


I loved it. But I loved everything about the package at that time. 
Maybe I mostly loved the time. :)


--
 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: We don't need a Player (was Re: New(?) Idea for Standalones)

[Richard Gaskin via use-livecode]

Trevor DeVore wrote:

> We agree that LiveCode should include a sensible baseline for building
> a standalone. We also agree that they shouldn't try to write solutions
> for all possible ways that someone may need to distribute a
> standalone. My 2 cents is that LiveCode should provide a way for 3rd
> parties to expand on what happens when a standalone is being built.
> This is more than just turning off an option. Turning off an option
> would introduce an absence of behavior. I'm suggesting the addition of
> behavior that can occur during key points of the standalone building
> process.

Yeah, in my effort to try to minimize my TL/DRs I didn't include a 
detailed specification, using colloquialism where more precision may 
have been useful.


I'm assuming they'd do something similar to what we have now with the 
pre- and post-build messages.  When we consider those, the Plugins 
subsystem, pubsub, and the vast range of other IDE hooks, I feel pretty 
confident that they wouldn't suddenly change direction and make a 
locked-down hookless solution on this one.



> Perhaps all use cases can adequately be handled with the messages that
> are already sent once when a standalone builder finishes (e.g.
> savingStandalone and standaloneSaved).
>
> But, perhaps the standalone building process would be better served
> with additional, more granular callbacks, and maybe those callbacks
> are sent to a target other than the stack being saved. That is what
> I would like to be considered when modernizing the Standalone Builder.

Like that.


I think we're all on the same page here.

--
 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: We don't need a Player (was Re: New(?) Idea for Standalones)

[Richard Gaskin via use-livecode]

Trevor DeVore wrote:

> On Mon, Mar 29, 2021 at 1:24 PM Richard Gaskin wrote:
>
>> Trevor DeVore wrote:
>>
>>  > On Mon, Mar 29, 2021 at 12:31 PM Richard Gaskin wrote:
>>  >> Add-ons to the product experience can be a useful temporary
>>  >> workaround for long-time users, but if we step back and look
>>  >> at the gestalt of the user experience they're not a true
>>  >> solution.
>>  >>
>>  >
>>  > Do you think that LiveCode should have built in support for all of
>>  > the various installers such as DropDMG, InnoSetup, WIX, etc.?
>>
>> "All" is the biggest possible number, potentially infinite.  So
>> logically, of course the only answer is "no".
>
> And that is why I like hooks into the standalone building process :-)
>
> Provide the baseline solution but make it extensible so that
> developers who need more can integrate whatever they need into
> building a standalone. The less manual steps the better.

#GMTA

Here's the bottom of the post you were replying to:

 One suitable solution in the box is all that's needed,
 with the option for folks to turn it off if they prefer
 using any other of the infinite variety of all possible
 solutions.


So yeah, I don't much mind whether we call them "hooks" or "options" or 
even "doilies" as long as it supports the core need right out of the 
box, without penalizing deeply-experienced professionals with specific 
tool preferences.


--
 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: mouseenter/mouseleave and pointer tool

[Richard Gaskin via use-livecode]

Jim Lambert wrote:

>> Klaus wrote:
>> when the pointer tool is active, "mouseenter" and "mouseleave"
>> handlers are executed nevertheless!?
>>
>> I don't this this is correct behaviour!
>
> I agree.
> When the pointer tool is selected in the IDE one is supposedly in
> Editing Mode.

This is a philosophical point in LC, created by a change in how tool 
modes are presented.


Throughout all of xTalk history, and the history of the LC engine prior 
to its acquisition in 2003, tool modes have always been presented as 
options available to scripters like any other part of the language, 
changeable with the "choose" command.


Most xTalk IDEs have lacked the confidence in their language to also 
build their IDE in their own language, so this was less of an issue for 
HC, OMO, Plus, and others.


But MetaCard, SuperCard, Gain Momentum provided runtime editing of the 
sort we have with LiveCode.  While each had subtly different ways of 
guiding the user to appreciate the differences in tool modes, their 
audiences had less confusion, because they presented tool modes as tool 
modes (language elements like any other available for us all to use), 
rather than attempting to present a more consumer-app experience in 
which the pointer tool is somehow not something a scripter could be 
expected to ever want to use.


LC documents the "choose" command, but is designed in a way that 
attempts to be both an xTalk dev environment and a consumer app, 
resulting in an experience that lends many users to think of the pointer 
tool as somehow not available among the "choose" options.




One of the most powerful moments of my scripting life was when I 
launched SuperCard and was invited to explore one of the sample apps 
that came with it, SampleDraw.  It was basically MacDraw, a decent 
drawing app with vector graphics, document handling, and all that, but 
SampleDraw even more capable, with features like polygon morphing, and 
the whole thing written in xTalk.


That moment of seeing an app I'd known well reimplemented more 
powerfully in a scripting language I enjoyed is what compelled me to 
spend so many years enjoying xTalks.


--
 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: We don't need a Player (was Re: New(?) Idea for Standalones)

[Richard Gaskin via use-livecode]

Trevor DeVore wrote:

> On Mon, Mar 29, 2021 at 12:31 PM Richard Gaskin wrote:
>> Add-ons to the product experience can be a useful temporary
>> workaround for long-time users, but if we step back and look
>> at the gestalt of the user experience they're not a true solution.
>>
>
> Do you think that LiveCode should have built in support for all of
> the various installers such as DropDMG, InnoSetup, WIX, etc.?

"All" is the biggest possible number, potentially infinite.  So 
logically, of course the only answer is "no".


DMGs are native to the OS, as is the AppleScript used to automate making 
them look attractive.


LC has a reasonably nice Windows installer framework, which we all use 
every time we install LC.


I don't think anyone here is expecting LC or any other tool vendor to 
provide all possible solutions to a given problem.


One suitable solution in the box is all that's needed, with the option 
for folks to turn it off if they prefer using any other of the infinite 
variety of all possible solutions.


--
 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: New(?) Idea for Standalones

[Richard Gaskin via use-livecode]

matthias_livecode_150811 wrote:

> Don't blame Microsoft and Apple

I'm not sure anyone here is. Jumping through hoops is painful, of 
course, but I think the folks here recognize that having their data and 
devices compromised is even more painful.




> And purchasing a code signing certificate for Windows here in Germany
> was  also not very easy years ago, especially for independent
> developers.
> It was not just purchasing it in an online store. After purchase i had
> to proof my identity through a notary agency. Comodo contacted my
> lawyer/notary and asked for a confirmation that i am a real person.
> Therefor i had to visit the notary office, show my papers to get
> authenticated.  So i had not only pay for the certificate, but also
> for the authentication through the lawyer/notary.
> Thanks god, now Comodo is using public business registers for
> confirmation and luckily i am listed in one of them now. So the
> authenticaton process is much faster and without any additonal costs.

That's a valuable story.  It's good to see security taken seriously, and 
even better to see where the process is tailored over time as the 
balance between threats and remedies becomes ever more finely tuned to 
shift the burden to larger stakeholders with the resources to handle it 
well.



Once upon a time SSL certs were expensive and cumbersome to obtain.  Now 
we have projects like Let's Encrypt, which provide strong SSL certs 
automatically updated not just annually but every 90 days, for free.


The change was moving the burden from individual web site owners to 
bigger players who are also stakeholders, ISPs and ad-supported industry 
giants who need a safe web to thrive.  They have vast resources beyond 
what indies have to put on the problem, and centralized solutions can be 
handled by experts with good implementations and fewer errors.


I expect over time we'll see initiatives in the app space evolve this 
way as well, with OS vendors and other bigger stakeholders actively 
investing in ways to make it ever easier for indy devs to deploy safe 
software.


In a smaller but no less helpful way, Mark Waddingham's comment 
demonstrates the value of centralizing security process where practical:


   ...this is probably best done by improving the standalone
   building process (i.e. making it as easy as possible)
   rather than anything else.



> As a customer btw i really prefer secure software. I know that even
> with those security achievements software is not 100% secure, but more
> secure than without any notarization/code signing.

The listing of Common Vulnerabilities and Exposures (CVEs) at 
CVEDetails.com is a good reminder of growth in both scope and 
sophistication of attacks:


https://www.cvedetails.com/product/156/Apple-Mac-Os-X.html?vendor_id=49

At first glance, one might see futility in the steady increase of CVEs 
against macOS growing nearly every year while Apple has made deployment 
ever more cumbersome.


But a brief pause to think about it reveals the deeper truth: imagine 
how many vulnerabilities would be exploited if OS vendors weren't adding 
hoops for deployment to jump through.


--
 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: We don't need a Player (was Re: New(?) Idea for Standalones)

[Richard Gaskin via use-livecode]

Trevor DeVore wrote:

> On Mon, Mar 29, 2021 at 10:57 AM Richard Gaskin wrote:
>
>> TL/DR:
>>
>> We don't need a generic player.
>>
>> What we need is an updated Standalone Builder, to provide
>> more complete tooling and better guidance for building a
>> modern standalone.
>
>
> An easy way to extend the standalone building process with plugins is
> a necessity IMO as well.

Add-ons to the product experience can be a useful temporary workaround 
for long-time users, but if we step back and look at the gestalt of the 
user experience they're not a true solution:



The problem is tooling and knowledge necessary but not found in the product.

Whether the third-parties delivering essential tools are OS vendors or 
community members, both require knowing where to hunt down the solution, 
set it up, and use it.


Either way it's not in the box, so many won't know where to find it, and 
most newcomers won't know it even exists.



Third-party plugins are ABSOLUTELY FANTASTIC for adding *supplemental 
capabilities and conveniences* to a product.


But they cannot be profitably relied on to provide a core requirement of 
a product's critical path of use.


When the product is a tool for building applications, nothing could be 
more integral to its mission than building standalones.


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

We don't need a Player (was Re: New(?) Idea for Standalones)

[Richard Gaskin via use-livecode]

TL/DR:

We don't need a generic player.

What we need is an updated Standalone Builder, to provide more complete 
tooling and better guidance for building a modern standalone.




- more complete version 


Background
--

This thread, and many others like it, didn't start with a desire for a 
player.  That was merely a response to the challenges of building 
standalones.


Building standalones is the point of LiveCode, the culmination of 
everything in LC's user experience.


And it's become a pain point for most, early-prohibitive for some.

OS changes are of course not LC's fault.  But they are LC's opportunity, 
if the company wants to maintain its place as the easiest solution for 
making apps.




The Last Great Deployment Change


Back in the early days, the IDE's Standalone Builder didn't provide any 
support for document associations, creator codes, or other essentials we 
now take for granted.  It was expected we'd open some dev tool from 
Apple (ResEdit) to set those up.


LC Ltd recognized those steps were cumbersome, and often error-prone 
where they were being done at all.


So they took the time to completely redesign the Standalone Builder to 
include support for nearly every detail apps need for solid deployment.




The Next Great Deployment Change


Many if not most deployment tooling required by OSes are command-line 
apps, lending themselves well to being called from another program, such 
as LC's Standalone Builder.


Automate everything possible.

And where a step can't be automated, guidance and be provided, such as a 
direct link right in the SB's UI to the necessary steps for completing 
the process, laid out with sufficient clarity and detail to allow the 
user to complete the build with confidence.


If a standalone building step is essential, it needs to be handled in 
the Standalone Builder.


Use direct automation where possible, or a direct link in the UI to 
step-by-step instructions needed to complete the task.




The Business Case
-
As we've seen here and many other threads like it from time to time, as 
long as building a standalone in LC is characterized by confusion and 
dread, people will seek alternatives.


Any alternative either compromises LC's revenue model (based as it is 
around standalone licensing), or eliminates it (if LC is just as hard to 
use as anything else, why not use anything else?).


No option provides as much return on investment as focusing on updating 
the Standalone Builder to be as simple and graceful as it can possibly be.


LC has a strong advantage with its language, made a nearly unbeatable 
with its integrated GUI object model.


Bring deployment up to par with the rest of the experience, and LC has a 
chance for a good life ahead, slowing attrition rates while accelerating 
growth.


--
 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: New(?) Idea for Standalones

[Richard Gaskin via use-livecode]

Alex Tweedly wrote:

> On 27/03/2021 02:43, Richard Gaskin via use-livecode wrote:
>> This makes the Community Edition a natural fit for a generic player,
>> since the proliferation the license explicitly encourages would be
>> very much with the grain of its goals.
>>
>> But then we have to ask: how many of those who might enjoy a generic
>> player embrace the GPL with the stacks they'd like to distribute it
>> with?
>
> hmmm - I don't get that bit.
>
> The generic player would be built with Community Edition - and hence
> must be GPL-compliant.
>
> However, the stacks it "plays" are merely documents. GPL is (afaiu)
> clear that documents viewed (or indeed created) by GPL apps are not
> covered by the GPL - i.e. it does not proliferate into the stacks.
> The stacks are not in any way derivative of the player.
>
> So I could build a stack with my Indy license, and distribute that
> under any restrictive licensing terms I choose, but use the CE/GPL
> compliant player app to run them.
>
> Of course, the source of the stacks would be visible, but there
> wouldn't seem to be any requirement on which licensing terms I apply
> to that stack.
>
> Or, I may be misunderstanding GPL again - I have done on many
> occasions since I first hired a developer to work on gcc back in the
> mid-80s :-)


The GPL is intentionally vague on what constitutes "derivative work" 
with regard to license inheritance, acknowledging the vast and 
ever-growing number of ways code can comingle at runtime.


LC's interpretation is similar to Wordpress, Drupal, Joomla, and others 
which regard code running inside their process. Those CMS' regard all 
templates, plugins, widgets, themes, etc. as "derivative works" 
inheriting all rights and responsibilities of the CMS framework's GPL.


When in doubt about how any license applies to anything, it's always 
best to check with the owner of the property.  One of Mark Waddingham's 
more complete set of comments on GPL and LC Community is here:

http://lists.runrev.com/pipermail/use-livecode/2016-March/224276.html

The most relevant part may be this:

  If you don't wish to pay for a commercial license of some sort,
  then your option is to enter the GPL ecosystem of LiveCode
  Community and abide by its rules. If you do decide to pay for a
  commercial license then you can walk in both. I, personally,
  think that is entirely fair and reasonable.

So in a sense we're both right, at least as far as meeting the company's 
expectations:  As long as you maintain a current license to a 
proprietary edition, you can "walk in both"; if your license expires, 
distribution is GPL.


This still leaves two questions:

1. Can a proprietary licensee choose ANY license for stacks distributed 
with the GPL engine, or must it be at least GPL-compatible (such as MIT)?


2. What if I write something in a licensed proprietary edition this 
morning, distribute it for use with a Community engine this afternoon, 
and then let my proprietary LC license lapse tomorrow?  Does the license 
of what I've already sent out into the field somehow transform into GPL? 
How could any user know?



The simplest way to avoid any questions about attempting to mix license 
types is to simply not mix them.


GPL is pretty clear, and only becomes complex with efforts to circumvent 
its terms through mixing with other licenses.


Here I follow one simple rule:

I embrace the GPL where sharing under its terms is my goal; I avoid it 
where my goals are otherwise, including any potentially-gray area not 
already clarifed by the copyright owner.




> I won't even start on that until I've finished fulminating over your
> misspelling of whisky - but a response (or two) will come.

My family is from Ireland and I live in the States. I raise my whiskey 
to toast your whisky, in the kinship of two related but 
regionally-distinct liquors, each spelled correctly.


--
 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: Unreliable File Deletion

[Richard Gaskin via use-livecode]

R.H. wrote:

> The similar or same problem as you have: I want to delete the text
> file. The command I issue is "detele file ". The error it
> returns: "Can't delete file".

LC's result will tell you only the general fact that a file I/O 
operation failed, but not why.


The syserror() function will tell you why, delivering the specific 
integer code for the error the OS reported back to LC.


Establishing a habit of always including a call to sysError when 
reporting a non-empty result will save you countless hours of diagnostic 
time, e.g.:


  delete file tFile
  if the result is not empty then
  answer the result &" ("& sysError() &")"
  end if


--
 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: New(?) Idea for Standalones

[Richard Gaskin via use-livecode]

Roger Guay wrote:

> On Mar 26, 2021, at 5:35 PM, Richard Gaskin wrote:
>
>> What are you looking for?  When were these "good ol days"
>> in which one could run stack files without an engine, and
>> how did that work?
>
> In the good ol days, I could build a standalone for the Mac,
> Windows and Linux and distribute it willy-nilly. Now I have to
> jump thru intolerable hoops (at least for the Mac) to give
> someone my standalone. if someone (hint. . .hint) could build
> a Livecode reader app for dirt cheap or even free w advertising
> that would run LC standalones, everything would be right in the
> world again!
>
> I think my martini is showing...

After I read that I poured myself two fingers of whiskey and sat back 
enjoying the memories you conjured. Good thoughts. Thanks.


In those days we made software for single users to run on a single 
computer running one brand of OS.


The web had barely been invented, the Internet not yet privatized for 
general use, and "cloud" was still called "mainframe".


It was a much simpler time. I miss those days myself.


The hoops we now jump through to deliver apps are OS vendors responding 
to an evolving need to establish trust in hostile connected environments.


As software opportunities have expanded, they've for everyone, good and 
bad actors alike.


My response to Alex was apparently too long to be read, but I touched on 
this in third block, re "security", re implications for a player as well:

http://lists.runrev.com/pipermail/use-livecode/2021-March/263948.html



> This conversation has given me some focus and clarification of the
> basic idea. Here is what I would love to see: A LiveCodeLight
> downloadable from the mother ship.

Why specifically from the mother ship?

Or to put it in business terms, which features/bug fixes would you be 
willing to see dropped so the company could commit to making and 
maintaining yet another project?


In addition to the opportunity cost to the company, there's also the 
segment who would use it as an alternative to maintaining a current 
license, resulting in at least some degree of revenue cannibalization.


And while the upside is non-zero, it's limited to a slender subset of 
promotional value opportunities which could more easily be attained with 
nearly any marketing strategy at lower cost, and in ways that more 
directly feed their funnel.


Moreover, a player produces no direct revenue, but maintenance and 
support obligations create immediate (if modest) direct payroll impact.


Free software isn't free to make and maintain.


> LiveCodeLight would be a stripped down version of the community
> edition that would not open the IDE, but would open and run stacks.
>
> Thanks, Brian for the idea.
>
> Is that a cool idea or what?

Also addressed in my earlier post (some day I'll learn to write less here).

The close of that post suggested this might make a good community 
project, and described how simple it could be if anyone here really 
wanted something that rudimentary.


But (for the reasons also described in that post) it would have to be 
with Community, which raises two questions not yet answered in any 
subsequent reply:


How many who would use a generic player would be willing to relicense 
their works under GPL, as would be required if distributed via the 
GPL-governed Community Edition.


And with Community's role in LC's business as a sort of freemium offer, 
how many projects might one want to distribute with a player which use 
absolutely none of any features found only in the proprietary editions, 
Indy and Business?


--
 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: New(?) Idea for Standalones

[Richard Gaskin via use-livecode]

Alex Tweedly wrote:

> On 27/03/2021 00:35, Richard Gaskin via use-livecode wrote:
>>
>> What are you looking for?  When were these "good ol days" in which
>> one could run stack files without an engine, and how did that work?
>>
> I can describe what I would like; that may be similar to what Roger is
> looking for. Or it may not.
> But I think it is :-)
>
> I'd like to be able to develop a stack and give it to a friends or
> family, and have them run it on their iOS or Android devices. I don't
> want to get involved in building iOS standalones (or even installing
> xCode), so ideally I would give them a simple app (i.e. stackRunner
> kind of thing), and then my "app" as a document to load into that
> 'runner' app.
>
>> There are many reasons it would be problematic to make one generic
>> "player" for everyone's stack files, mostly user experience but also
>> app store restrictions, and additional technical requirements for any
>> devs using it to keep stacks playing nicely together.
>
> I'm not going to sell apps, or distribute them widely, so I (don't
> think  I) care about app store restrictions.

None of us would, because Apple's app store explicitly prohibits apps 
that act anything like app stores, so any distribution would be outside 
of their app store.



> I also don't care about 'user experience' in the sense of branding or
> feeling like a unique app.

If I were delivering a standalone that ran stacks as courses for 
elementary students, I'd design it differently than if the standalone 
were aimed at adult learners, or at organizations where the stacks could 
be collaboration or productivity tools.


Everything, even with the most trivial products, comes down to: What are 
you making and who's it for?


A one-size-fits-all really fits none, with either clothes or software.

This is something that's been part of my career since the mid-90s, when 
I was working on this very question with the folks at Allegiant 
Technologies for SuperCard. Much of the work I've done all these years 
is building authoring systems for people to deliver interactive 
experiences.  I've had lots of time across a dozen industries to think 
this through.


A generic player is one of those things that seems simple, but is only 
simple in practice to the degree that it doesn't deliver a great experience.




Let's set design aside for the moment and look at one other corner of 
this: licensing.


A generic player poses a potential risk to proprietary editions of LC, 
since it could be used as a way for folks to bypass a need for licensed 
standalone building.  Understandably, the LC EULA for the proprietary 
editions prohibit building a generic player.


However, the GPL serves an entirely different set of goals, emphasizing 
the freedom for the recipient of a work to do whatever they want with it 
all the way down to the source code.


This makes the Community Edition a natural fit for a generic player, 
since the proliferation the license explicitly encourages would be very 
much with the grain of its goals.


But then we have to ask: how many of those who might enjoy a generic 
player embrace the GPL with the stacks they'd like to distribute it with?


If there's enough people into the GPL that part of the licensing 
questions is solved.  But at the moment I'm not sure that's the case, 
and even if it is we're still left with the other question of 
security/liability:



If I make a standalone that runs stacks designed for a specific range of 
needs under my supervision, I have no problem putting my name on it 
since it's all code I can vet.


But if I make a generic player and someone else decides to distribute 
malware for it, LC is quite powerful, and quite powerful damage could 
result, rapidly, to the lives of everyone who ran it.


Of course, depending on the jurisdiction, chances are good I'd prevail 
if someone tried to assert that my company's reputation is what 
encouraged them to believe that any stacks run with it would be at least 
reasonably safe, despite whatever disclaimer I'd included (case law is 
mixed on this).


But can you imagine the time and money needed to defend a case like that?

It only takes one annoyed person with deep pockets to turn your life 
into a living hell, even if you eventually "win" the case.




> I'm not sure what you mean by  "additional technical requirements..."
>
> If that's feasible, I'd happily buy (or contribute cost towards) such
> a 'runner' app. I doubt that I'd be the only one.

The technical side of this would be longer than the above, which is 
already too long.  I've found that the more complete my answers here the 
less they're read, so there's a point where mail lists just aren't a 
great place for deep dives.



TL/DR:

If all one wants is a vanilla runtime engine and doesn't care about 
either 

Re: New(?) Idea for Standalones

[Richard Gaskin via use-livecode]

Roger Guay wrote:

> I guess I’m just thick headed, Richard, but I don’t know how anything
> you said solves my problem. Say I want to share a standalone with my
> wife or a friend. How can I do that easily like the good ol days?

It seems I'm the one who didn't understand.

Here you're asking about how to transfer a standalone.

My reply to was to what I had read as a very different question, about a 
player.


I described a couple different ways to make a player, but that was not 
what you were looking for.


What are you looking for?  When were these "good ol days" in which one 
could run stack files without an engine, and how did that work?


--
 Richard Gaskin
 Fourth World Systems


> On Mar 26, 2021, at 3:54 PM, Richard Gaskin wrote:
>
> Roger Guay wrote:
> > Has anyone thought of building a “legal” and “blessed" app for
> > Mac, WIndows and Linux that would open standalones for for each
> > of those platforms? Why put each of us through the agony (and
> > expense) of shifting/changing requirements to be able to easily
> > distribute standalones? Just as Microsoft Word is required to
> > open .doc files why not have something like LCreader app open
> > .livecode files
>
>
> Applications can have documents, and with many apps the documents are
> interactive media.  The LC engine has been supporting the ability to
> do that since the beginning.
>
> A stack can open another stack file equally well whether you run that
> stack in the IDE or as a standalone.
>
> You make just one standalone set up with the libraries and UI you want
> to present to your audience, and allow it to open anything you want
> folks to run with it.
>
> The Standalone Builder even provides a place to assign a document type
> for your app's files.
>
>
> There are many reasons it would be problematic to make one generic
> "player" for everyone's stack files, mostly user experience but also
> app store restrictions, and additional technical requirements for any
> devs using it to keep stacks playing nicely together.
>
>
> But you can make just one standalone and run anything else you make
> with it.
>
> Most of the work I've done over the years does exactly that. We
> deliver new stuff all the time, but we don't bother updating the
> installed app but maybe once every could years as OS/engine needs
> change - we do it all with stack files as documents to the app.
>
> In fact, for the last decade or so I've gone one further: users don't
> even need to deal with documents, at least not directly.  The
> standalone pulls them down over the web.
>
> Modern, cloud-driven, just like Adobe, Microsoft and others are
> heavily invested in.  Only it's easier in LC, as easy as "go stack
> ".
>
> --
> Richard Gaskin
> Fourth World Systems
> Software Design and Development for the Desktop, Mobile, and the Web


___
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: New(?) Idea for Standalones

[Richard Gaskin via use-livecode]

Roger Guay wrote:
> Has anyone thought of building a “legal” and “blessed" app for
> Mac, WIndows and Linux that would open standalones for for each
> of those platforms? Why put each of us through the agony (and
> expense) of shifting/changing requirements to be able to easily
> distribute standalones? Just as Microsoft Word is required to
> open .doc files why not have something like LCreader app open
> .livecode files


Applications can have documents, and with many apps the documents are 
interactive media.  The LC engine has been supporting the ability to do 
that since the beginning.


A stack can open another stack file equally well whether you run that 
stack in the IDE or as a standalone.


You make just one standalone set up with the libraries and UI you want 
to present to your audience, and allow it to open anything you want 
folks to run with it.


The Standalone Builder even provides a place to assign a document type 
for your app's files.



There are many reasons it would be problematic to make one generic 
"player" for everyone's stack files, mostly user experience but also app 
store restrictions, and additional technical requirements for any devs 
using it to keep stacks playing nicely together.



But you can make just one standalone and run anything else you make with it.

Most of the work I've done over the years does exactly that. We deliver 
new stuff all the time, but we don't bother updating the installed app 
but maybe once every could years as OS/engine needs change - we do it 
all with stack files as documents to the app.


In fact, for the last decade or so I've gone one further: users don't 
even need to deal with documents, at least not directly.  The standalone 
pulls them down over the web.


Modern, cloud-driven, just like Adobe, Microsoft and others are heavily 
invested in.  Only it's easier in LC, as easy as "go stack ".


--
 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: Problem with Script Editor in LC 9.6.2 (rc3)

[Richard Gaskin via use-livecode]

Sean Cole wrote:

> RichardG,

Feel free to use simply "Richard" if you like.


> That was a very long way of not answering the question. Very
> insightful regarding the DG though. :)
> It also went a long way of assuming the skill levels of the audience.
> Some of us are not limited to xTalk level.

Where I wrote that it's "an oversimplification to arbitrarily divide the 
world into two types of programmers, xTalkers and C coders", what I 
meant to say is that it's an oversimplification to arbitrarily divide 
the world into two types of programmers, xTalkers and C coders.


Sorry I was unable to make that clearer.


> I understand C++ and why Trevor likely coded the DG using such.

My writing was even worse than I'd thought. Having once hired Trevor to 
write some C++ for a project many years ago, I'm well aware of the 
breadth of his skillset.


What I had attempted to illustrate there had nothing to do with coding 
styles, but with a merely pragmatic tradeoff necessary for certain uses 
of LC group objects.




> My question, just to reestablish, was what on Earth could possibly
> complicate the scrolling of the line-numbers in sync with the main
> 'field'?

Gave it my best shot.

TL/DL:

1. I don't specifically know what the LC SE is doing there.

2. I don't generally believe it makes sense to describe anything as 
simple until we take the time, however much patience that requires, to 
understand the goals of the design.




> Very occasionally the numbers freeze altogether until a click in
> the editor which is an interesting aside and only partly related
> to the question. I never notice a lag between the two areas.

That lag you just described awaiting the click?  That. That's one of the 
observable lags I'm referring to.




> 32-bit I feel is neither here nor there in relation to the syncing
> or imperceivable lag, especially for the SE.

Agreed, which is why I wrote "the 32-bit coordinate space only applies 
to controls, not the contents within text fields".


Coordinate space was only relevant in exploring why the DG uses dynamic 
scroll updates, contrasting the DGs architectural decisions with those 
used to populate line number fields, where such a choice is not 
necessary but may reflect styles of habit.



> Looking on github reveals that the majority of the code for the SE are
> indeed, as suspected, written in livecodescript (xTalk ;)) by BHall
> mostly, rather than CPP. And, as suspected, really quite simple and
> unconvoluted as they can get. Barely anything to become difficult in
> fixing for Henry's listed issue.
> revsecommoneditorbehavior.livecodescript holds the key, lines
> 2658-2721 most likely.

Looks like you've found your answer.

--
Richard Gaskin
Fourth World Systems


___
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: [ANN] This Week in LiveCode 259

[Richard Gaskin via use-livecode]

Andre Garzia wrote:
>> On 25 Mar 2021, at 14:58, Richard Gaskin wrote:
>>
>> Defaulting to HTTP for customer-facing systems simplifies a
>> lot of decision-making, and since most of the rest of the
>> world makes the same choice at least we're in good company. :)
>
> Also, HTTP/HTTPS are usually enabled on firewalls, makes your
> life a lot easier when you don’t need to tell your user that
> they need to fiddle with firewall rules.

Ah yes, I remember the good ol' days when Internet P2P seemed promising, 
shut down once everyone began reconsider the implications of expanding 
the attack surface with open ports...


--
Richard Gaskin
Fourth World Systems


___
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: Problem with Script Editor in LC 9.6.2 (rc3)

[Richard Gaskin via use-livecode]

Sean Cole wrote:

> On Wed, 24 Mar 2021 at 21:45, Richard Gaskin wrote:
>
>>  I believe it may be related to the complicated way the line
>> number field is kept in sync.
>
> Quick question. Why would the line number field be complicated? I
> can’t imagine anything that would necessitate making it complicated.
> Numbers and break points. That’s all it handles, right?


It's easy to describe anything in terms that make it sound simple, but 
whether a task is *actually* simple depends on many things.


It's equally an oversimplification to arbitrarily divide the world into 
two types of programmers, xTalkers and C coders, but that won't stop me 
from indulging in it here :



If we look at text editors made by C coders, they generally only render 
the line numbers visible on screen given the current scroll position. 
But they do everything with lower-level/computer-oriented thinking, with 
lineto and moveto and stringAt (yes, the Inside Macintosh references 
there show my age, but you know what I mean), so for them these types of 
calculations are second-nature and not considered tedious at all, it's 
just how things are done.


xTalkers, by virtue of choosing a language that is not only high-level 
but among the very few that directly incorporate GUI controls as 
inherent language elements, think differently. To us we put text into a 
field and set the scroll as we like and let the engine figure out the 
details.



Which is "best" is a topic that can be hotly debated, and was here on 
this list several years ago in a thread on making text editors in LC.


One of the participants in that thread was Jeff Massung, who'd made a 
very nice Erlang editor in LC. In his view, IIRC, it was wasteful to ask 
the engine to render thousands of lines of line numbers if the script 
being displayed was much shorter.  He felt that the "right" approach 
would be to do as C programmers do, to dynamically calculate which line 
numbers should be visible and dynamically populate the line number list 
with only those on each scrollBarDrag.


Others, including myself, felt that using xTalk objects as xTalkers are 
accustomed to using them was not a mistake at all, but actually quite 
with-the-grain for xTalk work. Even if we're asking the engine to work 
harder, we're doing it only once up front, relying on the engine's good 
buffering to make scrolling throughout the rest of the session simpler.



It's worth noting that the excellent DataGrid relies on 
dynamically-calculated scrolling, but even more worthy to note WHY:


It's not because scrolling the DG is made any faster (observably it isn't).

It's because the performance impact of dynamically-calculated scrolling 
is a NECESSARY tradeoff to cover the sometimes-large number of records 
it's asked to display.  LC uses 32-bit coordinate addressing, which is 
more than adequate for most things we render since it gives us about 30 
feet of drawing space, far bigger than any monitor. But if you try to 
place tens of thousands of groups nested within a scrolling group, 
you'll quickly discover what happens when you exceed 32-bit coordinate 
space. :)


So Trevor did the tedious work of providing a profoundly flexible 
DataGrid, where for the relatively low cost of a modest performance hit 
during scrolls we can effortlessly display even vast numbers of records, 
by only actually rendering those on screen at any given time.


But the 32-bit coordinate space only applies to controls, not the 
contents within text fields, so



Back to the LC Script Editor, truth be told it's been so long since I 
donned my pith helmet to dive into its code jungle that I'm not in a 
position to speak authoritatively on how it's constructed.


But we can observe (sadly, without much effort) a lag between scrolling 
the script field and the subsequent update of the line number list.  In 
some cases, depending on platform and script length, this lag is more 
easily seen than on others.


This suggests that there's a lot more going on with the SE's line number 
update than just setting its scroll to match the editor field's.


Indeed, given the variance of the lag it would seem it's not updated 
directly at all, but perhaps via "send".



It wouldn't be appropriate to say the LC implementation is necessarily 
"wrong" or even "bad".  It's a deeply complicated layout with a lot of 
updates to manage, and given the vast scope of its design ambitions it's 
hard to say what one "should" do there.


But it is safe to observe that it was written by people who cut their 
teeth on languages more lower-level than xTalk. Aside from Monte and 
Kevin, I don't know of anyone there who shipped a product using an xTalk 
before being hired to make an xTalk.


Obviously, that's exactly what we want in an engine team, C++ engineers 
who live and breathe deep computer science.


But from time to time it does lend itself toward designs and 
implementations that look like the work of native C coders rather than 
native 

Re: [ANN] This Week in LiveCode 259

[Richard Gaskin via use-livecode]

Andre Garzia wrote:

> On 24 Mar 2021, at 23:50, Richard Gaskin wrote:
>>
>> And with Windows 10, Microsoft is now embracing Linux in its Windows
>> Subsystem for Linux, so Win folk can enjoy industry standard tooling
>> on all OSes:
...
> If you have control of the Windows machine, then you can set it up to
> run as you want, but if you’re shipping software for end-users, you
> can’t assume WSL Ubuntu is there so you can run rsync.
>
> I know you didn’t say that but often I see scripts in other
> communities that assume a ton of stuff (even on macOS where
> many scripts assume homebrew is present).

True, I didn't say that. What I said was:

In this discussion of personal plugins run on macOS,
a macOS solution seemed appropriate.

We often see AppleScript presented on this list, as it was in this 
discussion as well.  But it's far less pervasive than bash: it's only 
available on macOS, with no option at all for using it anywhere else. 
And it's only well supported in an ever-smaller percentage of apps (not 
to mention slow, finicky, and hugely unpopular with the Steve Jobs/NeXT 
acolytes running much of Apple's tech divisions).


For most sysadmin tasks, these days Apple nudges us toward shell, with a 
large and growing number of bash examples in their dev docs.  macOS 
being a certified Unix, bash is a good choice for Apple to promote, and 
for developers and sysadmins to use.



Of course for any customer-facing solution we'll want to be mindful of 
dependencies.


But since everyone here is a developer, and this discussion is about 
developers making tools for themselves, appreciating the full scope of 
options available to us doesn't seem a mistake.


Modern macOS development increasingly means being familiar with 
Terminal. Time spent there is not only necessary for many things, but as 
we learn how to integrate the shell with LiveCode the options for 
automation of both local and remote workflows becomes nearly as 
limitless as one's imagination.




As for Windows, Microsoft doesn't pour millions into building out 
subsystems on a whim. Their embrace of the Linux shell for developers is 
as much a part of their well-thought-out strategy as Nadella's embrace 
of open source.


Microsoft understands what we see in the work that comes our own desks: 
in the modern world, software development is usually client-server 
development, with half of most systems we deliver living in the cloud.


Microsoft IIS remains deeply entrenched within the enterprise, but most 
things customer-facing are Linux. Indeed, even on Microsoft's own Azure 
the most popular OS is Ubuntu.


Like Apple, Microsoft is actively encouraging devs to consider adopting 
bash as a prime choice for admin tasks.  It's where the tooling is, and 
on dev systems it's being made ever more available for today's 
interoperable workflows.


We don't have a truly universal admin language, but bash is as close as 
we get right now:  built into every Mac, native to every Linux server we 
work with, and with strong developer support by Microsoft.


--
Richard Gaskin
Fourth World Systems



___
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: [ANN] This Week in LiveCode 259

[Richard Gaskin via use-livecode]

Andre Garzia wrote:

> Devising your own binary file transfer protocol based purely on TCP
> sockets is a very tedious and error prone process that will get you
> no advantages unless you really have some special need that is not
> solved by any of the solutions that already exists.
>
> The easiest way to work around not being able to use FTP and friends,
> is with a simple HTTP server and a CGI on the server machine that has
> logic for receiving file uploads, then you simply use either libURL or
> TSNet to send the files.


When SuperCard introduced socket programming to the Mac xTalk world with 
its companion Marionette add-on, being young folk we got all excited 
about crafting custom protocols for every little thing we needed.


It was a good learning experience, and I came to appreciate the vast 
range of styles in writing clients for NNTP, Gnutella, and FTP, in 
addition to the random protocols I came up with on my own.


But the biggest lesson I learned is not to write custom protocols. :) 
It's a lot of work to get them working well, and far more work to make 
them secure and robust.


These days I rarely think about protocols at all, at least in 
customer-facing code. I've adopted using HTTP as the default solution 
for everything, unless I have a specific reason not to use it.


Most of what we need from a server is to submit a request and get a 
reply, and occasionally have some metadata along for the ride.  HTTP 
does that well, with very slim header requirements that are also vastly 
extensible, so metadata is as simple or rich as you need in the moment. 
 There's more documentation and tooling for HTTP than any other 
protocol, so it's easy to learn to use it well, and if another 
programming joins the team they can work with your code effortlessly.


Defaulting to HTTP for customer-facing systems simplifies a lot of 
decision-making, and since most of the rest of the world makes the same 
choice at least we're in good company. :)


--
Richard Gaskin
Fourth World Systems


___
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: Set and get dgData and dgText delay

[Richard Gaskin via use-livecode]

The difference between the working and non-working examples seems to be 
limited to the introduction of a delay in the working one, between 
setting the dgData array and later obtaining its text.


Since the array form is what the DG uses internally, perhaps something 
during loading of that array or rendering the UI needs the "wait 0", and 
what you're seeing is a side effect of that internal need.


Being scripted in LC, the DG code could be examined for "wait" or "send" 
to see what's up.


But while the exploration may be fun it would likely be inconsequential, 
since given the general quality of Trevor's work the delay is probably 
not a mistake, but a necessity. That is, you'd learn WHY you need the 
delay, but you'd still need it.


If you do go spelunking in the DG source please let us know what you find.

But now that you've found the solution it may be just as well to use it 
and move on with what you're building.


--
Richard Gaskin
Fourth World Systems




Sean Cole wrote:


Thanks Craig

This could make some sense. There are a lot of handlers to deal with. I
thought I was going a bit mad. I’m just going to have to pick my way
through.

On Thu, 25 Mar 2021 at 12:44, Craig Newman via use-livecode <
use-livecode at lists.runrev.com> wrote:


I have seen this here and there for years, and having nothing to do with
dataGrids per se.

A handler will fail to run, but will step through in the debugger without
issue. This usually resolves, and I never know why.

Craig

> On Mar 24, 2021, at 5:09 PM, Pi Digital via use-livecode <
use-livecode at lists.runrev.com> wrote:
>
> Hi All
>
> This has been a bit of a mind bender, mainly because in a test stack it
works just fine, but...
>
> Has anyone ever had problems with something like this:
>
> on myHandle
> — ...some code
> Set the dgData of grp “myDG” to tDataA
> Put the dgText of grp “myDG” into tDataS
> — tDataS returns empty
> — process tDataS...
> end myHandle
>
> And this:
>
> on myHandle
> — ...some code
> Set the dgData of grp “myDG” to tDataA
> dispatch “myHandlePt2”
> end myHandle
>
> on myHandlePt2
> Put the dgText of grp “myDG” into tDataS
> — tDataS returns empty
> — process tDataS...
> end myHandlePt2
>
> However, this works:
>
> on myHandle
> — ...some code
> Set the dgData of grp “myDG” to tDataA
> send “myHandlePt2” to me in 0 sec
> end myHandle
>
> on myHandlePt2
> Put the dgText of grp “myDG” into tDataS
> — tDataS returns empty
> — process tDataS...
> end myHandlePt2
>
>
> It seemingly doesn’t have anything to do with data length. I’ve tried
forcing a refresh of the grid using dispatch refreshList to it but that
makes no difference. Stepping through in the debugger allows it to work or
setting a breakpoint, but does not when in full run. Both in standalone and
ide.
>
> A one have any clues why this might not work sometimes?
>
> Thanks
>
> Sean Cole
> Pi Digital
> eMail Ts & Cs



___
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: [ANN] This Week in LiveCode 259

[Richard Gaskin via use-livecode]

I don't understand.  FTP, SFTP, FTPS, scp, and rsync all use sockets.

Are you suggesting Jacque write her own file upload protocol?

--
 Richard Gaskin
 Fourth World Systems



Bob Sneidar wrote:

> Or sockets.
>
> Bob S
>
>
> On Mar 24, 2021, at 4:22 PM, Richard Gaskin wrote:
>
>> FTP is a great protocol for open-ended traversal of remote file
>> repositories.
>>
>> For just transferring a file, scp or rsync with shared keys is a one-
>> liner via shell(), and will be faster in addition to being simpler to
>> code.
>>
>> --
>> Richard Gaskin
>> Fourth World Systems


___
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: [ANN] This Week in LiveCode 259

[Richard Gaskin via use-livecode]

In this discussion of personal plugins run on macOS, a macOS solution 
seemed appropriate.


And with Windows 10, Microsoft is now embracing Linux in its Windows 
Subsystem for Linux, so Win folk can enjoy industry standard tooling on 
all OSes:


https://docs.microsoft.com/en-us/learn/modules/get-started-with-windows-subsystem-for-linux/1-introduction

--
 Richard Gaskin
 Fourth World Systems




 matthias_livecode_150811 at m-r-d.de matthias_livecode_150811 at m-r-d.de
Wed Mar 24 19:35:02 EDT 2021
-
Matthias Rebbe
Life Is Too Short For Boring Code


Am 25.03.2021 um 00:22 schrieb Richard Gaskin via use-livecode :

FTP is a great protocol for open-ended traversal of remote file repositories.

For just transferring a file, scp or rsync with shared keys is a one-liner via 
shell(), and will be faster in addition to being simpler to code.


But only on macOS and Linux. Windows has not any of those tools included by 
default.




--
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: [ANN] This Week in LiveCode 259

[Richard Gaskin via use-livecode]

FTP is a great protocol for open-ended traversal of remote file 
repositories.


For just transferring a file, scp or rsync with shared keys is a 
one-liner via shell(), and will be faster in addition to being simpler 
to code.


--
 Richard Gaskin
 Fourth World Systems




matthias_livecode_150811 at m-r-d.de matthias_livecode_150811 at m-r-d.de
Wed Mar 24 18:51:56 EDT 2021

what i forgot

my previous overview

Server scheme use sslis protocol
ftp://   false  ftp
ftp://.  true  ftp over SSL explicit
ftps://  trueftp over SSL implicit


is how tsNet needs the server url


-
Matthias Rebbe
Life Is Too Short For Boring Code


Am 24.03.2021 um 23:44 schrieb matthias rebbe via use-livecode :

I've just had a quick look at the documentation of Fetch. 
It seems Fetch uses ftps:// for both  FTPeS (FTP over SSL explicit)  and FTPS (FTP over SSL implicit). But it depends on the port number you have entered. 
If you keep port 21 then FTPS (FTP over SSL implicit) is used. 
If you set the port to 990 then Fetch uses FTPS (FTP over SSL implicit).


Btw. it is not granted that an FTP server supports all modes.

Regards,
Matthias

-
Matthias Rebbe
Life Is Too Short For Boring Code


Am 24.03.2021 um 23:25 schrieb J. Landman Gay via use-livecode :

On 3/24/21 4:02 PM, matthias rebbe via use-livecode wrote:

Server scheme use sslis protocol
ftp://   false  ftp
ftp://.  true  ftp over SSL explicit
ftps://  trueftp over SSL implicit


Thanks. Fetch documentation says that FTP with TLS/SSL URLs should start with 
"ftps" so now I'm not sure what it's doing.

--
Jacqueline Landman Gay | jacque at hyperactivesw.com
HyperActive Software   | http://www.hyperactivesw.com

___
use-livecode mailing list
use-livecode at lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode



___
use-livecode mailing list
use-livecode at lists.runrev.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