Control? Object?

[Mark Waddingham]

On 2016-06-20 14:48, David Bovill wrote:
> Great post Mark. I'm going to keep that for my notes!
> 
> I've too tangentially related questions - mainly with regard to what it 
> is
> better to do with widgets and with script. You say "the ability to be 
> able
> to package up a group of controls as a black-box just like a widget 
> would
> be entirely consistent and self-similar with the existing environment." 
> I'd
> like to know what you are thinking :)
> 
> My question are:
> 
>   1) Does the ability / robustness of using compound widgets - vs doing 
> the
> same with groups make it a here and now option to do compound layouts
> within widgets only? How does this relate to your "black box" comment
> above. I ask because I do a lot of compound nested groups with 
> behaviours,
> and I am wandering what bits to shift o widget only.

Well, rewriting existing code probably should only be done *if there are 
tangible advantages to doing so*.

At present you cannot 'wrap up' existing LiveCode Script objects as a 
widget with an 'inner script' (which would be akin to the code you write 
for a widget right now). It is, however, something which would fit with 
the current model of LiveCode Script very well - when we can figure out 
how to do it.

Widgets are completely encapsulated (compared to Script groups with 
behaviors) which has numerous advantages for all kinds of 'leaf' 
controls (things which have no real substructure and are 'just' a 
rendering of data in some fashion). This is mainly because rendering is 
done 'on demand' so your widget can have as many graphical elements as 
you like, without the (sometimes significant!) overhead of many many 
controls you would need in LiveCode Script. (The advantages are not only 
down to lower overhead, but also editing in the IDE and grokking by 
Script - even though you can 'hide' substructure of LiveCode groups in 
the Project Browser, that are still part of the object tree from 
Script's point of view which means you do, at the very least, have to 
make sure you name things appropriately lest scripts accidentally manage 
to resolve a reference to one of the objects in one of your control's 
groups rather than one they meant to).

Basically, if you have group-based controls which are essentially just 
collections of graphics and areas to interact with the mouse and touch 
and don't require other script controls within them to be manipulated 
from outside the control then they would likely make good candidates for 
widgetization. In Script, you don't need to tweak properties of numerous 
objects whenever the data changes - you just issue a 'redraw all' inside 
the widget and the OnPaint handler causes the display to be updated.

For example, the Clock widget would consist of 16 internal controls if 
it were a LiveCode group-based control - and on each resize you'd have 
to work out all the scaling and positioning and set all the properties 
of each of those objects. As a widget, however, you set up the transform 
appropriately in OnPaint then just render to a unit-square based on the 
time which is currently set as a property. When the time changes, you 
just 'redraw all' and OnPaint triggers to update the display.

>   2) Which animation and paint routines are significantly better with
> Builder so that making a widget is preferable to doing the same with 
> groups
> and script. In particular how about rostering images, of doing 
> animations?

As Builder uses the same image caching mechanism as Script, there isn't 
probably much performance difference between changing the id of an image 
to do animation compared to doing the same within a widget.

However, in Builder you have access to a full 2d Canvas API - including 
full affine transformations so you can do more in a widget with 
graphics, more easily. Also, the widget canvas you render to is 
completely sub-pixel based meaning you get a higher fidelity of display 
then you would get using graphics (as they currently are).

In terms of animation, one advantage of widgets is that the 'Timer' 
mechanism they currently have is entirely internal to the widget - you 
don't see any messages in the pending messages, and suspend and resume 
is automatically handled between Edit and Browse mode. This simplifies 
coding to a good degree as well as minimising any interaction with other 
scripts running and the internal operation of your widget (control).

So, if you have custom controls currently which are visualizations of 
some data, and don't require any user input beyond mouse interaction (or 
any at all) then they probably are really good candidates for turning 
into widgets.

I know Trevor has had great success in improving the UIs in his 
applications by using widgets as they allow him to much more easily 
create easy to use controls which render precisely how you need - what 
might require 3 or 4 graphics and a couple of fields before now, can be 
done with a single control. The latter simplifies the script view of the 
object tree, as well as making things more efficient.

Similarly, once we have Infinite LiveCode, then a good example of 
something which would make more sense as a widget rather than a script 
custom control might be a 'battery status widget' - something which 
displays the current charge level of the battery. It will be easy enough 
to present two interfaces to the battery monitoring APIs (as espoused in 
a recent blog post) - one for script, and one for Builder. The Builder 
one will have the advantage that the subscription to the battery level 
updates will be entirely private to the widget - no messages anywhere 
outside which can get interfered with. This means that you could easily 
write one where you simply drag out the 'battery status' widget and it 
hooks itself up to the notifications internally, and 'just works'.

Perhaps if you can explain some of the custom controls you have that you 
are considering moving to Builder, then we can advise more closely as to 
whether they are good candidates or not!

Warmest Regards,

Mark.

-- 
Mark Waddingham ~ mark at livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps