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 ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
