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