Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[widget metadata]can we do introspection to get widget metadata #25

Open
macMikey opened this issue Sep 13, 2022 · 5 comments
Open

[widget metadata]can we do introspection to get widget metadata #25

macMikey opened this issue Sep 13, 2022 · 5 comments

Comments

@macMikey
Copy link
Owner

some of the properties in some of the widgets have code similar to

if "showBorder" is among the keys of pProperties then
		put pProperties["showBorder"] into mShowDivide
	else
		put true into mShowDivide
	end if

which could be avoided if we could check the version metadata, and if it is under a certain value, assign those initial default values

@macMikey macMikey moved this to Todo in LCB-missing-manual Sep 13, 2022
@macMikey macMikey moved this from Todo to unanswered in LCB-missing-manual Sep 13, 2022
@bwmilby
Copy link
Collaborator

bwmilby commented Sep 14, 2022

This doesn't answer your question, but the above code is not correct. That else clause is totally unnecessary. OnCreate is called first and then OnLoad so there should never be a case where mShowDivide is not already initialized to true as defaults are already set at that point.

Unless you choose to save the version, the stack won't have any knowledge of what version was used stored. The version metadata is a part of the widget itself and not the data stored in the stack file. This is something that you, as a widget developer, would need to handle. As long as there are just properties being added, using a new version shouldn't pose a problem. For all of the changes that I proposed, the defaults (OnCreate) would set the widget up to match the prior version.

@macMikey
Copy link
Owner Author

That is from the navBar, by the way.
It was part of what was so confusing with OnCreate() vs OnLoad(), because in the style guide, it says that defaults should be set in OnCreate() not OnLoad(), but there were a bunch of these blocks in the OnLoad() handler.
Since OnCreate() is only executed once, I think (?), when the widget is instantiated the very first time, don't you have an issue for existing widgets if a new version of the widget comes along with new properties? Will OnCreate() ever fire for those pre-existing widgets?

@macMikey
Copy link
Owner Author

macMikey commented Sep 22, 2022

roundabout way, using lcs:
In revideextensionmanagerlistbehavior.livecodescript is a call to revIDEExtensions(), which returns the sExtensions array.

that is populated in __extensionsPropertySet from revideextensionlibrary.livecodescript

called by __extensionSetCommonProperties

called by __revIDELCBExtensionLoad

just grabbing the keys of one extension:

author
defaultScript
error
file
ide
install_path
label
manifests
name
os
platforms
requires
samples
source_file
source_type
status
support_files
svgicon
title
type
type_id
uservisible
version

@OXT-OpenXTalk
Copy link

OXT-OpenXTalk commented Oct 20, 2022

You can do introspection from the script side:

put extensionFetchMetadata(tPathToManifestFile) into tModuleManifestDataArray
put tModuleManifestDataArray["version"]

which uses the extension utilities library to parse the Widgets manifest XML

from Extension Builder I think you should be able to do something like:
get property "version" of my script object

@OXT-OpenXTalk
Copy link

OT but... I wish there was a way to re-'kind' all placed widgets of a specific 'kind' after you've changed the reverse-domain identifier (ie com.livecode..), a real pain it seems there's no way to update 'kind' for already placed widgets. I've had to do this for Widget demo stacks quite a few times now. I even tried to modify the all-widgets 'kind' property in its .tsv file to make 'kind' editable to no avail (the property just reverts to previous after setting it).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Unanswered
Development

No branches or pull requests

3 participants