I spent a few hours today playing with widgets. I haven't looked at them since @LCMark's first push to his repo a couple of years ago and they are getting pretty cool. One thing I found was there seems to be no font inheritance. Is there a way to find out the effective font of the owner and be notified when it changes? I presume there's the same issue with other inheritable properties. I think property inheritance is such an integral part of the platform it would be a shame to lose it. The other side of this is that adding common object properties like these might be such a common occurrence that it's worthwhile adding some support for them even if it's just some way to include an external file of common properties.

I've made a simple rotating text label which is something people have wanted for a while and is super easy as a widget.

(I've moved this topic to the LiveCode Builder Forum - which is the best place to discuss LCB and its use)

@monte: Welcome to LCB - things have changed a fair bit since my early prototypes!

In DP1 there is no font inheritence - however, support for the font properties in LC have been added as a result of http://forums.livecode.com/viewtopic.php?f=93&t=23555 (pull request, now in develop - https://github.com/runrev/livecode/pull/2064). In regards to general property inheritance then we haven't yet analysed or modelled that enough yet to work out the best way to map it into LCB. Indeed, the current use of inherited properties in LC are almost all intimately tied to 'themeing' which we are also working on.

In terms of 'common properties', then we are planning allowing a widget to extend another widget at some point. Ideally the root 'widget' type would be more like a (cut-down) MCObject which would sit as a resource (such as an AClip or VClip). Then there would be a derived type which would be more like a (cut-down) MCControl. Then derived types which would have all the same default behaviors as the full MCObject, MCControl. Obviously containers come in here somewhere too. Thus, you would be able to choose how 'existing engine' like your controls are choosing what the base-class is. There is still a fair bit of work to do here though!

In terms of property names then there are a few restrictions with identifier casing at the moment down to the fact we are using an LR-based parser (generated using bison) at the moment. Basically all lower-case identifiers are reserved for potential use by syntax - 'angle' is part of syntax rules in the canvas module so you can't use it as an identifier. Since properties are case-insensitive in LCS, you can just use Angle for now. However, this particular case should be easy to make work since the context of the identifier in the 'property' definition is so restricted. BZ http://quality.runrev.com/show_bug.cgi?id=14980.

2) Generalize widgets to a definition and make them a first-class citizen in LCB - thus allowing 'composite widgets'. A widget will be able to create other widgets within itself, creating a NSView-style internal hierarchy. These will still be completely opaque from the point of view of the engine. This will make it much easier to implement things like the player controller - which is really a group of more specific controls, rather than a single control.

3) Abstract the notion of container control in the engine and allow a widget to be implemented as a container. This would allow a widget to contain not only other widgets (internally); but also manipulate, control and contain LCS controls.

Also I didn't look at all the widget files but I didn't see anything that was obviously calling OS Frameworks. Are there any examples of that or are they being worked on? The other thing I'm wondering is will LCB libraries be able to define syntax or do we need to implement a module for that?

@monte: Sorry should have been clearer there - because we currently have two languages we have LiveCode Script (LCS) and LiveCode Builder (LCB). So LCS is the current scripting language and related infrastructure it has (UI objects, message path etc.).

There is very basic foreign handler support - if you take a look at the unittest.mlc files you can see this at work. @peter-b has implemented the entire LCB unit-test framework in LCB. It is going to require a fair bit more work to make the foreign handler bindings 'easier' and higher-level - also we haven't yet tackled wrapping foreign types fully. e.g. Wrapping and being able to derive from foreign classes, wrapping foreign types along with the memory management concerns - but this is all planned. At the moment, you can map to basic foreign (C) types and there is a pointer abstraction. So, you can do stuff, but it does involve getting your hands dirty.

At the moment LCB syntax is statically defined by the modules which are builtin. We decided getting widgets and extensions working first was the priority, with 'dynamic syntax' being second to it.

So, at the moment only LCB modules which are part of the core can have syntax (and we are tightly controlling this to ensure the basic standard syntax is correct / uniform and works - the bison parser has some gotchas in syntax definition which means you need a whole-syntax view to add syntax) and lc-compile is compiled with this syntax built-in.

What will bring syntax to LCB modules generally will be the Open Language parser. When this part is complete, a module will be able to define its own syntax and then when it is used by another module; its syntax will become available to that module - i.e. the parser will notionally be built dynamically for the set of modules which a given module uses. This will also be the basis for the syntax unification between LCS and LCB (the runtime unification will happen first - we are intending to rehost the LCS scripting language on the LCB VM when the latter is a bit more mature).