[<<] [<] 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 [>] [>>] |