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
directives.
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
substantial.
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
priority.
> 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
____________________________________________________________________
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
