1. Cross Platform API
I did a bit of research on the Mac and X Windows APIs this weekend; here =
are some findings, in case people are interested:
[Web Information]
My primary source for X Windows information is a great tutorial at:
http://www.ee.cityu.edu.hk/~edap053/xtut00.html
My primary source for Mac programming is an on-line book on coding the =
Macintosh for hobbyists, at:
http://cafe.ambrosiasw.com/alt.sources.mac/macintosh-c/
The are both excellent.
[Terminologies]
X Windows calls attributes 'resources', and controls 'widgets'. This can =
be a bit confusing.
[Similarity to Win32 API]
Both the Mac and X Windows are based around the same kind of event-based =
model. They both support the same basic set of controls. They both use =
callbacks to handle interaction with controls.
There seems to be more similarity than differences - but the differences =
can be a real pain.
[Calling the Mac API from Euphoria]
The Mac API is fairly simple to call. Although most calls look something =
like this in C:
createWindow( ... )
they can also be coded like this:
toolbox( _CreateWindow, ... )
using a Pascal calling convention. Since the Mac toolkit is part of the =
OS, the calls don't need to be resolved until runtime. This means that =
you could provide a mininal version of a Mac port that knew very little =
of the tookit, and have it extended by users - much the same as Win32.
[Calling the X Windows API from Euphoria]
The X Windows API is fairly low-level, and typically one would code to a =
higher-level interface, such as Motif or AfterStep. In either instance, =
the calls are to a library that is linked at compile time (as opposed to =
the run time DLLs of Win32). This means that Euphoria would need =
explicitly have to define what X Windows/Motif calls are to be =
supported.
[Possible Mac Issues]
In Mac programming, it seems that you have to define *all* your =
resources ahead of time, using a tool like ResEdit (resource editor). =
What's a resource? Just about anything: a window, a control, a menu =
item, a cursor.
In theory, the resource file can be bypassed by creating the controls on =
the fly (or resource files on the fly). In practice, this doesn't seem =
to be the direction that people take. For example, Sun's Tcl/Tk code =
simulates Mac controls by creating a set of each type of control in a =
hidden window. When that control needs to be displayed in a window, it =
copies a bitmap of that hidden control into the window that has that =
control.
With a new OS "just around the corner" (Rhapsody), it's not clear how =
portable the Mac code will be to the new OS. It seems that Apple is =
encouraging people to use the NextStep libraries (which are also =
available under the GNU license in the form of OpenStep).
[Cross Platform Issues]
Certain basic things, like bitmaps and fonts, are not easily transported =
between the platforms.
Unless you are using a geometry manager (such as Tk's), a window =
formatted for one OS will not look right for another.
The Mac is based on a Pascal model, not a C model. One example of this =
is the strings - they are size prefixed, not zero delimited.=20
I don't know if there is an -endian issue with the Mac.
[Cost of Compilers]
The X Windows libraries and compilers are typically free. The Mac =
compilers can range from about $100 (non-Power PC version of MetroWork's =
C Compiler or Apple's MPW compiler) to $450 (MetroWork's Power PC =
compiler).
[Is There A Market?]
There seems to be a large number of people using different tools on the =
Unix platform who would be willing to look at a Linux port of Euphoria, =
with or without a GUI. Problematically, most Unix users (as Robert has =
pointed out before) are used to not having to pay for their tools.
While there is less of a base for Mac users, there also seems to be less =
programming tools available.
I just thought people might be interested.
-- David Cuny
