Philosophical questions about the fontNames

Richard Gaskin ambassador at
Thu Mar 12 15:24:19 EDT 2020

Paul Dupuis wrote:
 > I *do* find that cross-platform UI design and implementation to still
 > be the hardest thing to do in LiveCode (on a relative scale of course,
 > since LiveCode overall is easy)
 > I would just like to be able to say in a preferences box for my app
 > that I am deploying to this platform and that platform and have the
 > LiveCode IDE or engine (or both) figure out what fonts and what sizes
 > everything should be to comply with the ever changing OS vendor HIGs!

For the most part you do, now that the team added the "(*)" textFont 

Your case is one where I would advocate extending "effective" to apply. 
I understand Mark's comments and generally support them, but like they 
say, exceptional circumstances require exceptional solutions.  The 
semantic difference between object inheritance and OS inheritance is 
real, but far more subtle than a hundred other things already in the 
language, and likely lost on most new users anyway.  "Give 'em the pickle".

But even here, it's a relatively narrow intersection of needs:

Most user-written content is either a sort of form or something more 

With forms, the user neither knows nor care what the font is, they just 
want to type.

With more substantial content (web authoring, printed materials, etc.) 
the user cares very much, and the likelihood of ever wanting the 
OS-specific default font is low, so assigning your own default font 
explicitly would work well (even better for some apps, let the user 
define a default).

So while I do support your request to extend "effective" to apply here 
(notwithstanding the considerable effort the team would need to do to 
figure out what the values of the OS constants refer to), I also 
recognize it's not a common use case.  Worth supporting, IMO, but of low 

 > I constantly run into things like we make a button with a label that
 > fits on one platform and then on another the label is too long or a
 > filed is sized to display x lines on this platform  but on that
 > platform the line sizes are different! Grrrr! It really is infuriating
 > at times.

And not even the IDE gets it right all the time, if you run Gnome with 
its large default font size.

I've given a lot of thought to how I might make tooling to take care of 
the implications of xplat font metrics on layouts.  And after thinking 
about it a very long time, I thought better of it. :)  Way too much 
work, and how I might decide to handle things with one control in one 
app will inevitably vary from how I'd handle it elsewhere.

There are probably underlying design patterns we could identify for such 
things, and make tooling for those.  But even then there will be edge 
cases, so we're either limiting layout options to a specific set of 
patterns, or raising expectations to a level that cannot be met.

Personally, I don't mind so much. I make tooling where I can, and 
hand-craft where not.  All the while I see my counterparts using other 
tools working even harder just for a single platform.  With LC as my 
not-so-secret weapon, I eat them for lunch.

  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  Ambassador at      

More information about the use-livecode mailing list