nanogui: Thread: What's the plan?


[<<] [<] Page 1 of 1 [>] [>>]
Subject: What's the plan?
From: Paul Houle ####@####.####
Date: 30 Apr 1999 11:19:15 -0000
Message-Id: <3729917A.4597CF8@honeylocust.com>

    I've been trying to compare the existing code to the plans mentioned
on the web site.  To be fair I haven't even compiled it yet and I can't
promise that I can put any time into the project right now.  (But I also
can't promise that I can't...)

    I'll preface this by saying that I've only written the simplest
programs using GTK,  but I did look at the overall design and API
because I was,  for a while,  interested in creating automatic code
generators for writing JNI stubs to connect Java to native code.  I did
a preliminary study of how to do this for GTK,  but didn't go further
because,  I didn't really need GTK-Java bindings.

    What stood out like a sore thumb was that GTK does not depend on X
Windows.  Rather,  it depends on GDK which is,  roughly,  a greatly
simplified version of the X Windows API.  Around this time I was hearing
that people were having luck porting GTK to Win32 and to BeOS.  And this
is why.

    Even though the mass-media computer press seems obsessed with
scalability into the stratosphere, (Do you really need a 64 way SMP?)
at least intellectually,  I think it's more fun to compete with Windows
CE for small devices rather than to compete with Solaris for big
machines.  It seemed to be generally held that X Windows,  simply being
a distributed windowing system,  consumes about twice the resources that
it has to -- for us to get Linux onto smaller machines,  we need to lose
X.  But then the trouble is,  where do we get applications from?  If,
for instance,  we made a new windowing system that is just a minimalist
implementation of GDK,  we could just recompile our GTK applications and
get them to work.  This would be particularly appealing for Red Hat,
who is pushing the GNOME desktop,  which uses GTK and could be ported to
minimal GDK.  A sort of "X Windows exit strategy."  I wrote to GTK lead
Owen Taylor,  who I used to share an office with,  about this and I got
no reply.

    I assume that your plan is to do just this -- beef up nano-X so that
it can support GDK.  Sounds like a great idea.

    A few things I was thinking about though...

    (1) You might ~really~ do better designing from the ground up to
mirror the architecture of GDK.  Certainly you should be thinking now of
how nano-gui and the GDK API will intermesh and,  if you really care
about small and fast,  change nano-gui to suit GDK where necessary.

    (2) Take a hints Windows CE.  The Windows CE GUI is aggressively
modularized,  so that different groups of widgets (some which might not
be appropriate on small devices) can be left out.  They're doing it at
the binary level,  but we've got source so we can do even better.  It
might be possible to break up both GDK functions and GTK support into
profiles,  such that you can find some subset of GTK which works great
on top of 50% of GDK.  It might even be a good idea to,  if possible,
modularize out support for multiple windows.  On some small devices,
you might only have one application running,  and you don't want to
bloat your footprint by 100k or more for a feature you don't need.

    (3) The reason I haven't compiled it is I'm not running 2.2;  call
me a sissy,  but I got burnt with 2.0.  I'm waiting for the big
distributions to come out with 2.2 kernel distributions AND for the
problems with binary-only apps like the JDK and Star Office with glibc
2.1 to be resolved.  Again,  I know nothing about the framebuffer driver
(yet) and I haven't looked at the code,  but it might be desirable to
write it so,  by option,  it can run over a direct framebuffer library
such as prometheus truecolor,  allowing a (bloated) version that us old
farts can mess around with and maybe have the convenience of running it
under X while we develop it.

    (4) Whatever you do:  DO NOT BUILD IN REMOTE ACCESS!  There is
something really beautiful called VNC which has a light memory footprint
that you'd be better off adopting.  VNC works at the "virtual
framebuffer" level.  Servers are available for X and Win32,  Acorn
RISC OS,  and BeOS,  letting you log into any of those environments with
VNC and the client is just an ordinary application and exists for all
the above and also MacOS,  Java (can log into your machine from a web
browser!), Win CE and many others.  Write a VNC client for nano-X and
you can run X windows applications remotely (never mind comandeer a
Win32 box for fun and profit) under NanoX;  replumb the server to speak
VNC,  and you can use nano-X remotely from all the above.  Read about it
at

http://www.uk.research.att.com/vnc/index.html

Subject: Re: What's the plan?
From: Alex Holden ####@####.####
Date: 30 Apr 1999 12:01:20 -0000
Message-Id: <Pine.LNX.4.04.9904301229540.29732-100000@www.linuxhacker.org>

On Fri, 30 Apr 1999, Paul Houle wrote:
>     I've been trying to compare the existing code to the plans mentioned
> on the web site.  To be fair I haven't even compiled it yet and I can't
> promise that I can put any time into the project right now.  (But I also
> can't promise that I can't...)

Okay, I'm hoping some other people will get involved as for the next few
weeks I won't have very much time (revision for end of year exams). If
not, then I should be able to spend a lot of time on it over the summer
anyway, and hopefully get something decent together by the Autumn (or
Fall, for the Americans on the list).

>     What stood out like a sore thumb was that GTK does not depend on X
> Windows.  Rather,  it depends on GDK which is,  roughly,  a greatly

Yes, that's a good feature, even if it does mean the M$ weenies now have a
semi-functional Gimp to play with ;)

>     Even though the mass-media computer press seems obsessed with
> scalability into the stratosphere, (Do you really need a 64 way SMP?)

Depends on what you want to do.

> at least intellectually,  I think it's more fun to compete with Windows
> CE for small devices rather than to compete with Solaris for big
> machines.  It seemed to be generally held that X Windows,  simply being

I think both are fun. I like the fact that Linux is so scaleable that
basically the same codebase can be built to run on both 64 way UltraSparc
monsters and tiny ARM based palmtops, and perform well on both.

>     (1) You might ~really~ do better designing from the ground up to
> mirror the architecture of GDK.  Certainly you should be thinking now of
> how nano-gui and the GDK API will intermesh and,  if you really care
> about small and fast,  change nano-gui to suit GDK where necessary.

I'm not sure, GDK was designed with X in mind. I'd rather start with a
tiny windowing system, then write the GDK wrappers for it.

>     (2) Take a hints Windows CE.  The Windows CE GUI is aggressively
> modularized,  so that different groups of widgets (some which might not
> be appropriate on small devices) can be left out.  They're doing it at
> the binary level,  but we've got source so we can do even better.  It

Why is it that "modular" applications usually seem to wind up bigger and
more bloated than you could manage otherwise? Take Apache as an example...

> might be possible to break up both GDK functions and GTK support into
> profiles,  such that you can find some subset of GTK which works great
> on top of 50% of GDK.  It might even be a good idea to,  if possible,
> modularize out support for multiple windows.  On some small devices,
> you might only have one application running,  and you don't want to
> bloat your footprint by 100k or more for a feature you don't need.

I can see that being a bit of an implementation and maintenance nightmare.
GDK, GTK+, Gnome-libs, the client side nano-X library, and the nano-X
server should all be distinct, seperate items. I don't think missing out
the window code would make it much smaller either (it's already incredibly
simple), though of course you wouldn't need a WM if you only have one
window. The window manager is one thing which I have considered including
as an (optional) integral part of the server, as it would seem to easier
to do that way. Does anyone know how window managers work in X? I haven't
managed to figure out how they work from reading the code...

>     (3) The reason I haven't compiled it is I'm not running 2.2;  call
> me a sissy,  but I got burnt with 2.0.  I'm waiting for the big

I haven't had any problems since about 2.1.88. The 2.2 kernels are _very_
stable on intel, and better than 2.0 on ARM. I don't know about any of the
other arch's.

> distributions to come out with 2.2 kernel distributions AND for the
> problems with binary-only apps like the JDK and Star Office with glibc
> 2.1 to be resolved.  Again,  I know nothing about the framebuffer driver

Glibc-2.1 is totally compatible with 2.0 applications which don't make use
of internal libc implementation features. The maintainers noticed things
were breaking randomly whenever they changed the implementation of things
in the library, so they decided to tighten up the rules so you _can't_
make use of the internals directly from a program linked to it. People
knew this was coming, and if they didn't do anything about it, that's
their fault. Perhaps you should switch to an Open Source alternative,
where you could just fix the problems and recompile it yourself rather
than having to wait for the manufacturers to do it? (admittedly I don't
think there is a decent alternative to the JDK yet though)

> (yet) and I haven't looked at the code,  but it might be desirable to
> write it so,  by option,  it can run over a direct framebuffer library
> such as prometheus truecolor,  allowing a (bloated) version that us old
> farts can mess around with and maybe have the convenience of running it
> under X while we develop it.
> 
>     (4) Whatever you do:  DO NOT BUILD IN REMOTE ACCESS!  There is
> something really beautiful called VNC which has a light memory footprint

Someone brought this up a few days ago. I expect someone will write a VNC
client at some stage, but it's not on my immediate TODO list (right below
"Don't totally flunk exams" :).

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

Subject: Re: What's the plan?
From: Alex Holden ####@####.####
Date: 30 Apr 1999 12:10:05 -0000
Message-Id: <Pine.LNX.4.04.9904301306530.30173-100000@www.linuxhacker.org>

I forgot a bit:

On Fri, 30 Apr 1999, Paul Houle wrote:
> (yet) and I haven't looked at the code,  but it might be desirable to
> write it so,  by option,  it can run over a direct framebuffer library
> such as prometheus truecolor,  allowing a (bloated) version that us old
> farts can mess around with and maybe have the convenience of running it
> under X while we develop it.

I'm sure Alan mentioned he had already managed to do something along
these lines, though I don't know how. I think it might have been something
to do with GGI... Alan?

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

Subject: Re: What's the plan?
From: ####@####.#### (Alan Cox)
Date: 4 May 1999 12:17:47 -0000
Message-Id: <m10eeww-0007TwC@the-village.bc.nu>

> I'm sure Alan mentioned he had already managed to do something along
> these lines, though I don't know how. I think it might have been something
> to do with GGI... Alan?

I did some playing but dont have anything working. I was trying to get a
fake fb running over SDL. Its all a question of time. I'd rather someone
else tried it themselves than waited for me

[<<] [<] Page 1 of 1 [>] [>>]


Powered by ezmlm-browse 0.20.