Here's my 25p's worth:
Ever since widgets 'appeared' I have thought of them as second class
citizens insofar as:
1. They are 'bits of stuff' where experts (the LiveCode team and so on)
have done the heavy lifting
for those of us who haven't got the skill, motivation or time to work
out how to get that sort of thing together
in LiveCode itself.
2. I certainly never get into widgets when I teach computer programming
for a number of reasons:
2.1. While I teach children to program with LiveCode, the ultimate aim
is to equip them with a series
of transferrable skills they can take 'to the table' of any programming
language: the ability to drop in
a prepackaged 'does-it-for-you' add-on (one of the things that sets my
teeth on edge about Python)
does not, as far as I am concerned, constitute computer programming as such.
Of course people might start shouting at me, at this point, and say,
"Well then, why don't you go back to command-line
programming?", to which my riposte is, "That's why I START my
programming with teenagers (it's a bit too much for
preteens) with BASIC programming on my BBC Micro machines I have
lovingly curated in my school."
After a day or two with BBC BASIC on a black screen teenagers will "do
anything for me" when they see the, supposedly,
old-fashioned LiveCode IDE and the ever-so-sexy WYSIWYG GUI.
2.2. While a LiveCode button can be examined via its property inspector,
a widget largely cannot,
so a learner cannot really begin to understand how it is put together.
3. Widgets are, undoubtedly very clever insofar as they provide tools
and services out of the box, and types
like myself don't have to spend an awful lot of effort working out how
to roll our own.
4. I suppose the 'price' of a widget is just exactly that one cannot
really get t its underpinnings (properties)
in quite the way one can withg a native LiveCode object.
Having said all this, I don't use widgets (beyond fooling around with
them when I have a spare moment),
and on my teaching computers the widgets section of the revTools palette
is never exposed.
Were widgets to be "integrated" into LiveCode as per buttons, fields,
images and so forth, with properties
palettes allowing a vast number of variables to be accessible, my
attitude towards them might change; but that
seems unlikely to happen as they are quite different beasts to buttons,
fields, images and so on.
Best, Richmond.
On 7.04.22 9:24, Richard Gaskin via use-livecode wrote:
Thank you for your reply, Monte. Comments inline:
Monte Goulding wrote:
>> On 7 Apr 2022, at 11:25 am, Richard Gaskin wrote:
>> Can you help me understand how it's better than "the properties",
>> and why this superior method isn't used for engine controls?
>
> Because the array created by export and used by import contains
> the state of the widget as is saved when saving the stack. The
> content may or may not be the same as the property names exposed
> to user scripts but a widget created with that state should be
> the same as if it were saved in the stack and the stack re-opened.
I've never used a widget in production yet, so I can't say I have an
opinion there. If the uses for widgets are viewed as sufficiently
different from engine-based controls that "the properties" so many of
us enjoy wouldn't apply, I'm okay with that. Just looking to understand.
>> That the company has such a narrowly specific view of the
>> applicability of "the properties" is indeed helpful. Thank
>> you for chiming in.
>
> I’m not the company.
Pardon my imprecision. I think the readers here are likely aware that
the company is comprised of many people, and there are likely many
different opinions on a wide range of topics, including this. Please
read that as "a significant member of the company".
> Mark may spend a lot more time pondering the utility of `the
> properties` than I do and indeed may have a different opinion.
> Indeed my opinion was much closer to yours is now when I sent
> in a PR for LC 6.1 all those years ago ;-)
One of the challenges with a tool as vastly capable as LiveCode is
wrapping one's head around all the use-cases, and all the perceived
priorities. Various members of the company and the community have
expressed a wide range of opinions on many things.
If "the properties" winds up being like the pointer tool requests I
used to ask about, no worries. I stopped asking about those years ago.
Indeed, even with "the properties" I've had a few discussions on this
with different team members going back to Dr Brett, back when LCB was
in its earliest stages.
In my own mind having two different methods for obtaining property
data for two classes of objects is akin to having two different words
for "rect" or other basic features. Where a useful implementation has
been chosen and established so long ago, it seems worth mirroring in
new implementations.
But TBH, since I haven't used widgets in production at all, the only
time it comes to mind is when someone asks me about it for one of my
tools, or in discussions like this one. This seemed a good time to see
what the current vision is. I appreciate the clarity provided.
>> How hard would it be for the team to map the existing means of
>> extracting widget properties to "the properties”?
>
> I don’t think it would be particularly tricky to iterate the exported
> property definitions to come up with a list of property names then
> turn that into a key/value array. Whether it would provide the utility
> you are looking for is a separate question.
If it does what "the properties" does it would suit my needs.
_______________________________________________
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
