Re: DataGrid question...

[Richard Gaskin via use-livecode]

Bob Sneidar wrote:

> I thought you could embed checkboxes in a data grid?

A DG is a collection of groups. Anything that can be put into a group 
can be part of the group that defines the row.



> When have we ever been able to embed another object in a field?

"Embed"? Never.  But we can display an image in a field.

It works very much like HTML, where you can reference an image object by 
ID to have it show up in a field:


  set the imageSource of char 13 of fld 1 to tSomeImgID

HtmlText for that would show something like:

  Hello World 


--
 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: Our first Community Zoom Session

[Richard Gaskin via use-livecode]

Mark Wieder wrote:

> I'm *very* impressed with Zoom's engineering team, rolling out a new
> version to quash this vulnerability asap. I got prompted to install
> the new version this morning. Upgrading was painless. Not only is
> Zoom being super-responsive about this (and given the publicity lately
> it stands to  reason that they would) but they're being upfront about
> the issues and backtracking and patching in public in real time. You
> don't often see companies with this size a customer base turn on a
> dime like this.

+1

I knew nothing about Zoom until a few weeks ago, but everything I've 
read since is impressive.


And as both technologists and citizens, in addition to what Zoom is, 
also valuable is what they're not: not Google Hangouts, not Apple 
FaceTime, not Microsoft Teams, etc.  A startup this successful outside 
the Big Five is helpful for everyone, and devs in particular. Developers 
thrive in diverse and fluid ecosystems.


And did you notice Zoom's API docs?
https://marketplace.zoom.us/docs/guides/tools-resources/zoom-apis

I've only started reading them, but the functionality seems like a very 
empowering compliment to LC's GUI capabilities, esp. for integrating 
with other services an organization may 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: Script Only Stack Properties

[Richard Gaskin via use-livecode]

Bob Sneidar wrote:

> I just discovered an interesting aspect of script only stacks. They
> CAN have Custom Properties… but ONLY while in memory! Once closed, the
> properties disappear. Seems like a slight mod would be able to save
> these properties as a separate file so that they can remain
> persistent.

Yep. So much of the difficulty folks have had using SoS come from just 
over-thinking them.


A stack is a stack is a stack.

With script-only stacks there is one distinction: the storage format 
contains only the stack script, and optionally a behavior reference.


That's it.

Everything else you can do with a stack at runtime can be done with any 
stack, regardless of its storage format.


Indeed, nearly everything we see in the IDE these days are SoS.

--
 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: Script Only Stack Properties

[Richard Gaskin via use-livecode]

Bob Sneidar wrote:

> Hmmm… If that is the case then theoretically, on closeStack the new
> properties could be arrayEncoded and saved to disk, and then on
> openStack they could be read and then arrayDecoded and reset again.

Stacks can also contain controls, each of which can be expressed as an 
array of properties.


You could craft an array-based format to allow storage and recreation of 
even complex GUI stacks.


What you'd have is a binary file dependent on a lot of scripted code.

Meanwhile, we already have a binary format handled robustly in the 
compiled object code of the engine. :)


--
 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: Our first Community Zoom Session

[Richard Gaskin via use-livecode]

Bob Sneidar worte:

> Richard wrote:
>> And did you notice Zoom's API docs?
>> https://marketplace.zoom.us/docs/guides/tools-resources/zoom-apis
>>
>> I've only started reading them, but the functionality seems like
>> a very empowering compliment to LC's GUI capabilities, esp. for
>> integrating with other services an organization may need.
>
>
> Richard,
>
> Without going into the details of the API, do you think a kind of
> Customer Support portal could be built into LC?

Why not?

And imagine what can be done integrating the workflow with other 
services useful to an organization, including perhaps an issue tracker, 
project management, contacts, content management, any of the great tools 
in Nextcloud, or MS Teams, or as Bill Prothero suggests, a learning 
management system.


The ways in which cloud services can be made even more useful by mixing 
and matching them to fit the unique needs of an organization are nearly 
limitless.


LiveCode can be used to provide attractive, feature-rich UIs that turn 
disparate services into a cohesive workflow.


I believe that this painfully disruptive moment in history provides all 
of us with thousands of ways yet to be discovered that we can lend our 
talents and interests to helping organizations get through this 
transition with less difficulty.


--
 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: Script Only Stack Properties

[Richard Gaskin via use-livecode]

Bob Sneidar wrote:

> True, but with properties, I can envision a use case for persistent
> values between sessions.

Persistence is essential in many contexts.  But is it necessary that 
data be bound to code?


Sometimes it is.  When it is, is it necessary that the file format be text?


> This is quite separate from GUI objects.

Is it?

What are objects but a type declaration followed by a set of properties?


> By saving and reloading properties of a script only stack, everything
> is still text file only based.

Encoding the array would be the simplest, fastest, and most robust 
option.  LSON is to LC what JSON is to JS, the most with-the-grain 
serialization method for the scripting engine it was designed for.


But in one respect LSON is more akin to MondgoDB's BSON: it's more 
efficient than JSON because the format is binary, requiring fewer steps 
to de-serialize.


So if your circumstance requires you to be working exclusively with text 
files, LSON is a non-starter.


Then you can choose among JSON, YAML, XML, ISHI, or any number of other 
plain-text serialization formats.



When I need to combine code with data, I usually use stack files.

If I need data alone, I often use LSON.

If the project requires that the storage format be interoperable, then I 
look at other options.


--
 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: Our first Community Zoom Session

[Richard Gaskin via use-livecode]

Dan Brown wrote:

> Definitely not a startup, they employ 700 developers in China.

True, "startup" was a bad word choice on my part.  I was grasping for a 
word that distinguishes them from The Big Five that currently control 
nearly everything on the Internet.


In a system as vast and important as the net, it benefits all of 
humanity to have its control broader than the number of people who can 
fit in a golf cart.



> In fact your data is passing through China, and being passed on to
> facebook also.

I had heard about the FB thing, but had thought that was opt-in.  If not 
requiring explicit opt-in, I don't think the word "evil" is entirely out 
of bounds.  Psychosocial profiling derived from mass data collection is 
something we should all be wary of.



> https://jitsi.org/ is a great open source Zoom alternative

Excellent - thanks! I'll look it up and see what it takes to set up a 
VPS with 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: Maximum field height?

[Richard Gaskin via use-livecode]

J. Landman Gay wrote:

> I have a field that reports a formattedheight of 125396. I want to
> extend it to full height for use inside an enclosing scrolling group.

I see that method used in the Lesson on using a scroller for text as 
well, but I've never understood why.  What is the advantage of putting 
the field inside of a group rather than using the scroller with the 
field directly?



> But when I try to set the height to the formattedHeight, I get an
> error: Value is not a number.

I think Paul has the answer there: groups have limit of 32,767px on 
either axis.  That's about 30' on desktop systems so generally useful, 
but when using them to contain a field sized for long text it can easily 
be exceeded.


--
 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: Go to card has become slow

[Richard Gaskin via use-livecode]

Bob Sneidar wrote:

> Thanks Terry I did the same thing. The focus is on server performance,
> not client. What I gleaned is that for an individual transaction, the
> difference between a transactional select statement and non is
> indistinguishable to the end user.

The rubric I was given back in the day is that transactions benefit 
writes but not reads. Thanks for confirming.



> Also, filtering out any save operations (including those occurring in
> plugins) increased performance on Windows by an astounding amount.
> While queries still take 3 to 4 times as long on Windows as they do on
> Mac, the lag has become acceptable and comparable to other apps doing
> similar operations.

I've been trying to sort through several reports about write speeds on 
Windows, but most examples I've seen conflate several different tasks. 
For example, the latest I came across had a mix of JSON translation and 
array manipulation in addition to writes, so diligent analysis would 
require pulling that example stack apart into three different tests to 
pinpoint the actual bottleneck.


It may be that there's something about the APIs LC uses on Win which are 
less than optimal, or perhaps something inherent in NTFS.


But I so often see speedy writes on Win in LC that I haven't yet pinned 
down a recipe that exposes a write issue specific to LC on Windows.


Does anyone have a clue to the question that comes up in various forms 
here lately: what factors could make writes from LC slower on Windows 
than on Mac or Linux?


--
 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: Maximum field height?

[Richard Gaskin via use-livecode]

J. Landman Gay wrote:

> @Richard, when developing for desktop you don't need the enclosing
> group, but on mobile you do because acceleratedRendering only applies
> to groups. Without it you can't achieve smooth scrolling. I wish we
> could just set a field to scrolling layermode, it would sure make
> layout and resizing easier.

My own mobiles apps haven't yet displayed text longer than a few dozen 
pages, but I was impressed with the smoothness.


I'd always taken LC's field excellent field buffering for granted, given 
that their text engine is internal and used on all platforms.


I've had such good luck so far with using scrollers directly on fields 
that it never occurred to me that accelerated rendering would be useful 
for field objects.


Maybe Mark Waddingham could explain the relationship between LC's field 
buffering and the non-text buffering the engine does with groups?


--
 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: Maximum field height?

[Richard Gaskin via use-livecode]

J. Landman Gay wrote:

> On April 5, 2020 12:46:19 PM Richard Gaskin wrote:
>
>> I've had such good luck so far with using scrollers directly on
>> fields that it never occurred to me that accelerated rendering
>> would be useful for field objects.
>
> If you're using a vScrollbar then no problem. But for swipe scrolling
> without a scrollbar, which is what mobile users expect, it's a
> different story. Android isn't as bad as iOS but there's a noticeable
> stutter on both.

I've been too lazy and much too enamored with The xTalk Way for any of 
that:


Once I saw that the scroller works well on the field content I've been 
working with, I added a routine to my mobile lib that automatically 
removes the vScrollbar from any non-editable field that has one, and 
instantiates a matching scroller over it.


So yes, I'm using the field directly with no enclosing group, but no, I 
don't use the desktop scrollbar on mobile; the scroller overlay does a 
good job of tracking the user interaction, with the appropriate endpoint 
indication and all, and scrolling the field in response to the 
scroller's messages has worked well.


But then again, I haven't used really long text with that. I'll explore 
that soon, and in the meantime I look forward to what you learn with 
this experiment from your earlier post:


>  I've switched over to trying a group set as a container and setting
> the field itself to scrolling layermode. I haven't tried it yet on
> mobile but we'll see.

While you're at it, it may be worthwhile turning the scrollbar of the 
field off and having your scrollerDidScroll set the scroll of the field 
directly, with no enclosing group at all.


If it works as well for you as it's been doing for me, it saves me 
another test  and gives confidence to others that actually 
development with LiveCode isn't nearly as cumbersome as that Lesson on 
scrolling fields suggests.


--
 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: Socket Help

[Richard Gaskin via use-livecode]

Bob Sneidar wrote:

> I am creating a client/server socket based app and I am trying to
> develop both the client and server on the same workstation, and I
> am having difficulty. I *think* the issue is that the client and
> server cannot both be on the same system, but I’m not entirely sure.
> I’m asking the system to listen and also talk on the same port.
>
> Anyone have any insight into this?

Hard to say without seeing the code, but my-go recommendation is, when 
in doubt review this excellent sockets example:


http://lessons.livecode.com/m/4071/l/12924-how-to-communicate-with-other-applications-using-sockets

--
 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: Maximum field height?

[Richard Gaskin via use-livecode]

J. Landman Gay wrote:

> On 4/5/20 1:12 PM, Richard Gaskin via use-livecode wrote:
>
>> Once I saw that the scroller works well on the field content I've
>> been working with, I added a routine to my mobile lib that
>> automatically removes the vScrollbar from any non-editable field
>> that has one, and instantiates a matching scroller over it.
>
> That's my standard procedure too, unless I'm using a pseudo-scrolling
> handler that allows pushing up or down on the field on desktop. It's
> basically a simulation, but for quick access during development it's
> faster to just use the built-in scrollbar.

Exactly. Reducing the differences between runtime and development is a 
cornerstone of The xTalk Way.


Dropping a field on a card works. If we want it scrollable, we click a 
checkbox.  Once clicked, it works everywhere, adapting to the UI 
conventions of the host platform. Why should that not work on a phone?


A generic solution REALLY SHOULD BE IN THE ENGINE (is that loud enough? 
Good), but in the dismaying absence of that feature completion some ten 
years later, being able to work around it by having a generic solution 
in a library is acceptable.


That is, if it works:

>> So yes, I'm using the field directly with no enclosing group, but no,
>> I don't use the desktop scrollbar on mobile; the scroller overlay
>> does a good job of tracking the user interaction, with the
>> appropriate endpoint indication and all, and scrolling the field in
>> response to the scroller's messages has worked well.
>
> I just released an app using this method and on iOS the stutter is
> quite noticeable, as well as on Android devices with slower CPUs.
> It's okay for short text, sort of (though there's a brief
> jerk) but for anything longer it fails.

Good to know.  Thanks.

It's a good thing for the more sensitive readers of this list that I 
have a busy Sunday planned, because my ALL CAPS portion above is just a 
small sample of the "When Keeping It Real Goes Wrong" episode I would 
otherwise drop on this list like a truckload of customer advocacy bricks.


Suffice to say politely and succinctly: a decade later, LC for mobile 
remains half-baked compared to what it could be, compared to The xTalk 
Way that rests at the heart of its origins.


There, I said it. Someone had to.

And it's too bad, because on the desktop it absolutely rocks beyond just 
about any other option on the planet.


It doesn't need to be this way.

Software is eating the world, The xTalk Way is supremely productive, and 
LiveCode is the most powerful xTalk ever.


LiveCode should be eating the planet. That it isn't is a function of the 
customer experience. If we don't soberly own that, there is no 
meaningful growth path forward.



> Up until LC 9 it was possible to set the field to use a scrolling
> layermode in the property inspector, but that's been removed. You
> can still set it by script, but it has no effect (and probably never
> did) and the engine defaults to dynamic layermode instead.

If a scrolling field can't be scrolled on mobile with checkbox ease for 
the developer and well-met expectations for the user, that would be a bug.


Let's not lower the bar. Let's complete the implementation.

Let's deliver excellence, and enjoy excellent growth.

The world is hungry for highly productive software development 
solutions, right now more than ever. Can we feed them?


--
 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 locating Android SDK

[Richard Gaskin via use-livecode]

I'm setting up a new machine for Android development.

Where is the one-page list of steps on the livecode.com site that 
reliably guides a new user through this for all supported platforms 
(Mac, Win, Linux)?


This one fails:
http://lessons.livecode.com/m/2571/l/625198-livecode-and-android-studio


#CriticalDocumentationBugsThatTurnOffNewUsers

--
 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: Maximum field height?

[Richard Gaskin via use-livecode]

Bob Sneidar wrote:

> I’m curious though if a library could be created so that a handler for
> a mobile message (let’s say a touch message) could “translate” into a
> desktop message? In this way, the app on the mobile would send a
> mouseUp message to the target.

Why not?  Most developers I know do exactly that.

We all rewrite the same library, over and over, because it isn't in the box.

Newcomers will not know to do this, or how.

--
 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: Socket Help

[Richard Gaskin via use-livecode]

Bob Sneidar wrote:

> I’m curious how this client server method handles multiple
> simultaneous connections? I had the idea of having a listener agent
> spawn an SQL Agent stack the first time a client connected, that would
> then listen on a random port. The listener agent would return the
> random port to the client which would then in the future communicate
> with the random SQL agent directly. A kind of passive connection if
> you will. I’m not sure all that is necessary though.
>
> I kept waking up all night thinking of ways to implement the
> encryption so that even a person with time to decipher the method
> would not be able to use it in subsequent captures.


Two rubrics that have saved me much time, effort, and unrest:

1. Unless you have a specific reason why another protocol is truly
   necessary, use HTTP.

   Tooling, documentation, simplicity, extensibility - it's all there,
   ready to use, right now.


2. Never roll your own security.

   Consider all the hours spent developing, testing, refining,
   reporting, revising, packaging, documenting.  No single human
   will ever replicate even a corner of that in an entire lifetime.
   And there's no need, since most of the best security options are
   Free and open.


--
 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: Go to card has become slow

[Richard Gaskin via use-livecode]

Bob Sneidar wrote:

> In review, I tested saving stacks on a standalone Windows Workstation,
> a VMWARE VM on a very robust server host, a Parallels VM on a
> workstation and my Mac. As I am saving the stack, I am watching the
> folder the stack is in. I see the tilde version pop up and go away. On
> Mac it’s almost instantaneous. On Windows it can be 3 to 4 seconds.

My messages don't seem to be getting through, because each time this 
observation method of measuring write throughput comes up I post the 
same reply, yet it keeps coming up.  Please confirm if you can see this:



Your application writing data to disk is a very different thing from 
Windows Desktop Explorer automatically refreshing a directory view.


Any GUI file manager on any OS will use some form of timer/polling for 
the refresh, and the refresh rate for macOS' Finder is much shorter than 
the one in Windows Desktop Explorer.


Observing those GUI file managers only tells us the refresh rate of that 
GUI, not the write speed for the app saving a file.


To measure write speed from LC it would be better to measure within LC 
itself, e.g.:


on mouseUp
  put the long seconds into t
  write "somedata" to url ("file:whatever")
  if the result is not empty then
 answer "Couldn't write file (" &sysError()&")"
 exit to top
  end if
  put the long seconds - t
end mouseUp


When run on similarly-configured iron, is there a significant difference 
between macOS and Windows?


When I isolate write speeds in this manner, I don't see a difference 
larger than could be explained by differences in hardware.


But given the frequent notes about perceived differences, it would be 
great if we could pin down the source of those disparities with some 
sort of test isolating the cause.


--
 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: Mobile Wondering

[Richard Gaskin via use-livecode]

Alex Tweedly wrote:

> On 06/04/2020 03:55, scott--- via use-livecode wrote:
>>> 1. xTalk features just don't work, or work totally inadequately
>>> (e.g. scrolling fields).
>> I feel this is overly harsh. Livecode fields (and the creation of
>> native UIText fields) do work on mobile. I think the issue is that
>> the use of some objects (like fields) on mobile is not as drag ’n'
>> drop simple as it is on desktop. No argument there.
>
> Yes, it was harsh - but sometimes a little bit of hyperbole helps, if
> only the mood of the speaker :-)

And for purposes of new-user advocacy.  Which could (and arguably 
should) be read as "conversion rates", or more directly, "making money".


Mobile fields are a subset of the excellent LiveCode-native field.

If things were the other way around that would pose a problem.  But as 
they are, the LC field object is so flippin' awesome it certainly 
doesn't hurt us at all to simply use a subset of its rich features for 
mobile development.


Of course mobile editing UI is not directly supported in the LC field 
object. It does a wonderful job on the desktop, and it would be 
super-awesome to see the object extended to support the other 55% of 
where users spend time.  But at least we have the option to script our 
way to an OS-native mobile field.


But why would we do that?  This is an xTalk.  The benefit of The xTalk 
Way is at the heart of all GUIs, direct manipulation of objects.  It may 
seem perfectly reasonable to a C++ programmer to type out every little 
thing, but it doesn't reflect the charm, allure, and productivity 
advantage of The xTalk Way.


Thankfully, LC is also super-flexible, so it's not all that hard to 
write a library that on preOpenCard looks for all editable fields, hides 
them, and creates matching OS-native fields over them.


Extra bonus points for re-routing messages for OS-native mobile fields 
to traditional LC fields - even dispatching them directly to the field 
object the library used as the basis for the mobile field.



This does two things:

1. We type less.

   LC is a GUI app development tool, the world's most powerful
   example of The xTalk Way.  We type only when we need to.
   And we don't need to type out definitions for something as
   basic as a field.


2. We test on-device less.

  The joy of The xTalk Way is that we code and run and
  code and run interchangeably, interleaved, in a seamless
  continuum of creative flow. "We don't need no stinking
  compile-runtime cycle."

  Sure, when you want to test OS-specific features, you need
  to test on the specific OS.  If you want to see how your
  AppleScript works, you test on your Mac.  If you want to
  check your registry settings, you test on Windows.  If you
  want to see how incomplete the player object is, you test
  on Linux. Same with mobile - test your OS-specific features
  where they exclusively live.

  But think about how much of a drag LC would be if every time
  you changed one line of code you had to stop everything you're
  doing, walk through a number of steps to move the app out of
  where you can already see it right in front of you, to go
  look at the same controls on a different screen.

  So just don't do that.

  Design the workflow to reflect the joyful productivity
  which is the reason you're reading this now, the reason we
  choose LiveCode.  Code and run seamlessly interleaved right
  where you are as much as possible.

  When we maximize use of LC-native controls, and automate
  instantiation of mobile-native controls based on those
  LC-native controls, we get to spend more time where time
  is best spent, right in the IDE.

  Data entry, navigation, server connectivity, graphics
  manipulation, and many other things apps do are equally
  available on desktop and mobile OSes.

  So if you set up a workflow that requires on-device testing
  of things that can be tested in the IDE, you're choosing to
  slow down development and reduce the joy of coding.


LiveCode is a wonderful environment, a rich thriving forest of 
development treats.  Let's spend as much time in that lush world as we 
can, minimizing the sometimes-necessary ventures into the desert of a 
handheld device foraging desperately for scraps of debugging info.


Let's live well.  Let's live The xTalk Way.


This discussion on editable fields is just one way to streamline LC into 
a joyful experience.  Other controls can be similarly mapped, and even 
moving the stack to the device for testing can be radically streamlined. 
And the IDE itself is ripe for refinement of some of its GUI elements to 
provide better guidance with a simpler appearance.


We can explore all of that after we resolve the question that gave rise 
to this thread:


What is the simplest way Jacque can accomplish the most basic task of 
gracefully displaying a block of scrolling text?


Money-making hint: if it requires creating a separate container object 
just to handle a deficiency in field buffering, that wou

Re: Problems locating Android SDK

[Richard Gaskin via use-livecode]

Colin Holgate wrote:

> On Apr 6, 2020, at 10:14 AM, Richard Gaskin wrote:
>>
>> I'm setting up a new machine for Android development.
>>
>> Where is the one-page list of steps on the livecode.com site that
>> reliably guides a new user through this for all supported platforms
>> (Mac, Win, Linux)?
>>
>> This one fails:
>> http://lessons.livecode.com/m/2571/l/625198-livecode-and-android-studio
>
> That link does work, and helps to solve the problem. The current
> Android Studio comes with Android 10 installed, and LiveCode needs
> Android 9.

The link itself works, in that it goes to a page. :)

But I have followed its instructions to install Android 9, and pointed 
my LC prefs to the folder shown in the screen shot, and LC reports:


  The chosen folder is not a valid Android SDK. Please
  ensure that you have installed it correctly, and enabled
  support for 9.0 (API 28)


When I run Android Studio it all seems to work.  But LC says it doesn't.

What did I miss?

--
 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: Go to card has become slow

[Richard Gaskin via use-livecode]

Bob Sneidar wrote:

> On Apr 6, 2020, at 9:28 AM, Richard Gaskin wrote:
>
>> Your application writing data to disk is a very different thing from
>> Windows Desktop Explorer automatically refreshing a directory view.
>
> Control doesn’t return to the application until the tilde version goes
> away.

True, but LC is done with that tilde file and deletes it LONG before the 
separate process of the Windows File Explorer polls and redraws the 
graphical illustration of the deletion that has already happened.



> On Apr 6, 2020, at 9:28 AM, Richard Gaskin wrote:
>
>> on mouseUp
>>  put the long seconds into t
>>  write "somedata" to url ("file:whatever")
>>  if the result is not empty then
>> answer "Couldn't write file (" &sysError()&")"
>>exit to top
>>  end if
>>  put the long seconds - t
>> end mouseUp
>
> You are testing low level file operations. I am testing the saving of
> a Livecode stack. I don’t think this test applies.

Comforting to know that there is no perceived difference in generic file 
writes between Mac and Win, and that we can focus exclusively on the 
small handful of additional steps LC takes when saving a stack file.


This is my understanding of the steps LC takes to save a stack file 
(hopefully Mark Waddingham will chime in if any of this is incorrect or 
incomplete), where "*" denotes steps unique to stack files not taken 
with other files:


* 1. Serialize stack data
* 2. If file exists, rename it with tilde
  3. Open the file
  4. Write the data to disk
  5. Close the file
* 6. Delete the tilde'd file


This test will measure that:

on mouseUp
  put the long seconds into t
  save this stack
  put the long seconds - t
end mouseUp


If the stack contains little data, as with other benchmarking you may 
need to put the task in a loop in between the timing statements to have 
a duration long enough to be meaningfully measurable, e.g.:


on mouseUp
  put the long seconds into t
  repeat 100
 save this stack
  end repeat
  put the long seconds - t
end mouseUp

Run that on similar Mac and Win iron and let us know how it goes.

--
 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 locating Android SDK

[Richard Gaskin via use-livecode]

Colin Holgate wrote:

> You may have read the path where tools are as being where you need to
> point LiveCode to. Point LiveCode to ~/Library/Android/SDK, and not
>  ~/Library/Android/SDK/Tools

Thank you, Colin.  ~/Android/SDK/ is where I pointed it (Ubuntu 18.04).

--
 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 locating Android SDK

[Richard Gaskin via use-livecode]

Skip Kimpel wrote:

> Richard,
>
> It took me two attempts at the Android Studio install.  I realized
> during the first attempt that I had cut it short before it had
> finished everything.  After re-installing, it worked just fine.

Thank you, Skip (and good to see you back on this list, BTW).

Well, turning it off and then turning it back on again is the universal 
IT fix, so I'll do a resinstall and see how it goes.


--
 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: Mobile Wondering

[Richard Gaskin via use-livecode]

When a desktop theme manager isn't available, LC reverts to its built-in 
emulated Motif, hence the odd appearance (which is awesome if you love 
NeXT, and horribly confusing to literally every newcomer if they're not 
ancient enough to remember the old Unix UI and know the intricacies of 
MetaCard's history, or even what MetaCard was).


For mobile, LC suggests hand-scripting a overlay object to handle the 
user interation and graphical feedback for scrollable controls like 
fields and groups.


In practice, most devs I know don't type those manually, but have 
written their own routines that automatically instantiate mobile 
scrollers by examining controls on preOpenCard and setting up the 
scrollers as needed.


I do not know why this is impossible for the engine to do, but it's easy 
enough to work around in a script.


--
 Richard Gaskin
 Fourth World Systems




Mobile Wondering 
Neville Smythe neville.smythe at optusnet.com.au
Mon Apr 6 13:50:27 EDT 2020

Previous message (by thread): Mobile Wondering 
Next message (by thread): [ANN] This Week in LiveCode 220
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

I had been wondering when the third-class status of mobile platforms in the LC 
world, particularly in relation to scrolling fields and groups, would crop up 
here.

Some time ago I looked at converting an iOS project to LC, and was appalled at 
the crude 1984-style appearance of scroll bars. I presume they look that way to 
inhibit their use, since the scrolling idiom on mobile platforms iOS is quite 
different from the desktop. But I reckon the native-scroller thingy which you 
had to use in its place seemed an awful hack:  its appearance in a different 
layer meant other objects got overwritten in a completely unacceptable way (has 
that changed?); and the separation of the testing regime from the IDE turned 
back the clock on the development process, again to 1984 when you developed on 
the Lisa, tested on the Mac. (Yes, I was there!)

So I developed a custom scrollbar which worked on both desktop and iOS. It is 
doable, with a modicum of fiddly stuff.
You need

1. An installer stack or widget. When you drag a scrollbar template onto a field (or group), it registers the field id with the scrollbar, snaps the scrollbar to fit the field dimensions with the desired vertical or horizontal orientation, and adjusts the thumb to match the field content. It also installs a backscript and frontscript in the stack.  

2. The front script captures mouse events/ drag touch gestures intended for the field, filters for scrolling events and diverts those to the appropriate custom scrollbar.  For 2-dimensional scrolling I used two separate scrollbars which needed some cross-mediation of gesture directions; a combined double-scrollbar would have been better. 


3. The backscript catches changes to the field affecting content, position or 
dimensions which need to be reflected in the scrollbars.

I had it working pretty well, to the point of a mostly complete examples / 
installer stack . You can customise all sorts of things, such as the appearance 
of the thumb and scrollbar background, whether the thumb length should reflect 
field content proportionally or not, visible-on-demand or as-needed or hidden 
thumb, the number of thumb positions - for example you could have a stepper 
with just 5 positions and a custom image as thumb - and even have left side or 
top mounted scrollbars. You could even have a desktop look and feel if you 
wanted, and why not if Apple can flout their own UI guidelines?

The  iOS project lapsed, running the maze of Apple distribution requirements 
became discouraging and I lost interest. But it can be done.

Neville

Previous message (by thread): Mobile Wondering 
Next message (by thread): [ANN] This Week in LiveCode 220
Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

More information about the use-livecode mailing list


___
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: Socket Help

[Richard Gaskin via use-livecode]

Bob Sneidar wrote:

> I was a big believer that SSL was never going to be compromised… until
> it was. The retooling of industry security standards over the last 6
> years or so has taught me the opposite: NEVER rely on out of the box
> security if you can help it.

After acknowledging how bugs can creep into even widely-used and 
critical code, do you really want to try to outdo hundreds of security 
specialists single-handedly?


Heartbleed is an excellent case in point, as the maintainer was a single 
person, and though the code was open everyone using it just took it for 
granted. The amazing thing is that nothing worse happened - that one 
fella was pretty good, just one single error added during an uncommonly 
hectic day. After that there are now two assigned maintainers, and an 
large number of code reviews with every build from staff in orgs 
dependent on it.


I hold no security certifications. But I pass along the rubric of "never 
write your own security" from literally everyone I know who does.


Your code, your call, of course.


> Asking a web server to get data and return it introduces a lag time
> which I am already struggling with.

What is the lag time of an already-resident Apache process (or Lighttpd, 
or NGinX) in compiled object code optimized for that one task by 
specialists, vs a scripted implementation in LiveCode?


Might be worth measuring before replicating.


> And if I DID use a web server, I would still have to go through
> extraordinary measures to secure THAT!

What steps are needed to secure a standard web server that are not 
needed for equivalent security in a custom server?



I'm not arguing here.  Heck, I sometimes even write my own database 
engines, so I'm certainly not trying to talk you out of having a good 
time scripting.  But the older I get the more I like to have my fun 
where the fun happens, in the business logic of the system I'm 
delivering, rather than reinventing generic infrastructure.


--
 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: Who else doesn't want auto-select when opening a card?

[Richard Gaskin via use-livecode]

J. Landman Gay wrote:

> I want a property or setting that lets me turn off this default
> behavior. It's annoying and disruptive, and has been there since
> day one.

I lost count of how many times I've seen that come up in the forums over 
the years.


What you propose seems reasonable and useful.  And because it involves 
NOT doing something, it would seem relatively easy to implement.


Anyone here up for the task of implementing 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: Socket Help

[Richard Gaskin via use-livecode]

Thanks for the example, Bob.  Yes, it does seem very conclusive.

Do you know if there's an existing bug report for this?

I've seen a few other Win-specific reports, but the ones I recall were 
mostly about file I/O, and I don't recall one for network I/O.


--
 Richard Gaskin
 Fourth World Systems


Bob Sneidar wrote:

> Hi Richard.
>
> Just to be absolutely certain I excluded any other factors, I tested
> retrieving data from mySQL from a Mac and from a PC using only the
> Message Box (no UI).
>
> Since I am out of the office, I can only test my Mac remotely. I can
> however remote into the mySQL server at work which is running LC. Both
> are v9.5.1 Community.
>
> With the Mac I am getting as low as 295 milliseconds to query my
> entire database of customers and retrieve it as an array. On the
> actual server where the mySQL database resides, I am getting over 1000
> milliseconds.
>
> Querying for only 1 record from the same database, I’m getting 123 and
> 865 respectively. To ensure I wasn’t encountering DNS lag I set the
> server host to localhost. I cannot get much more local than that.
>
> Even with the added latency of the Internet from the Mac, and the
> advantage of the PC being the very computer the SQL server is on, I am
> getting a difference of roughly 7 times slower. No UI updating is
> involved. It’s a straight up message box script:
>
> put the milliseconds into tStart
> put sqlquery_createObject("customers") into qObject
> sqlquery_set qObject, "limit", 1
> put dbQuery(qObject, "array") into aData
> put the milliseconds into tEnd
> put tEnd - tStart
>
> I think this is pretty conclusive. Either Windows networking is for
> whatever reason, considerably slower, at least for this kind of
> operation, than Mac, or else the Windows LC engine is the bottleneck.


___
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: Devolution bug

[Richard Gaskin via use-livecode]

Andre Garzia wrote:

> I just reinstalled LC and Devolution here but every time I try opening
> any of the panes, it does an audible chime. Trying to click any of the
> tabs in the first pane (the one with about, check for updates, etc)
> just sounds the chime and doesn't change anything. It feels like there
> is a modal somewhere offscreen and I can't click it.

I've seen reports in the forums about dialogs opening behind palettes in 
recent versions of LC, unrelated to devolution.


Devo rarely does anything modal, but if perhaps you clicked something 
that opens a file picker, if you're seeing the same LC bug others have 
seen in other contexts, it may be the getfile dialog is opening behind 
the pane.


Just a hunch.  Haven't seen this yet, but if you can tell which OS 
you're on I'll see if it's possible to reproduce it 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: Go to card has become slow

[Richard Gaskin via use-livecode]

Neville Smythe wrote:
> Richard wrote
>> Bob Sneidar wrote:
>>
>>> In review, I tested saving stacks on a standalone Windows
>>> Workstation, a VMWARE VM on a very robust server host, a
>>> Parallels VM on a workstation and my Mac. As I am saving
>>> the stack, I am watching the folder the stack is in. I see
>>> the tilde version pop up and go away. On Mac it?s almost
>>> instantaneous. On Windows it can be 3 to 4 seconds.
>>
>> My messages don't seem to be getting through, because each time this
>> observation method of measuring write throughput comes up I post the
>> same reply, yet it keeps coming up.  Please confirm if you can see
>> this:
>
> Yes we see this. But as you know in 2018 I reported this slow saving
> of stacks under Windows10, using LC timing of just the save handler
> rather than the visual perception of the screen update, and it has
> been confirmed as a bug.  bug 21305  /show_bug.cgi?id=21305> The time to save is extreme for large stacks.
> It took some time for QualityControl to confirm, because apparently
> it doesn’t seem happen on every Windows 10 installation - just every
> one  that I or my users have tried. It has not been fixed since 2018.

Thank you for the link to that report, Nevile.  While I have been a 
subscriber to it I also follow many reports, so your link is very helpful.


I was eager to run the test stack there, but discovered there isn't one. 
 I don't mind creating one, but it would be helpful to know what's 
required.


Have you seen any difference between a stack with little content but a 
large number of objects vs one with a small number of objects but a lot 
of text or images?


Once I can reproduce the test, I'll modify it to isolate the time 
devoted to stack files separately from other file I/O for 
equivalently-sized files.


--
 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: Go to card has become slow

[Richard Gaskin via use-livecode]

Great test set, Neville. Thanks for posting that link.

The hardware on my Linux and Win boxes is so different I don't have a 
strong opinion there. But I did modify your main test script to see what 
I might learn from isolating the file I/O from the stack serialization:


on mouseUp
  put word 2 of the long name of stack "data" into fName
  replace quote with "" in fName
  if the shiftKey is "up" then
put the long seconds into t0
save stack "data"
put the long seconds - t0 into t1
put "saving data took " && t1 && "seconds" into fld "timeInfo"
put 0.01*(the length of URL ("file:" & fName)) && "MB" into fld 
"lengthInfo"

  else
put url ("binfile:"&fName) into tData
put the long seconds into t
put tData into url ("binfile:"& fName)
put the long seconds - t
  end if
end mouseUp

So I ran your tool, making a stack with 300 cards, which produces a file 
a bit over 8MB.  These are my times:


Ubuntu 18.04 w/SSD
Stack: 0.097182
File:  0.008475

Windows 10 w/HDD
Stack: 8.183708
File:  0.014

Even with the differences in the hardware, it looks like the bottleneck 
is in the stack serialization, and the file I/O seems good.


Anyone here in a position to run Neville's test with this modification 
on similarly-configured systems but different OSes?


--
 Richard Gaskin
 Fourth World Systems


Neville Smythe wrote:


Richard

Here is a link to the test stack for testing the speed of save stack

https://www.dropbox.com/sh/cb2r9jbohxqv6bp/AAAQ1weLLlzrKYQ21yn1apf9a?dl=0

I don’t know why the test stacks I supplied disappeared from the QC bug report.

You need the SlowSave.livecode and the data.livecode stacks. They are both 
small, but SlowSave creates a large stack with 300 cards and the lorem ipsum 
text data to build an 8 MB stack, and displays the timing for saving. On my 
MacBook Air it takes 0.13 seconds to save; on Windows 10 installations I have 
seen times from 3 seconds to 10 seconds.

In this test, the stack has just 300 cards, 1 field on each, and lots of ascii 
text (so there should be no problems converting to utf-8 before saving in the 
unlikely event that is happening, and in any case would happen on all 
platforms). I haven’t tested stacks with large numbers of controls or large 
images rather than large text data.

Other apps on Windows 10 certainly don’t display this behaviour, which  
indicates it is a LC problem not a Windows problem. Antivirus software and 
Defender were off during the test. I was under the impression that saving files 
from LC, rather than stacks, was not slower than normal, but Bob’s recently 
experience with saving data to a database may contradict that.

Some people have had trouble verifying my observations (other LC Forum users have confirmed). QC originally could not confirm the bug until they tried it “on an older PC”. However one of my users recently updated to a *very* fast HP box; it cut the save time down significantly but was still at least 20 times slower than on a typical Mac, ie almost usable. So maybe it has something to do with the Windows installation, though the ones I used were stock standard. I can’t see how fonts could be involved, for example. 


Neville



___
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: Go to card has become slow

[Richard Gaskin via use-livecode]

Ralph DiMola wrote:


LC 9.5.1
Win 10 Hyper-V VM with 8 processors assigned
Stack and data on smb served by VM host.
Host ==> i7 6700 3.40Ghz 16 Gig

saving data took  38.46 seconds
8.183708 MB



LC 9.5.1
MacBook Pro Early 2011 OSX 10.13.1 16 Gig
Stack and data on smb served by the aforementioned Win 10 VM host.

saving data took  0.400926 seconds
8.183708 MB


Thanks for testing that, Ralph.

If you use this script, what do you get with a second run with the Shift 
key down to measure only a straight write, separate from the "save 
stack" routine?:



on mouseUp
   put word 2 of the long name of stack "data" into fName
   replace quote with "" in fName
   if the shiftKey is "up" then
 put the long seconds into t0
 save stack "data"
 put the long seconds - t0 into t1
 put "saving data took " && t1 && "seconds" into fld "timeInfo"
 put 0.01*(the length of URL ("file:" & fName)) && "MB" into fld
"lengthInfo"
   else
 put url ("binfile:"&fName) into tData
 put the long seconds into t
 put tData into url ("binfile:"& fName)
 put the long seconds - t
   end if
end mouseUp



--
 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: Go to card has become slow

[Richard Gaskin via use-livecode]

Ralph DiMola wrote:

> 0.033 shift key down
> 28-30 seconds shift key up.

It's almost like the stack file takes longer, if only the difference 
were more clearly evident. :)


I'll include your results with the test data I'll add to the report. 
Thanks for running 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: Go to card has become slow

[Richard Gaskin via use-livecode]

Neville Smythe wrote:

> I have updated the SlowSave test stack with Richard's enhancement to
> also show the time to save the binary data (no need to use the shift
> button)
>
> https://www.dropbox.com/sh/cb2r9jbohxqv6bp/AAAQ1weLLlzrKYQ21yn1apf9a?dl=0
>
> Pleased to see everyone is seeing the problem at last, it doesn’t seem
> to be related to the particular Windows 10 installation. But 38
> seconds for 8 MB!!

Yes, the difference is quite pronounced.

Thank you for updating the stack.

Brian Milby's comment was most illuminating:

   Internally, each object is serialized and written to the
   file buffer in turn.  So the question then becomes how
   much of the difference is due to writing the file in
   pieces compared to the process of serializing the data.


I just did a search at DuckDuckGo for "difference in write speed windows 
vs mac programming":


https://stackoverflow.com/questions/48356177/c-program-runs-much-slower-on-windows-vs-linux-when-doing-file-operations


Among the first results was this discussion from stack overflow, where 
the problem is described as:


  When you execute a build operation with ChatScript, it scans
  all the script files that comprise your chat-bot. In my case,
  that's hundreds of files. This process takes nearly 30 times
  longer on Windows 8.1 than it does on Ubuntu 16.04. Therefore
  I do use Linux for much of my work, but there is a part of
  my work that I have to do on Windows because of certain
  associated tools, so I would like to modify the code base so
  that Windows ChatScript compiles are as fast as on Linux.

  Can anyone think of a reason the code would run so much slower
  on Windows vs. Linux? Are there some C++ file operation codes
  (read/write/etc.) that are known to be much slower on Windows
  compared to Linux due to variances in the C++ run-time libraries
  running on each platform?

Sounds kinda like us, no?

But it gets better.

The first reply suggests a few common things to speed up disk I/O, like 
defragging and double-checking compiler options, but then he kinda gives 
up and says, "But doing all those things for me has never got the 
Windows compile to be quicker than on linux using equivalent disk 
hardware, not once."


Better still, see the last comment on that page. :)

It kinda fits Brian's observation about how the stack file is written in 
a series of small writes, one per object.


--
 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: Go to card has become slow

[Richard Gaskin via use-livecode]

The speed difference with stack files seems to be that there's high 
overhead for each write on Windows 10, and stack files are written on a 
series of small writes.


Given this, which would make more sense?:

a) Serialize objects to one buffer in memory
   and flush to disk in one write
   (changes current behavior, but I can't think
of why anyone would mind)

b) Extend the "save file" command with a flag
   to tell the engine to flush in one write
   (keeps current default behavior, allowing
   the single-flush method as an option)

--
 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: Go to card has become slow

[Richard Gaskin via use-livecode]

Bob Sneidar wrote:

>> On Apr 8, 2020, at 11:16 PM, Richard Gaskin wrote:
>>
>> Better still, see the last comment on that page. :)
>>
>> It kinda fits Brian's observation about how the stack file is
>> written in a series of small writes, one per object.
>
> Yes, but I have saved stacks with both Defender and Kaspersky
> disabled. In our case I do not think that is the entire issue.

Probably not exclusively. But to assess the contributory effect, what 
are your measurements using Neville's test with and without those AV 
packages active?


--
 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: [OT] Banks, Governments looking for COBOL programmers

[Richard Gaskin via use-livecode]

Martin Koob wrote:
...
> Just an OT comment with a tangential link to LiveCode.
...
> "People who are conversant in terse languages, like C, do not like
> COBOL because it's very wordy. You say things out in plain English
> sentences and before you even get down to doing anything you have
> to describe all of your data in a very elaborate structure," says
> retired COBOL programmer, Jay Moseley.

I have no opinion on COBOL, but when we see complains of "verbosity" 
with LiveCode it makes me laugh:


The view stems from a focus on individual statements, somehow never 
noticing that there are dramatically fewer statements overall.


Moral: Measure chars-per-task, not chars-per-statement.

--
 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: Mobile screen sizes - another naive question

[Richard Gaskin via use-livecode]

Graham Samuel wrote:

> Folks, yet again I don’t know where to look for an answer in the LC
> documentation.
>
> The issue is the enormous variety of screen sizes on smart phones. For
> example the iPhone XS Max has 1242 pixels width, the iPhone 5 has 640.
> And there are many many more before we even get to tablets…
>
> The question is, how do most of you tackle this, and does LC help?
> Obviously an object taking up a fixed number of pixels on one phone
> will look absurdly large or small on another one, or of course may not
> fit on the screen at all. Not all objects can be vector drawings, and
> the ones that are still have to be resized according to device
>
> Is there anything better than the obvious trick of resizing everything
> in sight when the app is being initialised, including substituting the
> more sensitive graphics from a library of appropriate sizes? Seems
> tedious.

Is it all that tedious?

Computers have had resizable windows since Mac 1.0, and even HyperCard 
stacks could be resize after its first version.


True, in the very olden days we all enjoyed the simplicity of knowing we 
never had to accommodate any screen size other than 512x342.  Ah, those 
were the days! :)


But 640x480 came along not long after, and it caused much concern among 
developers. Suddenly we had to become aware of screen metrics, and 
rearrange our layouts to make good use of the available space.


Then 1024x768 came along, and then we had THREE(!) screen sizes to 
contend with. Oh the humanity! :)


Then by the early 90s we got over it.  Anticipating multiple screen 
sizes became the norm, new tools like SuperCard, OMO, and MetaCard came 
along offering true resizable windows, and we learned to respond to 
notification that the window had resized so we can adjust our interior 
contents nicely.


Flash forward to 2010: iPhone comes out, with the presumption that one 
size will satisfy all tastes.  That didn't last long.  History doesn't 
always repeat itself, but it often rhymes. :)




As with desktop software, I find it instructive to observe how the best 
apps on mobile behave, and then - because those establish user 
expectations - do what they do.


And what we see is not all that different from how designers handle 
resizable windows on the desktop: some objects stay where they are, 
those that make sense to enlarge enlarge, those that make sense to 
remain adjacent to something next to them remain adjacent to something 
next to them, etc.


If you've written resizeStack handlers at any point in the last 28 years 
since MC premiered, you've already learned most of what you need to know 
to handle a resizeStack message on a mobile device.


The specifics of how this plays out in your layout will of course depend 
entirely on your layout.  But I have found a few things that have 
greatly simplified my UI work, chiefly:


- Use Groups Smartly

Relatively recently (a few years ago) the engine now sends a 
resizeControl message to groups whenever they're resized by any means, 
either user interaction with the pointer tool (as had always been the 
case) or via script (the new addition).


This allows us to work with our UIs very cleanly, recognizing that an 
app is ultimately a set of rows, and that some rows are divided into 
blocks.  When we group controls by their location/purpose logically, we 
get to take advantage of a wonderfully simplifying cascading effect with 
regard to resizing, which allows us to keep control adjustments local to 
their containing group.


Imagine a simple message form, where the rows are:

- Icons for navigating to different screens

- Message, which includes three rows:
  - Subject field
  - Body field
  - Send button

With that, our card script need only bother itself with the general 
placement of the two main goups:


on resizeStack x,y
   set the rect of grp "Nav" to 0,0,x,40
   set the rect of grp "Message" to 0,40,x,y
end resizeStack

And because the groups will get a resizeControl message when that card 
script adjust them, each can contain its own handler to take care of its 
interior contents.  This might be the script for the Message group:


on resizeControl
   set the rect of fld "Subject" to the left of me, the top of me, \
 the right of me, the top of me + 40
   set the rect of fld "Body" to the left of me, 40, the right of me, \
 the bottom of me - 60
   set the bottomRight of btn "Send" to x-20, y-10
end resizeControl


Encapsulating resizing within the group not only keeps the logic simple 
and tidy, but by using the group bounds as its basis rather than the 
card (e.g., "the left of me") the group is maintainable and even 
portable - the card script that sets its rect can change at any time, 
and the group's resizeControl handler will continue to work well.



There are probably other tips and tricks worth considering, but none 
have radically streamlined the process of delivering the UI I want my 
user to enjoy as much as using groups as containe

Re: Another Apple iOS Deadline

[Richard Gaskin via use-livecode]

Ralph DiMola wrote:

From App developer email I just received:
>
> Please note that all apps that authenticate or set up user accounts
> must support Sign in with Apple if required by guideline 4.8 of the
> App Store Review Guidelines. New apps must follow guideline 4.8 and
> Human Interface Guidelines on Sign in with Apple starting April 30,
> 2020. App updates must follow these guidelines starting June 30, 2020.
>
> Can we do this?

Or would we want to?

I'm hoping I misunderstand that, because it sounds like the most onerous 
and invasive thing I've ever read from that powerful controlling entity, 
far worse than even their demand a few years ago to control the file 
format of every Mac app's prefs settings.


Do you have a link where we can learn more?

--
 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: Another Apple iOS Deadline

[Richard Gaskin via use-livecode]

Matthias Rebbe wrote:
> So let us keep our fingers crossed that Apple does not change the
> exceptions.

The debacle around iOS SDK v4.0 Section 3.3.1 in 2010 reminds us to 
remain wary of such things at all times...


--
 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: Video format for mobile

[Richard Gaskin via use-livecode]

Tom Glod wrote:
> There is cisco's openh264 codec which they open sourced.  So that is a
> potential solution that would have to include the livecode team.
>
> https://github.com/cisco/openh264

Super-cool, Tom. Thanks for posting that.

It's an impressive work, both technically for its breadth of support and 
with its license, the permissive MIT-like BSD 2-Clause "Simplified" License.


Curious about how they were able to pull that off without triggering the 
patent wrath of the MPEG-LA consortium, it seems Cisco wrote a large 
check and is absorbing the cost internally, not passing that cost on to 
users of the component:

https://blog.mozilla.org/blog/2013/10/30/video-interoperability-on-the-web-gets-a-boost-from-ciscos-h-264-codec/

This is how we can watch Netflix in Firefox, and many other things with 
proprietary and DRM content.


Thanks, Cisco!

--
 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: Go to card has become slow

[Richard Gaskin via use-livecode]

Earlier I wrote:
> Bob Sneidar wrote:
>
>  >> On Apr 8, 2020, at 11:16 PM, Richard Gaskin wrote:
>  >>
>  >> Better still, see the last comment on that page. :)
>  >>
>  >> It kinda fits Brian's observation about how the stack file is
>  >> written in a series of small writes, one per object.
>  >
>  > Yes, but I have saved stacks with both Defender and Kaspersky
>  > disabled. In our case I do not think that is the entire issue.
>
> Probably not exclusively. But to assess the contributory effect, what
> are your measurements using Neville's test with and without those AV
> packages active?

It may not be worth the trouble.

When I run Neville's stack saving test here with Windows Defender's RTP 
on the 8MB stack save takes a little over 8 seconds.


And when I turn RTP off it takes a bit over 7 seconds.

So while RTP is a clear conributor, it doesn't account for most of the 
speed loss on stack saves.



@Brian Milby: When you were looking up the stack serialization in the 
code, did you see anything which might explain why this slowdown is only 
evident on Windows but not Mac or Linux?


--
 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: Mobile screen sizes - another naive question

[Richard Gaskin via use-livecode]

Brian Milby wrote:

> I also built a stack last year to show how much space is not used when
> using different modes.  I'll see if I can locate that and make it
> available.

Useful I'm sure, but this lesson about using fullScreenMode as an option 
for handling different screen sizes includes illustrations showing the 
various crop/pad/stretch/distort effects available with each of the modes:


http://lessons.livecode.com/m/15262/l/565745-how-do-i-make-my-app-scale-to-fit-the-screen-on-all-devices


--
 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: Go to card has become slow

[Richard Gaskin via use-livecode]

Brian Milby wrote:

> I'm going to be that guy who replies to himself...
>
> I just imported a 500kb image to the card, removed the text from the
> field, created 300 cards. 0.756 seconds normal (171MB).  1.124 from a
> variable. (image instead of text) 8.311 seconds normal (8.2MB).  0.047
> from a variable.  (original text)
>
> I'll need to clean this up with a better image (something I can share)
> and try on my Mac for comparison when I get off today, but this points
> squarely at the serialization of the field object being the
> difference.

Thanks for exploring this, Brian.  It's mystifying how such generalized 
code could have such a pronounced impact on only one platform, but with 
your assistance I'm more confident we'll find 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: Mobile screen sizes - another naive question

[Richard Gaskin via use-livecode]

Graham Samuel wrote:
> Thanks Richard, for that typically useful reply! I have indeed written
> many a resize handler, but getting back into this stuff I was struck
> by how messy it can get. Right now I don’t even know if say a field
> with 12 point type in it has to be changed to a smaller or larger
> rectangle with smaller or larger type in it, but obviously as soon as
> I can start doing simulations (I have a totally different problem
> there!) I can experiment.

If it seems messy you may just be thinking about it too hard. :)

Geometry not longer differs as much between the IDE and the device as it 
used to.


In the first versions of LC's mobile offering, we didn't have resolution 
independence. Heck, in the fist versions we didn't even have a 
pixelDensity function.  Back then, fullScreenMode was offered as a 
quicky workaround because while it rarely produces apps that look 
exactly like the ones we most commonly use, it was easy to implement and 
easy to use.  The alternative involved a lot of guesswork and tedious 
arithmetic to try to figure out the difference between logical and 
physical pixels.  Ugh.


Today, LC only uses logical pixels, and it automatically translates 
those to whatever physical pixels a given phone may be using.


Want to place a button 20 pixels from the bottom-right of the screen? 
Just use the syntax you've been using for years:


on resizeStack x,y
set the bottomRight of btn 1 to x-20, y-20
end resizeStack

One nice thing about this approach is that you spend a LOT less time 
needing to move the stack to the device just to see what it'll look 
like.  Just resize the stack in the IDE and look at it. :)



> I do like the idea of sending resizeControl to groups - I have used
> similar techniques for other purposes in the past. Powerful and
> encapsulated.

It's one of the most useful enhancements added to LiveCode, making so 
much about delivering pixel-perfect UIs on every platform so much easier.



> As to graphics, I can presumably start with the highest possible
> resolution and resize at startup according to the actual screen size,
> or do what I said before, have a little library of different versions
> tweaked for different screen sizes. Or possibly use SVG...

No matter which method you use for your layout, LC includes options for 
including referenced images of different resolutions.  IIRC the manual 
covers that pretty well.


But if you can use SVG for the images you want you'll never need to 
think about multiple copies at all, and will always have a rendering 
optimized for the device you're running on.



> Well, I am trying to learn, and I am grateful for all that you’ve
> said.

They key to that long post is this line:

  As with desktop software, I find it instructive to observe how the
  best apps on mobile behave, and then - because those establish user
  expectations - do what they do.

I haven't seen your app so I can't say with complete confidence whether 
explicit placement via resizeStack or automated approximation with 
fullScreenMode is the best fit for your particular needs.


Consider what your app needs to do, and study the apps on your phone 
that best reflect your design goals.  Rotate the device, run the apps on 
your phone and your tablet, observe how the apps adapt their layouts to 
make the best use of each screen size.


As we've been doing on the desktop all these years, we can often get 
results every bit as good as apps made with anything else, and usually 
more easily.


--
 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: Mobile screen sizes - another naive question

[Richard Gaskin via use-livecode]

Good catch. It would be great if the Lessons were in Github so they 
could be enhanced by the community. I guess for now a comment there is 
the only mechanism for filing enhancement requests.


How does showAll differ from the options shown there?

--
 Richard Gaskin
 Fourth World Systems


J. Landman Gay wrote:

I hadn't seen that lesson before. They didn't include showAll though.

--
Jacqueline Landman Gay | jacque at hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On April 10, 2020 12:11:40 PM Richard Gaskin via use-livecode 
 wrote:



Brian Milby wrote:

> I also built a stack last year to show how much space is not used when
> using different modes.  I'll see if I can locate that and make it
> available.

Useful I'm sure, but this lesson about using fullScreenMode as an option
for handling different screen sizes includes illustrations showing the
various crop/pad/stretch/distort effects available with each of the modes:

http://lessons.livecode.com/m/15262/l/565745-how-do-i-make-my-app-scale-to-fit-the-screen-on-all-devices




___
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: Apps to fight COVID-19

[Richard Gaskin via use-livecode]

Mark Wieder wrote:
> Of course, a "standard" app will soon become compulsory for tracking
> and permission to be out on the street, as it did in China.
>
> 
https://twitter.com/ashk4n?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1248659874679902210


If compulsory, the first thing I'll do is throw my phone away.  The 
second thing I'll do is join the millions in the streets reminder our 
leadership that we don't do things here like they're done in China.

#BillOfRights

--
 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: Sample Stacks tab in IDE is not functional

[Richard Gaskin via use-livecode]

kee nethery wrote:

> Am unable to search and get results.
>
> 9.5.1 on MacOS Indy Edition Build 15505
>
> Have gone to web site and it too is unresponsive.
>
> In specific I’d like to get a stack that can read or parse a QR code.

Confirmed here in v9.6dp3.

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

[Richard Gaskin via use-livecode]

Graham Samuel wrote:

> Still, subject closed - I presume the mother ship has long ago decided
> not to enhance LC in this respect any time soon.

Not at all.  I noticed this thread got off on the tangent of codec 
specifics, but never addressed your core question:


LiveCode can play all of those and more.

Just not specifically using the old audioClip method.  That method was 
an early attempt to emulate HC's resource-fork-based SND clips, and 
never got past using the .au format which was popular way back in the 
day on the platform MetaCard was born on, Unix.


Since then audio and video support assumes richer formats of greater 
length than are practical with embedded media clips.


Play them as files and you should be fine.

(That is, unless you need to deploy to Linux, where the Player object 
started breaking a few years after the turn of the century and has 
gotten steadily worse since.)


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

[Richard Gaskin via use-livecode]

Graham Samuel wrote:

> Well, Richard, as usual you say something informative and useful!
>
> I didn’t know that LC could play a sound file in MP3 format.

LC's Player control uses the host OS's playback engine, so as long as 
the OS-supplied media player can handle a format, LC should be able to 
as well.



> Instinctively I thought that an audioclip was the way to go, because I
> saw it as a small chunk of data best embedded in my app. In my mind,
> the format of an external file trades flexibility (the user or the app
> can switch content easily) against a massive overhead of storage and
> software mechanics and potential delays due to loading etc, whereas
> the audioclip is small, clean, and can be started and stopped with no
> overheads.

True, reading the media file takes a bit more time than a clip already 
in RAM with the rest of the stack file.  But in many cases it's not 
noticeable.  And where it is noticeable it probably has less to do with 
the file I/O than the codec itself:  HC's SND resources had few 
compression options, and MC's audioclips were limited to .au format, 
which IIRC isn't compressed at all.


It might be nice to see LC expand the internal clips options to support 
the same range of formats/codecs the Player does. But even then it would 
be limited to smaller files where it's practical to load them all into 
RAM with the rest of the stack file, modestly useful for some projects 
but prohibitive with longer files.


As for user modification, the files can be in the Mac bundle, and on 
Windows usually an installer is required anyway so you can put them in 
any useful place the user is unlikely to stumble across them 
accidentally (this isn't a problem at all on Linix - the absence of a 
functional Player in that LC version simplifies many things ).


I miss the simplicity of delivering true stand-alone apps, but with so 
many of the most lauded features of LC 8-and-later having been 
implemented as externals, adding some media files to the mix doesn't 
affect deployment options much.


If there's a security or other concern requiring the files be protected 
from user manipulation, there are options for that.  Like any DRM, 
there's usually a tradeoff between strength and ease of implementation, 
but if it's needed we can explore 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

Keyhole effect?

[Richard Gaskin via use-livecode]

Back in the day I could easily make a sort of keyhole effect, in which I 
used one graphic to obscure an image, and a second graphic on top as a 
mask to define a shape (such as a keyhole) through which I could see a 
portion of the image.


It was done easily enough with inks.

Inks that, it seems, we no longer have.

So given the subset of inks we're now limited to, has anyone here seen 
firsthand an example of this in LC v9.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: Keyhole effect?

[Richard Gaskin via use-livecode]

Brian Milby wrote:

> On Tue, Apr 14, 2020 at 5:32 PM Richard Gaskin wrote:
>
>> Back in the day I could easily make a sort of keyhole effect, in
>> which I used one graphic to obscure an image, and a second graphic
>> on top as a mask to define a shape (such as a keyhole) through
>> which I could see a portion of the image.
>>
>> It was done easily enough with inks.
>>
>> Inks that, it seems, we no longer have.
>>
>> So given the subset of inks we're now limited to, has anyone here
>> seen firsthand an example of this in LC v9.x?
>
>
> We had a discussion in 2018 about using a hex shaped grc to split up
> an image (started by Richmond).  The key line there was:
>
> set the backPattern of grc "hex" to the ID of img "box"
>
> Since attachments and stacks were involved, I'm pretty sure it took
> place on the forums.  I'm not sure if this will accomplish what you're
> looking for though.  I can send a stack off list if you'd like to see
> it.

Thanks, but the solution I'm looking for has to use inks.

I'm open to other things, but the mask needs to be a circle so a polygon 
is out, and backpattern won't work because of a bug/unsupported use (see 
the fine print in the Dictionary about the specific dimension 
requirements for backPattern, which turned out to be a problem for us).


So inks it is.  If it's possible now that the good inks are gone.

--
 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: Keyhole effect?

[Richard Gaskin via use-livecode]

Monte Goulding wrote:

> If I understand what you want correctly then:
>
> Create image
> Create mask object
> Group both
> Set the ink of the mask object to blendDstIn
> Set the ink of the group to blendSrcOver

Super, Monte. That works well.

I was up late with a tool I'd made to let me walk through all sorts of 
combinations, but I hadn't thought to group them.


Thanks!

--
 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: Keyhole effect?

[Richard Gaskin via use-livecode]

Mark Waddingham wrote:
> On 2020-04-15 02:30, Richard Gaskin via use-livecode wrote:
>> Monte Goulding wrote:
>>
>>> If I understand what you want correctly then:
>>>
>>> Create image
>>> Create mask object
>>> Group both
>>> Set the ink of the mask object to blendDstIn
>>> Set the ink of the group to blendSrcOver
>>
>> Super, Monte. That works well.
>>
>> I was up late with a tool I'd made to let me walk through all sorts
>> of combinations, but I hadn't thought to group them.
>
> Oh look, clearly the 'useful' inks haven't really been removed -
> they've just been replaced with the modern equivalents which give
> much better fidelity results ;)


Whenever I fail to add, "...or seemingly so based on 22 years of 
experience in delivering applications with LiveCode, but of course 
notwithstanding the full scope of all possible things one might try 
given infinite time", please consider that implied. :)


I'm not the first person to have work stopped on a feature when the 
older inks were removed.


Monte's suggestion, and you your explanation, are very helpful.  I've 
passed them along to another developer I know who held up some of their 
own work when the method they'd been using was no longer available.


The new inks are indeed quite good, and the group trick is a very 
helpful key to unlocking how to use them well. Thank you.



> Just to explain why the group is necessary - if a group has the
> 'blendSrcOver' ink applied then it becomes a 'transparency group'.
>
> This means it has its own alpha channel which can be affected by the
> 'destination alpha modifying' porter-duff operations. So in this case:
>
>1) The group is a transparency group so allocates its own
> transparent buffer
>2) The image is composited into the buffer
>3) The mask is then composited into the buffer with the DstIn ink.
> This means that the destination buffer alpha is adjusted so it is only
> 'in' the mask (an analog of ANDing the buffers alpha channel with the
> mask's alpha channel - indeed, previously I'm guessing you would have
> done this using some sort of AND bitwise ink and being careful with
> colors used).
>4) The buffer is then composited with the background.
>
> The transparency group thing is needed partly for efficiency and
> partly because you can't remove alpha from an opaque destination
> - which a window provides.
>
> Hope this helps!
>
> Mark.

--
 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: Issues with Mobile Native controls

[Richard Gaskin via use-livecode]

Graham Samuel wrote:

> I’ve recently bought Mobile Native Essential pack...

Curious, I looked it up.

Who is "LiveCode Factory" (the vendor), and how is anything labeled 
"essential" not in the base install?  Is it essential or not?


--
 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: Which git service suits a LiveCoder best?

[Richard Gaskin via use-livecode]

doc hawk wrote:

> It’s no substitute for GitHub and the like, but I have a rather simple
> system that intercepts saveStackRequest, checks the date, and saves a
> new version with the date as part of the name.  I also have a bmpVrsn
> routine that can be used to advance a letter during the day, so things
> like 200422b for the second version of a stack from today.

That's 1/3 of why I keep my work folders synced with my local Nextcloud 
server.


(The other 2/3 is that all those versions are safely backed up, and kept 
up to date on all the machines I use for testing.)


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

J. Landman Gay wrote:

> So what I did was use a round-rect graphic as a button. Set the
> linesize to 1 and the round radius to 8. You can set the border color
> and the text color.

Using the graphic is a much better choice than a roundRect button, 
because the button uses an older non-antialiased corner.


If any of the C programmers here have a few minutes, we could enjoy all 
the benefits roundRect button with appearances as good as a roundRect 
graphic with what Monte describes as a fairly minor bit of work:


   This is possibly a good user contribution. It's just wrapping
   the drawroundrect call with `dc -> setquality(QUALITY_SMOOTH);
   ` & `dc -> setquality(QUALITY_DEFAULT);`

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

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

mouseColor randomly returning "0,0,0"

[Richard Gaskin via use-livecode]

For years I've relied on the mouseColor to pick up colors for my 
layouts, but lately I've found something weird:


Most of the time it works, but sometimes it return "0,0,0" over things I 
know aren't black.


For example, this morning it's returning that color of a large block of 
solid light green.


Has anyone else seen oddities with the mousecolor?


Current test environment: LC 9.6dp4, Ubuntu 18.04

--
 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: Mobile screen sizes - another naive question

[Richard Gaskin via use-livecode]

Graham (and Brahmanathaswami may enjoy this too):

I've been itching to write a tutorial on using specific object placement 
("Responsive Design", as the kids call it) to compliment the Lesson 
we've had for years on the other mobile layout option, FullScreenMode.


I had a few minutes over the weekend, and a discussion with a new 
developer prompted me to craft a simple example of how groups can be 
used to handle common design patterns with little code.


This may be fleshed out more fully in the future, but for now at least 
it's more than the zero tutorials we've had on it thus far:


https://forums.livecode.com/viewtopic.php?f=53&t=33989&start=15#p190927

--
 Richard Gaskin
 Fourth World Systems



-- original post from 9 April -

Graham Samuel wrote:

> Folks, yet again I don’t know where to look for an answer in the LC
> documentation.
>
> The issue is the enormous variety of screen sizes on smart phones.
> For example the iPhone XS Max has 1242 pixels width, the iPhone 5 has
> 640. And there are many many more before we even get to tablets…
>
> The question is, how do most of you tackle this, and does LC help?
> Obviously an object taking up a fixed number of pixels on one phone
> will look absurdly large or small on another one, or of course may not
> fit on the screen at all. Not all objects can be vector drawings, and
> the ones that are still have to be resized according to device
>
> Is there anything better than the obvious trick of resizing everything
> in sight when the app is being initialised, including substituting the
> more sensitive graphics from a library of appropriate sizes? Seems
> tedious.

Is it all that tedious?

Computers have had resizable windows since Mac 1.0, and even HyperCard
stacks could be resize after its first version.

True, in the very olden days we all enjoyed the simplicity of knowing we
never had to accommodate any screen size other than 512x342.  Ah, those
were the days! :)

But 640x480 came along not long after, and it caused much concern among
developers. Suddenly we had to become aware of screen metrics, and
rearrange our layouts to make good use of the available space.

Then 1024x768 came along, and then we had THREE(!) screen sizes to
contend with. Oh the humanity! :)

Then by the early 90s we got over it.  Anticipating multiple screen
sizes became the norm, new tools like SuperCard, OMO, and MetaCard came
along offering true resizable windows, and we learned to respond to
notification that the window had resized so we can adjust our interior
contents nicely.

Flash forward to 2010: iPhone comes out, with the presumption that one
size will satisfy all tastes.  That didn't last long.  History doesn't
always repeat itself, but it often rhymes. :)



As with desktop software, I find it instructive to observe how the best
apps on mobile behave, and then - because those establish user
expectations - do what they do.

And what we see is not all that different from how designers handle
resizable windows on the desktop: some objects stay where they are,
those that make sense to enlarge enlarge, those that make sense to
remain adjacent to something next to them remain adjacent to something
next to them, etc.

If you've written resizeStack handlers at any point in the last 28 years
since MC premiered, you've already learned most of what you need to know
to handle a resizeStack message on a mobile device.

The specifics of how this plays out in your layout will of course depend
entirely on your layout.  But I have found a few things that have
greatly simplified my UI work, chiefly:

- Use Groups Smartly

Relatively recently (a few years ago) the engine now sends a
resizeControl message to groups whenever they're resized by any means,
either user interaction with the pointer tool (as had always been the
case) or via script (the new addition).

This allows us to work with our UIs very cleanly, recognizing that an
app is ultimately a set of rows, and that some rows are divided into
blocks.  When we group controls by their location/purpose logically, we
get to take advantage of a wonderfully simplifying cascading effect with
regard to resizing, which allows us to keep control adjustments local to
their containing group.

Imagine a simple message form, where the rows are:

- Icons for navigating to different screens

- Message, which includes three rows:
   - Subject field
   - Body field
   - Send button

With that, our card script need only bother itself with the general
placement of the two main goups:

on resizeStack x,y
set the rect of grp "Nav" to 0,0,x,40
set the rect of grp "Message" to 0,40,x,y
end resizeStack

And because the groups will get a resizeControl message when that card
script adjust them, each can contain its own handler to take care of its
interior contents.  This might be the script for the Message group:

on resizeControl
set the rect of fld "Subject" to the left of me, the top of me, \
  the rig

Re: Mobile screen sizes - another naive question

[Richard Gaskin via use-livecode]

Very good thoughts there, Alex.

The assumptions you list would be important to keep in mind if one were 
aiming to generalize basic layout handling, with libraries that have 
nicely-designed APIs, or even further with virtual props that would lend 
themselves well to reducing things further to simple point-and-click 
authoring.


But in this exercise I'm making no assumptions at all; I'm just looking 
at the UI and writing purpose-built code to make it do what I want.


And with only a dozen lines, why not?

There's good value in generalizing app development.  Data binding is 
ripe with unexplored opportunities, as are field entry validation, 
window management, menu management, exception handling and reporting, 
socket comms, and many other things we write.


Sometimes we make tools or libraries to reduce the scripting we would 
use to deliver those.


Sometimes we generalize far enough to reduce it further to assigning the 
desired behavior with property settings which would then lend themselves 
to a point-and-click development workflow.


But often we just write a few lines of script to do what we want to do 
for the case at hand and be done with it.


The draft Lesson I posted serves only as a reminder that placing objects 
where we want them isn't all that deep, and if we use groups well we can 
reduce that scripting even farther.


That this wasn't clear in the writing suggests the draft is possibly too 
long.  "Set the loc of  to " doesn't really require a whole 
page.


Different apps require different code. Layout is the least of it. 
LiveCode is a scripting language.  We script.


And when we look at the apps we use from others, regardless what tool 
they're written in, we see those authors do the same thing: they look at 
their layout, consider what they want to communicate to the user, and 
put things where they want them to support that.


What I had tried to convey was that putting things where you want them 
is neither mysterious nor difficult in a nice language like LC.  Clearly 
I overwrote.


--
 Richard Gaskin
 Fourth World Systems



Alex Tweedly wrote:

On 27/04/2020 21:29, Richard Gaskin via use-livecode wrote:


I've been itching to write a tutorial on using specific object 
placement ("Responsive Design", as the kids call it) to compliment the 
Lesson we've had for years on the other mobile layout option, 
FullScreenMode.


I had a few minutes over the weekend, and a discussion with a new 
developer prompted me to craft a simple example of how groups can be 
used to handle common design patterns with little code.


This may be fleshed out more fully in the future, but for now at least 
it's more than the zero tutorials we've had on it thus far:


https://forums.livecode.com/viewtopic.php?f=53&t=33989&start=15#p190927

Interesting, and as you say, a good start can be made easily. But it has 
many built-in assumption that may come back to bite you 


on resizeControl -- Allow the user to enjoy whichever orientation -- 
they prefer with responsive design: -- put item 1 of the loc of me 
into tMidX put item 2 of the loc of me into tMidY -- if the width of 
this cd < the height of this cd then -- Portrait: set the loc of grp 
"UserInfo" to \ tMidX, tMidY - (the formattedHeight of grp "UserInfo" 
div 2) set the loc of grp "MembershipInfo" to \ tMidX, tMidY + (the 
formattedHeight of grp "MembershipInfo" div 2) else -- Landscape: set 
the loc of grp "UserInfo" to \ tMidX - (the formattedWidth of grp 
"UserInfo" div 2), tMidY set the loc of grp "MembershipInfo" to \ 
tMidX + (the formattedWidth of grp "MembershipInfo" div 2), tMidY end 
if -- end resizeControl
In Portrait mode, this assumes that the two groups are the same height 
(or nearly so). If they're not, one or other of them will finish up 
bumping against the top (or bottom) of the card.


Similarly, in Landscape, it assumes they are same-ish width, otherwise 
one of them will stick out the side.
*AND* it assumes they are the same height, otherwise the tops will be 
mis-aligned and potentially ugly.

( you could add lines like
put the min(top of grp "MembershipInfo", the top of grp "Userinfo") into 
temp if temp < the top of me + 10 then put the top of me + 10 into temp 
set the top of grp "MembershipInfo" to temp set the top of grp 
"UserInfo" to temp


to the end of the Landscape case).

And there are other assumptions

1. the fields are sized suitable to fit in the width of the narrowest 
device. If a narrow device is small enough, maybe the labels should 
slide around to above its field, rather than be beside it.


2. assumes that you don't want to widen the fields on not-very-narrow 
devices - whether stretching the fields, or increasing spacing between them.


3. In landscape, there may well not be enou

Re: Mobile screen sizes - another naive question

[Richard Gaskin via use-livecode]

Thank you for your feedback, Graham.

If it takes more than a quick skim to get to the "a ha!" of using groups 
well to reduce scripting, I'll bet I can revise that to be clearer.


Help me understand something - anyone, please chime in:

Resizable windows have been around since the dawn of GUI OSes, and 
putting things where we want them by setting the rect and loc of objects 
has been central to all xTalk dialects since HC 1.0.


What parts of putting objects where you want them have been challenging?

Have most LC devs been delivering fixed-size windows all this time?

My aim with that brief tutorial is to encourage folks to use the object 
placement commands they already know to deliver UIs that behave like the 
other apps they use.


Setting loc and rect gets us there, and using groups well gets us there 
with a fraction of the code.


FullScreenMode is easy, but when you look at the apps on your phone 
you'll see very few that do anything like it.  In most other tools 
designers put things where they want them in ways that make optimal use 
of the screen, at any size screen, any ratio, in either orientation.


We can do this in LC at least as easily.  And groups make short work of 
much of it.


Why is it our community often makes apps that don't have the look and 
feel of most others with regard to object placement?


We share this level of interest in the appearance of individual 
controls, with much discussion about getting every detail as nice as we 
can make it to meet user expectations.  Heck, we even have at least five 
ways to make a simple button so we can be sure to get the exact look we 
want.


But somehow when it comes to how those controls work together to respond 
to changes in screen/window size, the interest wanes.  I'm not sure why.


--
 Richard Gaskin
 Fourth World Systems



Graham Samuel wrote:

> Richard, thanks for these valuable insights. I am doing my best to
> absorb them as quick as I can, meanwhile making use of FullScreen mode
> just to get my app running before it becomes redundant. You are right,
> it has been very difficult to gather comprehensive info on the topic
> until now.
>
> Graham
>
>> On 27 Apr 2020, at 22:29, Richard Gaskin wrote:
>>
>> Graham (and Brahmanathaswami may enjoy this too):
>>
>> I've been itching to write a tutorial on using specific object
>> placement ("Responsive Design", as the kids call it) to compliment
>> the Lesson we've had for years on the other mobile layout option,
>> FullScreenMode.
>>
>> I had a few minutes over the weekend, and a discussion with a new
>> developer prompted me to craft a simple example of how groups can
>> be used to handle common design patterns with little code.
>>
>> This may be fleshed out more fully in the future, but for now at
>> least it's more than the zero tutorials we've had on it thus far:
>>
>> https://forums.livecode.com/viewtopic.php?f=53&t=33989&start=15#p190927
>>
>> --
>> 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: Mobile screen sizes - another naive question

[Richard Gaskin via use-livecode]

You never need an excuse with me. On the contrary, having an adventurous 
mind hardly needs an excuse at all.


In fact, where you're headed is a potentially exciting place.

I have a need for something tangentially related for a web production 
tool, where I need to reproduce in an LC lib some of the key benefits of 
CSS Grid.


Having thought about this for some time, FWIW I would suggest considering:

- Both FlexBox and Grid merit attention for design inspiration,
  but between the two it seems most designers find Grid more
  generally applicable, so where they differ consider how Grid
  does things, at least for a first pass.

- Allowing Grid to serve as more than just inspiration, but an actual
  model in terms of properties and how setting those adjusts behavior
  would seem very useful for two reasons:

  - The design work for something like that is the hard part, and
 Grid's design process was thorough, its result very good.

  - A lot of us do both native and web apps, so being able to transfer
knowledge from one domain to another simplifies adoption.


When I think of adaptation of web methods for native apps in LC, my mind 
often returns to the excellent work of Ralf Bitter with his revIgniter 
framework.  Inspired by the popular PHP-based webIgniter, his 
implementation carries forward the best of what that offers, enhanced in 
ways that make very good sense for LC devs.


Our community could benefit from more things like that, popular ideas 
from other parts of the world re-envisioned in LC-savvy implementations.


If the parts I need for my web production tool become generally useful 
I'll happily contribute them to any more generalized effort toward a CSS 
Grid-like lib for LC.


--
 Richard Gaskin
 Fourth World Systems



Alex Tweedly wrote:

> Richard,
>
> it wasn't that you over-wrote it - the problem was I over-thought it.
>
> My excuse is that I have been thinking quite a bit this last week
> about whether there was a (simple enough) approach to layout that
> would allow "rows & columns" semi-flow layout to be nearly automatic,
> and be possible to provide a UI that would make it practical (and
> quick) to provide extra guidance to such a system.
>
> You message just happened to fit into that thought exercise - causing
> me to over-complicate things.
>
> So my apologies. I think what you wrote was perfectly clear, it just
> didn't happen to be the same as I was working on :-)
>
> Alex.


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: FormattedHeight

[Richard Gaskin via use-livecode]

J. Landman Gay wrote:

> I think the solution has to be in the engine. I'm in trouble.

Even if you find a workaround, I hope the engine team understands that 
it's a workaround, and has interest in letting us work in ways that are 
far less strangely counterintuitive that having to wrap a field in a group.


Same with buttons (why do we have five different ways to make one 
control type), and so many things on mobile.


Yesterday in the forums a new user was asking about copy and paste on 
mobile, something we understand doesn't work with LC's built-in fields 
(along with a good many other things), but new users expect LC to behave 
as well with mobile development as it does for desktop, and the need to 
type out control definitions like we're C programmers stuck in 1993 
while using what is supposed to be be an easy drag-n-drop GUI was barely 
acceptable as a short-term workaround when LC first jumped into mobile, 
and now a decade later it's maddeningly mystifying.


So I tried to explain the situation as nicely as I could:

LiveCode's built-in field object have not yet been expanded
to integrate with mobile OSes as it does on desktop platforms.

In addition to clipboard support, you'd eventually discover other
shortcomings using those on mobile, including nonstandard UI for
text selection.

LiveCode does offer support for mobile-native fields, however,
using the script interface described in the User Guide and this
lesson:

http://lessons.livecode.com/m/4069/l/29112-how-do-i-use-native-text-controls-on-mobile


To which this new customer replied:

   Right, so that's sorted by using a native input, and letting the OS
   deal with text and copying.

   That feels like quite an awkward solution for a paid license of a
   product with heavy focus on mobile development, but it did solve
   the problem at hand, thanks for the info FourthWorld


I agree with him. It is at best awkward.

LiveCode is nearly unmatched for making desktop apps, but for mobile 
development there are so many unfinished edges it's barely a contender 
for anyone not already heavily invested in LiveCode from desktop work.


It would be reassuring if the LC team could share with us their plan to 
finish their mobile implementation, to deliver a user experience on par 
with its best-of-breed desktop workflows.


If that's not a goal that's useful to know as well.

--
 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: Most obscure HC question

[Richard Gaskin via use-livecode]

What happens if you make a copy of the HC standalone file, delete the 
resources, and change the file's type fom 'APPL' to 'STAK'?


Can you then open the remaining data fork in an older version of LC to 
bring it into the modern world?


--
 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: Most obscure HC question

[Richard Gaskin via use-livecode]

J. Landman Gay wrote:

On 5/2/20 6:04 PM, Colin Holgate via use-livecode wrote:
>> As it’s a standalone application I can’t easily get at the stack,
>> but feel sure there was a way to hack the stack out of a standalone.
>
> There was, only I can't remember the details either. But I do remember
> that there was a fairly clear division between the stack content and
> tacked-on engine, and if you knew what to look for you could delete
> the engine part in a text editor and end up with a working stack.

In Mac OS (as opposed to the modern macOS), an application kept its code 
in 'CODE' resources, with the resource of ID 0 containing the main entry 
point.


So...

http://lists.runrev.com/pipermail/use-livecode/2020-May/260175.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: FormattedHeight

[Richard Gaskin via use-livecode]

J. Landman Gay wrote:

> On 5/2/20 8:20 PM, Richard Gaskin via use-livecode wrote:
>> LiveCode is nearly unmatched for making desktop apps, but for
>> mobile development there are so many unfinished edges it's barely
>> a contender for anyone not already heavily invested in LiveCode
>> from desktop work.
>>
>> It would be reassuring if the LC team could share with us their
>> plan to finish their mobile implementation, to deliver a user
>> experience on par with its best-of-breed desktop workflows.
>
> That's what widgets are for.

Are they?

Widgets are great for specialized functionality not in the box.  But 
crafting custom widgets should not be seen as a replacement for 
essential common GUI elements.


Will you be solving your field display issue by writing your own text 
engine from scratch in a lower-level scripting language?


Should I tell that forum user that LiveCode doesn't provide common GUI 
essentials out-of-the-box?


Show of hands: how many of you would be using LiveCode today if the 
desktop editions required you to write your own common GUI controls from 
scratch?



> There are native fields and buttons, though some are still
> missing, but not enough people are writing them. And unfortunately,
> mobile GUIs change often enough on both Android and iOS that the
> native buttons aren't so native any more.

If/when this goes in the engine, it could be handled as it is on the 
desktop, with hooks into the host OS renderer.  Write once, render anywhere.


But at the moment, at a minimum the team could do what so many of us 
have done: write a library that walks through LC-native controls on the 
card and makes appropriate replacements/additions where needed for mobile.


When the script sees a group or field with scrollbars, it turns the 
scrollbars off so they're not visible and automatically creates the 
mobile-native scoller region to match it.


When the script sees a checkbox, it hides that and instantiates a 
mobile-native Boolean selector.


When the script sees an editable field, it hides that and creates an 
editable field matching those properties in its place.


Pinch-to-zoom on images becomes a property, so those interactions invoke 
a good-but-difficult-to-find-buried-in-the-forums-script to handle that 
(the Lesson on that is woefully incorrect).


In each case, message handlers route mobile-native messages to their 
LC-native counterparts.  This lets you script using LC objects without 
having to type out control defs in code like you're a C programmer from 
1993.  And it lets you enjoy one of the finest benefits of The xTalk 
Way: blurring the line between development and runtime so you spend more 
time developing your app in the environment designed for developing.


This won't handle all possible circumstances, but will remove the most 
serious pain points from at least 80% of LC's uniquely odd mobile 
development workflows.


This could be done today.  It could have been done many years ago.  Many 
of us have been replicating this for years.



That would reduce the most common pain points, but still wouldn't 
address your need to scroll field text whose formatted height exceeds 
32765px.


For that we need some engine work, to finally be done with the 
frankly-bizarre requirement that a perfectly good field needs to be 
wrapped inside of a group just to scroll smoothly.


We don't need that strange and unpredictable extra step on the desktop, 
and that we need it on mobile is not a feature, it's a bug, a 
shortcoming that I hope the engine team has a plan to address.


LiveCode on the desktop is flippin' awesome.  LiveCode on mobile can be 
every bit as awesome, and needs to be if it's to remain relevant in a 
world of simpler competitors.


The current workflow requirements undo the otherwise-powerful benefits 
of using LC on mobile for many newcomers.


--
 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: Most obscure HC question

[Richard Gaskin via use-livecode]

Paul McClernan wrote:

> That old HC stack that removes the HC engine leaving only a stack file
> is here:
> https://archive.org/details/hypercard_standalone-stripper-232

From the link:
   This stack 'deconverts' HyperCard standalone applications into
   stacks by removing the 'stock' standalone resources, changing
   the file's Type and Creator codes to 'STAK' and 'WILD', and
   clearing the new stack's 'hasBundle' bit.

Can also be done with ResEdit or LC:
http://lists.runrev.com/pipermail/use-livecode/2020-May/260175.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: HTML Platform

[Richard Gaskin via use-livecode]

Mark Wieder wrote:

On 5/5/20 4:47 PM, Trevor DeVore via use-livecode wrote:
>> I don't use HTML deployment myself, but thought I would mention that
>> there has been some emscripten activity in GitHub lately. Looks like
>> WebAssembly (WASM) support is being added.
...
>
> Yeah, I saw the github posts come flying by, and that's a promising
> feature, but it doesn't address the limitations and broken features of
> the current html implementation.

In my own mind I phrase that differently.  Whether it's gentler or more 
stark is up to the reader, but for me it's more:


  ...it can't address the fundamental differences between desktop
  and web architectures, and the limitations inherent in Emscripten.

Emscripten is good for what it was designed to do.  But look deeply at 
LC, consider what Emscripten is, and the more time you spend pondering 
it the clearer it becomes how difficult it is to put a desktop app's 
square peg into a browser hole.


"Difficult" is maybe unfairly optimistic. And "impossible" never applies 
to software. Perhaps "prohibitively expensive" is fair.



> Also, it remains to be seen how much bloat this adds to deployed web
> apps.

Putting an entire scripting engine and object model into a browser 
application that already has its own scripting engine and object model 
cannot achieve size, performance, and integration features as well as a 
web-native implementation.


If you truly need a browser as your only deployment option, it's kinda 
hard to argue against going with the grain of the browser.


But most apps that might make good candidates for LC's HTML export have 
characteristics that lend themselves very well to not doing HTML at all, 
instead using a one-time download of an LC standalone which then 
downloads and runs stack files (a practice that, in the absence of a 
more common label, I like to call "streaming apps").


Fits most of the same uses cases, but provides a more focused user 
experience that integrates with the OS as only a native app can.


Extra bonus points that they're cheap and easy to build in LC, fast 
cheaper to deliver sophisticated works than even web-native implementations.


For the sorts of vertical audiences where LC's HTML would seem 
interesting, I believe simply streaming stacks in a standalone is the 
most underappreciated and underutilized opportunity in our community.


MetaCard promoted the idea heavily with some nice example downloads, but 
in all these years only a few of us make streaming apps regularly.


If you're waiting for LC's HTML to get good, let's discuss streaming 
apps for those where they might be a great solution.  We really don't 
need to wait for anything to have the benefits of net-distributed apps. 
You can have it all today, with the LC you know and love already.


--
 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: I need some DataGrid performance help

[Richard Gaskin via use-livecode]

zryip theSlug wrote:

> datagrids are using virtual properties, so you can't lock the
> messages.

Reminds me: we have a request to do away with that,since it complicates 
a lot of otherwise-powerful-and-simple things we can do with custom 
controls.


A while back Mark Waddingham reviewed the situation and decided that 
getProp and setProp were indeed more rightly in the category of custom 
messages rather than system messages, and as such should ideally be 
immune to the effects of "lock messages".


Anyone on the team have an update on this?

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

--
 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: HTML Platform

[Richard Gaskin via use-livecode]

Erik Beugelaar wrote:

> It would be great if a lesson comes available how to create streaming
> apps with LC.

Thank you for your interest.  I'll do that, but it'll have to wait until 
I finish some client projects first.


In the meantime, the beauty of this approach is its simplicity.  Like 
anything else it can be made complicated, but it boils down to:


1. Make a slim standalone that contains just a splash screen and
   only enough code to download a stack file from your server
   (or report a network error if it can't).  "Load URL" is a good
   choice for larger stacks because it lets you display a progress
   indicator asynchronously, but for smaller stack files simply
   "go stack " will work just fine.

2. Put a stack file with the guts of your app on a server.

3. Run your standalone.

It gets even better when you use LC's built-in gZip compression to 
reduce download times.


And better still, you can also cache what you download to support 
offline modes where practical.  Using a small text file on the server 
containing the build number of the stack file there makes it quick and 
easy to check if a fresh copy of the stack file needs to be downloaded, 
otherwise it opens the cached copy.


The beauty of this is that it's neither new nor exotic.  We've been 
doing it since MetaCard first made a one-liner out of HTTP GET with 
libURL back in the '90s.


For a fairly simple example, see LiveNet (in the IDE, Development -> 
Plugins -> GoLiveNet).  That small plugin downloads a stack file that 
includes fields and other containers that are then populated with data 
it pulls from multiple sources, exemplifying both the ease of 
downloading stack files and (hopefully) serving as an inspiration for 
building mash-ups.


--
 Richard Gaskin
 Fourth World Systems



-Original Message-

Mark Wieder wrote:

On 5/5/20 4:47 PM, Trevor DeVore via use-livecode wrote:
 >> I don't use HTML deployment myself, but thought I would mention 
that  >>

there has been some emscripten activity in GitHub lately. Looks like  >>
WebAssembly (WASM) support is being added.
...
 >
 > Yeah, I saw the github posts come flying by, and that's a promising  >
feature, but it doesn't address the limitations and broken features of  >
the current html implementation.

In my own mind I phrase that differently.  Whether it's gentler or more
stark is up to the reader, but for me it's more:

   ...it can't address the fundamental differences between desktop
   and web architectures, and the limitations inherent in Emscripten.

Emscripten is good for what it was designed to do.  But look deeply at LC,
consider what Emscripten is, and the more time you spend pondering it the
clearer it becomes how difficult it is to put a desktop app's square peg
into a browser hole.

"Difficult" is maybe unfairly optimistic. And "impossible" never applies to
software. Perhaps "prohibitively expensive" is fair.


 > Also, it remains to be seen how much bloat this adds to deployed web
 > apps.

Putting an entire scripting engine and object model into a browser
application that already has its own scripting engine and object model
cannot achieve size, performance, and integration features as well as a
web-native implementation.

If you truly need a browser as your only deployment option, it's kinda
hard to argue against going with the grain of the browser.

But most apps that might make good candidates for LC's HTML export have
characteristics that lend themselves very well to not doing HTML at all,
instead using a one-time download of an LC standalone which then
downloads and runs stack files (a practice that, in the absence of a
more common label, I like to call "streaming apps").

Fits most of the same uses cases, but provides a more focused user
experience that integrates with the OS as only a native app can.

Extra bonus points that they're cheap and easy to build in LC, fast
cheaper to deliver sophisticated works than even web-native implementations.

For the sorts of vertical audiences where LC's HTML would seem
interesting, I believe simply streaming stacks in a standalone is the
most underappreciated and underutilized opportunity in our community.

MetaCard promoted the idea heavily with some nice example downloads, but
in all these years only a few of us make streaming apps regularly.

If you're waiting for LC's HTML to get good, let's discuss streaming
apps for those where they might be a great solution.  We really don't
need to wait for anything to have the benefits of net-distributed apps.
You can have it all today, with the LC you know and love already.

--
  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: HTML Platform

[Richard Gaskin via use-livecode]

Pi Digital wrote:

> Richard wrote:
>> But most apps that might make good candidates for LC's HTML export
>> have characteristics that lend themselves very well to not doing HTML
>> at all, instead using a one-time download of an LC standalone which
>> then downloads and runs stack files (a practice that, in the absence
>> of a more common label, I like to call "streaming apps").
>
>
> Two words, Richard.
> IT Departments.
> Of the 150+clients my client has, 150+ of them would emphatically
> prefer a web based app than a desktop one. They don’t want stuff
> ‘installed’ or ‘run’ on their machines that haven’t been thoroughly
> tested before use. Each and every update. And they really don’t want
> to have to keep testing each and every update. Using Chrome/Edge-
> Chromium overcomes all of that.

I hear you loud and clear on that, Sean. I've run into that myself 
(humorous anecdote below).


In the subset of cases where IT is absolutely forcing the entire 
enterprise to ditch OS-native apps in favor of browser apps, there's 
little you can do to stop that.


And where the limitations inherent in any Emscripten-based solution pose 
no impediment to functionality, why not?  You'll still need to do 
significant rework of the stack to meet user expectations (e.g. more 
than half of all net traffic is on mobile devices so responsive design 
has become a common expectation for web apps), but where Emscripten does 
what you need by all means use it.


There is no one-size-fits-all for any of the work each of us does.  We 
evaluate the needs of our audience and make our deployment choices 
accordingly.



But the advent of the web hasn't killed OS-native apps.  The Mac app 
store is filled with them, and they remain a mainstay throughout 
organizations big and small.


Indeed, even the rise of the cloud hasn't killed off OS-native apps, but 
simply validated the "streaming app" model with the popularity of 
net-savvy apps like Adobe's Create Suite, Microsoft's Office 365, and 
Apple's iTunes.


An OS-native app allows a level of integration with common OS services 
and workflows difficult or impossible to achieve in the confines of a 
browser window.


Extra bonus points that it's also often a better overall user 
experience, and far cheaper to build and maintain in the LC we know and 
love.




> And mySQL from LC in the browser is tonnes faster than on the desktop
> - massively! Because they’re both on the same server. Even though the
> message path is LC>JS>(AJAX)>PHP>JS>LC!

I suspect there's something going on there that can be remedied.  As you 
noted, compiled object code should be faster than interpreted 
JavaScript.  In every other respect the calls should be the same, so 
throughput should be faster in the OS-native implementation.  If it's 
not let's review that to bring it up to speed.




--
Aside: A Humorous Anecdote about working with Corporate IT

I was once a partner in a company that deployed a networked app which we 
delivered to institutions on CD-ROM.  As we told customer IT, we 
designed it for their convenience, so installation is simply copying a 
folder from the CD-ROM to a shared volume.  That's it.


IT at one facility didn't believe us.  They were up to their armpits in 
lesser tools than LiveCode, they were unable to conceive of a true 
standalone, accustomed to apps that spew DLLs all over the hard drive 
and then also require mods to their firewall.


They insisted we produce an Installation Guide.  We did.  It was one 
paragraph describing how to copy a folder from a CD to a shared drive, 
with the rest of the page being an illustration of doing that.  They 
were fully satisfied with that deliverable. :)



Years later we did migrate the consumer portion to a web-native 
implementation (using LC to generate it).  And since the original was 
built in LC, we easily moved a lot of the logic that had been in the 
client onto the server with minimal effort.  More on that in a moment.


We kept the authoring desktop-native, and expanded it into a streaming 
app where it was used by dozens of collaborating authors in offices 
around the world.


Authoring had originally been slated for migration into an existing 
Java-based system the org had built for similar products. The only 
reason for expanding our own authoring system to become multi-user was 
because the IT staff at an acquiring company was so busy with other 
tasks it became more cost-effective to build out ours than to wait for 
IT to catch up on the tasks the org relied on them for.  Great IT staff, 
just busy.  The authoring system written by a single LC dev eventually 
had more features than their similar system built in-house by an entire 
team of Java programmers, and for a much lower cost.



But on the consumer-facing web side, we have one more punchline:

One of the orgs that had insisted on a browser-based version did so for 
the usual reason, the one you noted, the concern for security.  As a 
regional hospital network (

Re: HTML Platform

[Richard Gaskin via use-livecode]

David Bovill wrote:

> WASM support is very important to Livecode future. It will address
> most of the problems of current HTML5 deployment

WASM will definitely benefit the two most visible issues, load time and 
performance.


Performance is an unqualified benefit, but with load time the benefit 
with web use is minimal, since the engine is re-downloaded nearly every 
time the user visits your site (unless of course yours is the only site 
they visit, so cache never purges).


While an OS-native app is downloaded once, the impact of download times 
on web apps is multiplied by frequency of use.


In compiled object code the LC engine ranges from about 17 MB (Win) to 
32 MB (Mac). Assuming the WASM export comes closer to that, it's still 
outside the short patience most end-users have acquired for public sites.


Can still be quite good for specialized audiences who understand up 
front the value of waiting for what you're delivering.  But where a 
priori buy-in is that deep I find those audiences often equally 
amendable to a one-time download of a desktop app.



That said, even with improvement on the most immediately-visible issues, 
 switching interpreters from JS to WASM can't address the less visible 
ones we discover only after we commit to that path. We're still stuffing 
a desktop object model and functionality into an HTML Canvas object 
inside of a browser application.


As I wrote in a recent forum thread on a related subject:

   And even if the size and speed impediments could be overcome
   affordably, then what? Given that the desktop and the browser
   are such fundamentally different platforms, the vision of
   exporting an existing desktop app to the web is impractical
   from a design standpoint alone. File I/O, windowing, menus,
   OS integration, layout flow, etc. - all vastly different, some
   non-existent on the web altogether given its vastly different
   role.
https://forums.livecode.com/viewtopic.php?f=120&t=25210&start=75#p190586

Emscripten-based export can be good for some use cases.  But I'd wager 
that the number of use cases where it's an ideal fit is the same or 
fewer than those where a net-savvy OS-native app would also be welcome.


For all the popularity of the web, native apps haven't gone away.  They 
are different animals.



> and I definitely intend to use it - for micro service deployment, and
> blockchain integration for instance.

I have a friend who's been nudging me to spend more time with 
blockchains. Please keep us posted.  I'll be interested to learn how 
much of the business logic is in the client and how much is on the 
server.  So many options there...



> It will doubtless be a commercial feature

Oh dear I hope not. It's too easy to be attracted by a shiny nickel 
today at the cost of a dollar tomorrow.


LiveCode as a product has its fate bound by LiveCode as a *platform*. 
Unless we want to limit its audience to mostly retired HyperCard fans, 
we'll need to encourage a reconeptualization of the role of the 
Community Edition in platform-building.


--
 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: I need some DataGrid performance help

[Richard Gaskin via use-livecode]

Mark Waddingham wrote:


On 2020-05-06 17:36, Richard Gaskin via use-livecode wrote:

A while back Mark Waddingham reviewed the situation and decided that
getProp and setProp were indeed more rightly in the category of custom
messages rather than system messages, and as such should ideally be
immune to the effects of "lock messages".


If by a 'while back' you mean the thread from 2013 in the engine forum 
(http://forums.livecode.com/viewtopic.php?f=66&t=18048) then that's a 
long time ago! If I have commented more recently on this, then a 
reference to what I said would help :)


I look forward to having the luxury of time to catalog your every word. 
:) In the meantime I work with what I can recall offhand, and trust 
you'll provide correction where needed.


Thanks for doing so here:

In reality if you want encapsulated custom controls which cannot be 
broken by user scripting around them, then it is not just property 
handlers which should be immune to lock messages, all engine messages to 
such a custom control should be immune.


"Cannot be broken by user scripting around them" is an enticingly high 
threshold, but one I've never considered.


In an imperfect universe in which all decisions involve trade-offs, my 
own modest desires would be satisfied well enough with being able to 
lock messages without having to consider side-effects on the DataGrid or 
other prop-driven scripts.


But keeping those implications in mind hasn't stopped me from delivering 
anything yet, so I'll continue to do well with what we have.



Regardless of what I said 7 years ago, now (being older, and maybe a 
little wiser) I don't think I really see how changing lock messages (and 
breaking a lot of code as a result!) would get us any further towards 
better custom controls would it?


Sure.  Maybe this BZ item be closed to put the concern to rest?
https://quality.livecode.com/show_bug.cgi?id=226

--
 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: Recommended (simple) Linux distro for Livecode server home dev/test?

[Richard Gaskin via use-livecode]

Keith Clarke wrote:
> Hi folks,
> Which distro(s) would you recommend for a Linux newbie as the easiest
> way to repurpose an old PC, Mac Laptop or Mini to host Livecode Server
> for lightweight ‘LAMP/LAML' dev/test dabbling?
>
> I’ve never had a Linux desktop machine and server-wise, never had to
> delve below C-Panel & WHM on hosted VPS Linux environments - so am
> very much the newbie on this.

Ubuntu, without question.

There many great distros, and I don't think there is a single "best". 
But Ubuntu has by far the largest installed base, so most of the 
tutorials and other support materials you'll find are written with 
Ubuntu in mind.


This is especially true on servers. Heck, even on Microsoft's Azure 
cloud ecosystem. Ubuntu is the leading OS.


Desktop:
https://ubuntu.com/download/desktop

Server:
https://ubuntu.com/download/server

You may change later; some folks like to distro-hop often. But the vast 
range of support materials makes Ubuntu the go-to starting point for 
getting into Linux.



> Hardware specs would be useful, too - to gauge how far back on the
> cupboard to reach to source an appropriate box!

You can check the requirements at the site, but you probably don't need 
to worry about it.  If it's for a sever you won't need the GUI desktop 
edition, and it's the desktop where requirements tend to be much higher. 
 There's a flavor of Ubuntu for everything from Raspberry Pi to 
supercomputing clusters - you should have no trouble finding one for 
your old PCs. The Server edition should get you up and running on just 
about any machine made in the last 10 years or more.



If you want a GUI desktop edition and have an old machine that's a bit 
underpowered for Ubuntu, there's a lightweight flavor you can use:


https://lubuntu.net/

Lubuntu is the leanest Ubuntu flavor I've tried.  It's been running on 
my desk almost continuously for the last decade, downloading, collating, 
and posting data for the info you see in LiveNet (see the GoLiveNet 
plugin in LC's Plugins menu).


I prefer Ubuntu's Gnome Shell for my main workstation, but on 
lower-powered machines I've been impressed with how efficiently Lubuntu 
runs.


--
 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: Enabling "About MyApp"

[Richard Gaskin via use-livecode]

GEORGE WOOD wrote:

> How can I activate the "About MyApp" under the Apple menu?

On other OSes the "About" item is usually the last item in the Help 
menu.  If you put your About item there, you'll find that when LC 
automatically translates its menu objects for the Mac menu bar it'll 
move your About item to the application menu.


In fact, a similar thing happens with "Preferences". On most platforms 
it's the last item in the Edit menu, and when you put a "Preferences" 
item there the automatic menu bar change that LC does will put it in the 
application menu as well, below About.


--
 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: Open printing to pdf

[Richard Gaskin via use-livecode]

GEORGE WOOD wrote:

> Here is on example of what I tried:
>
> on mouseup
>  put “⁩/Desktop⁩/test files/Test.pdf” into temp
>  open printing to pdf temp
>  print cd 1 from (topleft of cd 1) to (bottomright of cd 1)
>  close printing
>  put the result
> end mouseup

"the result" returns exception info for the last command executed. In 
that case it's the "close printing" command.


Move it a line up and it'll tell you what's happening with the print 
command.


But add an error-check just after "open printing..." and I'll bet you'll 
find the culprit:


You path begins with "/", which signifies the root of the volume.  But 
"Desktop" is in the root, it's in the user's Home folder at (assuming Mac):


  /Users//Desktop/

Using specialFolderPath("Desktop") will always return the correct path 
on all platforms with a Desktop.


But in your case, you can do something even simpler:

  put "~/Desktop/test files/Test.pdf" into temp

The leading "~" is shorthand for the current user's folder.

--
 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: Atom Editor Help

[Richard Gaskin via use-livecode]

Peter Reid wrote:

> ...several of the LiveCode staff use the Atom text editor.

That may explain the state of LC's Script Editor.

--
 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: Changing text properties in a field via the IDE

[Richard Gaskin via use-livecode]

Graham Samuel wrote:

> I’m using LC 9.6.0 rc1 on a Mac. Just now I did something very simple
> that didn’t work. I created a label field, opened the Property
> Inspector for the field and changed its text - that worked. Then I
> attempted to change the font size - that didn’t work. The appearance
> of the label in the stack itself didn’t change, nor could I change the
> font, make the text bold etc. I tried this again with a regular field
> - same result. I started a new stack with just the one field - same
> result.
>
> All these values can be changed by script, in the Message Box or
> elsewhere, but I can’t make them in the IDE by changing values in the
> Property Inspector.
>
> What am I doing wrong?

Text attributes can be set in the field, and the field properties can be 
overridden by a text run within the field.


When changing field properties doesn't change what you see, try 
selecting the text within the field and changing 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: Changing text properties in a field via the IDE

[Richard Gaskin via use-livecode]

Graham Samuel wrote:

> To an ordinary LC developer, if you can change the properties of the
> initial text (to a different size for example) without overtly
> selecting it, then the same behaviour can be expected from the IDE
> when trying to change text you’ve pasted in. It may or may not be
> styled, but the confusing part is that selecting the text in the
> Object Inspector has no effect...

I just tried this recipe:

1. Paste styled text into a field
2. Choose pointer tool
3. Double-click the field to open the Inspector
4. In the Inspector, navigate to the Text pane
5. In that pane, select text, then type Ctrl-B

RESULT: Both the styled text in the Inspector and the styled text in the 
field being inspected updates the contents to show the portion I'd 
changed to bold.


Is that not working there?

--
 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: Changing text properties in a field via the IDE

[Richard Gaskin via use-livecode]

Graham Samuel wrote:

> Well, I am happy to be wrong, so I repeated exactly what you did, of
> course using my own bit of styled text. It didn’t work - partly
> because I can only select the text in the field itself in ‘run’ mode,
> but I can only see the Inspector in ‘edit’ mode. When I switch between
> the two modes, I can’t do your (5), because I can’t select the text in
> the pane as you suggest.

FWIW, it's not necessary to use the Inspector, or change tool modes.  If 
the field is editable you can use the IDE's Text menu to change 
attributes in text selections directly in place, as you would with any 
word processor.


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

Obtaining URL to latest Stable LC Server

[Richard Gaskin via use-livecode]

It would be helpful to have a convenient way to obtain the URL to the 
latest stable version of LC Server, to automate deployments.


I don't believe the company provides that, do they?

Without a company-maintained URL, I suppose one could write a function 
that relies on a scraper for the downloads.liveocde.com page.  Has 
anyone here done 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: Obtaining URL to latest Stable LC Server

[Richard Gaskin via use-livecode]

JeeJeeStudio wrote:

> Op 20-5-2020 om 21:18 schreef Richard Gaskin via use-livecode:
>> It would be helpful to have a convenient way to obtain the URL to the
>> latest stable version of LC Server, to automate deployments.
>>
>> I don't believe the company provides that, do they?
>>
>> Without a company-maintained URL, I suppose one could write a
>> function that relies on a scraper for the downloads.liveocde.com
>> page.  Has anyone here done that?
>
>
> that's not the same version as the one you can download from
> livecode.com when you log-in. Community vs commercial

True, but my focus on the Community Edition is based on two considerations:

1. The proprietary edition requires an account-specific licensing key
   which AFAIK precludes external automation.

2. The proprietary edition is very rarely needed.

Most modern server solutions are open source, and many use GPL 
specifically, including not only LiveCode but also MySQL, MariaDB, 
Neo4j, MediaWiki, NextCloud, Wordpress, Drupal, Joomla, Git, Ansible, 
and a good many more.


The GPL being a distribution license, proprietary edition of LiveCode 
Server would be needed only in those cases where the developer is 
distributing a server solution for other devs making server solutions, 
and where they want their own code to be under proprietary license. I 
can imagine such a specific use may case exist in our community, but I 
haven't yet come across it.


For services accessed over a network, the code remains on the server and 
is not distributed to the user. So open source, even GPL, is a very good 
fit for web sites, apps, and other network-delivered services.


--
 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: Obtaining URL to latest Stable LC Server

[Richard Gaskin via use-livecode]

The encrypt and decrypt commands are part of the core language common to 
all editions, along with hashing with messageDigest and the older 
md5Digest and sha1Digest functions.


The one form of encryption proprietary editions enjoy is with stacks, to 
protect scripts. For the most part this is irrelevant to any open source 
use since of course the whole point is sharing code.


But there are at least two use cases where stack encryption might be 
useful with open source projects:


- Preventing code modification: If you had a system that uses unlocked 
stacks downloaded from multiple sources, it's possible that one script 
downloaded from  nefarious source could modify another.


- Protecting secrets: Other scripting languages (PHP, Python, Ruby, 
etc.) are plain text files, so secrets like DB passwords need to be 
handled with care.  With LC it would be possible to put that info in an 
encrypted stack for an additional level of protection that would give LC 
a competitive advantage no plain-text scripting language could match.


That said, both are edge cases and neither prevents us from getting 
serious work done with what we have today.


In the first case, if one dared to make a system that ran stacks from 
unknown sources, code modification would be the least concern compared 
with all the other ways script behavior can be modified at runtime 
within a single LC instance (frontScripts, backScripts, etc.).  In a 
server context it's almost completely irrelevant because that's the last 
place we'd want to put code from unknown sources. :)


And the second case puts even unlocked LC stacks at no disadvantage 
compared to pretty much any other language everyone else everyone uses. 
If traditional ways of managing secrets are good enough for healthcare 
and banking, they're probably good enough for the types of web services 
the rest of us make.


--
 Richard Gaskin
 Fourth World Systems



JeeJeeStudio wrote:


Yes, true.

Does the commercial version not contain options comparable like LC Indy 
e.g. Encrypting or otherwise?


Thanks for your answer.


Op 21-5-2020 om 18:21 schreef Richard Gaskin via use-livecode:

JeeJeeStudio wrote:

> Op 20-5-2020 om 21:18 schreef Richard Gaskin via use-livecode:
>> It would be helpful to have a convenient way to obtain the URL to the
>> latest stable version of LC Server, to automate deployments.
>>
>> I don't believe the company provides that, do they?
>>
>> Without a company-maintained URL, I suppose one could write a
>> function that relies on a scraper for the downloads.liveocde.com
>> page.  Has anyone here done that?
>
>
> that's not the same version as the one you can download from
> livecode.com when you log-in. Community vs commercial

True, but my focus on the Community Edition is based on two 
considerations:


1. The proprietary edition requires an account-specific licensing key
   which AFAIK precludes external automation.

2. The proprietary edition is very rarely needed.

Most modern server solutions are open source, and many use GPL 
specifically, including not only LiveCode but also MySQL, MariaDB, 
Neo4j, MediaWiki, NextCloud, Wordpress, Drupal, Joomla, Git, Ansible, 
and a good many more.


The GPL being a distribution license, proprietary edition of LiveCode 
Server would be needed only in those cases where the developer is 
distributing a server solution for other devs making server solutions, 
and where they want their own code to be under proprietary license. I 
can imagine such a specific use may case exist in our community, but I 
haven't yet come across it.


For services accessed over a network, the code remains on the server 
and is not distributed to the user. So open source, even GPL, is a 
very good fit for web sites, apps, and other network-delivered services.





___
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: Obtaining URL to latest Stable LC Server

[Richard Gaskin via use-livecode]

Ralph DiMola wrote:


I use the commercial server so I can use password encrypted stacks.
I have an app that the customer required encryption of all data and source
code. The library stack is in the iOS app/APK is also used on the backend
server. I don't want to have to strip the passcode from the stack when
release updates to the app/LC server. Besides the customer asked that all
source code be encrypted in the app or on the sever so I complied.

Edge case... probably... But LC stack encryption made the customer happy so
that made me happy.


I like it when clients write requirements in a way that rule out pretty 
much everything else but LiveCode.


The more popular server languages - PHP, Python, Ruby, Perl, etc. - all 
use plain text, so with a requirement for source encryption every 
industry-standard option is off the table.


Now if only we could get that requirement to catch on... :)

--
 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: About box equivalent for mobile apps?

[Richard Gaskin via use-livecode]

Graham Samuel wrote:
> In desktop apps, at least on the Mac, one has an “About” box where
> you can put acknowledgements of the use of copyright material and
> any other info like the version number of the app. There isn’t such
> a provision in a mobile app, is there? Is there any convention for
> this that I’ve missed, or should I just wing it somehow?

You may have to wing it.  I didn't turn up anything on About info in a 
quick review of the iOS HIG:

https://developer.apple.com/design/human-interface-guidelines/ios/overview/themes/

Also turned up no general discussion searching for a convention on this 
in DuckDuckGo.


If someone here has an authoritative reference to the contrary please 
post it, but as AFAIK it looks like there is no prescribed place for 
such info.


--
 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: Enabling "About MyApp"

[Richard Gaskin via use-livecode]

Agreed, and apparently the docs team does too - see the chapter 
"Programming Menus & Menu Bars", section "Menu Bars on Mac OS X 
Systems", where pg 181 discusses "Special Menu Items".


--
 Richard Gaskin
 Fourth World Systems


Andre Garzia wrote:

> This should be in the user guide...
>
> On Tue, 12 May 2020 at 00:42, Richard Gaskin via use-livecode <
> use-livecode at lists.runrev.com> wrote:
>
>> GEORGE WOOD wrote:
>>
>>  > How can I activate the "About MyApp" under the Apple menu?
>>
>> On other OSes the "About" item is usually the last item in the Help
>> menu.  If you put your About item there, you'll find that when LC
>> automatically translates its menu objects for the Mac menu bar it'll
>> move your About item to the application menu.
>>
>> In fact, a similar thing happens with "Preferences". On most
>> platforms it's the last item in the Edit menu, and when you put a
>> "Preferences" item there the automatic menu bar change that LC does
>> will put it in the application menu as well, below About.


___
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: Enabling "About MyApp"

[Richard Gaskin via use-livecode]

My comment was in reply to George's request about desktop menus.

Mobile systems have no menu bar of course, so any conventions that apply 
to menu bars don't apply to mobile platforms.


I did a couple searchs to try to find an answer for your mobile 
question, and posted the results here:

http://lists.runrev.com/pipermail/use-livecode/2020-May/260470.html

--
 Richard Gaskin
 Fourth World Systems


Graham Samuel wrote:
> Sorry, how does this apply to a mobile app which hasn’t got a menu in
> an explicit sense - of course I can provide a ‘menu’ item, i.e. some
> kind of choice the user can make (I do in fact have a ’settings’ card
> in the app I’m producing, so that could be somewhere to put it), but
> it’s not obligatory, is it?
>
> Graham
>
>> On 22 May 2020, at 14:11, Andre Garzia via use-livecode 
 wrote:

>>
>> This should be in the user guide...
>>
>> On Tue, 12 May 2020 at 00:42, Richard Gaskin via use-livecode <
>> use-livecode at lists.runrev.com> wrote:
>>
>>> GEORGE WOOD wrote:
>>>
>>>> How can I activate the "About MyApp" under the Apple menu?
>>>
>>> On other OSes the "About" item is usually the last item in the Help
>>> menu.  If you put your About item there, you'll find that when LC
>>> automatically translates its menu objects for the Mac menu bar it'll
>>> move your About item to the application menu.
>>>
>>> In fact, a similar thing happens with "Preferences". On most
>>> platforms it's the last item in the Edit menu, and when you put a
>>> "Preferences" item there the automatic menu bar change that LC does
>>> will put it in the application menu as well, below About.


___
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: lc vs macos vs xc vs ios table

[Richard Gaskin via use-livecode]

So many discussions of which build goes with which version of this 
component and that OS and workarounds for chains of dependencies...


Is this really as good as it gets when using a non-Apple dev tool?

Anyone here build iOS apps in anything other than LC or XCode - is 
everything out there this complicated?


--
 Richard Gaskin
 Fourth World Systems


Mike Kerner wrote:

here's an interesting note for me the next time I'm in a panic over an
annual build:
XC prior to 11 won't run on catalina (maybe 10 will, so maybe pretend I
said "10" back there).  On your machine, you'll see the circle-slash
through the icon for xcode 9.x, which means apps that you built with LC 8.x
aren't going to get their annual rebuild if you don't hold your breath and
move to LC 9, right?
Nope.  It turns out you can still build in catalina with LC 8.x and XC9.
You just can't run XC9.  That was a pleasant surprise after doing our
annual rebuild broke one of our apps on "older" (2018 era) ipads that are
stuck in ios 9.x
***BUT*** that build config causes the app to fail on newer versions of ios.


___
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 have I done now ? (aka CR and LF confusion)

[Richard Gaskin via use-livecode]

Alex Tweedly wrote:

> Re. a PR to change it, it does seem it will run into concerns about
> backward compatability. Is it likely to succeed to propose a new
> URL-type - maybe "textfile".

What exactly does the PR do?

If it changes default Mac line endings from CR to LF, thumbs up.

macOS is a certified Unix, and has been for more than 20 years.  LF is 
the OS-default line ending. Command-line tools expect LF, and the GUI 
apps I've explored this in accept both where they use CR at all.


So while I can understand a concern about backward compatibility, it 
seems this one really only applies to a relatively small subset of edge 
cases for those depending on the simpler non-binary syntax for a 
specific binary sequence.


The simpler non-binary syntax is there to make things, well, simple.

Those needing a specific binary sequence should expect to use the binary 
syntax, while everyone else can enjoy simple file I/O reliably.


Keep in mind that "everyone else" includes what we hope will be a much 
larger audience of future users than the sum of all users to date.  Why 
plan for no-growth?  And even among current users, as in this thread it 
seems most expect the default to use the OS'es current default, not 
something leftover from the '90s.


Am I missing something?

LC has a very strong and favorable history of maintaining backward 
compatibility, far beyond anything I've seen with any other language.


I wonder sometimes if we take it too far, if maybe the rest of the world 
isn't wrong in sometimes allowing for the inevitable changes that take 
place in OSes.


From time to time LC does deprecate and change things, and sometimes 
that means a little extra work for folks moving to a newer engine.  But 
given how rarely this happens, I don't think folks would mind another 
rare moment of change, esp. one that seems far more an improvement for 
most devs than a problem.


--
 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: Times ARE changing

[Richard Gaskin via use-livecode]

Richmond wrote:
> If some of these types who go on endlessly about anything that might
> be vaguely construed as 'racist' were capable of slightly more subtle
> thought they might examine intentions: after all if we all judged
> people on what they looked like most of us would be out of a job and
> starving.

There is also the problem of linguistic false cognates. Similar words 
from different regions often have very different etymologies.


While the stories of the old British Empire can be charming (I love the 
two hard-bound volumes of Kipling my father gave me), the Indian tale is 
unrelated to both the origins of the American word "sambo" and its 
colloquial use.


On this continent, much of our language is influenced by the Spanish who 
were among the first Europeans to explore and settle most the Americas.


From Wikipedia:

   The word "sambo" came into the English language from the Latin
   American Spanish word zambo, the Spanish word in Latin America
   for a person of mixed African and Native American descent.[3]
   This in turn may have come from one of three African language
   sources. Webster's Third International Dictionary holds that
   it may have come from the Kongo word nzambu ("monkey") — the
   z of (Latin American) Spanish being pronounced here like the
   English s.

Complicating matters further is the difference between etymology and 
popular usage, as Ms Gay has reminded us with good humor over the years. :)


English-speaking people in the US didn't use the word until after the 
American Civil War, popularized mostly by the losing side of that 
conflict as a derogatory term.


Though the war was long ago, the legacy is evident. We needn't go any 
further on that here in this programmer's list.


It is indeed unfortunate that those who used the word most commonly in 
the States have cast an unfortunate pallor on a tale from the other side 
of the world, and that Samuel Battistone and Newell Bohnett found 
themselves in an awkward spot with their restaurants well known for 
excellent pancake breakfasts.


Indeed, the Santa Barbara restaurant is still family-owned, and the 
current manager Chad Stevens has expressed a hopeful note about the name 
change that goes into effect this Friday:


"With the changing world and circumstances, the name isn’t just about 
what it means to us, but the meaning it holds for others. At this point, 
our family has looked into our hearts and realize that we must be 
sensitive when others whom we respect make a strong appeal. So today we 
stand in solidarity with those seeking change and doing our part."


Maybe best of all, the new temporary name they'll be using while the 
family decides on a permanent one is: "☮&LOVE"


https://www.noozhawk.com/article/bizhawk_sambos_santa_barbara_to_change_name_20200604

By any name, the restaurant at 216 W. Cabrillo Blvd in Santa Barbara is 
well worth making a point of visiting whenever you're passing through 
that part of California's coast.  The pancakes are truly awesome.



This is quite off-topic, and I hope this momentary indulgence in 
etymology and pancakes doesn't stray too close to cheese.


Back to our regularly-scheduled LiveCode discussion, where I'll post a 
question about the Browser widget next...


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

Browser Widget on Linux: how can it become possible to use?

[Richard Gaskin via use-livecode]

The Browser widget doesn't work on Linux, and hasn't for a good many years.

Possibly related, I recently discovered that the OAuth authentication 
window so completely hangs LiveCode that a force-reboot is required 
(yes, bug report forthcoming, when I have time and temperament for that 
sort of uniquely-frustrating recipe-finding).


I have a vague memory that someone in our community had found some sort 
of workaround for changing the browser config so that it's possible to 
use LiveCode's Browser widget on Linux.


If I'm remembering that correctly, what is that workaround?

And for the longer term, though Linux runs most of the modern world's 
infrastructure I respect that they've ceded the desktop to Microsoft. 
Accordingly, when it comes to desktop platforms I respect that Windows 
deserves the lion's share of LC Ltd's time an attention.


But as the LiveCode Linux engine falls ever farther out of parity from 
other platforms, unless we're about to declare the LC Linux engine 
abandoned maybe we could bring some of that functionality back. The 
Browser might be a good place to start.


What is needed to make the Browser widget work in LC's Linux engine?

--
 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: Browser Widget on Linux: how can it become possible to use?

[Richard Gaskin via use-livecode]

Mark Wieder wrote:

On 6/7/20 1:17 AM, Richard Gaskin via use-livecode wrote:


What is needed to make the Browser widget work in LC's Linux engine?


http://forums.livecode.com/viewtopic.php?f=4&t=33805&p=189397&hilit=CEF#p189397


Sounds like the Browser widget is completely DOA in LC for Linux.

I hope I misread that.

--
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: Linux OAuth2 (was Browser Widget on Linux: how can it become possible to use?)

[Richard Gaskin via use-livecode]

Brian Milby wrote:


I think it should be relatively easy to fix the OAuth2 library such that it
works on Linux.  Currently it does use the browser widget for a better user
experience, but it should be able to launch the URL and use the system's
default browser.  Is there any interest in a PR for that type of fix for
this issue (at least until the browser widget can be addressed).


Absolutely. Thank you. I owe you a beer.


Also, I ran into a bug in the library this week where the auth code that
was returned included something that was actually URL encoded.  The
library then encoded it again which made things not work.  I actually found
the bug report which provided the solution to the problem.  You can see the
PR here:  https://github.com/livecode/livecode/pull/7381


Good work - thank you.


I don't mean to press my luck, but do you have any insight into why the 
Browser widget has been broken on Linux for the last few years? Or more 
specifically, what it might take to fix it?


Mark Wieder posted a link to a discussion on it, and while it did 
describe that the problem is non-trivial I have no idea if that means 
the Browser widget is abandoned in LC on Linux forever, or what it would 
take to address it.

http://forums.livecode.com/viewtopic.php?f=4&t=33805&p=189397&hilit=CEF#p189397


--
 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: Chromebook apps?

[Richard Gaskin via use-livecode]

William Prothero wrote:

> Probably HTML5 would be better, ultimately. But, I look at the HTML5
> postings, limitations, and quirks and it would most likely require me
> to become an expert in javascript and various server technologies that
> put me over the interest level that would be required.

If your app doesn't depend on server tech beyond downloading, a web app 
wouldn't either.


That said, I hear you on this:

> I’m fine with programming in livecode, but I don’t think the payoff
> for me to get into HTML5 is worth what I would get out of it. My
> programming is a combination of personal apps that I can use (like
> managing my 6 water meters and fruit tree drip system) and updating a
> plate tectonics app that students at UCSB use. My two sons are both
> 5’th grade teachers, one of whom uses chromebooks in his school, so
> collaborating with him on a nice app for his students is attractive,
> but only so far.

Writing in HTML/CSS/JavaScript is a world apart from LiveCode.  When the 
business opportunity merits it, it can be rewarding (oh the joys of 
never needing to genuflect at an OS vendor's app store, or give up a 
third of your revenue for the privilege of their control).


And because the nature of the browser is so radically different from 
native app development, I agree that attempting to port LC stacks to the 
web via the Emscripten option is pretty much a non-starter for most 
things people have ever made in LC.


I haven't yet deployed to a Chromebook so I have nothing to offer there 
with regard to LC compatibility. But with the core of Android well 
represented in ChromeOS, I would hope it's no more difficult than 
deploying to a tablet.  Please keep us posted with what you learn.


--
 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: Chromebook apps?

[Richard Gaskin via use-livecode]

John McKenzie wrote:


 Could you not just deploy a Linux desktop Livecode app to a
Chromebook? ChromeOS is a Linux distribution, if admittedly a stripped
down one, after all.


Alas, while ChromeOS is based on the Linux kernel, everything above the 
kernel is different (desktop manager, compositor, UI inputs, etc.).


And of course the current LC build for Linux is compiled for x86 
processors.  Since Frazier left we haven't seen any further development 
of an ARM-based compile of the LC Linux engine.


--
 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: Chromebook apps?

[Richard Gaskin via use-livecode]

William de Smet wrote:

I am a longtime user of Chromebooks in education and most 'cheap'
Chromebooks' come with only 4 GB RAM.
The Chrome browser itself uses a lot of RAM already and my experience with
Android apps on Chromebooks is that they are slow (lack of available RAM)
or sometimes not fully functional/compatible.


Ouch.

Thanks for that info, William. It's disappointing, but I'd much rather 
be disappointed by real constraints than invest in deployment plans that 
can't come to fruition.


--
 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 the heck? Writing and reading ios files??

[Richard Gaskin via use-livecode]

Ralph DiMola wrote:

> I did not know that. I thought all DNS was case insensitive not just
> the TLD. I never seen it to the contrary.
>
> The Unicode thing is scary though. It validates my surfing habits. I
> never use email links. If I get an email from say my bank I always
> type the URL into a browser or a verified bookmark to check it out.

Good habit.

For extra protection this browser extension (Firefox, Chrome, Opera) 
will warn and block when you attempt to visit a Unicode domain:


https://aykutcevik.com/blog/idn-safe-now-available-for-nearly-all-browsers/

--
 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 many objects (IDs) can be generated by script?

[Richard Gaskin via use-livecode]

Heriberto Torrado wrote:

> I read this thread, but it's old and it is not very clear to me.
>
> http://forums.livecode.com/viewtopic.php?t=22112
>
> I have the same problem than "Havanna".
>
> About six years ago I developed a Livecode desktop app for my company.
> Several employees open and close the app several times a day.
> Many fields are created at runtime.
>
> The current IDs are in the 250.000
>
> Is there a limit?
> Can we have a problem on the next years?
> Did it changed with Livecode 64bits versions?

My understanding is that the 64-bit versions of LC are compatible with 
64-bit OSes, but internal addressing is still 32-bit.


So AFAIK my comment from the thread you linked to still applies:

   IDs are 32-bit unsigned integers, so the range of possible values
   goes up to about 4 billion.

   If you never manually set IDs, since the engine begins with ID 101
   and increments within a stack from there with each object created,
   for all practical purposes over the life cycle of an app there's
   little risk of running out of IDs.

   If you're curious about what happens when you exceed the range of
   possible values, you can set a control's ID to the highest value
   allowed (UINT4, or 4294967295), and then create some new controls.
   Last time I did that (several versions ago) I found nothing amiss
   during the current session, but after saving the stack I was unable
   to open it again.

   As long as you work with ID ranges well below the maximum, you should
   have no problem for many years even with the DataGrid or other
   controls that create large numbers of objects dynamically. Given
   practical memory limits, ID range could only be a problem if you go
   out of your way to set IDs to unnecessarily large numbers.

   If by chance you happen to have the first project in this community's
   history that actually runs out of IDs, the worse thing that would be
   needed would be to simply copy the controls to a new stack (could
   easily be automated), in which the ID numbers would be reset starting
   at 101.


--
 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 many objects (IDs) can be generated by script?

[Richard Gaskin via use-livecode]

Heriberto Torrado wrote:

> 4 Billions is a lot, but I think it could be possible to reach it
> using some kind of automation tool.  I'm thinking about a stock
> exchange app or something that uses many changes and/or math
> calculations and it is displayed on a real time on a created field
> at runtime.

If you're generating those objects on the fly in each session you don't 
need to save them.  And if you're not saving the stack it doesn't 
increment its nextID counter.


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

OFFLIST Re: Animation Engine: speed tips

[Richard Gaskin via use-livecode]

On the use-livecode list you wrote:
> Hey Alex,
>
> Public Domain it is. I’ve set it free couple. of years back, as I am
> essentially no longer writing code. :-) Still following LiveCodes
> progress with interest though.  :-)
>
> Cheers,
>
> Malte

If you're no coding, what are you up to these days?

--
 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: OFFLIST Re: Animation Engine: speed tips

[Richard Gaskin via use-livecode]

D'oh! My bad, I'd meant to not take up list space with this.

But we all love Malte, and maybe he won't mind taking a moment to let us 
know what he's working on lately.


--
 Richard Gaskin
 Fourth World Systems


Colin wrote:

We’re all curious!


On Jun 29, 2020, at 9:26 AM, Richard Gaskin via use-livecode  wrote:

On the use-livecode list you wrote:
> Hey Alex,
>
> Public Domain it is. I’ve set it free couple. of years back, as I am
> essentially no longer writing code. :-) Still following LiveCodes
> progress with interest though.  :-)
>
> Cheers,
>
> Malte

If you're no coding, what are you up to these days?



___
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

OAuth2 on Win10: not returning to my app

[Richard Gaskin via use-livecode]

I've been working with the Oauth2 lib included with v9 (superhandy, 
team, thanks!), and I've run into a snag:


When I call it, the browser widgets opens and goes to the authentication 
provider (in this case Office 365), and authentication seems to work well.


However, at that point I'd expect the browser widget's window to close 
and "it" would contain the approved auth scope info.


Instead what I'm seeing is the browser widget window remains open, and 
it redirects into my Office 365 account.  I can close the window 
manually with the "Cancel" button, but then "it" in my calling script 
contains "Cancel", no auth info.


Have any of you successfully used LC's OAuth2 lib to log into MS Office 
365 or other MS product that uses OAuth?


If so, what did you use for the redirect URL?  Or is there something 
else I should be considering?


TIA -

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