nanogui: Thread: Small Xlib replacement

: I know. I was talking about Xlib too. We did consider changing the
: function names to closer match X, but it might confuse people into
: thinking that Nano-X is supposed to be a faithful clone of X, which it
: isn't.
	Perhaps the name should be changed Nano-Y then.  It's
already confusing.  Nano-X implies a smaller version of X.  Most
newbie questions on this list seem to want a small X.

 There are a lot of things which can be done (and are done) more
: simply than how X does it.

	That's a for sure ;-)


: 
: > The point is that the nano-X api is *already* Xlib compliant, but noone
: > realizes it, and that further slows development.  I'm not suggesting that
: > the API has to remain Xlib compatible, but when you've already got 90% of
: > your API compliant, why not?
: 
: It isn't anywhere near that close,

	Check out each function and it's arguments.  Although the types
are typedef'd, you'll find that very many are exactly the same, of course
lacking the Display * arg.

	In any case, if folks are looking for a small, highly functional
Xlib api that is *much* smaller than Xlib, but performs very similarly,
I'll write it.  I estimate that I could have it *finished* in about a week.
This would allow the Gtk etc guys to get their stuff running very quickly,
and then we could concentrate on the harder aspects that the engine
doesn't currently support, like off-screen pixmap drawing.

	The idea would be to implement the Xlib api quickly using exactly
the same parms as documented, until the engine or Xlib design required (because
of good design considerations, like size) a change.  This would end up
creating a large set of compatible routines, and a smaller set of incompatible routines.
Of course, anyone's free to add new api entry points to their heart's content.
Most of the initial engine work is completed, as evidenced by the MicroWindows demo.
As I've mentioned before, the biggest engine problem is lack of offscreen drawing
support, which involves some larger architecture/driver changes.

Greg

On Wed, 8 Sep 1999, Greg Haerr wrote:
> 	Perhaps the name should be changed Nano-Y then.  It's
> already confusing.  Nano-X implies a smaller version of X.  Most
> newbie questions on this list seem to want a small X.

The idea was that it does the equivalent of the X server for the NanoGUI
system (in retrospect probably a bad idea). It might be better to forget
the Nano-X name and call it NanoGUI instead. Or nanoserver and nanolib.

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

----- Original Message -----
From: Greg Haerr ####@####.####
To: 'Alex Holden' ####@####.####
Cc: Vidar Hokstad ####@####.#### ####@####.####
Sent: Wednesday, September 08, 1999 12:10 PM
Subject: Small Xlib replacement


> In any case, if folks are looking for a small, highly functional
> Xlib api that is *much* smaller than Xlib, but performs very similarly,
> I'll write it.  I estimate that I could have it *finished* in about a
week.
> This would allow the Gtk etc guys to get their stuff running very quickly,
> and then we could concentrate on the harder aspects that the engine
> doesn't currently support, like off-screen pixmap drawing.

I think you hit the nail right on the head.  I'm at the point in my current
Linux-MIPS project where I need something just like this.  I think that you
will be providing a *major* service to many people by doing this.  I highly
encourage you to proceed with your plan.

How can I help?  I'm not a Xlib programmer at all, but maybe getting your
work running in my Linux-MIPS project will be a good test.  What else can I
do?

Regards,
Brad

----- Original Message -----
From: Alex Holden ####@####.####
To: Greg Haerr ####@####.####
Cc: Vidar Hokstad ####@####.#### ####@####.####
Sent: Wednesday, September 08, 1999 12:30 PM
Subject: Re: Small Xlib replacement


> On Wed, 8 Sep 1999, Greg Haerr wrote:
> > Perhaps the name should be changed Nano-Y then.  It's
> > already confusing.  Nano-X implies a smaller version of X.  Most
> > newbie questions on this list seem to want a small X.
>
> The idea was that it does the equivalent of the X server for the NanoGUI
> system (in retrospect probably a bad idea). It might be better to forget
> the Nano-X name and call it NanoGUI instead. Or nanoserver and nanolib.

What is NanoGUI intented to be used for?  What is it the equivalent of?  Or,
maybe better, what will it replace?

Regards,
Brad

On Wed, 8 Sep 1999, Bradley D. LaRonde wrote:
> What is NanoGUI intented to be used for?  What is it the equivalent of?  Or,
> maybe better, what will it replace?

The GUIs of Photon, Epoc, PalmOS, Wince, etc. as well as the multitude of
embedded UIs you find in things like photocopiers (more and more of them
are being built with enough processor power and a good enough display to
be able to run Linux, ucLinux or ELKS and a tiny GUI).

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

----- Original Message -----
From: Alex Holden ####@####.####
To: Bradley D. LaRonde ####@####.####
Cc: Greg Haerr ####@####.#### ####@####.####
Sent: Wednesday, September 08, 1999 12:44 PM
Subject: Re: Small Xlib replacement


> On Wed, 8 Sep 1999, Bradley D. LaRonde wrote:
> > What is NanoGUI intented to be used for?  What is it the equivalent of?
Or,
> > maybe better, what will it replace?
>
> The GUIs of Photon, Epoc, PalmOS, Wince, etc. as well as the multitude of
> embedded UIs you find in things like photocopiers (more and more of them
> are being built with enough processor power and a good enough display to
> be able to run Linux, ucLinux or ELKS and a tiny GUI).

So one would have to write specifically to it, as one writes to Gnome or
KDE?

Regards,
Brad

> > embedded UIs you find in things like photocopiers (more and more of them
> > are being built with enough processor power and a good enough display to
> > be able to run Linux, ucLinux or ELKS and a tiny GUI).
> 
> So one would have to write specifically to it, as one writes to Gnome or
> KDE?

Neither. Gnome is built on gtk (which is window system independant (ish)) which
is built on gdk which is window system specific. So you port gdk you get
gnome on it - ditto Qt andd KDE.

In general both gnome and kde are a bit big for small pdas. Fltk looks more
promising

On Wed, 8 Sep 1999, Bradley D. LaRonde wrote:
> > The GUIs of Photon, Epoc, PalmOS, Wince, etc. as well as the multitude of
> > embedded UIs you find in things like photocopiers (more and more of them
> > are being built with enough processor power and a good enough display to
> > be able to run Linux, ucLinux or ELKS and a tiny GUI).
> So one would have to write specifically to it, as one writes to Gnome or
> KDE?

Not really, as you could theoretically port GDK, Glib, GTK+, and Gnome to
NanoGUI (probably without a huge amount of work) and then be able to
compile Gnome programs to run on NanoGUI. IE. Gnome and KDE are at a
higher layer than we're talking about. But yes, you would need to
either port the particular toolkit used to write the applications you're
interested in to NanoGUI or if it doesn't use a toolkit (most do), port
it directly to the NanoGUI API itself which, as Greg is saying, isn't a
million miles away from the X API. 

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

On Wednesday, September 08, 1999 10:40 AM, Alan Cox ####@####.#### wrote:
: > > embedded UIs you find in things like photocopiers (more and more of them
: > > are being built with enough processor power and a good enough display to
: > > be able to run Linux, ucLinux or ELKS and a tiny GUI).
: > 
: > So one would have to write specifically to it, as one writes to Gnome or
: > KDE?
: 
: Neither. Gnome is built on gtk (which is window system independant (ish)) which
: is built on gdk which is window system specific. So you port gdk you get
: gnome on it - ditto Qt andd KDE.
: 
: In general both gnome and kde are a bit big for small pdas. Fltk looks more
: promising
:
	Gtk is built on top of Xlib, right?

On Wednesday, September 08, 1999 10:40 AM, Alan Cox ####@####.#### wrote:
: > > embedded UIs you find in things like photocopiers (more and more of them
: > > are being built with enough processor power and a good enough display to
: > > be able to run Linux, ucLinux or ELKS and a tiny GUI).
: > 
: > So one would have to write specifically to it, as one writes to Gnome or
: > KDE?
: 
: Neither. Gnome is built on gtk (which is window system independant (ish)) which
: is built on gdk which is window system specific. So you port gdk you get
: gnome on it - ditto Qt andd KDE.
: 
: In general both gnome and kde are a bit big for small pdas. Fltk looks more
: promising
:
	Whoops - I meant Gdk is built on Xlib, right?