Sannyasin Brahmanathaswami wrote:
> It matters not that in the past a group may have been used to
> surround controls with a border and show a label.. in *all* other
> environments (Indesign, Illustrator, Photoshop, synFig, whatever…)
>
> A group, its dimensions, it's rect, and its properties are comprised
> of the objects it groups and nothing more. It is not the business of
> the IDE to start adding "adornments" (borders, line width, show name,
> margins)
I very adamantly support that one: the IDE should NOT alter engine
defaults unless for some very rare reason it's absolutely necessary.
The value of an xTalk is that it allows truly live coding, nearly
eliminating the differences between development and runtime. And
differences there may be are often found only in runtime, where there
are no tools to help explain the difference, leaving the user confused
and frustrated.
That said, the specific group properties in question here are indeed the
engine defaults.
By and large, most engine defaults for objects reflect common HIG
conventions at the time they were created. The conventions may change
over time, and compounding decisions like this is that objects are often
used in a variety of contexts, each requiring a different combination of
property settings.
Each of the three tools you mentioned above are drawing tools, while
LiveCode is a software development tool. True, LiveCode can be used to
make drawing tools, but the effort involved in making a drawing tool is
non-trivial; the three lines of script needed to use groups for that
will be less than 0.001% of the code needed for such an app.
Moreover, the group properties you're proposing be changed have been in
place since I started using MetaCard nearly 20 years ago. Today, using
them in one context requires changing three properties; if the proposal
were acted on a percentage of projects ever written over the last 20
years would need to be updated to accommodate the request.
I share the belief that the users of tomorrow matter far more than the
users of today. Indeed, for LC to be a truly thriving platform we would
expect at least an order of magnitude more users in the future than we
have right now. So anything that is an unquestionable benefit for
tomorrow's users IMO trumps backward compatibility.
In rare cases, we do see changes in the engine that meet the standard of
"unquestionable". For example, charToNum and numToChar are common
functions used throughout all xTalks for decades, but since they predate
the invention of Unicode and modern text standards make them largely
obsolete as exclusively single-byte operations, LiveCode added byteToNum
and numToByte for single-byte use, and extended charToNum and numToChar
to be Unicode-aware. Those engine changes required some of us to modify
our scripts, but given that the benefits of doing so are self-evident
and that we had literally years of advance notice, it's been far easier
to adjust to that change than most companies' backward compatibility issues.
With these group properties, however, respectfully I would suggest they
don't meet the standard of "unquestionably beneficial". Certainly
they're "arguably beneficial", but folks love to argue so darn near
anything can meet that standard easily. :)
Personally I don't mind one way or another if this were changed, providing:
1. An effort has been made to quantify use cases to show unquestionable
benefit, or at least something close to it. It is, after all, easier to
guess what the value of 0 should be when you need it than to guess the
value of a HIG-savvy margin when you need that instead.
2. Any changes to any object's default values should always be made IN
THE ENGINE and not in the IDE, to maintain the fluid live coding
experience that is at the heart of LiveCode's value.
--
Richard Gaskin
Fourth World Systems
Software Design and Development for the Desktop, Mobile, and the Web
____________________________________________________________________
ambassa...@fourthworld.com http://www.FourthWorld.com
_______________________________________________
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
