OpenXTalk Forums

I have been working with the ExtensionBuilder and the ExtensionManager from Livecode to make possible adaptations for OpenXTalk.

For the Livecode ExtensionBuilder we edit widgets and libraries in LCB format. To be able to use or "install" it in Livecode ExtensionManager it must be "converted" into the LCE format.

Now I have taken a closer look at the LCE format. Thereby I noticed that the *.LCE is nothing else than a simple archive like *.ZIP, *.TAR or *.RAR.

If you have a *.LCE file, then simply extract it with an archive program and you can simply edit this widget or library.

Small note at the edge:
- The LCE file type is primarily associated with LockCrypt.
- LCE is also a ZX Spectrum 128 Laced Screen Bitmap

astu wrote: ↑Tue Dec 07, 2021 10:15 am I have been working with the ExtensionBuilder and the ExtensionManager from Livecode to make possible adaptations for OpenXTalk.

For the Livecode ExtensionBuilder we edit widgets and libraries in LCB format. To be able to use or "install" it in Livecode ExtensionManager it must be "converted" into the LCE format.

Now I have taken a closer look at the LCE format. Thereby I noticed that the *.LCE is nothing else than a simple archive like *.ZIP, *.TAR or *.RAR.

If you have a *.LCE file, then simply extract it with an archive program and you can simply edit this widget or library.

Small note at the edge:
- The LCE file type is primarily associated with LockCrypt.
- LCE is also a ZX Spectrum 128 Laced Screen Bitmap

Yes I know .LCE is a ZIP (that may or may not include the LCB source code) usually with some metadata type files, API.lcdoc, .__defaultscript, icons, example stack "samples" folder, etc. I guess it's a lot like the idea for basically a package manager sort of thing. If you look at the Extension Manager window, there's FIVE tabs, Widgets, Libraries, Sample Stacks, Snippets, and Store ...it's basically a framework for an IDE package manager already, just needs to be wired up for that purpose.

It's REALLLY hard to find a Dot.3 extension that HASN'T already been used by something in the past 4+ decades of computing.

I just wanted to document it for those who want to understand the structural setup.

The problem I always come across is that hardly anything is documented so cleanly that you can see what is communicated or linked to which component.

To me it looks like they have tried for years to simply upgrade an ancient system with new components without updating or adapting the old things. Some constructs look like an old ZUSE relay computer that you want to equip with an Intel processor, to exaggerate a bit.

astu wrote: ↑Tue Dec 07, 2021 4:09 pm I just wanted to document it for those who want to understand the structural setup.

I'm all for documenting as much of all of it as possible.

I'd like to make up a nice widget shell, with ALL of the standard "classic" controls properties and messages that can be mirrored in a Builder Widget (mouseDown/Up, mouseMove, visible, foregroundColor, textColor, ink effects, etc.) already setup with the appropriate metadata. That would sort of serve as documentation and provide pre-filled-out inline lcdocs as a template for building your own widgets.

There is a definitely a need for some better documentation for things like the metadata used for various things in Builder.

LiveCode has implemented a way to build widgets (something I would read as 'new objects') inwith LiveCode itself; probably because LCB is undocumented and a half-cock job.

All I have ever felt is that LCB serves to backup critics of xTalk who state that xTalk is not a 'proper' programming language. There should be no need for xTalk to need another programming language like a set of leg callipers for a polio victim.

If the ability to build wdiegets with xTalk were implremented inwith OXT that could even mean that an 'OXT Educational' could do away with LCB add-ons altogether.

I remember in about 1972 getting cheesed-off with the idea of LEGO Technik: and, although my LEGO collection is now about 25 time the size it was in 1972, I have NEVER besmirched it with either 'Technik' or any of the other 'perversions'.

richmond62 wrote: ↑Wed Dec 06, 2023 8:00 am LiveCode has implemented a way to build widgets (something I would read as 'new objects') inwith LiveCode itself; probably because LCB is undocumented and a half-cock job.
-------
If the ability to build wdiegets with xTalk were implremented inwith OXT that could even mean that an 'OXT Educational' could do away with LCB add-ons altogether.

I really don't understand their touting of, as a new latest feature, the ability to build 'Widgets' with script / without LCB. You could already do that as a 'grouped control', which is exactly the way I built my first "Piano Widget" before rebuilding it in LCB. And isn't the DataGrid, or Bernd's Mod Table Field, not basically the same sort of thing as as a 'Widget'?

You absolutely could remove ALL of the LCB stuff and it's bitcode module compiler, in a trimmed down version of the iDE, in fact you could pull the UI stacks for your widget-less IDE from LC Community v.7.x and use those.

richmond62 wrote: ↑Wed Dec 06, 2023 8:00 am All I have ever felt is that LCB serves to backup critics of xTalk who state that xTalk is not a 'proper' programming language. There should be no need for xTalk to need another programming language like a set of leg callipers for a polio victim.

I think they had loftier goals when they decided to develop Extension Builder than just checking off some 'proper programming language' checkbox, at least they said they did and I took them at their word.

Anyway I disagree that there's was no need for another language. In the end they all compile down to assembly-to-machine code in order to be executed by the hardware, but different programming languages have different design goals.

Extension Builder is designed to extend the engine, its UI toolkit, and extend its own language. An early stated goal was to build the entire Engine and IDE in LCB, which if they had done that, we wouldn't have to worry about updating and compiling for new architectures some rather old C++ code today. Extension Builder FAR more xTalk-Scripter-friendly than C++.

Most importantly, YES, it does do the closer-to-bare-metal proper-programming language things far better than you can from most scripting languages. Not just xTalk scripting, I mean a lot of libraries used with Lua or Python aren't actually written in Lua or Python. Python and Lua (just for popular examples, and these even have the required static primitive types like a 'proper' programming language) use FFI to access the symbols from libraries written in other languages. That USB/Bluthooth HIDAPI library that built an Extension module around, uses the exact same library, written in C, that PyGame uses.

Extending the possibilities with XCMD/XCFN, Xtras, XTernals, etc. IS an xTalk tradition, in fact HyperCard probably invented the idea of extending software with "plug-ins". The IDE already uses a few 'Externals', like the Database stuff, which you need a lower level language and the 'glue code' to build. Extension Builder however, is very much in the tradition of WindowScript and CompileIt! from Heizer Software, which allowed you to build 'externals' XCMD/XFCN modules, as well as code Resources, WDEF (Window definitions), DLOG (Dialogs), Palette Windows, etc. for HyperCard, all without having to drop down to writing them in Apple Pascal, Think-C ( later you could use FutureBASIC too). CompileIt would transpile/compile an extended variation of HyperTalk Script, giving scripters access to the Macintosh ROM's Toolbox. It's this the sort of user-centric extensibility that is what made HyperCard THE insanely great software in the early days of mac, and it's at least a part of why I'm still here obsessing over xTalk. Honestly, If I couldn't do the fun stuff like CoreMIDI that Extension Builder allows for, I probably would have reluctantly moved on to Swift or whatever else by now.

I think the biggest mistakes with Extension Builder were not working on it more, not documenting it better, and not encouraging uptake by their user base more. I like it still.

richmond62 wrote: ↑Wed Dec 06, 2023 8:00 am I remember in about 1972 getting cheesed-off with the idea of LEGO Technik: and, although my LEGO collection is now about 25 time the size it was in 1972, I have NEVER besmirched it with either 'Technik' or any of the other 'perversions'.

I don't know what any of that means, but my youngest son loves the LEGO stuff, has built tons of sets. Lego has their own programming language too.

in fact you could pull the UI stacks for your widget-less IDE from LC Community v.7.x and use those.

MMMM . . . and the Unicode implementation? Didn't it come in with '8'?

I took them at their word.

Quite.

So did quite a lot of use, about various things: and now feel slightly stupid.

I don't know what any of that means, but my youngest son loves the LEGO stuff, has built tons of sets.

What it means is that my 2 sons and I have never made 'a set' [as in followed the bit of paper inside the box], but we have made things which our imaginations have come up with with what I might term 'Lego version 1' rather than 'Lego versions post 1980'.

I think the biggest mistakes with Extension Builder were not working on it more, not documenting it better, and not encouraging uptake by their user base more. I like it still.

That is a valid point . . . I have never attempted anything with LCB as I am still looking around for the "Idiot's Guide".

I really don't understand their touting of, as a new latest feature, the ability to build 'Widgets' with script / without LCB. You could already do that as a 'grouped control'

Possibly for the same reason as a 15 year old girl I teach was seriously 'miffed' when I told her that when I was 12, the dinner 'ladies' (who were 16), at a sink-hole prep school I attended for a year (went bust 4 years later) wore wedge heels.

I have a feeling that our friends "up north" are desperately looking around for new ideas to inspire the ever-decreasing clientele, and finding none (they, themselves getting increasingly long-in-the-tooth and lack-lustre) are repackaging the 1974 wedge heels as something "twenty-first century", and, sadly, fooling no-one.
- -
I think she really got worried when I pointed out that in 1968 the fashion was for topless dresses, and they were sure to 'pop up' (quite literally) in Bulgaria very soon.

different programming languages have different design goals.

Indeed, they do.

So, why invent LCB to change xTalk's design goal?

and not encouraging uptake by their user base more

How would you do that?

1. "Serious" programmers will use other programming languages to achieve other things which LiveCode cannot provide.

2. "Hobbiests" and "One Trick Ponies" (like myself) won't bother.

3. As you point out above, if I want a navigation bar I'll just group 4 or 5 faux buttons (images) and bung a border round them; and I'll be in Scotland 'Afore Ye', or Kev for that matter.

And there was a lot of bollo about "native" buttons; and as the buttons have never been 'native' in terms of adhering to MicroSoft's or Apple's dictatorial strictures anent Human (that means what B. Gates or S. Jobs like) Interface Guidelines, why should we get all excited when we can just magic a button to our own taste up in GIMP . . . ?
- -
AND that one was made entirely inwith OXT Lite from a rectangular graphic and a backGroundPattern, which for purposes of illustration was just left as it was: however, to preserve cross-platform (and cross machine) parity, it is possibly best to group the graphic (to preserve shadows and so on) and import a snashot of the group to use as a button.

richmond62 wrote: ↑Wed Dec 06, 2023 7:12 pm

in fact you could pull the UI stacks for your widget-less IDE from LC Community v.7.x and use those.

MMMM . . . and the Unicode implementation? Didn't it come in with '8'?

Full Unicode support was in v7, I'm not sure if successive versions made improvements to that support or not.
What I meant just moving the UI stacks (like revMenu, revTools, etc.) from 7 which had no LCB/widgets, but mixing it with / using the rest of it from v9.x. It might not work 100% as drop-in replacements though, but having already tried using the Binary Exe from v8 with the IDE files from v7 with success (although with limited testing), I think it would work. Certainly the Tools Palette would work fine, the 'classic' controls haven't changed in a long time.

richmond62 wrote: ↑Wed Dec 06, 2023 7:29 pm

different programming languages have different design goals.

Indeed, they do.

So, why invent LCB to change xTalk's design goal?

It wasn't a change to xTalk goals IMO, just as CompileIt! XCMD/XFCN, Xtras, Externals were'nt changes to xTalk.
I believe the goal of LCB was to make it easier for lots of community members to build add-ons (obviously that didn't work out), because in the past, with the exception of CompileIt!, a mere mortal, regular user needed to learn Pascal, C, C++, etc. ( I used FutureBASIC back in the day, which still exists and is freeware now) and also add the required special glue code (like in LC's Externals SDK) in order to extend xTalk the environment. LCB looks a lot more like xTalk than any of those and so IMO it's far more pleasing syntax to look at for people who love xTalk. Also, LCB came with its own xTalk-controlled (command-line) bytecode compiler and the script engine has a module loader, so no Xcode, VisualStudio, etc. are needed in order to build Extensions, unlike Externals. LCB can two-way communicate with the scripting engine so the 'Glue' is baked in. 'Extension' has everything needed to build right into the IDE. It's similar to building an External but MORE xTalk-like.

richmond62 wrote: ↑Wed Dec 06, 2023 8:02 pm

and not encouraging uptake by their user base more

How would you do that?

1. "Serious" programmers will use other programming languages to achieve other things which LiveCode cannot provide.

2. "Hobbiests" and "One Trick Ponies" (like myself) won't bother.

3. As you point out above, if I want a navigation bar I'll just group 4 or 5 faux buttons (images) and bung a border round them; and I'll be in Scotland 'Afore Ye', or Kev for that matter.

And there was a lot of bollo about "native" buttons; and as the buttons have never been 'native' in terms of adhering to MicroSoft's or Apple's dictatorial strictures anent Human (that means what B. Gates or S. Jobs like) Interface Guidelines, why should we get all excited when we can just magic a button to our own taste up in GIMP . . . ?
-
Screenshot 2023-12-06 at 22.04.01.png
-
AND that one was made entirely inwith OXT Lite from a rectangular graphic and a backGroundPattern, which for purposes of illustration was just left as it was: however, to preserve cross-platform (and cross machine) parity, it is possibly best to group the graphic (to preserve shadows and so on) and import a snashot of the group to use as a button.

I would do it with better documentation, much more Tutorials / YouTube Video lessons, walk throughs, hand-holding via forum, etc.

There is a significant learning curve, but once you're over that hump it gets much easier IMO. I've made a few handlers that help me debug, basic handlers that log type or properties of an Objective C object, so that helps a lot for macOS and iOS FFI specific building. Of course for FFI Extensions it helps to be familiar with Objective C, C, C++, Java, and JavaScript (depending on your target platform(s) ).

"1. "Serious" programmers will use other programming languages to achieve other things which LiveCode cannot provide."

Sure they could, but you don't need a 'serious' programmers if you make a language that is easy enough for "The Rest of Us" to do it ourselves, right?

"2. "Hobbiests" and "One Trick Ponies" (like myself) won't bother."

Well this hobbyist did, mostly because I've never like the nested curly brackets and other cryptic symbol syntax used in those other languages. I wanted to play with algorithmic music stuff in xTalk again and wanted to use a Playstation-style controller as an expressive musical instrument and that sort of thing. I don't much like PureData and Max MSP sort of thing that use the 'code block' 'no-code' sort of metaphor, nor their underlying languages (Pd is JavaSCript based).
Some of the stuff I've used LC for I totally could've created with Automator and AppleScript (which is very xTalk-like).

"3. As you point out above, if I want a navigation bar I'll just group 4 or 5 faux buttons (images) and bung a border round them; and I'll be in Scotland 'Afore Ye', or Kev for that matter."

You wouldn't need to build one if you could have one that is already built, downloaded directly from within the IDE, with all of it's logic built-in and custom properties already set up, with pre-filled 'default scripts' available to click-add that are specific to the custom object type, just waiting to drag-drop onto a card.
"I'll be in Scotland 'Afore Ye'" always reminds me of Marillion's eaarly-80s Margaret, they would perform at live shows.

And there was a lot of bollo about "native" buttons; and as the buttons have never been 'native' in terms of adhering to MicroSoft's or Apple's dictatorial strictures anent Human (that means what B. Gates or S. Jobs like) Interface Guidelines, why should we get all excited when we can just magic a button to our own taste up in GIMP . . . ?

Custom made buttons are fine, but it really depends on your design goals. Custom made buttons will look the same regardless of the underlying platform, HOWEVER, and they'll look the same regardless of the underlying platform, the advantage to native buttons is that when macOS or other vendor gets a new major version and totally changes the widow manager theme, your stacks would theoretically inherit the new look without any additional work from the stack's author.