Defaults for groups

[Richard Gaskin]

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
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com