nanogui: Thread: Re: NanoX version 0.5

> 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

On Tue, 18 May 1999, Greg Haerr wrote:
> 	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?

I don't see why. It's simpler and easier to have a different driver for
each type of frame buffer, and it's better to be able to only compile in
the one that you need.

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

Running a Nano-X server on top of a PDA GUI?

> 	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

People with Linux based palmtops and embedded systems with only a few megs
of flash, but need the networking capabilities of Linux and a user
friendly graphical interface might disagree with you.

--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
-------------------- http://www.linuxhacker.org/ --------------------

> I don't see why. It's simpler and easier to have a different driver for
> each type of frame buffer, and it's better to be able to only compile in
> the one that you need.
> 
> > 	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 suggested this for the very reason that you thought it a good idea
to toss ReadPixel.  Maintaining multiple drivers for similar architectures is more
of a job than it seems.

Greg

On Tue, 18 May 1999, Greg Haerr wrote:
> 	I suggested this for the very reason that you thought it a good idea
> to toss ReadPixel.  Maintaining multiple drivers for similar architectures is more
> of a job than it seems.

I never said that there shouldn't be a readpixel(), and I never "tossed"
it either. I simply haven't implemented it yet in Bogl because I'm not
convinced that's the best way to do it yet. It may be, but I want to do
some additional research on the topic first. Also, a large complex driver
is harder to maintain than several simple ones, and takes up more memory
if you only wanted it to do the function of one of the smaller ones. It
would also probably be slower if it isn't optimised for one specific bit
depth.

--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
-------------------- http://www.linuxhacker.org/ --------------------