nanogui: Thread: Status?

What is the current status of Nano X?

I've been away for a while, and have been catching up on the list.. I've
looked at both Alex' and Gregs archives, and it doesn't look like too much
have happened in the last couple of months.

I'm working on a widget set for Nano-X now (based on some code Alexander
Peuchert wrote and was nice enough to send me), and during that work I've
found quit a bit of bugs, in particular in the network support...

Some of them I've fixed, some I'm still struggling with.

I've also started seeing a few shortcomings that needs to be dealt with,
especially with regard to palette handling, and of course server side
pixmaps etc.

So, is anyone working on modifications, fixes etc. to Nano-X that aren't
publicly available yet? I'd love to take a look at any work in
progress, and help out if possible. And what is the current official tree,
and who would be the right person(s) to send patches to?

My bug fixes are mostly against 0.5pre3, but most of them also apply to
the Microwindows release (allthough for some reason my widget set and test
program won't work at all with the Microwindows version of Nano-X even
with the bugfixes). I also have a mostly working GGI driver for 0.5pre3.

Btw., we're finally hiring more developers, and I'll allocate at least one
of them to work on Nano-X, and also to port the open sourced flash player.
We're also sharing the cost for a developer to port a web browser to
Nano-X with another company. 

Regards,

Vidar Hokstad ####@####.####
Director of Technical Development, Screen Media AS

On Mon, 6 Sep 1999, Vidar Hokstad wrote:
> What is the current status of Nano X?

As I told somebody else just this morning, it's more or less "in stasis"
as I'm currently working up to 13 hours a day on another project.

> I'm working on a widget set for Nano-X now (based on some code Alexander
> Peuchert wrote and was nice enough to send me), and during that work I've
> found quit a bit of bugs, in particular in the network support...

The original network code was wrong from the outset, what it should have
done instead of a command response, was to package up the request and
stick it in a queue, which should be forwarded to the server in one block
whenever a function is executed which requires a result to be returned. I
started doing this, and I think the code I did is in the CVS.

> Some of them I've fixed, some I'm still struggling with.

If it's in the networking code, I'd abandon it and start again with the
new model (much more efficient and less problems with error conditions).

> So, is anyone working on modifications, fixes etc. to Nano-X that aren't
> publicly available yet? I'd love to take a look at any work in
> progress, and help out if possible. And what is the current official tree,
> and who would be the right person(s) to send patches to?

My preference is for people to use the CVS tree on linuxhacker.org. If
anyone else wants write access, just let me know.

> Btw., we're finally hiring more developers, and I'll allocate at least one
> of them to work on Nano-X, and also to port the open sourced flash player.
> We're also sharing the cost for a developer to port a web browser to
> Nano-X with another company. 

Cool. You're not the first person to say that they are seriously 
considering allocating a developer to work full time on Nano-X either :)
I'd really like to see Nano-X take off, I just don't have any free time to
work on it. Linuxhacker.org is of course always at your disposal for
mailing list, web, ftp, cvs, etc. services...

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

On Mon, 6 Sep 1999, Alex Holden wrote:

> The original network code was wrong from the outset, what it should have
> done instead of a command response, was to package up the request and
> stick it in a queue, which should be forwarded to the server in one block
> whenever a function is executed which requires a result to be returned. I
> started doing this, and I think the code I did is in the CVS.

Great... I have been seriously considering doing the same, but I didn't
want to mess with it until I'd checked on the status.

> My preference is for people to use the CVS tree on linuxhacker.org. If
> anyone else wants write access, just let me know.

Ok.. I'l take a look at the CVS version :)
 
> Cool. You're not the first person to say that they are seriously 
> considering allocating a developer to work full time on Nano-X either :)
> I'd really like to see Nano-X take off, I just don't have any free time to
> work on it. Linuxhacker.org is of course always at your disposal for
> mailing list, web, ftp, cvs, etc. services...

We *need* a small GUI, and currently that's NanoX, so we'll have to make
sure it works at least well enough for our purpose... :-)

Now the only delay for us is actually finding the right person.. So if
anyone in Oslo, Norway is following this list, they should mail me ASAP
for a new cool Linux related job :) (we will consider people who will work
remotely too, but it's easiest for us to deal with someone here).

Regards,

Vidar Hokstad ####@####.####
Director of Technical Development, Screen Media AS

> I've also started seeing a few shortcomings that needs to be dealt with,
> especially with regard to palette handling, and of course server side
> pixmaps etc.

The code that nanogui is based on was for an EGA system, which kind of limited
the colour issue. It does need proper colour stuff adding. Nobody is doing
it right now. Similarly for size reasons server side pixmaps werent in
the original (and it would be good to keep them optional)

> Btw., we're finally hiring more developers, and I'll allocate at least one
> of them to work on Nano-X, and also to port the open sourced flash player.
> We're also sharing the cost for a developer to port a web browser to
> Nano-X with another company. 

Mozilla is almost ready to be hackable to Nanogui. The Mozilla drawn widgets
(eg the Xlib mode) are about to get turned on properly. At that point you
don't even need a toolkit as such to get Mozilla up

On Mon, 6 Sep 1999, Alan Cox wrote:

> The code that nanogui is based on was for an EGA system, which kind of limited
> the colour issue. It does need proper colour stuff adding. Nobody is doing
> it right now. Similarly for size reasons server side pixmaps werent in
> the original (and it would be good to keep them optional)

I guess I'll take a look at it, at soon as I get Alex' network code
rewrite to work :)

> Mozilla is almost ready to be hackable to Nanogui. The Mozilla drawn widgets
> (eg the Xlib mode) are about to get turned on properly. At that point you
> don't even need a toolkit as such to get Mozilla up

I know, but we may end up with another browser than Mozilla for our web
terminal, because of space considerations. We hope to end up with about
1MB for Nano-X + browser + our glue (kernel and glibc comes on top of that
of course), and it seems well within reach.

I still want to look into getting Mozilla to work on Nano-X, but that will
probably be on the side of what I'm doing at work.

Regards,
Vidar Hokstad ####@####.####
Director of Technical Development, Screen Media AS

I have been thinking about using Nano-X as the basis for the Linux CE gui.
I haven't started on it yet, but last night I just finished a working
framebuffer driver for the Vadem Clio, so it looks like the next step is the
gui.  Oh, in case you didn't hear, we have Linux up and running on a few
Windows CE devices.  See:

    http://www.ltc.com/linux-mips

for more info.

It sounds like our projects may overlap considerably, and I would be
interested in exploring collaboration options.

Regards,
Brad

----- Original Message -----
From: Vidar Hokstad ####@####.####
To: Alex Holden ####@####.####
Cc: NanoGUI mailing list ####@####.####
Sent: Monday, September 06, 1999 6:55 AM
Subject: Re: Status?


> On Mon, 6 Sep 1999, Alex Holden wrote:
>
> > The original network code was wrong from the outset, what it should have
> > done instead of a command response, was to package up the request and
> > stick it in a queue, which should be forwarded to the server in one
block
> > whenever a function is executed which requires a result to be returned.
I
> > started doing this, and I think the code I did is in the CVS.
>
> Great... I have been seriously considering doing the same, but I didn't
> want to mess with it until I'd checked on the status.
>
> > My preference is for people to use the CVS tree on linuxhacker.org. If
> > anyone else wants write access, just let me know.
>
> Ok.. I'l take a look at the CVS version :)
>
> > Cool. You're not the first person to say that they are seriously
> > considering allocating a developer to work full time on Nano-X either :)
> > I'd really like to see Nano-X take off, I just don't have any free time
to
> > work on it. Linuxhacker.org is of course always at your disposal for
> > mailing list, web, ftp, cvs, etc. services...
>
> We *need* a small GUI, and currently that's NanoX, so we'll have to make
> sure it works at least well enough for our purpose... :-)
>
> Now the only delay for us is actually finding the right person.. So if
> anyone in Oslo, Norway is following this list, they should mail me ASAP
> for a new cool Linux related job :) (we will consider people who will work
> remotely too, but it's easiest for us to deal with someone here).
>
> Regards,
>
> Vidar Hokstad ####@####.####
> Director of Technical Development, Screen Media AS
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: ####@####.####
> For additional commands, e-mail: ####@####.####
>

: I've been away for a while, and have been catching up on the list.. I've
: looked at both Alex' and Gregs archives, and it doesn't look like too much
: have happened in the last couple of months.

	Yep, I kinda shut down after it seemed that the list quieted down,
and all my mods were done.


: 
: I'm working on a widget set for Nano-X now (based on some code Alexander
: Peuchert wrote and was nice enough to send me), and during that work I've
: found quit a bit of bugs, in particular in the network support...
: 
	The network support has never worked, and will regularly core dump.


: Some of them I've fixed, some I'm still struggling with.
: 
: I've also started seeing a few shortcomings that needs to be dealt with,
: especially with regard to palette handling, and of course server side
: pixmaps etc.

	Very extensive palette handling is completed in the MicroWindows 0.82
release.  This version also supports the nano-X api.  All the color handling code
is written in the "portable across user-api's" middle device layer, devdraw.c.
Basically, the color model was enhanced to full RGB support in 0.82, with
the GR_COLOR expanded from an unsigned short "ansi color number" from 0-15
to an unsigned long RGB color.  The system is compiled with 16 color or
256 color palette tables, and then the requested RGB color is distance-cubed
compared with the palette.  Various mechanisms exist for remapping the system
palette with the nano-X palette, for use with 256 color pictures.  My work
was initially with MicroWindows in this area, and I completed all the work
for color bitmaps.  The system should also work with truecolor hardware,
but I've never been able to get the framebuffer stuff to work in truecolor.


: 
: So, is anyone working on modifications, fixes etc. to Nano-X that aren't
: publicly available yet? I'd love to take a look at any work in
: progress, and help out if possible. And what is the current official tree,
: and who would be the right person(s) to send patches to?

	Alex maintains a tree for the network code he started working
on some months ago.  My tree contains many enhancements, including
color management, cursor management, ELKS port, SVGAlib port, etc.
See the ChangeLog for details.  The Microwindows project also entailed
quite a few changes to nano-X that will be required when someone
writes a window manager.  (I wrote on for Microwindows, but was waiting
for others for nano-X.)

: 
: My bug fixes are mostly against 0.5pre3, but most of them also apply to
: the Microwindows release (allthough for some reason my widget set and test
: program won't work at all with the Microwindows version of Nano-X even
: with the bugfixes). I also have a mostly working GGI driver for 0.5pre3.

	The color model changed, and you can't use simple integers for
colors anymore.  In  many cases, the simple integers 0-15 come out quite
black ;-)  The MicroWindows tree has no reported/known bugs.

Greg

: The code that nanogui is based on was for an EGA system, which kind of limited
: the colour issue.

	Not quite.  The nanogui color model is based on the RGB system,
running on palettized hardware.  On truecolor systems, the color could be passed
thru.  Currently, all color management is done on top of the hardware, with a single
driver-level setpalette() call to map RGB entries.

 It does need proper colour stuff adding. Nobody is doing
: it right now. Similarly for size reasons server side pixmaps werent in
: the original (and it would be good to keep them optional)

	Color bitmaps (windows) are implemented.  Yes, someone does
need to implement color pixmaps (X).  This should be easy.

: Mozilla is almost ready to be hackable to Nanogui. The Mozilla drawn widgets
: (eg the Xlib mode) are about to get turned on properly. At that point you
: don't even need a toolkit as such to get Mozilla up
: 
	I think the best way to go for nano-X would be the approach I took for MicroWindows.
That is, the nano-X api should be a "completely compatible" api with some standard
api.  Xlib is the one that comes to mind.  In this fashion, there's little time spent
debating api's, instead more time implementing them.  This flushes out design
issues in the basic engine.  At the same time, reference implementations of Xlib
abound, and the only decisions is which portions to implement when.  It is surprising
how much can run on top of even a partially-implemented graphics api.
	This method allows alot of code to be moved over quickly.  Certain
components can then be rewritten if an api "shortcut" is taken, rather than 
writing them from scratch...

Greg

On Tue, 7 Sep 1999, Greg Haerr wrote:

> : I'm working on a widget set for Nano-X now (based on some code Alexander
> : Peuchert wrote and was nice enough to send me), and during that work I've
> : found quit a bit of bugs, in particular in the network support...
> : 
> 	The network support has never worked, and will regularly core dump.

Actually, it works just fine for me with the 0.5pre3 release, and a couple
of minor bug fixes.
 
> 	Very extensive palette handling is completed in the MicroWindows 0.82
> release.  This version also supports the nano-X api.  All the color handling code
> is written in the "portable across user-api's" middle device layer, devdraw.c.

> Basically, the color model was enhanced to full RGB support in 0.82, with
> the GR_COLOR expanded from an unsigned short "ansi color number" from 0-15
> to an unsigned long RGB color.  The system is compiled with 16 color or
> 256 color palette tables, and then the requested RGB color is distance-cubed
> compared with the palette.  Various mechanisms exist for remapping the system
> palette with the nano-X palette, for use with 256 color pictures.  My work
> was initially with MicroWindows in this area, and I completed all the work
> for color bitmaps.  The system should also work with truecolor hardware,
> but I've never been able to get the framebuffer stuff to work in truecolor.

This sounds like the right way to go... The mess of a color system in X
doesn't exactly contribute to small programs :-) 
 
 
> : So, is anyone working on modifications, fixes etc. to Nano-X that aren't
> : publicly available yet? I'd love to take a look at any work in
> : progress, and help out if possible. And what is the current official tree,
> : and who would be the right person(s) to send patches to?
> 
> 	Alex maintains a tree for the network code he started working
> on some months ago.

I've taken a look at that, and I'm debating whether I should try to
complete it, or write something along the same line (I have some ideas
that should be about as flexible, but save quite a few function calls,
as well as use less memory).

> My tree contains many enhancements, including
> color management, cursor management, ELKS port, SVGAlib port, etc.
> See the ChangeLog for details.  The Microwindows project also entailed
> quite a few changes to nano-X that will be required when someone
> writes a window manager.  (I wrote on for Microwindows, but was waiting
> for others for nano-X.)

Ok..

I guess it would be about time to try to merge as much as possible
together. It's a nuisance to have two trees (and as I've mentioned I've
got some changes lieing around too).

Have you two discussed any merging of the trees?

> : My bug fixes are mostly against 0.5pre3, but most of them also apply to
> : the Microwindows release (allthough for some reason my widget set and test
> : program won't work at all with the Microwindows version of Nano-X even
> : with the bugfixes). I also have a mostly working GGI driver for 0.5pre3.
 
> 	The color model changed, and you can't use simple integers for
> colors anymore.  In  many cases, the simple integers 0-15 come out quite
> black ;-)  The MicroWindows tree has no reported/known bugs.

Aha... I guess that might be part of the problem. But it also locks up in
some cases that work fine with 0.5pre3. But then I use the network code,
so that might be the cause of the problems.

Vidar Hokstad ####@####.####
Director of Technical Development, Screen Media AS

On Tue, 7 Sep 1999, Greg Haerr wrote:

> : Mozilla is almost ready to be hackable to Nanogui. The Mozilla drawn widgets
> : (eg the Xlib mode) are about to get turned on properly. At that point you
> : don't even need a toolkit as such to get Mozilla up
> : 
> 	I think the best way to go for nano-X would be the approach I took for MicroWindows.
> That is, the nano-X api should be a "completely compatible" api with some standard
> api.  Xlib is the one that comes to mind.  In this fashion, there's little time spent
> debating api's, instead more time implementing them.  This flushes out design
> issues in the basic engine.  At the same time, reference implementations of Xlib
> abound, and the only decisions is which portions to implement when.  It is surprising
> how much can run on top of even a partially-implemented graphics api.
> 	This method allows alot of code to be moved over quickly.  Certain
> components can then be rewritten if an api "shortcut" is taken, rather than 
> writing them from scratch...

I'm not sure I agree with this. X is fairly complex compared to what it
should be possible to run Mozilla on.

The color model is one example. Other things, such as line drawing,
doesn't exactly make it any prettier.

But as soon as the Gfx widgets (widgets drawn with the Mozilla Gfx
classes) are turned on by default only the basic graphics code will have
to be reimplemented to get Mozilla running. Also, parts of the graphics
code needed, such as region handling, are readily available in other open
source libraries, and are fairly generic.

Sure, a Xlib layer would make it easier to port other stuff, but I don't
think we should attempt to use the Xlib API by default.

Regards,
Vidar Hokstad ####@####.####
Director of Technical Development, Screen Media AS