nanogui: Re: [Handhelds] pocket linux: how to install / microwindows
Subject:
Re: [Handhelds] pocket linux: how to install / microwindows
From:
"Greg Haerr" ####@####.####
Date:
18 Aug 2000 17:56:50 -0000
Message-Id: <02f401c0093d$b0bceb80$15320cd0@gregh>
: * Is it possible to run microwindows and fltk programs on top of
: pocketlinux or is it java-only? If yes, why not take the other way and
: run kaffe on top of handhelds.org's linux and microwindows?
I've just returned from the LinuxWorld Expo and talked extensively
with the PocketLinux folks. Currently, their product is java-only,
but they have indicated interest in their Kaffe port on top of
Microwindows. BTW, effective Tuesday they released
their full-blown Kaffe complete with full-blown AWT as open
source. This is very exciting, since the previous Kaffe
didn't fully implement AWT.
Currently, it seems the PocketLinux strategy is to have a complete
self-contained system that does all sorts of interesting things, all
basically coded in Java, and running on a single JVM interpreter
that uses a framebuffer-based AWT for the draw code. This
means no windows, no additional non-java applications. Of course,
the first minute I saw it I thought how cool it would be to have
all that running in a window, and have the ability to run other
non-java apps in another [full-screen] window, using Microwindows.
But that's not really the intent of the PocketLinux platform.
With a technically minor Microwindows enhancement, any
previous framebuffer-only application could run on top of the
Microwindows/Nano-X environment almost unmodified, and
still allow any other Nano-X clients to run.
This modification would be: instead of the original framebuffer-
based application (in this case PocketLinux Kaffe) opening
/dev/fb0 directly and drawing the mmap'd framebuffer,
it would make a Nano-X GrOpen(), requesting
a framebuffer address. Microwindows would then
respond by allocating a window, but then returning a
client-side memory mapping for that window's framebuffer
offset. Of course, for full-screen windows, that memory
address would be the same as the real framebuffer address.
For non-full screen windows, there are some complications
for handling overlapped window clipping or automatic
portrait mode, but these could be left until later. The
original application's main event loop would need some
tweaking also.
Regards,
Greg
