nanogui: Re: NanoX version 0.5
Subject:
RE: NanoX version 0.5
From:
Greg Haerr ####@####.####
Date:
18 May 1999 19:27:03 -0000
Message-Id: <01BEA12F.A058C6A0.greg@censoft.com>
> Bogl already supports pretty much every framebuffer type except for mono,
> and when I finally get my Geofox, I'll add support for MFB to Bogl.
I'm thinking about the idea of taking the original bogl stuff for
all the different framebuffer devices, and making a single nanoX framebuffer
driver from them. Then people can add various smaller features for their
particular framebuffer without starting from scratch... What do you think?
>
> > non-linux systems, like palmtops, we have to keep emphasizing the driver
>
> Palmtops generally come with their own GUI. Nano-X is only interesting in
> that situation if you run Linux (or ucLinux, or NetBSD) on it.
>
No, because the nanoX driver encapsulates all the needed functionality
for all the (currently mini-x) programs above it, by writing one driver, you can port
all your neat programs to another operating system.
I personally feel that, Vidar's comments aside, nano-X on linux isn't that
interesting because linux already has X, which is a lot more powerful. Certainly
it can be used as a base for booting linux, though.
Another good question is: what api do we want to build all the widgets
on top of? My thoughts are that noone wants to rewrite widgets all the time,
so we should pick some base that there are quite a few widgets already written.
Then, make those already written widgets work with nanoX. We need at least
Button, radio button, check box, scrollbar, listbox, and pop-down listbox. If anyone
has small code for these built on top of Xlib that use their own (good looking)
draw code, it'd be nice to look at them.
I have a full custom control set for the Win32 api, that by implementing
a very small set of GDI calls on top of a modified nanoX engine, will give us
all the above controls and more...
Greg
