nanogui: Thread: Small Xlib replacement

----- Original Message -----
From: Alan Cox ####@####.####
To: Bradley D. LaRonde ####@####.####
Cc: ####@####.#### ####@####.#### ####@####.####
Sent: Wednesday, September 08, 1999 12:40 PM
Subject: Re: Small Xlib replacement


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

Let's see if I get it:

    Gnome -> gtk -> gdk-for-x -> Xlib -> xserver -> framebuffer
    KDE -> Qt-for-x -> Xlib -> xserver -> framebuffer

Now put NanoGUI in:

    Gnome -> gtk -> gdk-for-nano -> NanoGUI -> NanoX -> framebuffer
    KDE -> Qt-for-nano -> NanoGUI -> NanoX -> framebuffer

Is that right?  Does NanoGUI replace the Xlib layer, and NanoX replace the
xserver layer?


Regards,
Brad

On Wed, 8 Sep 1999, Greg Haerr wrote:
> 	Gtk is built on top of Xlib, right?

No, GDK.
GDK has ports to Xlib, Win32 and, I believe, Be.

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

 > So one would have to write specifically to it, as one writes to Gnome or
: > KDE?
: 
 port
: it directly to the NanoGUI API itself which, as Greg is saying, isn't a
: million miles away from the X API. 

	Ah, finally, the need becomes clear: if the nanoGUI api were
Xlib, then there isn't much of a porting issue at all.  Otherwise it becomes
one of dozens of graphical systems apis out there that few use...
And what do you know, nanoX is damn near Xlib now.  (I still hold
my 90% is accurate)

On Wed, 8 Sep 1999, Bradley D. LaRonde wrote:
> Now put NanoGUI in:
>     Gnome -> gtk -> gdk-for-nano -> NanoGUI -> NanoX -> framebuffer
>     KDE -> Qt-for-nano -> NanoGUI -> NanoX -> framebuffer
> Is that right?  Does NanoGUI replace the Xlib layer, and NanoX replace the
> xserver layer?

No, NanoGUI is just the name of the project. It isn't a layer in the GUI.
Apart from that, that's correct, though Gnome is very heavyweight for
NanoGUI's intended platforms.

Application -> toolkit -> NanoGUI -> framebuffer
Application <- toolkit <- NanoGUI <- mouse/keyboard/touchpad

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

>     Gnome -> gtk -> gdk-for-nano -> NanoGUI -> NanoX -> framebuffer
>     KDE -> Qt-for-nano -> NanoGUI -> NanoX -> framebuffer
> 
> Is that right?  Does NanoGUI replace the Xlib layer, and NanoX replace the
> xserver layer?

Nanogui is everything below Qt-for-nano, gdk-for-nano

> : 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?

Currently. You write a new gdk for each platform. There are experimental
non X11 gdk targets

On Wed, 8 Sep 1999, Greg Haerr wrote:
> 	Ah, finally, the need becomes clear: if the nanoGUI api were
> Xlib, then there isn't much of a porting issue at all.  Otherwise it becomes
> one of dozens of graphical systems apis out there that few use...
> And what do you know, nanoX is damn near Xlib now.  (I still hold
> my 90% is accurate)

Not only would making something close to X11R6 compliant necessitate
adding significant complexity to the server, there's the additional
problem of people who will incorrectly assume that it is supposed to be
fully X compliant and complain when they find they can't compile an
unpatched GTK+ against it or something. Things like the X11 font, colour,
Window manager, and input models really don't want to go into something
intended to be a palmtop, and things that we do want to have like the
handwriting recognition extensions we talked about don't directly fit into
the X11 model. I don't see any problem with simply changing the names
and, where possible, parameters of the API to match the X11 model; in fact
you may as well simply create a new version of the client lib with the
different names in it, but it still won't give you anywhere near a full
X11 implementation. 

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

: Not only would making something close to X11R6 compliant necessitate
: adding significant complexity to the server, there's the additional
: problem of people who will incorrectly assume that it is supposed to be
: fully X compliant and complain when they find they can't compile an
: unpatched GTK+ against it or something.

	There's no question that we shouldn't be attempting to recreate X11R6.
No, we don't want full X compliance, either.

 Things like the X11 font, colour,
: Window manager, and input models really don't want to go into something
: intended to be a palmtop,

	Yep.  The font model can be heavily simplified with compiled-in
and later loadable fonts stored as simple bitmaps.  The color model can go
to an easy to understand and implement RGB model, and the Window manager
can be compiled in.  Drop the databases also. 


 and things that we do want to have like the
: handwriting recognition extensions we talked about don't directly fit into
: the X11 model.

	A new api would be nice here.


 I don't see any problem with simply changing the names
: and, where possible, parameters of the API to match the X11 model; in fact
: you may as well simply create a new version of the client lib with the
: different names in it, but it still won't give you anywhere near a full
: X11 implementation. 
: 
	Great - I'll take on this project.  The idea here is to create
an Xlib-compliant graphics api similiar to the MicroWindows implemention
of the Win32 api.  Certainly, noone mistakes MicroWindows as being Windows.
But, unmodified simple Windows programs will run on MicroWindows.  The
window manager is built in.  The font support is simplified.  It works.  Anyone
wanting to port low level graphics-oriented Windows programs to framebuffer,
SVGAlib, or raw hardware can use MicroWindows to do it.  Now they'll be able
to do the same thing with their low-level graphics-oriented X programs.

Greg