nanogui: Thread: Re: [Handhelds] pocket linux: how to install / microwindows

: * 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

"Greg Haerr" ####@####.#### writes:

> : * 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.

Correct.  We released some of the stuff that previously was only
proprietary - but it still needs to be merged into the desktop
edition.  The goal is to have only one version of kaffe going forward.
It's a change in business direction for us.

> 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.  

That's basically correct.  For certain devices, such as PDAs, a pure
Java UI seems to make sense, and a desktop-style windowing system is
less useful.  Since our focus is on developing a full set of
application from scratch, we'd rather use Java, which isn't
surprising, given our background.  :-)

That said, I don't see any reason why it shouldn't be possible to
write apps in C (for example), and still have the output share the
screen.  In fact, I think that's what our MPEG2 video demonstration
does.  Some of the guys here think that it would be cool to get MAME
working inside the PocketLinux stuff...

I haven't played around with Linux virtual consoles on the iPaq - if
there was a way of switching them without using a keyboard, that might
be interesting.  That way, somebody would be able to run all the
different environments at the same time, and just switch between them.

> 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.

That sounds interesting.  It would be a cool hack.

As for us, we'd like to play nice with all the open source windowing
systems out there.  We like to think that interoperability and
portability is one of our strengths.  :-)

Cheers,

 - Jim


-- 
Really, I'm getting paid to play with all these toys.  :-)
http://www.pocketlinux.com/