nanogui: Thread: Re: nanoGui development

Alex,
	Thanks for answering so quickly.  It seems like you've got no
problem with me moving this stuff forward, since you've got other projects and
exams.  I've been looking for just this kind of initial project, since I'm into
"small" systems, guis, compiler/interpreters.

	I'll get all this stuff working, and change a few things so that
the project can be compiled as client/server, as well as a non-network version.  I also
have some ideas on how to better integrate the "screen drivers" (bogl) so that
different bits-per-pixel etc can be supported, and that the screen driver interface
is extremely well defined.

	I got into this because I've been watching the ELKS development work,
and they were wondering whether this work could used for their project.  The answer
is absolutely yes, although some direct real-mode linked in frame-buffer support would
be necessary.  To get ready for that, and the associated possible 16-bit compiles, this
project should use typedefs for the internal types, like colors, and x,y,w,h stuff.  I would
like to typedef all that stuff.  All-in-all, this would allow for nanoGui to become quite
portable.

	On another note, it took me quite a while to figure out the v2.2 framebuffer support,
since I was running v2.0.  It might be a good idea to include some setup info in your
FAQ.  With the low-level interface well implemented, it would also be fairly straight-forward
to include support for vgalib, which would allow older v2.0 linux users to run this.

Greg

On Monday, May 03, 1999 1:20 PM, Alex Holden ####@####.#### wrote:
> On Mon, 3 May 1999, Greg Haerr wrote:
> > 	After working dang near the whole weekend on it, I finally have the
> > nanoGui package up and running.  It turns out there were all sorts of unimplemented
> > routines...  I wrote all the event management stuff, GetNextEvent, CheckNext, Peek,
> > etc.  I was wondering, did this package ever run the examples/demo or exampes/landmine?
> 
> It did before I broke quite a lot of it in writing the network code and
> (starting to) fix various things which were badly done the first time
> round.
> 
> > It appears that they never ran.  In any case, I've got the demo running now.  I've also
> 
> Great.
> 
> > written a stub library that allows the application to be linked directly to the server,
> > so that the network stuff can be debugged separately.
> 
> Haha. That sounds like it was before I started on it ;) Originally the
> application and server were linked together because the original author
> never got around to writing the network stuff.
> 
> > 	There's quite a few issues I would like to talk about.  Is there a way we could
> > talk?  I need to get an understanding as to what has worked etc, so I don't spend
> 
> Email is best, either personal or through the list. IRC isn't ideal for me
> as we have to pay for phone calls by the minute in the UK.
> 
> > too much time rewriting stuff that supposedly once worked...  By tonight I think
> > I'll have all the event stuff completely working, as well as the text output.  I'm also
> > ready to put in the fixes for cursor hiding during drawing, etc.
> 
> I'm not working on Nano-X currently myself, as I have a couple of projects
> for Uni to finish off very urgently, plus exams in a couple of weeks. The
> only reason I released it when I did really was because I knew I wouldn't
> have any time to spend on it myself for a while, but that others might
> want to have a go...
>  
> > 	Are you currently doing all this also, or should I send you my source?
> 
> No, I don't have the time to do it myself at the moment. I'll give you
> the details for write access to the CVS server in a seperate mail, so you
> can sync your stuff up yourself.
> 
> --------------- Linux- the choice of a GNU generation. --------------
> : Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
> -------------------- http://www.linuxhacker.org/ --------------------
> 

On Mon, 3 May 1999, Greg Haerr wrote:
> 	Thanks for answering so quickly.  It seems like you've got no
> problem with me moving this stuff forward, since you've got other projects and
> exams.  I've been looking for just this kind of initial project, since I'm into
> "small" systems, guis, compiler/interpreters.

Yep, no problem. I find it interesting making systems which require less
than 64MB Ram and a 1GB hard disk to run optimally too :) I've spent quite
a bit of time developing for small PICs, and it's amazing what you can do
with a few hundred bytes if that's all you have.

> 	I'll get all this stuff working, and change a few things so that
> the project can be compiled as client/server, as well as a non-network version.  I also
> have some ideas on how to better integrate the "screen drivers" (bogl) so that
> different bits-per-pixel etc can be supported, and that the screen driver interface
> is extremely well defined.

Okay, I was talking to someone else who has also ported mini-X to
Linux-2.2 framebuffer, but done it without bogl. He was interested in
merging his work with nano-X, but I haven't been able to contact him
lately as his DNS is dead. If his code is a better way of doing it than
bogl, I might use that instead, but I haven't seen it yet. Certainly a way
of supporting more bit-depth levels, preferrably in the same binary with
autodetection, is needed.

> 	I got into this because I've been watching the ELKS development work,
> and they were wondering whether this work could used for their project.  The answer

That's something I've never played with...

> is absolutely yes, although some direct real-mode linked in frame-buffer support would
> be necessary.  To get ready for that, and the associated possible 16-bit compiles, this
> project should use typedefs for the internal types, like colors, and x,y,w,h stuff.  I would
> like to typedef all that stuff.  All-in-all, this would allow for nanoGui to become quite
> portable.

Yes, quite a lot of it is typedef'd to start with.

> 	On another note, it took me quite a while to figure out the v2.2 framebuffer support,
> since I was running v2.0.  It might be a good idea to include some setup info in your
> FAQ.  With the low-level interface well implemented, it would also be fairly straight-forward
> to include support for vgalib, which would allow older v2.0 linux users to run this.

I never used the framebuffer on a 2.0 kernel... Perhaps a pointer to the
Alex Buell's Framebuffer-HOWTO would be a good idea?

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

Definitely put a link to Alex Buell's Framebuffer HOWTO...

On Monday, May 03, 1999 3:57 PM, Alex Holden ####@####.#### wrote:
> On Mon, 3 May 1999, Greg Haerr wrote:
> > 	Thanks for answering so quickly.  It seems like you've got no
> > problem with me moving this stuff forward, since you've got other projects and
> > exams.  I've been looking for just this kind of initial project, since I'm into
> > "small" systems, guis, compiler/interpreters.
> 
> Yep, no problem. I find it interesting making systems which require less
> than 64MB Ram and a 1GB hard disk to run optimally too :) I've spent quite
> a bit of time developing for small PICs, and it's amazing what you can do
> with a few hundred bytes if that's all you have.
> 
> > 	I'll get all this stuff working, and change a few things so that
> > the project can be compiled as client/server, as well as a non-network version.  I also
> > have some ideas on how to better integrate the "screen drivers" (bogl) so that
> > different bits-per-pixel etc can be supported, and that the screen driver interface
> > is extremely well defined.
> 
> Okay, I was talking to someone else who has also ported mini-X to
> Linux-2.2 framebuffer, but done it without bogl. He was interested in
> merging his work with nano-X, but I haven't been able to contact him
> lately as his DNS is dead. If his code is a better way of doing it than
> bogl, I might use that instead, but I haven't seen it yet. Certainly a way
> of supporting more bit-depth levels, preferrably in the same binary with
> autodetection, is needed.
> 
> > 	I got into this because I've been watching the ELKS development work,
> > and they were wondering whether this work could used for their project.  The answer
> 
> That's something I've never played with...
> 
> > is absolutely yes, although some direct real-mode linked in frame-buffer support would
> > be necessary.  To get ready for that, and the associated possible 16-bit compiles, this
> > project should use typedefs for the internal types, like colors, and x,y,w,h stuff.  I would
> > like to typedef all that stuff.  All-in-all, this would allow for nanoGui to become quite
> > portable.
> 
> Yes, quite a lot of it is typedef'd to start with.
> 
> > 	On another note, it took me quite a while to figure out the v2.2 framebuffer support,
> > since I was running v2.0.  It might be a good idea to include some setup info in your
> > FAQ.  With the low-level interface well implemented, it would also be fairly straight-forward
> > to include support for vgalib, which would allow older v2.0 linux users to run this.
> 
> I never used the framebuffer on a 2.0 kernel... Perhaps a pointer to the
> Alex Buell's Framebuffer-HOWTO would be a good idea?
> 
> --------------- Linux- the choice of a GNU generation. --------------
> : Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
> -------------------- http://www.linuxhacker.org/ --------------------
> 

Greg Haerr writes:
> 
> 	I got into this because I've been watching the ELKS development work,
> and they were wondering whether this work could used for their project.  The answer
> is absolutely yes, although some direct real-mode linked in frame-buffer support would
> be necessary.  To get ready for that, and the associated possible 16-bit compiles, this
> project should use typedefs for the internal types, like colors, and x,y,w,h stuff.  I would
> like to typedef all that stuff.  All-in-all, this would allow for nanoGui to become quite
> portable.
> 

I have been lurking on this list for the very same reason, and as soon as
I can get nano-gui to work I will have a look at getting it to work under
ELKS in ernest. It will probably initially only work on UNIX sockets as we
are a long way from having a TCP/IP stack, and UNIX sockets are going to be
much simpler to implement. I also suspect that getting hold of a flat
framebuffer in 8086 real mode is a bit unlikely so more porting work is
going to be required there. Unfortunatly getting things to work on ELKS
often involved feature stripping them, which often does not add to
portability.

If you could make the code you have available I would be very interested in
looking at it and testing it out, finding bugs etc.

Al
--
Alistair Riddoch
ELKS kernel developer

On Tue, 4 May 1999, Alistair Riddoch wrote:
> I have been lurking on this list for the very same reason, and as soon as
> I can get nano-gui to work I will have a look at getting it to work under
> ELKS in ernest. It will probably initially only work on UNIX sockets as we
> are a long way from having a TCP/IP stack, and UNIX sockets are going to be
> much simpler to implement. I also suspect that getting hold of a flat

It does already use Unix sockets, not TCP/IP. I suspect it would be a bit
of a security liability currently if you let it run on a networked machine
with access to it via TCP/IP ;) That said, putting the basics of a TCP/IP
interface into it should be pretty easy.

> If you could make the code you have available I would be very interested in
> looking at it and testing it out, finding bugs etc.

I've given Greg CVS write access, so when he checks it in you'll be able
to get it from there.

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

Alistair -
	I've got the nanoGui project moved up quite a bit.  It now runs the sample
programs pretty well.  As Alan mentioned, I'll be checking all this stuff in shortly.
I've also made a makefile option that allows the graphics application to be linked
directly with the nanoX server.  This means that you won't have to implement any sockets
in the ELKS kernel for initial testing.  Following are the things that someone will have
to worry about (I'm planning on getting to these, but I still can't develop on ELKS, 
and cross-development is a pain...  BTW I have the bcc tools source hacked to 
self-host now, for instance it will compile the ANSI C Minix libc source on Minix...)
Anyway, the following needs to be addressed for nanoGui on ELKS:

	o A real mode VGA driver (we can use int 10h for this, pretty easy, then
hack bogl for 16-bit ints)  BTW this driver also needs to switch between text
and graphics modes, rather than using consoles.  I recommend that all the graphics/text
stuff remain in nanoGui for ELKS for the time being, we don't need a bigger kernel for this.
Taking this approach means that ELKS can leave out all graphics stuff from the kernel
for the time being.

	o A mouse driver (this is more of a pain, we could still leave it out of the kernel)

	o Kernel select() support for mouse and keyboard fd's (note that we require
tty ~ICANON raw mode.  (^C signal handling would be nice to abort the server on bad errors)

	o Nanogui uses ANSI prototypes that won't compile with bcc, unless someone
wants my ansi modifications,  I'm thinking of releasing it myself.


	Currently, NanoGui implements a decent subset of low-level X primitives, although
they're renamed.  Window creation, GC manipulation and text routines work.  We still
need some better low-level drawcode support.  For instance, XOR drawing isn't done yet.

	My plan is to take nanoGui and abstract the mouse, keyboard and screen
interfaces into fully defined interfaces within structures, that would allow nanoGui to become
completely portable with anyone able to roll their own drivers.  I should have this work done
in a couple of days.  I've got to hook up my linux box to the net to use the CVS checkin,
hopefully that'l get done tonight or tomorrow.

Greg


On Tuesday, May 04, 1999 4:13 AM, Alistair Riddoch ####@####.#### wrote:
> Greg Haerr writes:
> > 
> > 	I got into this because I've been watching the ELKS development work,
> > and they were wondering whether this work could used for their project.  The answer
> > is absolutely yes, although some direct real-mode linked in frame-buffer support would
> > be necessary.  To get ready for that, and the associated possible 16-bit compiles, this
> > project should use typedefs for the internal types, like colors, and x,y,w,h stuff.  I would
> > like to typedef all that stuff.  All-in-all, this would allow for nanoGui to become quite
> > portable.
> > 
> 
> I have been lurking on this list for the very same reason, and as soon as
> I can get nano-gui to work I will have a look at getting it to work under
> ELKS in ernest. It will probably initially only work on UNIX sockets as we
> are a long way from having a TCP/IP stack, and UNIX sockets are going to be
> much simpler to implement. I also suspect that getting hold of a flat
> framebuffer in 8086 real mode is a bit unlikely so more porting work is
> going to be required there. Unfortunatly getting things to work on ELKS
> often involved feature stripping them, which often does not add to
> portability.
> 
> If you could make the code you have available I would be very interested in
> looking at it and testing it out, finding bugs etc.
> 
> Al
> --
> Alistair Riddoch
> ELKS kernel developer
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
> 
> 

On Tue, 4 May 1999, Greg Haerr wrote:
> 	I've got the nanoGui project moved up quite a bit.  It now runs the sample
> programs pretty well.  As Alan mentioned, I'll be checking all this stuff in shortly.
                             ^ Alex 

> 	o A mouse driver (this is more of a pain, we could still leave it out of the kernel)

If you don't want to use GPM, there was some simple MS and PS2 protocol
stuff in there before which didn't work. You could try getting that 
working as a compile time option.
 
> 	o Nanogui uses ANSI prototypes that won't compile with bcc, unless someone
> wants my ansi modifications,  I'm thinking of releasing it myself.

Oops. Mini-X was K&R, but I changed it all to ANSI because I thought no
sane compiler didn't do ANSI these days ;) What's bcc anyway?

> 	Currently, NanoGui implements a decent subset of low-level X primitives, although
> they're renamed.  Window creation, GC manipulation and text routines work.  We still
> need some better low-level drawcode support.  For instance, XOR drawing isn't done yet.

I wouldn't mind renaming them all to get them closer to X.

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

Sorry, Alex, for some reason I was thinking that you and Alan Cox were named Alan  ;-)

I think its better to use ANSI C prototypes.  bcc is the compiler that ELKS uses, 
its a pretty good, small C compiler that compiles 16 and 32 bit.  I have modifed
it to compile ansi functions.

In regards to GPM, I will abstract it to yet another mouse driver, which will allow
any mouse driver to be used.

In regards to X, it might be a good idea to rename stuff, but I think it's fine for now.

I would be interested in a bunch of other simple X programs to add to the test suite, though.
We could create a #define header file to convert the function calls...

Greg

On Tuesday, May 04, 1999 11:32 AM, Alex Holden ####@####.#### wrote:
> On Tue, 4 May 1999, Greg Haerr wrote:
> > 	I've got the nanoGui project moved up quite a bit.  It now runs the sample
> > programs pretty well.  As Alan mentioned, I'll be checking all this stuff in shortly.
>                              ^ Alex 
> 
> > 	o A mouse driver (this is more of a pain, we could still leave it out of the kernel)
> 
> If you don't want to use GPM, there was some simple MS and PS2 protocol
> stuff in there before which didn't work. You could try getting that 
> working as a compile time option.
>  
> > 	o Nanogui uses ANSI prototypes that won't compile with bcc, unless someone
> > wants my ansi modifications,  I'm thinking of releasing it myself.
> 
> Oops. Mini-X was K&R, but I changed it all to ANSI because I thought no
> sane compiler didn't do ANSI these days ;) What's bcc anyway?
> 
> > 	Currently, NanoGui implements a decent subset of low-level X primitives, although
> > they're renamed.  Window creation, GC manipulation and text routines work.  We still
> > need some better low-level drawcode support.  For instance, XOR drawing isn't done yet.
> 
> I wouldn't mind renaming them all to get them closer to X.
> 
> --------------- Linux- the choice of a GNU generation. --------------
> : Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
> -------------------- http://www.linuxhacker.org/ --------------------
> 

On Tue, 4 May 1999, Greg Haerr wrote:
> I think its better to use ANSI C prototypes.  bcc is the compiler that ELKS uses, 

I agree.

> its a pretty good, small C compiler that compiles 16 and 32 bit.  I have modifed
> it to compile ansi functions.

Interesting. Is it x86 only?

> In regards to GPM, I will abstract it to yet another mouse driver, which will allow
> any mouse driver to be used.

Fine. Alternatively you could just write a tiny replacement for GPM which
generates mouse-systems format data (_very_ simple) on a pipe, which is
what GPM repeater mode does. 
 
> I would be interested in a bunch of other simple X programs to add to the test suite, though.
> We could create a #define header file to convert the function calls...

Is it just the names which are different, or are the arguments different
too? The first thing I'd like to get going is some kind of simple
Xterm-like program, then some kind of minimal window manager.

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

I thought that the GPM repeater mode took any mouse and rewrote it to Logitech
style commands, so that nanoGui has only one set of commands to parse...

bcc runs on linux only, although I have ported it to Minix, and when ELKS gets
stable, I hope to use it to self-host ELKS.  It has it's own assembler and linker and produces
older a.out minix-style binaries.

I think there's alot of work getting a small xterm together, do you know
of any really small xterm's anywhere?

The window manager will have to be linked into nanoGui, and needs to draw the window
borders.  I have some ideas on this.

Greg

On Tuesday, May 04, 1999 11:49 AM, Alex Holden ####@####.#### wrote:
> On Tue, 4 May 1999, Greg Haerr wrote:
> > I think its better to use ANSI C prototypes.  bcc is the compiler that ELKS uses, 
> 
> I agree.
> 
> > its a pretty good, small C compiler that compiles 16 and 32 bit.  I have modifed
> > it to compile ansi functions.
> 
> Interesting. Is it x86 only?
> 
> > In regards to GPM, I will abstract it to yet another mouse driver, which will allow
> > any mouse driver to be used.
> 
> Fine. Alternatively you could just write a tiny replacement for GPM which
> generates mouse-systems format data (_very_ simple) on a pipe, which is
> what GPM repeater mode does. 
>  
> > I would be interested in a bunch of other simple X programs to add to the test suite, though.
> > We could create a #define header file to convert the function calls...
> 
> Is it just the names which are different, or are the arguments different
> too? The first thing I'd like to get going is some kind of simple
> Xterm-like program, then some kind of minimal window manager.
> 
> --------------- Linux- the choice of a GNU generation. --------------
> : Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
> -------------------- http://www.linuxhacker.org/ --------------------
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>