OpenXTalk Forums

Christmas time is over, full of food and with my new friend, the Mandalorian Child (my better half really made me happy with it), I analyzed the Extension Builder.
And actually I never wanted to give a wall of text here, but in this case I can't help it.

After taking a closer look at it, I wonder if it was the right decision to choose this element to revise and adapt to oXT.
It's unbelievable what we have tried to create extensions with all these years and it doesn't surprise me at all that almost everyone who has dealt with widgets/extensions and the LCB syntax have thrown the towel sooner or later.

My first impression: It is and remains simply an unfinished product.
I think that we could never fully exploit the possibilities of the extensions because it was simply not finished.
As Marvin said in the Hitchhikers Guide: "I talk to the Engines... they don`t like me". So now I have a project name for the whole thing - "Marvin".
The deeper I get into it, the more I am glad that I decided not to buy a license of the latest LC version.
If the builder looks like this, how does the rest of the libraries and tools look like?

To understand the whole thing you have to look at the whole construct of the Extension Builder.

Let's start with the "GUI", or to stay in slang, the stack.

On the top right we find in the header the points "Edit" to edit the LCB-file in an external(!) editor, to open a LCB-file and the Preferences-cog. In the Preferences you should see the installed and active Extensions... which, as expected, is not the case...

The name of the extension is packed into a label of an opaque button, which overlays another button, in which extensions in the development environment of the creator are referenced, which are not accessible for us... for whatever reason...

The Icons. Let's be honest: who makes the effort to create icons in PNG format, when you can display them as SVG icons via the LCB file? And if someone uses this format, why didn't the creator hide the ugly frames of the IMAGE elements?
By the way, I generally recommend to use only SVG icons and to store them as path in the LCB.

The field "Resources". Have you wondered why nothing is ever displayed there? It's quite easy to explain. This is a display field for the content of the directory "resources" which is never created. Unless you create it manually.
By the way, originally the PNG icons of the extension should be there, but they have to be put into the folder "support", so that the builder or later the IDE can access them at all. This field is in my eyes therefore superfluous and serves finally only information what this directory contains... if it was created and contains something...

Defaultscript... also such a field where nothing is displayed. This is actually not true. Something is displayed. As soon as you press the button "Edit" below this field, the folder "Support" is created and a "defaultscript.livecodescript" is stored in it. And only if you write something in this defaultscript and save it, the content of the script is shown in the field "defaultscript". In a very small field... about 200*52 px... under Windows with Helvetica with 12px font size...
Do you already have a defaultscript in the directory "Support" and it is still not displayed? Then press the edit button once, the script will open in the LC-Editor and will be shown in the builder field.
And you can't edit in the small field either. A simple "defaulscript available" or a separate tab in the header would have been sufficient at this point.

The point API: if you open a LCB in the builder it will always say YES... the API is created automatically. Which is a good thing.

But what concerns the User Guide. This point should inform you if there is a userguide.md in the LCB directory.
In the time I have been working with widgets and the builder, i have never seen a *.MD file.
Here the question to the MAC and Linux users: Do you need the format for your OS? At least on Windows I don't need it, because the documtation of the command structure is loaded into the dictionary with the API.
What I would rather see than *.MD would be a license-information-file. so a license.md

What I am excited about is the "Console" field.
This is ideal for debugging and for me, besides the LCE packaging, the only reason why the Builder can call itself Builder and not Extension-Tester. Here I have nothing to complain about.

I don't talk about the footer now, because it contains the essential functions that you really need for testing, packaging and installing the widget / extension.
This could have been solved more nicely, but that would be only a design question again...

As for the scripting of it all. There are only two positions with three lines of code each where the stack itself is scripted. The EDIT button for the defaultscript and the retrieval of the Extension-Name in the opaque button....

Everything else is described in the separate behavior script.
This takes care of the positioning of the objects in the stack and some functions of the extension builder. But only a few, because the Behaviorscript accesses a Library-Script to get more functions, which in turn accesses another library script to pass its functions to the stack behavior script so that the stack can be used. Apart from that, there are functions stored in the libraries for the Extension Builder that are not used.

The whole thing is so nested that it is not nice anymore. If you make a careless change in the wrong place, the whole construct does not work, or if you are unlucky the whole IDE does not work anymore.

At the moment I also ask myself if it makes sense to rework the Extension Builder or if it is better to rewrite it completely, including parts of the library scripts. Also whether one should not throw it from the IDE and offer as an optional PlugIn, should be discussed.

Have a nice time
Andreas

FYI, the main Extension Builder script library is actually a Script Extenstion (Extensions libraries do not have to be LCB, they can be LCS), has inline documentation for itself, so if you load that extension-utils.livecodescript file into the Extension Builder. the Documentation Parser scripts (another script library) will build an API.lcdoc file from it. I know this because I've already done it and it is included in the OXT revised syntax Dictionary, along with some other Documentation that wasn't previously included.

I agree, the whole thing is spaghetti, piled on top of other spaghetti. I also understand the sentiment, the more I dig into it the more I think I'll just keep waiting to see where they go with it before I sign up for their development environment as a monthly subscription service. I'd love for all of it to get simplified if possible. However, as you've seen, you have to be very careful making any edits as to those files as there are a lot things that are interconnected in the IDE. And it is not just the Extension Builder. For example I've made edits to the Dictionary that broke the left pane in the Script Editor where it shows available syntax for whatever type of control you're editing the script of.

astu wrote: ↑Tue Dec 28, 2021 7:00 am The Icons. Let's be honest: who makes the effort to create icons in PNG format, when you can display them as SVG icons via the LCB file? And if someone uses this format, why didn't the creator hide the ugly frames of the IMAGE elements?
By the way, I generally recommend to use only SVG icons and to store them as path in the LCB.

I'd certainly prefer, in an age where a screen may not be 72 or 96 dpi, but 144 or 288 dpi, to use scalable vector graphics wherever possible. Part of my interest in rebuilding the tools palette is due to the fact that the "classic controls" still use bitmap graphics and don't look great when they're enlarged or reduced.

Defaultscript... also such a field where nothing is displayed. This is actually not true. Something is displayed. As soon as you press the button "Edit" below this field, the folder "Support" is created and a "defaultscript.livecodescript" is stored in it. And only if you write something in this defaultscript and save it, the content of the script is shown in the field "defaultscript". In a very small field... about 200*52 px... under Windows with Helvetica with 12px font size...
Do you already have a defaultscript in the directory "Support" and it is still not displayed? Then press the edit button once, the script will open in the LC-Editor and will be shown in the builder field.
And you can't edit in the small field either. A simple "defaulscript available" or a separate tab in the header would have been sufficient at this point.

This has been broken for a long time. I had planned to work on some of these annoyances eventually.
BTW, I'm the person that suggested that there could/should be "default scripts" for extensions to begin with!

The point API: if you open a LCB in the builder it will always say YES... the API is created automatically. Which is a good thing.

Does it always say YES? I hadn't noticed. It should only say YES if the extension has inline documentation or a seperate API.lcdoc file.

But what concerns the User Guide. This point should inform you if there is a userguide.md in the LCB directory.
In the time I have been working with widgets and the builder, i have never seen a *.MD file.

Take a look at "com.livecode.widget.clock" included with the IDE, it has a guide in com.livecode.widget.clock/docs/guide/guide.md, this gets added to the Dictionary's Guides tab when the that gets built. I think Guides are needed for certain extensions where the usage might be very complicated or just where 'how-to-use' is not so obvious. They're probably more useful for Builder libraries than they are for Builder widgets.
Adding an option for a license.md file as well seems like a fine idea to me.
Really I'd like better documentation for ALL of add-in files options and the metadata available for use in Extension Building. As well as ones that are forbidden or too broken to use, such as certain properties that can't be "mirrored" by a Builder Extension like textSize (the solution is to rename your property to something different from the IDE's property name, so rename 'textSize' to 'labelTextSize').

OpenXTalkPaul wrote: ↑Wed Dec 29, 2021 11:00 pm I'd certainly prefer, in an age where a screen may not be 72 or 96 dpi, but 144 or 288 dpi, to use scalable vector graphics wherever possible. Part of my interest in rebuilding the tools palette is due to the fact that the "classic controls" still use bitmap graphics and don't look great when they're enlarged or reduced.

For the widget display in the Tools palette or in the Extension Manager, SVG Icon is perfectly sufficient. There the bitmaps icons would not be needed anymore. But I will keep the possibility. And a note in the documentation that it is possible to continue to use bitmaps....

This has been broken for a long time. I had planned to work on some of these annoyances eventually.
BTW, I'm the person that suggested that there could/should be "default scripts" for extensions to begin with!

I plan a simple display that a defaultscript is available and callable with the editor. An extra field which shows me the content of the script is not necessary. DefaultScript will remain, but not as a text field.

Does it always say YES? I hadn't noticed. It should only say YES if the extension has inline documentation or a seperate API.lcdoc file.

Yep. is always displayed if a file api.lcdoc exists in the folder. No matter what is in it. The file is generated directly as soon as the LCB is loaded for the first time.

Take a look at "com.livecode.widget.clock" included with the IDE, it has a guide in com.livecode.widget.clock/docs/guide/guide.md, this gets added to the Dictionary's Guides tab when the that gets built. I think Guides are needed for certain extensions where the usage might be very complicated or just where 'how-to-use' is not so obvious. They're probably more useful for Builder libraries than they are for Builder widgets.
Adding an option for a license.md file as well seems like a fine idea to me.

So I keep the guide.md. Noted.
as for the Licence.md... what should be the standard? GNU? MIT?
I added it to my roadmap under the item "for later".

Really I'd like better documentation for ALL of add-in files options and the metadata available for use in Extension Building. As well as ones that are forbidden or too broken to use, such as certain properties that can't be "mirrored" by a Builder Extension like textSize (the solution is to rename your property to something different from the IDE's property name, so rename 'textSize' to 'labelTextSize').

I am writing the documentation for the ExBuilder in parallel.
Since something can change at any time.

As for the documentation of the extensions or the LCB language, this is a mammoth task, since there is only a rudimentary documentation and not all functions and settings are described.

First of all, the builder itself has to work properly.

Green: in work
Yellow: partly in work
Red: No touch @ Moment

Snapshot:

Awesome! Can't wait to try what you come up with!

"Resources" I believe (but I could be wrong, I've yet to ever used it myself) can be used for any resource files (sounds, images, fonts, text, etc.) that an extension requires to operate and would get packaged up with the extension.

As for default license.md, that should probably be GPLv3.
Anything added to OXT MUST have a GPLv3 compatible license.