LiveCode Forums.

This seems exciting. But what can be done with a widget written is LCS that cannot be done in LCS itself?

In other words, I understand that both speed and access to low level functionality requires working "under" the layer that LCS lives in. So is there a different compile protocol that is available to a widget, even if developed in LCS? Does "attaching" a widget per se in and of itself live in that more basic level?

Craig

This seems exciting.

What does?

This message is floating around, disconnected from whatever it is supposed to be a response to
so that foolish types like me don't understand it or what it refers to.

@Richmond
Look here: https://livecode.com/progress-update-on ... invention/

@Craig
I have no idea!

OK: I looked.

Life would have been easier with the link in the OP's post.

Err, Macros by another name?

richmond62 wrote: ↑

Fri Oct 07, 2022 8:25 pm

Err, Macros by another name?

Not how I read it - not even remotely.
What the post implies is that you can create a fully encapsulated widget using LCS instead of LCB.
It’s is a Big Deal…

stam wrote: ↑

Fri Oct 07, 2022 9:48 pm

What the post implies is that you can create a fully encapsulated widget using LCS instead of LCB.

Back in the days before LCB, before DataGrid was added to the package, back when Ben Beaumont was Product Manager, that was the plan for custom controls.

Ever wonder where the "before" and "after" handler declarations came from? It was all part of that early groundwork.

The origins of LCB were never quite clear to me. Foreign function interfaces were a built-in part of Toolbook's xTalk implementation way back in the '90s, a good model for inspiration. And custom controls were already being made as groups, so finding a way to package them for convenient sharing seemed a logical next step.

Good to see they're returning to this approach. LiveCode Script is a very capable language. It'll be great if they add LCB's indexed arrays to LCS, but even as-is it's quite capable.

And most importantly for an extensibility initiative where success is measured by deployed add-ons, LiveCode Script is the one language every LiveCode scripter knows.

Richmond.

You need to keep up with the news. And yes, I suppose I should have provided some context.

I was so excited when I got the announcement that I just whipped off my initial post. It may be possible make plug-ins and libraries that work either faster of have the ability to access low-level API's or other gadgetry.

You of all people should be excited, since you are always trying to work out your odd font issues

Of course, truth be told, I am excited because maybe I won't have to learn LCB. Lazy, you see.

Craig

dunbarx wrote: ↑

Sat Oct 08, 2022 3:28 am

...and libraries that work either faster of have the ability to access low-level API's...

They're adding foreign function interface to LiveCode Script?

I had thought the new initiative was just for custom controls, effectively a packager for behavior-driven groups. I would be very glad to have misunderstood that.

Richard..

I only speculate. Maybe wishful thunking?

Craig

Well, I am semi-excited as it seems marvellous.

I am also semi-unexcited as I cannot afford a licence.

Richard.

They're adding foreign function interface to LiveCode Script?

What is that?

Anyway, how would you quickly describe the advantages of widgets? I thought the whole point was that they could reach into places LCS could not, the LCS world being limited to the fixed scope of the language as delineated in the dictionary.

Craig

dunbarx wrote: ↑

Sat Oct 08, 2022 6:49 pm

Anyway, how would you quickly describe the advantages of widgets? I thought the whole point was that they could reach into places LCS could not...

LCB offers two salient features: the ability to make custom controls that are more easily shareable than what we could make with groups, and a foreign function interface (FFI) for accessing OS routines and other binary APIs.

Those can be used together, but not necessarily. For example, I can't imagine the Clock widget needs low-level access to the OS, whereas I believe the button widgets use OS calls for rendering native appearance.

LC Script offers a wide range of great primitives, like fields, buttons, scrollbars, images, graphics, etc., which we often use to make custom controls. The DataGrid is a famous example of a complex one, but many of us use grouped controls driven by a central behavior script for all sorts of things.

One of the best things about using LC Script for custom controls is the field object. It's extremely powerful, and I don't believe LCB offers anything like it (I'm not sure LCB offers an editable text object at all; earlier versions didn't).

The only downside to using grouped controls to make a custom control is sharing it across projects. You'll need some way for the behavior script to come along for the ride, and an easy way to instantiate the custom control.

Within my own projects a simple copy command instantiates easily enough, and since I work in small teams it's easy to remind others using it to also include the behavior that drives it.

But for sharing with other LC devs we want to aim higher, to make them much easier to install and use.

And that's where the packager comes in. If the various parts needed for sharing a custom control can be put into a single file, and the packager system understands the layout of the file and can put things where they need to go, sharing becomes much easier. And with the dynamic spec-driven layout of the Inspector, one can even have custom settings there for the properties unique to the new control type.

What's not clear to me is the other part, FFI. There are several challenges with adding that to LiveCode Script, much of it being the need for specific data types, problematic in a typeless scripting language.

Toolbook solved it by having optional type declarations that were very flexible, sufficiently that one could declare the type and that they were calling foreign functions, and the Toolbook engine took care of the rest. I used it on a project once and it was pretty cool, allowing be to use Win APIs to bind one window as an overlay region in another.

A widgets packager for LC Script would be pretty awesome in itself.

But if they're also in a position to extend LC Script to be able to call foreign functions, that would be mind-blowingly cool.

If I understand correctly, which is not at all probable, a widget is a custom control that can be manipulated with setting of properties against "the control" without the user needing to manage the settings of the individual control elements making up the widget, and, I believe, being able to view and set properties in the IDE's Property Inspector as if it was a native control.

To date, the creation of a widget has been solely within the scope of LCB. The possibility of creating a widget may now become extended to LCS.

The functionality of a widget depends on the language and syntax employed by its creator. LCB has calls to lower level OS functions and APIs available (Foreign Function Interfaces) which LCS does not.

@Craig, as I interpret this, I don't believe that is what you are understanding. I'd like to be wrong.


[Edit] what Richard said [/Edit]

Thank you, Richard, for explaining how a widget is "packaged" in a "complete" form that does not require links to other parts of the program, such as a behavior script. If I understand this, anything built wholly in LCS has to conform to the limits, needs and exigencies of the IDE. But a widget does not.

Do I have this right at all?

So then what is the story I hear so much about of being able to access these lower level API's? Can you give an example? It can be made up just to explain the concept.

Craig

dunbarx wrote: ↑

Sat Oct 08, 2022 9:23 pm

So then what is the story I hear so much about of being able to access these lower level API's? Can you give an example?

FourthWorld wrote: ↑

Sat Oct 08, 2022 7:48 pm

LCB offers two salient features: the ability to make custom controls that are more easily shareable than what we could make with groups, and a foreign function interface (FFI) for accessing OS routines and other binary APIs.

Those can be used together, but not necessarily. For example, I can't imagine the Clock widget needs low-level access to the OS, whereas I believe the button widgets use OS calls for rendering native appearance.
...
What's not clear to me is the other part, FFI. There are several challenges with adding that to LiveCode Script, much of it being the need for specific data types, problematic in a typeless scripting language.

Toolbook solved it by having optional type declarations that were very flexible, sufficiently that one could declare the type and that they were calling foreign functions, and the Toolbook engine took care of the rest. I used it on a project once and it was pretty cool, allowing be to use Win APIs to bind one window as an overlay region in another.