On Fri, 19 Jan 2001 <[EMAIL PROTECTED]> wrote:
> Although MacOS X is based on Unix, Scott will propably have to do a
> complete port of the MetaCard display engine... which is not an easy
> task and may take a while... remember: There is only one Unix
> look-and-feel in MetaCard: Motif; no Gnome or KDE or anything. He could
> carbonize the Classic MacOS engine, but that would not introduce the
> Aqua look-and-feel.
This is not a very accurate description of the issues. We're not
planning a port to the "native" drawing system on OS X (Quartz), but
instead to Carbon, a subset of the current Mac OS APIs. Quartz by
itself is not developed enough to use directly, so you have to use one
of the two higher-level APIs for it. There will be very few new apps
that will use the other high-level API (Cocoa) which is based on the
old NeXTStep APIs because most developers are smart enough to see the
handwriting on the wall about the eventual phase out of that API. The
only exception may be the poor Java developers for whom Cocoa
represents yet another unavoidable set of proprietary extensions
they'll have to deal with.
> IMHO MacOS X will come with several themes preinstalled and new ones
> following soon... Apple has started to add things like that to the
> Classic MacOS, and Kaleidoscope is such a success that they won't miss
> to beat Microsoft to it.
Kaleidoscope a success? I think that's the first time I've heard both
words in the same sentence ;-)
> If it does not make it in the first version, it
> will definetely be in the second one scheduled to come 3 to 12 months
> after the initial release.
I think this is probably not likely either: Aqua is a vastly more
complicated system than the standard MacOS controls, and unlike Gnome
(which has every look under the sun, including a wide range of truly
ugly ones), adding new looks for Aqua is not something people will be
throwing together in a weekend.
> OTOH the MetaCard engine does not use the OS routines to draw controlls,
> but it uses its own to fake it... exceptionally well! Sometimes even
> better than the original OS... and you can adapt them freely to your own
> tastes... and you can use any look-and-feel on any platform. But if you
> would switch themes (or skinns or whatever they call it) in the OS, the
> controlls in MC will stay just the same... and every new theme would
> need another reimplementation from MC.
This is an issue, but far from an insurmountable problem. If we can't
do a reasonable emulation of Aqua, using native controls (via
Appearance Manager) would be no big deal, though it might mean making
certain sacrifices (e.g., you may not be able to overlap "standard"
style buttons or use them in visual effects). This the only remaining
major development task in the OS X engine, though, and there's no way
for it to prevent us from geting *something* out in the proposed
timeframe. We certainly won't be alone if our Aqua implementation is
less than perfect: overriding OS-supplied controls is practically the
hallmark of development on MacOS and there are very few applications
that don't do this in one form or another. Few of them will have time
to clean up all of these hacks in time for their first OS X release.
Keep in mind that there were applications that Apple included on the
OS 9 CD that didn't even properly support the Platinum look introduced
in OS 8. And that change was insignificant compared with what it
takes to move to Aqua...
> Regards
> Rüdiger
>
> P.S.: It would be a great step to have a command line version of MC for
> MacOS X, so we could run CGIs and stuff.
We'll probably get around to doing that at some point, but it depends
on getting some X11 libraries for OS X. With those, such an engine
would pretty much be just a recompile. Without them, it'd be several
tedious days of stubbing out all the drawing routines. Word is that
there is an X11 port in the works, though, so it may not be too long a
wait. Even if the X server doesn't work right, we'll still be able to
use the client libraries to build a console-mode engine for Darwin
(the BSD API OS X is built on).
Regards,
Scott
PS: I can't recall ever posting a message with more acronyms and code
names. These are truly trying times...
> --------------------------------------------------------------
> GINIT Technology GmbH [EMAIL PROTECTED]
> Ruediger zu Dohna phone: +49-721-96681-0
> Emmy-Noether-Str. 11 fax: +49-721-96681-11
> D-76131 Karlsruhe http://www.ginit-technology.de
> --------------------------------------------------------------
********************************************************
Scott Raney [EMAIL PROTECTED] http://www.metacard.com
MetaCard: You know, there's an easier way to do that...
Archives: http://www.mail-archive.com/[email protected]/
Info: http://www.xworlds.com/metacard/mailinglist.htm
Please send bug reports to <[EMAIL PROTECTED]>, not this list.
