nanogui: Thread: Libraries, interfaces, X, Win32

Here's my entry into the discussion of small-Xlib, MicroWindows, naming,
etc.

Half an hour ago, I proposed this naming model:

nanodevice <-> nanoserver <--nanoprotocol--> nanolib
\__________________________________________________/
             NanoGUI

(I am a newbee to NanoGUI, but this is how I see the code is built up.
Correct my if I'm wrong.)

MicroWindows (I've played a little with it) would then be a library
which implements "nanoprotocol" with a different interface. The
client-side of Nano-X (which I call nanolib) then implements
"nanoprotocol" with an Xlib-like interface.

A real Xlib-clone implementation of "nanoprotocol" (which has been
proposed) would then be yet another library that implements
"nanoprotocol". That would be three libraries which implement that
"nanoprotocol", which isn't really that complicated.

Such a library should _really_ be named nano-X, and the "native" NanoGUI
library would then be "nanolib". This would also give us the opportunity
to refine our "own" library and make it suit use better, while having
the X-ness in a separate library. Or interface. Or whatever.


New model:

                                           /--> MicroWindows
nanodevice <-> nanoserver <--nanoprotocol-----> Nano-Xlib
                                           \--> "Native" NanoLib

Which isn't that hard to implement. Hasn't anyone attempted to merge the
MicroWindows and NanoGUI sources?

On Thu, 9 Sep 1999, Guan Yang wrote:
>                                            /--> MicroWindows
> nanodevice <-> nanoserver <--nanoprotocol-----> Nano-Xlib
>                                            \--> "Native" NanoLib

Yes, that's what we have discussed doing. Simply create a new version of
the client library which transparently translates between Xlib-like calls
or Win32-like calls (or potentially Epoc-like or Palmos-like calls) and
native nanoserver calls. The nanoserver API can then be extended or
modified without the applications which use the client library needing to
know about it.

> Hasn't anyone attempted to merge the MicroWindows and NanoGUI sources?

No. Currently Microwindows uses a modified Nano-X as it's base, and
those modifications would have to be merged into Nano-X (or nanoserver as
it looks like we'll be calling it) in a clean way, and quite a few changes
would need to be made to the way Microwindows is implemented in order to
support one nanoserver which has multiple "appearances" depending on what
client library you use. That may well be the way things go, but it's
really up to Greg how he chooses to develop Microwindows.

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

On Thu, 9 Sep 1999, Alex Holden wrote:

> >                                            /--> MicroWindows
> > nanodevice <-> nanoserver <--nanoprotocol-----> Nano-Xlib
> >                                            \--> "Native" NanoLib
>
> Yes, that's what we have discussed doing. Simply create a new version
> of the client library which transparently translates between Xlib-like
> calls or Win32-like calls (or potentially Epoc-like or Palmos-like
> calls) and native nanoserver calls.

That does have space implications on platforms which don't support shared
libraries, though, doesn't it?

Matthew.

On Thu, 9 Sep 1999, Matthew Kirkwood wrote:
> > Yes, that's what we have discussed doing. Simply create a new version
> > of the client library which transparently translates between Xlib-like
> > calls or Win32-like calls (or potentially Epoc-like or Palmos-like
> > calls) and native nanoserver calls.
> That does have space implications on platforms which don't support shared
> libraries, though, doesn't it?

A library with a translation layer in it probably won't be much more code
than the one without it, which you have to link against anyway. If you're
worried about saving probably less than a couple of KB, use the nanoserver
API directly instead of an emulation layer for a different API. The amount
of code needed is so tiny that shared libraries wouldn't make much
difference at all (any gain you might get would most likely get lost in
the noise).

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