>Alain: Macintosh controls "jump forward" ?? Windows do
>that - if you click on a window that is not in the
>foreground, it will jump forward to the foreground and
>become the active window. But controls??
Alain,
try it. Copy HC, make the OK and Cancel buttons of some HyperCard-dialog
(e.g. Button Info) overlap using ResEdit and click the one that appears to
be behind. It appears to "jump forward".
>Alain: The hiliting of parts in HyperCard is the same
>as the hiliting of Macintosh controls, aren't they??
>Did HyperCard stray THAT far from Apple's Human
>Interface Guidelines??
HC draws all its buttons itself, "by hand". Same applies to highlighting
etc. It heeds the Human Interface Guidelines, but it fakes everything.
>Alain: We will be supporting all of the events that
>HyperCard 2.x supports, right?
FreeCard 1.0 will have HC 2.x's feature set if there's no *very big*
problem that forces us to do otherwise.
>Alain: Are you talking about : (a) FreeCard-specific
>source code, written in C/C++, or (b) FreeCard script
>language code (FreeScript) ?
C/C++ code. Not scripts.
>Alain: set the style of <button> to <buttonStyle>
That's not the problem. The problem is that on MacOS there is a button
control, a check box control etc., but there's no (reliable) way to turn a
button control into a check box.
>Alain : But the <buttonStyle> token will have to be
>defined somewhere, in a structure that detects and/or
>asks the user for the current/projected
>platform/context in order to only offer the btnStyles
>that are supported. But how do you switch custom
>btnStyles when someone goes from one platform to
>another? Unless, of course, each mac-btnStyle has a
>corresponding win-btnStyle and linux-btnStyle. If
>these corresponding btnStyles are not identical, then
>FreeCard will look different on every platform. So
>what's it going to be ? Same look and styles
>irregardless of platform, or platform-specific
>enhanced looks/styles that are quite distinct for each
>platform?
There will be functional styles. Rectangle. shadow etc. will look the same
on all platforms, while "standard" will look like dialog buttons
("roundrect") on Macs and like square buttons on Windows etc. I'd like to
avoid having styles that aren't supported on one of the platforms. Ideally,
every button/field style would map to native look on the platform it's
currently running under.
>Alain: Absolutely. Abstraction of implementation
>details of each platform would undoubtedly be one of
>the Ten Commandments of programming, if such a thing
>existed. The only hitch is that universality usually
>translates into designing for the
>Lowest-Common-Denominator that is common to all of the
>targeted platforms.
Usually; but I hope that we'll be able to fake some of the features on
other platforms. E.g. if some platform wouldn't support popup menus, we'd
draw a button and display a menu by hand or something like that. Of course
we can't simulate QuickTime on Unix, but we could support other native
movie libraries and add support for decoding various image formats into the
platform-specific aspects of that environment.
The hard part will be deciding when what is more important; in some cases
we'll need to sacrifice universality for performance's sake. But this needs
to be decided on a case-to-case basis and needs to be confirmed with
proof-of-concept code, and in worst cases by trial and error.
Cheers,
-- M. Uli Kusterer
------------------------------------------------------------
http://www.weblayout.com/witness
'The Witnesses of TeachText are everywhere...'
--- HELP SAVE HYPERCARD: ---
Details at: http://www.hyperactivesw.com/SaveHC.html
Sign: http://www.giguere.uqam.ca/petition/hcpetition.html
