nanogui: Thread: NanoX version 0.3 released

On Tue, 11 May 1999, Alexander Peuchert wrote:
> less lib code!

No, just split up into two parts so that you aren't forced to have _all_
of GDK compiled in for every single app which uses nano-X.

> Another thing: what is >inappropriate< for nano-X ?

Whatever is non-essential. The processing which GDK does should be in the
GDK library, only the interface to the Nano-X server should be in the
Nano-X server should be in the Nano-X library. The interface could be
modified to make it easier to port GDK, but I don't want to force people
to compile GDK in if they don't want it.

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

On Tue, 11 May 1999, Alex Holden wrote:

> On Tue, 11 May 1999, Alexander Peuchert wrote:
> > less lib code!
> 
> No, just split up into two parts so that you aren't forced to have _all_
> of GDK compiled in for every single app which uses nano-X.

Good point, I didn't think of that.

> 
> > Another thing: what is >inappropriate< for nano-X ?
> 
> Whatever is non-essential. The processing which GDK does should be in the
> GDK library, only the interface to the Nano-X server should be in the
> Nano-X server should be in the Nano-X library. The interface could be
> modified to make it easier to port GDK, but I don't want to force people
> to compile GDK in if they don't want it.

What would you prefer:

1) splitting the GDK API into two parts. one for the nano-X part, one for
the rest, but using the GDK API function names for both.

or

2) a nano-X lib and a nano-GDK wrapper lib. The nano-GDK lib provides the
additional functinallity and just function name translation from GDK to
nano lib, either through simple jumps or #defines.


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

- alex

Alexander Peuchert
####@####.####
http://www.peuchert.de ( not very interesting yet ;-) )

On Tue, 11 May 1999, Alexander Peuchert wrote:
> What would you prefer:
> 1) splitting the GDK API into two parts. one for the nano-X part, one for
> the rest, but using the GDK API function names for both.
> 2) a nano-X lib and a nano-GDK wrapper lib. The nano-GDK lib provides the
> additional functinallity and just function name translation from GDK to
> nano lib, either through simple jumps or #defines.

2, but with the functions which can be translated directly without any
extra work (apart from renaming and/or reordering arguments) in the nano-X
lib. So, if you wanted to program directly to nano-X, you would see a
subset of the GDK functionality. Link with the nano-GDK lib, and you see
the whole GDK functionality, which you can stick GTK+ or anything else
which uses GDK directly on top of without modification.

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

On Tue, 11 May 1999, Alex Holden wrote:

> On Tue, 11 May 1999, Alexander Peuchert wrote:
> > What would you prefer:
> > 1) splitting the GDK API into two parts. one for the nano-X part, one for
> > the rest, but using the GDK API function names for both.
> > 2) a nano-X lib and a nano-GDK wrapper lib. The nano-GDK lib provides the
> > additional functinallity and just function name translation from GDK to
> > nano lib, either through simple jumps or #defines.
> 
> 2, but with the functions which can be translated directly without any
> extra work (apart from renaming and/or reordering arguments) in the nano-X
> lib. So, if you wanted to program directly to nano-X, you would see a
> subset of the GDK functionality. Link with the nano-GDK lib, and you see
> the whole GDK functionality, which you can stick GTK+ or anything else
> which uses GDK directly on top of without modification.

There could also be a possibility of building two nano libs:

libnano.a    // just the necessary functs
libGDKnano.a // additionall GDK functionality and libnano already included

all made by a makefile



I still cannot see what isn't appropriate for nano from GDK. GDK is an
abstraction layer over Xlib. Nano-X should provide the same functionality.
Maybe DnD or RGB could be left out, but how could this be simulated by
libGDKnano, if it isn't there ?

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

- alex

Alexander Peuchert
####@####.####
http://www.peuchert.de ( not very interesting yet ;-) )

On Tue, 11 May 1999, Alexander Peuchert wrote:
> There could also be a possibility of building two nano libs:
> libnano.a    // just the necessary functs
> libGDKnano.a // additionall GDK functionality and libnano already included

That's possible, but probably doesn't have any benefit over having
libnano-X.so and libnano-GDK.so as suggested previously. The previous
method has the advantage that if you have both on one system, the total
will be smaller (only a few KB admittedly, but that might be important on
an embedded system), plus they are seperate from a distibution standpoint.

> I still cannot see what isn't appropriate for nano from GDK. GDK is an
> abstraction layer over Xlib. Nano-X should provide the same functionality.
> Maybe DnD or RGB could be left out, but how could this be simulated by
> libGDKnano, if it isn't there ?

I haven't looked into GDK in enough detail to say.

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

On Tue, 11 May 1999, Alex Holden wrote:

> On Tue, 11 May 1999, Alexander Peuchert wrote:
> > There could also be a possibility of building two nano libs:
> > libnano.a    // just the necessary functs
> > libGDKnano.a // additionall GDK functionality and libnano already included
> 
> That's possible, but probably doesn't have any benefit over having
> libnano-X.so and libnano-GDK.so as suggested previously. The previous
> method has the advantage that if you have both on one system, the total
> will be smaller (only a few KB admittedly, but that might be important on
> an embedded system), plus they are seperate from a distibution standpoint.

As the complete functional parts of GTK require a space of about 10meg (
here Solaris, correct me please.), the libnano-GDK.so wouldn't be used on
a system with memory restrictions, I think. And if there would be enough
space for GTK, them X would be used.

So, after think sometime about it, nano-X shouldn't bother about GDK, just
try to make a possible port easy ...

> 
> > I still cannot see what isn't appropriate for nano from GDK. GDK is an
> > abstraction layer over Xlib. Nano-X should provide the same functionality.
> > Maybe DnD or RGB could be left out, but how could this be simulated by
> > libGDKnano, if it isn't there ?
> 
> I haven't looked into GDK in enough detail to say.
> 
> --------------- Linux- the choice of a GNU generation. --------------
> : Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
> -------------------- http://www.linuxhacker.org/ --------------------
> 

- alex

Alexander Peuchert
####@####.####
http://www.peuchert.de ( not very interesting yet ;-) )

On Tue, 11 May 1999, Alexander Peuchert wrote:
> As the complete functional parts of GTK require a space of about 10meg (
> here Solaris, correct me please.), the libnano-GDK.so wouldn't be used on
> a system with memory restrictions, I think. And if there would be enough
> space for GTK, them X would be used.

I don't think it's that bad- are you looking at binaries with debugging
information included?

[alex@hyperspace alex]$ ls -l libgtk-1.2.so.0.2.0
-rwxr-xr-x   1 alex     alex      3315720 May 10 14:51 libgtk-1.2.so.0.2.0
[alex@hyperspace alex]$ strip libgtk-1.2.so.0.2.0
[alex@hyperspace alex]$ ls -l libgtk-1.2.so.0.2.0
-rwxr-xr-x   1 alex     alex      1141520 May 11 14:52 libgtk-1.2.so.0.2.0
[alex@hyperspace alex]$

I'm not quite sure exactly what other libraries are needed, though, I'll
have to have a look at it. I was rather hoping I would be able to run GTK+
apps on my Geofox... 
 
--------------- Linux- the choice of a GNU generation. --------------
: Alex Holden (M1CJD)- Caver, Programmer, Land Rover nut, Radio Ham :
-------------------- http://www.linuxhacker.org/ --------------------

On Tue, 11 May 1999, Alex Holden wrote:

> I don't think it's that bad- are you looking at binaries with debugging
> information included?
> 
> [alex@hyperspace alex]$ ls -l libgtk-1.2.so.0.2.0
> -rwxr-xr-x   1 alex     alex      3315720 May 10 14:51 libgtk-1.2.so.0.2.0
> [alex@hyperspace alex]$ strip libgtk-1.2.so.0.2.0
> [alex@hyperspace alex]$ ls -l libgtk-1.2.so.0.2.0
> -rwxr-xr-x   1 alex     alex      1141520 May 11 14:52 libgtk-1.2.so.0.2.0
> [alex@hyperspace alex]$
> 
> I'm not quite sure exactly what other libraries are needed, though, I'll
> have to have a look at it. I was rather hoping I would be able to run GTK+
> apps on my Geofox... 

Same for me, if my Geofox will ever be built :-(.

I think, additionally the glib and a windowing system like nano-X is
needed. And space for the apps and execution space and space for the
kernel and ...

I can't tell you, if that would give a usable system. I want to use 'my'
geofox on a daily bases, if possible, not as a technology study.

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

- alex

Alexander Peuchert
####@####.####
http://www.peuchert.de ( not very interesting yet ;-) )

On Mon, 10 May 1999, Alex Holden wrote:

> It'll be very nice if you manage that... They must have slimmed things
> down a lot since last time I looked (tens of megabytes of libraries that
> took a couple of minutes just to load into memory).

Yeah, I remember that too.. There's still a lot of bloat there, IMHO, but
it's been steadily dropping in size. Also, most of the bloat is in the
Mozilla GUI code, it seems, not in the rendering engine. The rendering
engine is actually pretty nice now :)
 
> We should be writing a GDK port for Nano-X eventually anyway. You may want
> to help with that rather than grafting Mozilla directly onto Nano-X 
> itself.

I've been thinking about it... The API's seem to be fairly similar
already, so maybe that's the best way to go.

Vidar Hokstad ####@####.####
Director of R&D, Screen Media AS

On Tue, 11 May 1999, Vidar Hokstad wrote:
> Yeah, I remember that too.. There's still a lot of bloat there, IMHO, but
> it's been steadily dropping in size. Also, most of the bloat is in the
> Mozilla GUI code, it seems, not in the rendering engine. The rendering
> engine is actually pretty nice now :)

Any idea why there is a noticable delay between moving the mouse pointer
over a button, and the button becoming highlighted? GTK+ doesn't do that,
so they must have messed around with the event chain somehow, adding
masses of processing into what should have been a pretty fast response
chain. I don't see why they would have done that though...

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