Getting Up To Speed A Little Quicker?

[netdzynr]

So I'm reading the docs, and looking at the examples, but am still trying to learn my way around the new architecture. A few questions (sorry if these are obvious and I just missed them):

- It seems that the script for a widget can exist anywhere on the drive, but where do installed widgets wind up (ie such as when downloaded from the Extension Store)?

- Do any of the demo widgets offer settable custom properties that are not part of the standard LiveCode dictionary? If so, where are these properties accessed to be changed? For example, if I create a specialFrontColor property for my widget, presumably I have the ability to include this property among the standard LiveCode color properties somehow. Do all settable properties need to fit within some standard editing categories or groupings? If an editable property setting doesn't fit in a "standard" category, where does it get displayed?

- Is there any concept of a set of widgets that share a common set of properties, or are widgets solely independent components at this point? Would something like this be handled more by a library?

Thanks in advance for the answers. Am sure more questions will come along

[benjibeaumont]

Hey Scott,

1) Installed widget are placed in you "My LiveCode/extensions/" folder which by default is in your documents folder. We're working on a way to make it easy to test install extensions locally so you don't have to deliver everything through the store while developing.

2) Yes, any property you define in script is exported when built. The built package contains a manifest that is read by the IDE at startup and providing data for the property inspector. If the type of the property "specialFrontColor" is "Color" then the inspector will display a color picker for that property. This is early days and we're aware of quite a few issues with this which we're addressing for 8.0 A3. We plan to add meta data to the mlc files allowing you to customise how you'd like the inspector the treat a given property. Additionally, we're working on submodule support in a widget allowing you to include more than one widget is a built package. The aim here to to allow developers to write a widget for editing special properties which the property inspector in the IDE will use.

3) At the moment widgets are independent units. Certainly they can call into a library that maintains a shared data space but that would be up to you as the developer. Is there a specific example you have in mind. If so share, it may shape some of our design work going forward.

Thanks for your questions. Keep them coming.

Warm regards,

Ben

[LCMark]

@scottrossi: Just to build upon what @benjibeaumont was saying in (3)...

At the moment widgets are entirely independent - however, we are currently working on a few significant changes:

• Widgets will cease being a 'module' and instead be a definition within a module (so module foo; widget bar; end widget; end module) [ What is considered to be a 'widget module' now will just be a module with a single widget clause ].
• With this change it means that a widget will not only have access to instance variables defined within it, but also variables declared at module scope. The module scope variables will be shared amongst all widgets in the module.
• Widgets will be able to inherit from another widget - thus you will be able to have a common base widget with common properties and events and then specialize them in descendent widgets.