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
