How to get the properties defined in a Widget Extension

[OpenXTalkPaul]

Most of the time it would be some sort of string...

Most of the time... and what about when it's not a string?
It seems like this stuff is getting further and further away from the "programming for the rest of us". I'd defer to your knowledge on xTalk, however (don't get big headed ) but even you aren't 100% sure how this all works, so what chance do us mere mortals (or anyone else for that matter) have?

As I said you can find out what sort of value you're receiving by checking with script if a variable "is an Array".

I'm not 100% certain how the IDE currently does this because I haven't tried building a new Property Inspector so I haven't really looked yet (and I spent all of this morning typing in this thread about it instead), but I do know exactly where that data originates from (metadata tags in the extension source file or from the manifest.xml that gets generated from the source), so I could write a handler that parses that info directly if I needed to, but I know that the IDE already builds this cache for installed Widgets so why reinvent the wheel.

Again, if any "Standard properties" (the ones that ALL controls have, like "disabled", or "visible") are implemented by a Widget those do not need to have a bunch of extra meta data declarations because those would use the same exact editor that a "classic control" such as a button would use for those properties.

[OpenXTalkPaul]

Thing is, I could have used:
traversal.png
I can just run that in the messageBox to get (and set) the current value. How did I know that "traversalON" actually means "Focus with Keyboard"? Because on the inspector I can hover over it and the tooltip gives the name of the property. (As does my replacement property inspector). Without that, I would likely have been stuck.

I don't understand this, because you could've done the same thing with a widget too, you can even do that with props that are user_visible=false. Also widget properties can have a label metadata that shows as a tooltip for the property instead of its property name too.

For my Piano Widget I used the fact that you can have 'non-visible' properties to included several 'synonym' properties, which use the same handlers for their 'back-end' and set that and retrieve the same property only using a different name, allowing end-user to use whichever name for that property sits better in their minds (this was because I'm not an expert in music theory).

With the tree-view widget did you try putting its foldOver (or Whatever it was) property in the message box? I would think it would have put "true" or "false". The only widget that I know of that has any "WRITE-only" properties is my own Piano Widget.

[tperry2x]

I don't understand this, because you could've done the same thing with a widget too

I don't think I'm making myself clear, but that's my fault. Not yours.
At the moment, I have a inspector that can list these properties for me. Great, except it's the old inspector with all it's other problems.
So, I want to replace that. Now that's fine, but there's the problem. With not being able to read these properties in the 'new inspector', how will I know what properties and values to set?

Why not just get them off the old inspector? - That doesn't solve the problem. That way I'm only guessing at what values these keys could support. But this time, that won't work, because they could be anything.
That's why I can inspect a widget at the moment with the old inspector, but - won't be able to do that in the new inspector without knowing the mechanism of how. Then if I download a new widget, I won't know how to read the supported properties of each new key. Does that make sense?

With the tree-view widget did you try putting its foldOver (or Whatever it was) property from the message box? I would think it would have returned "true" or "false". The only widget I know of that has any "WRITE-only" properties is my own Piano Widget.

Foldstate returns nothing. No error, nothing on the message box. So, I assume this is a no-no, but HOW do I know in advance?

foldstate.png (6.35 KiB) Viewed 1231 times

ChatGPT 4 says:

Code: Select all

on mouseUp
    -- Assuming the widget's name is "YourWidgetName"
    put the properties of widget "YourWidgetName" into tProperties
    put tProperties into field "PropertiesField" -- Assuming the field's name is "PropertiesField"
end mouseUp

But this doesn't work as I changed "YourWidgetName" to the short form of the widget (error, not found), and the same result using the entire reverse identifier.

I then asked ChatGPT 4 how I'd find out the supported values for each each key of a widget. It came back with:

• Refer to the widget documentation from the widget author.

• Experiment by setting different values through the LiveCode IDE or script and observing the results.

Neither of which are workable, and is not what the current inspector is doing.

[OpenXTalkPaul]

Example:
clock.png
Here's a clock widget dragged in from the tools palette. What does "timezone" do? nothing... or is that broken?
What about if I want it to display an hour in advance, or 10 minutes in advance? Where are the settings for it? Yes, I can change colours but I can't do much else.

Yet, I could absolutely do all that with a group of classic controls and have pre-populated scripts when they were dragged off the tools palette to allow full user control. None of that would be a mystery. All someone has to do to 'get at' the code is edit the group.

Sure, you could re-build that as a group of classic controls and then create a loop script that updates it every one-second, and hopefully stays accurate while your scripts try to do other things without blocking it's updating.
But for one thing this clock example widget is already built, you can drag drop it and inspect its properties immediately. This IIRC was originally built as a simple demo. I'm guessing timezone property supposed to be set to something that comes from the seperate time-zone library that has long been included in the IDE along with this widget. As a user, I would read its guide (if it has one included) or look it up it's properties in the dictionary to find out for sure, but we can't do that as IDE developers, we must figure out which property editor the property should use.

If you want to add some properties to the clock widget I could help you do that, depending on the property you might just need to add some meta-data tags to the .lcb file and recompile.

Essentially I see widgets a bit like the problem of the engine. It's all wrapped up in its own obfusicated way. Talking about externalising things, we would be better off having widgets made up of classic controls in my opinion - thereby externalising the widgets.

IMO, the task here should include un-obfusicated all of it, and THEN rebuild parts of it as needed.

Extensions are already external modules of compiled byte code (that's what those .lcm files are), that's way more externalized then classic controls that are created by the engine and emulate (fake) an operating system's appearance with non-native, custom drawn controls that are 'set in stone' (they are in the engines C++ source, and then are customized somewhat by the IDE based on those tab-sep values lists, like in "properties.txt").

I can't find the video I did online at the moment, but I'll show you later a widget (experiment) that distorts image data and can be scripted to do realtime animations with it. I had planned to use it to do some card-flip or "cover-flow" style animations with it. I don't think the classic image control could do that, at least not quite as fast, and if you could do it with an image control it would require a LOT of scripting, whereas a Widget/XB-lang you can simply use the fast libSkia image transformations functions that already come with the Extension Builder language.

[tperry2x]

...as IDE developers, we must figure out which property editor the property should use.

Yes, this. Exactly this. The question is how.

[OpenXTalkPaul]

I take everything from ChatGPT with a grain of salt because it makes stuff up out of thin air.
As I said 'the properties" doesn't really work for Widgets.

If putting the property yeilded 'empty' then that is also a valid value for that property, just like with a lot of classic control's properties. Empty typically means 'use default' or 'inherit value from parent'.

Try getting the 'classic control' property like 'textFont' that hasn't had the property set to anything, it'll probably return empty, so you have to account for that.
What I did with my text palette thing for property that may be non-existent was to wrap the handler in 'try/end try'.

I'll try to take a closer look at the way the rev Inspector does this stuff later tonight if I have time.

My guess is it's a combination of 'automatic' for any required or 'standard properties', and for widget defined properties uses some handlers that parse the info from the extension package, like that revWidgets() handler's array includes.
It would be nice if the IDE had already included some simple syntax for this (like 'put the widgetProperties of widget "whatever") but as far as I know it doesn't (but then before this thread I didn't know that Widgets could include a custom property inspector editor either).

[OpenXTalkPaul]

It seems most of the IDE's handlers relevant specifically to Widget properties are located in this library (revideextensionlibrary.livecodescript):
https://github.com/OpenXTalk-org/OpenXt ... cript#L217

Moreover there's handlers there to do other things that could be useful (like hide a widget from the widgets section of the Tools palette for example.).

[OpenXTalkPaul]

put revIDEExtensionProperties(the kind of widget "MyWidge") into tArray
That's the handler/array data that you're after for Inspector display (includes editor to use, user visible, section, etc.)

[tperry2x]

put revIDEExtensionProperties(the kind of widget "MyWidge") into tArray
That's the handler/array data that you're after for Inspector display (includes editor to use, user visible, section, etc.)

Excellent!
Indeed that is exactly what I need, so I've built a stack to show each value of each key (attached).
This will help me build the inspector, especially for dynamic properties like widgets. Thank you.

You can see in the screenshot, it returns the values of the switch widget > key: "theme" > value: native, iOS, Android

So this is exactly what I need as my inspector will know for example, to make a popup menu called "theme" and populate the dropdown with "native, iOS, Android" submenus.

widget-data-test-2.png (194.44 KiB) Viewed 1190 times

Indeed, not as easy as one would hope - and now a bit of a headache to script the automatic 'classic control' groups, buttons, and fields that tie in to this - but certainly doable. I think we are there now, so once again - thank you for finding that and digging through the interwoven bits to locate it.

[tperry2x]

[Toolset/libraries/revideextensionlibrary.livecodescript]
...here's handlers there to do other things that could be useful (like hide a widget from the widgets section of the Tools palette for example.).

Also, you may already be aware. I discovered the "revTools.livecodescript" script only stack also contains handlers such as:

Code: Select all

isolateTool [tool] -- for disabling all tools except the one specified.
enableTools, disableTools
groupDisable [widget/classic/graphic/graphictools/paint], [true/false]
toolEnable [button/widget]
toolDisable [button/widget]

[OpenXTalkPaul]

[Toolset/libraries/revideextensionlibrary.livecodescript]
...here's handlers there to do other things that could be useful (like hide a widget from the widgets section of the Tools palette for example.).

Also, you may already be aware. I discovered the "revTools.livecodescript" script only stack also contains handlers such as:

Code: Select all

isolateTool [tool] -- for disabling all tools except the one specified.
enableTools, disableTools
groupDisable [widget/classic/graphic/graphictools/paint], [true/false]
toolEnable [button/widget]
toolDisable [button/widget]

Glad to help! Looking forward to trying out your new inspector!

I learned a few things too, the undocumented fact Widgets can include their own custom property editors too (I don't know that any of them do, but I know I'm going to experiment with it).

This thread has me thinking a lot about the Extension packaging format in general. I'm becoming convinced we could modify the same system to implement stack/script 'widgets' in some way. Some way that would have to be fleshed-out of course. I know LC has done something similar, but I have no knowledge of what their system does now days, and I'm not too worried about staying compatible going forward. I don't think there's any reason a stack's script or behavior couldn't have the same sort of metadata, the system already allows for widgets to include a '_defaultsScript" that serves the same purpose as the 'classic controls' equivalent (in IDE /Tools/Toolset/resources/supporting_files/default_scripts), the system has a folder defined for demo stacks, plus package manifest (.xml), and API.lcdoc for adding docs to the dictionary.

I've been thinking any of those could individually be delivered via the .lce package (again its just a zip file) system sans any Xtension Builder module. So maybe the .lce only contains a 'samples' folder that could contain a whole collection of Demo stacks and any peripheral media that might go along with them in a 'Resource' folder, along with a description, or docs/guide/ serving as a brief "read-me". These 'virtual-Extensions' packages could populate the 'Sample Stacks' browser, which is something I want to detach from relying on outside sources.

I've probably looked at the tools pal scripts more than hundred times by now, I guess my news tools palette should support those handlers, I'm not sure where in the IDE they're actually used if at all, I think you'd only want to isolate / disable controls on the tools palette in edge-cases like with the Tutorial system maybe (to highlight a particular control).

At one point early on I started trying to collect a list of 'public' IDE related functions available in the IDE that could be useful. That's when I noticed that some of them had the same sort of in-line documentation that's used with Extension Builder, and then used 'Extension Builder' stack to parse those out.

Here's a few from Home stack that could be useful:
put revEnvironmentExtensionsPath() -- IDE Extensions
put revEnvironmentExtPath() -- IDE Externals
put revEnvironmentToolsetPath()

I'm going to try to add the in-line docs for Extensions Properties stuff from this thread, then add it to Dictionary for us to use (or anybody else who may interested in working on IDE things).

[OpenXTalkPaul]

To go along with the idea of script 'widget' extensions, and specifically widgets as you can already make script-based library extensions, the IDE library revIDEDeveloperExtensionLibrary contains handlers like:
revIDEDeveloperExtensionEditScript pFolder
Which looks to edit either an .lcb which launches external editor, OR a stack file within the given folder. If it's a stack file, it then does 'edit the script of stack...'. So there's already existing infrastructure that could be used.

Finding lots of interesting things in these libraries.
Just found another undocumented Extensions feature, there's a 'revIDEDeveloperExtensionNew' handler that can take an array and merges it with a template file, which can be located in the IDE at:
/Toolset/widget_template.txt
/Toolset/library_template.txt

[OpenXTalkPaul]

This code snippet will retrieve a list of the 'kinds' of installed extension widgets (they could be uninstalled, or could error while loading), but only includes the ones that are set to be user visible:

Code: Select all

 
 -- revIDEExtensions (pTypeKind, pInstalledStatus, pExcludeUserInvisibles)
 put the keys of revIDEExtensions ("widget","installed", true) into tLoadedUserVisibleWidgetModules
   sort tLoadedUserVisibleWidgetModules
   put tLoadedUserVisibleWidgetModules

put the keys of revIDEExtensions ("library","installed", false)
will get you a list of all installed extension libraries with uservisible = false library's showing.
That shows additional object archiver library, which I hadn' realized was set to be user-hidden. I'm not 100% sure what that library is for, but I think its for serializing an 'object' for storage/recall. But it is interesting that library's can be hidden as well.

[OpenXTalkPaul]

This snippet will list the public handlers from a library extension given it's 'kind' (identifier)

Code: Select all

put revIDEExtensionLibraryHandlers("com.livecode.library.timezone")

ToUniversalTime
FromUniversalTime
TimeZones

So I'm guessing the clock widget or any other script that deals in timezones can use:
put TimeZones() ... yup, it yields a long list of timezones

[OpenXTalkPaul]

So I started adding docs for some of these handlers for IDE use, eventually I'll run the file through revDocsParser via Extension Builder stack and get a API.lcdoc markdown file which can be added to the Dictionary building files.

If anyone wants to help document any of the IDE's handlers here's an example multi-line comment that is in revDocsParser's in-line docs format, use it as a template.

Code: Select all

/**
Get a list of Extension Library's Handlers

Syntax: revIDEExtensionLibraryHandlers( pModuleID )

Parameters:
pModuleID (string): A string that is an IDE Extension Module identifier.

Return (string list): A line delimited list of handlers available from the module.

Example: 
put revIDEExtensionLibraryHandlers("org.openxtalk.library.macnative")

put revIDEExtensionLibraryHandlers("com.livecode.library.timezone")

Description:
Given a library extension module kind itentifierthis will return a line-delimited
list of names of the public handlers made available by the module.

References: revIDEExtensions (function), revIDEExtensionProperties (function)
**/
function revIDEExtensionLibraryHandlers ...
...

The **/ (must have two asterix) should end it right before the handler that it documents

There are additional 'keys' (:) that can be used with this docs formatting.
Keys such as 'OS:'
os: Mac, iOS, Linux, etc.
But those keys don't really apply to the IDE's functions.

That's another thing, terrible lack of documentation, there should be a complete list of these inline-docs 'keys' somewhere, but currently I have to trudge through the IDE libraries to make my own list. More often I'll just copy/paste from some existing docs comment and use that as a template.

Most 'keys' such as 'References:' are optional, but we would want to least have Description: for the handler and info for 'Parameters:' and 'Return:' value type if any.

[tperry2x]

I guess my news tools palette should support those handlers, I'm not sure where in the IDE they're actually used if at all, I think you'd only want to isolate / disable controls on the tools palette in edge-cases like with the Tutorial system maybe (to highlight a particular control).

When I saw those handlers, I thought they might be handy to Richmond: if he wanted to disable bits of the tools, simplify it down etc for teaching purposes?

[OpenXTalkPaul]

I guess my news tools palette should support those handlers, I'm not sure where in the IDE they're actually used if at all, I think you'd only want to isolate / disable controls on the tools palette in edge-cases like with the Tutorial system maybe (to highlight a particular control).

When I saw those handlers, I thought they might be handy to Richmond: if he wanted to disable bits of the tools, simplify it down etc for teaching purposes?

Or he could mark any extensions to hide/or not load at startup, via the Extension Manager (or via some of the IDE libraries handlers), I think you might even be able to hide 'classic controls' via those properties files, they're a lot like the property metadata keys used with Extension Widgets.

I was thinking more about that 'isolateTool' one, I'm pretty sure that's used by that Guided Tutorial system.

I see your stack demo v2 parses the manifest directly. That info should be already parsed and cached, just need the right IDE handler to get it. I'm intend to stick with using existing IDE handlers at least for Extensions stuff because of all of the intertwined-ness of it with the Extension Building and Module Loading/Unloading, and Documentation Libraries.

[tperry2x]

I see your stack demo v2 parses the manifest directly. That info should be already parsed and cached, just need the right IDE handler to get it. I'm intend to stick with using existing IDE handlers at least for Extensions stuff because of all of the intertwined-ness of it with the Extension Building and Module Loading/Unloading, and Documentation Libraries.

Yes, I debated whether to use the cached version or load it directly. In the end, I decided to load it directly as I'm only inspecting one widget at a time. I also worried that working from a cached copy could in theory lead to changes not being shown, as you are working on a copy of object data that could in theory be out of date. (Although I don't know that for sure, I was trying to eliminate that as a possibility). I thought it probably wouldn't make much difference to speed (cached copies would be faster I'm sure when you are talking about loading in multiple widgets at the same time), but as it's only an individual one showing in the inspector - I think reading it directly might be more reliable (for my purposes at least).

[OpenXTalkPaul]

I see your stack demo v2 parses the manifest directly. That info should be already parsed and cached, just need the right IDE handler to get it.

Yes, I debated whether to use the cached version or load it directly. In the end, I decided to load it directly as I'm only inspecting one widget at a time. I also worried that working from a cached copy could in theory lead to changes not being shown, as you are working on a copy of object data that could in theory be out of date. (Although I don't know that for sure, I was trying to eliminate that as a possibility). I thought it probably wouldn't make much difference to speed (cached copies would be faster I'm sure when you are talking about loading in multiple widgets at the same time), but as it's only an individual one showing in the inspector - I think reading it directly might be more reliable (for my purposes at least).

It could be out of date if you DON'T use the cached (array) because in theory (probably would be very rare) an Extension could get loaded or unloaded by the user while your script is trying to read it? Somehow? On the other hand it's not like we really have to worry about 'locking' (parallel processing, 'thread-safe locked' variables), either way is probably safe enough for the few hundred milliseconds it takes to read/display.

The only thing I'd point out is that way is reading a file from disk, so that could be a slow drive if it's sitting on old HDD vs SSD, where as reading an Array that's already in memory should be the fastest method.

Also that cached array should already be a combined list of both IDE-included extensions and any user installed extensions that may be in the user's 'My OpenXTalk' folder, OR in some other folder (like a dev beta versions that's module has been temporarily loaded to memory), so that's one less consideration to deal with in script.

[OpenXTalkPaul]

Oh I found one of my lists of notes on the some IDE librarie(s)/handlers:

https://github.com/OpenXTalk-org/OpenXt ... things.txt