Widgets

[monte]

One of the side benefits of adding runrevmark's fork as a remote is you get to see interesting new branches like 'feature-widgets' appear. Playing with the demo and it's pretty cool!

[FourthWorld]

I'll bite: what is 'feature-widgets'?

[mwieder]

added.

Your message contains 6 characters. The minimum number of characters you need to enter is 10.

[monte]

Widgets appear to be a new type of object that has an implementation script that handles redrawing the content of the object rectangle. I'm not really sure where the advantage will be in widgets over regular custom controls but the drawing appears to be really quick. One advantage appears to be the implementation script is in front of the object script rather than behind as is the case with behaviors.

[FourthWorld]

Sounds cool - thanks for the info. Will the be implemented soon?

[monte]

What has been implemented appears to work nicely but I'm not sure what else is in the plans before it's considered useful enough to release.

[LCMark]

Hehe - I wondered how long it would take for someone to find that branch... One of the advantages of github is that it easily allows you to work on stuff on more than one computer... One of the disadvantages of github is that everything is public (unless you jump through hoops to root through a private repo)

The 'feature-widgets' branch is a prototype for the idea of 'controls written in LiveCode'.

The idea is that you should be able to write controls in LiveCode as if you had written them in C in the engine. They are a slightly 'lower-level' than the type of controls people write in LiveCode using groups, but more suited to cases (which is the majority) where a control ends up being just a collection of field, image and graphic objects. The latter is woefully inefficient in a number of ways, and also ends up (in many cases) being more complicated than writing a paint method. They will be entirely 'isolated' from the surrounding environment so you completely control the dispatch of messages to script, and don't have to worry about any 'default' behavior that might exist for any events. Essentially, they are blank canvases which get the full set of event messages that you might want to process.

They are one step towards proper (isolated) aggregate controls in the sense that the lessons learnt and changes made to support this kind of control will help shape and instruct as to how to do the same thing at the 'next level up'.

The end vision (from the developer perspective) is that you'd use this kind of control (widgets as posed) to make building block controls, leaving aggregate controls for where you truly are composing functionality together. For example, a push button, field and list control would all probably better implemented at the slightly 'lower-level' (using a paint method) - whilst a control that used all three of these to build a 'list manager' control (i.e. one where you can add / remove items from a list) would be better built as an aggregate control.

The end vision from my perspective is that I want to see as much of LiveCode functionality as possible written in LiveCode (or at least a subset of it). Essentially the 'widgets' feature should eventually allow us to rewrite the entire interface framework in LiveCode - the native code portion would be responsible for managing script, windows, events and redraw aspects whilst everything else (buttons, fields, scrollbars etc.) would all be in LiveCode.

The current branch (which I hacked together at the end of last week) is so I can start evaluating how feasible / useful / far off from being made a reality they are. The good news is that it is potentially slightly easier (engine-side) than I envisaged but more importantly I foresee that the amount of cognitive overhead (in terms of not having to think at all about C/C++-ness) saved compared to having to write them in native code is immense. (The example that is currently there is a little pointless, but I've been coding up a simple 'table' object as a better testbed example...).

There's still a lot of work to do to get them to a release-worthy feature, particularly as I want to see them as robust and unbreakable as possible, however hopefully the seed will grow over time into something really quite cool.

[monte]

Nice, I look forward to seeing your table object...