Thread: [Simplygnustep-discuss] What's new in SGSTEP
Status: Alpha
Brought to you by:
cehardin
From: Chad H. <ceh...@ma...> - 2002-10-09 04:27:03
|
First: Rafeal and I are starting to look for people who wish to help, if anybody is interested, please let us know! (does anybody even read these emails?) I've spent a lot of time fiddling! Fiddling takes a lot of time since recompiling the code takes 15 hours! Current Fiddles: **Glibc-3.3: Could not get to work, when I compile with this I can't do a chroot and continue the build process (chroot segfaults) back to glibc-2.2.5 **GCC-3.2: Does not compile glibc-2.2.5, back to gcc-3.1 **Patched linux kernel 2.4.19pre8: Applied the vmware.o video framebuffer patch, it seems to work ok but is quite slow. Hopefully the vmware.o will start appearing in the new kernels soon. (see NuVu below as to why I am doing this) **Patched linux kernel 2.4.19pre8: 2.4.19 is different than 2.4.18 in one way which hit me in a bad, bad way! As you may know, I rely on the devfs to run the install cd, I just pass root=/dev/cdroms/cdrom0 to the kernel and it will mount the proper root file system easily! Unfortunately, 2.4.19 loads devfs AFTER trying to mount root! This means that when the kernel tries to mount root, there is no /dev/cdroms/cdrom0, only /dev/had, /dev/hdb, etc. If this is the way the Linux kernel will stay, then I have to make the move to syslinux and initrd, which is not a bad thing, it will just take a while to make it work right. **NuVu: The codename, or perhaps final name, of the new display system which SGSTEP will use. That's right, no X11. My intention is to create a very lightweight WindowServer which will be build upon DirectFB, which uses the linux video framebuffer (hence, explaining why the vmware.o is needed) At first, I was going to use DirectFBs built-in system of handling multiple apps, this would have made NuVu very, very easy to create. Unfortunately, all DirectFB apps need to be run as root and they share a common shared memory area (passwords can be sniffed). This will clearly not work. So now I'm working on making a extra level of abstraction. The server will be linked with libdirectfb and communicate with clients via gnustep distributed Objects (DO) (NuVu will be an objc/GNUstep "Tool"). Only very simple messages will be passed between the server and clients, like: createwindow, mousemove, keypressed, etc. NO drawing code will be passed between client and server. Instead, the server will create a shared memory area of a pixmap, the client will draw to the pixmap and tell the server when to display the contents. This means that all the burden will be placed on the client side software. Luckily, there are some great libs out there to help, libart provides great anti-alias graphics and freetype (pango too?) can provide the text. It will still be a difficult task. Also, the will be nno "window Manager" the clients will handle window decoration and functions. Note that when I say client side I am talking about a new gnustep-backend. Applications will need no modifications to compile With NuVu, we can probe for the video card right after init loads and switch to framebuffer mode and then continue on with a graphical init. **I've added all kinds of goodies to the current source tree, I wish I could share it with CVS, but it is just way to large at 3.5GB. New stuff: Cvs Dhcpcd (yeah!) Links Nano editor Cups Directfb Automount (not configured, just there) Terminal.app GsPDF.app Gworkspace-0.4.0 Fbset freetype2 Kaffe Hotplug Libart Libbadpenguin Libhardware (awesome hardware detection, will work GREAT for the installer!) Openssh Openssl Patch Pciutils Usbutils And some other little stuff The upcoming Interim Developer Releases (IDR) will be based on X11 for a while, we are shooting to make the final 1.0 release use NuVu. Once again, does anybody read this stuff? Later! Chad |
From: David A. <d....@in...> - 2002-10-09 07:45:21
|
Chad Hardin wrote: >First: Rafeal and I are starting to look for people who wish to help, if >anybody is interested, please let us know! (does anybody even read these >emails?) > Well, they are read, but sorry, can't contribute. Little time, and hardly any know-how concerning Linux-Distro's >**Patched linux kernel 2.4.19pre8: Applied the vmware.o video framebuffer >patch, it seems to work ok but is quite slow. Hopefully the vmware.o will >start appearing in the new kernels soon. (see NuVu below as to why I am >doing this) > I guess there is no (reliable?) free (as in speech) framebuffer you could use instead. I'm wondering whether this one is actually free (as in beer), as there seems to no reference of it on thier download page. >So now I'm working on making a extra level of abstraction. The server will >be linked with libdirectfb and communicate with clients via gnustep >distributed Objects (DO) (NuVu will be an objc/GNUstep "Tool"). Only very >simple messages will be passed between the server and clients, like: >createwindow, mousemove, keypressed, etc. NO drawing code will be passed >between client and server. Instead, the server will create a shared memory >area of a pixmap, the client will draw to the pixmap and tell the server >when to display the contents. This means that all the burden will be placed >on the client side software. Luckily, there are some great libs out there >to help, libart provides great anti-alias graphics and freetype (pango too?) >can provide the text. It will still be a difficult task. Also, the will be >nno "window Manager" the clients will handle window decoration and >functions. > > Sounds intersting, you seem to be relying on having all apps being GNUstep apps. (This is not critisizm, it's actually an implied question :-) ) That would imply you maybe should GNUMail.app. I'm not sure whether there is a browser you could include. But I'm sure even when targeting the developer community these will be essential. Hey, but I also realize that your busy trying to get the underlying stuff to work, so concider these suggestions as side comments momentarily. Keep up the good work! Cheers, Dave |
From: Chad H. <ceh...@ma...> - 2002-10-09 08:37:41
|
"David Ayers" wrote: > Chad Hardin wrote: > >> First: Rafeal and I are starting to look for people who wish to help, if >> anybody is interested, please let us know! (does anybody even read these >> emails?) >> > Well, they are read, but sorry, can't contribute. Little time, and > hardly any know-how concerning Linux-Distro's > That's perfectly ok! this distro is aimed at both developers AND users. It has a very definite split between user and developer packages. Maybe you'd like to test soe time (prob far) down the road? >> **Patched linux kernel 2.4.19pre8: Applied the vmware.o video framebuffer >> patch, it seems to work ok but is quite slow. Hopefully the vmware.o will >> start appearing in the new kernels soon. (see NuVu below as to why I am >> doing this) >> > I guess there is no (reliable?) free (as in speech) framebuffer you > could use instead. I'm wondering whether this one is actually free (as > in beer), as there seems to no reference of it on thier download page. > The vmware FB was originally taken from the XFree86 code, the license has since changed to LGPL (I believe) so it should good to go in the kernel. The author is currently trying to get it in there. >> So now I'm working on making a extra level of abstraction. The server will >> be linked with libdirectfb and communicate with clients via gnustep >> distributed Objects (DO) (NuVu will be an objc/GNUstep "Tool"). Only very >> simple messages will be passed between the server and clients, like: >> createwindow, mousemove, keypressed, etc. NO drawing code will be passed >> between client and server. Instead, the server will create a shared memory >> area of a pixmap, the client will draw to the pixmap and tell the server >> when to display the contents. This means that all the burden will be placed >> on the client side software. Luckily, there are some great libs out there >> to help, libart provides great anti-alias graphics and freetype (pango too?) >> can provide the text. It will still be a difficult task. Also, the will be >> nno "window Manager" the clients will handle window decoration and >> functions. >> >> > Sounds intersting, you seem to be relying on having all apps being > GNUstep apps. (This is not critisizm, it's actually an implied question > :-) ) That would imply you maybe should GNUMail.app. I'm not sure > whether there is a browser you could include. But I'm sure even when > targeting the developer community these will be essential. Hey, but I > also realize that your busy trying to get the underlying stuff to work, > so concider these suggestions as side comments momentarily. Keep up the > good work! Yes, GNUstep only for now. Perhaps sometime far in the future X11 will be able to run too, just like in OS X, but this is not a priority. GNUMail.app is in there! The web browser is definitely something we need, not sure what the best approach is right now. Everything from a commercial OMNweb to a Gecko based browser is possible. Thanks! Chad > > Cheers, > Dave > > > > |
From: Joel S. <jo...@mo...> - 2002-10-09 13:40:47
|
On Tue, 8 Oct 2002, Chad Hardin wrote: > First: Rafeal and I are starting to look for people who wish to help, if > anybody is interested, please let us know! (does anybody even read these > emails?) > > ... > > Once again, does anybody read this stuff? I for one read it ;-) I have been watching SGStep for quite a while now. Since I read a review of the first release, on OSNews I think. I'm very excited in SGStep being a sort of free software alternative to OpenStep/MacOSX. Your ideas for NuVu sound really exciting. NuVu sounds like something I have been dreaming about for a long time! Unfortunatly, I am working on my own project at the moment, a OSKit based symbolic OS, so I don't have much time to share. Is there a TODO about? It would be nice to give people some kind of idea of what needs to be done. Keep up the really great work! Happy Hacking, Joel. |
From: Chad H. <ceh...@ma...> - 2002-10-12 21:46:14
|
NuVu, the display system that will be SGStep has been floating around in my head for a couple months now. I=B9m glad to say that I have got most of it nailed down and will start codin= g it tonight! NuVu will be a lightweight window server which will use SystemV IPC for client/server communications, shared memory, and locking. It wil be double-buffered for speed but will also be quite a memory hog as well. It will be completely alpha-enabled at the core, not a add-on hack and should be quite fast when used on top of DirectFB. First thing to come out will be the client and server C-based libs. Next a (or a set) of Window server executables will be created, the final step wil= l be the creation of a new GNUstep-backend to use it. This should be some good, fun, stuff. Later, Chad |
From: Chad H. <ceh...@ma...> - 2002-10-12 22:05:58
|
NuVu has been submitted to be on sourceforge. NuVu will be developed using CVS so anyone can contribute. |