A Portable API for Euphoria
------ =_NextPart_000_01BD5D67.09055140
Content-Transfer-Encoding: quoted-printable
Hi, All.
This is another one of those "gimme some feedback" posts.
I've been working on a port of Win32Lib to DOS. I've got most of the =
graphic primitives working, and can display most of the widgets that I =
need - text, buttons, check boxes and the like. Now I have to add =
functionality to the program.
Here's a screen shot of the kind of things that it can currently draw:
=20
I've been thinking about cross-platform issues, in the hope that some =
day in the near future Robert ports Euphoria to Linux and the Mac. It is =
unlikely that any of the Win32Lib code could usefully be ported to =
either platform - which would mean that any work on a GUI those =
platforms would again have to be coded from scratch, and would have no =
cross-platform compatibility.
Then I ran across Sun's recent port of Tcl/Tk. It runs on all three =
platforms with a native look and feel. This seemed like an ideal thing =
for Euphoria to use as a GUI library. Unfortunately, it seems unlikely =
that the Tk disentangled from the Tcl code easily, although there are a =
number of languages that use "pure" Tk as the basis for their user =
interface, so I know it can be done.
So I decided, what the heck - I'll try to put together a portable API. =
The proposed architecture is:
1. Minimal graphics core. This assumes nothing more than the ability to =
create windows, and read and write to a bitmaps on them. In the case of =
DOS, windows are emulated.
2. Widget display. This code displays windows, widgets and text using =
the graphics core. All the display is done using the graphics code in =
DOS - text is constructed from bitmaps. If the OS can handle these =
things, you'd use the regular OS calls.
=20
3. Widget emulation. This code provides functionality for any widget =
that cannot be handled by the OS. In the case of DOS, that means =
everything. In the case of any other OS, it would mean making "native" =
calls where possible. As an example of how this is different from the =
display level, a button bar would be emulated at this level for a GUI =
like X Windows, and the actual display of the buttons would be a native =
call in the widget display.
4. Event loop. This hooks into the Win32Lib code, as well as the widget =
emulation
5. I/O. This sends events from the OS to event loop. In DOS, this means =
converting mouse events and keystrokes into queued events for the event =
loop, such as "mouse click :menu bar" or "mouse move over:radio button =
32".
I'm using Tk as a rough model for the middle levels, so I don't just a =
port of the Win32 API. I've selected the Mac for similar reasons: it =
places various widgets in different locations than Win32 (the menu, the =
go away box, the status bar, etc.).
Since DOS will need to emulate *everything*, the minimum port to a new =
OS would be layers 1 and 5. To do a minimal port to Win32, for example, =
you would provide a large window with a bitmap as the screen, and =
capture mouse and keystroke events, and feed them to the event loop.
I've got the first two layers written for DOS32Lib. That's the easy =
part. The third layer is obviously the most difficult - especially =
keeping it GUI independant. Much of this code I've written before, for =
the TextGUI.=20
I hope to get *something* posted in the next couple of weeks. It =
probably won't do much, other than to pop up a window, print some text, =
and maybe toggle some controls.
OK, now for some questions:
1. Robert: Is there likely to be a Mac/Linux port in the near future? =
There's no point in doing all this work if Euphoria is going to remain =
locked to the WinTel architecture forever.
2. Is there a better way of doing this? I'm especially interested in =
people who might have a clue about X Windows, since I suspect that would =
be the next Euphoria port. Can I just hack into the Tcl/Tk DLL?
3. General comments?
Thanks for reading this.
-- David Cuny
------ =_NextPart_000_01BD5D67.09055140
|
Not Categorized, Please Help
|
|
