Date: Sat, 6 Mar 1999 18:12:11 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: asmodai@wxs.nl (Jeroen Ruigrok/Asmodai) Cc: brian@CSUA.Berkeley.EDU, freebsd-chat@FreeBSD.ORG, eagle@phc.igs.net Subject: Re: A BSD-licensed GUI toolkit? Message-ID: <199903061812.LAA03755@usr06.primenet.com> In-Reply-To: <XFMail.990306183203.asmodai@wxs.nl> from "Jeroen Ruigrok/Asmodai" at Mar 6, 99 06:32:03 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > I think that it's about time that a good GUI toolkit for X be developed > > and released under the two-clause BSD license, both so that developers > > like myself can release software with a clean conscience, knowing that's > > *free* and completely unencumbered, not just "Open Source(r)", and to > > encourage commercial developers to port their software to Unix/X11, as > > they would not have to purchase a Motif or Qt license, use some LGPLed > > library, or write their own toolkit from scratch. > > *nods* > > Very good points. > > > Would anyone here be interested in participating in such a project by > > leading it, hosting it, writing code for it, helping to design it, or in > > any other way? > > Leading such a project would be better off in hands like someone as Terry. I already have a Motif clone partially completed. It runs up through chapter 4 in the Young book, and all O'Reilly examples, but is a hell of a long way from Mozilla. My criteria for participation are harsh: 1) You must not own or otherwise have access to a copy of Motif, unless you are in charge of compiling statically linked comparative binaries. 2) You can only work from published information in books and source code on the net. 3) You may *not* use the LessTif code base, since they used examination of header file contents, name lists of libraries, and other quasi-legal means to obtain their information. 4) All internal structures must be documented as to their derivation from public information. The point of doing this is to ensure that, once complete, the former OSF doesn't come and rain on your parade when you start taking market share away from them. So far, I'm the only participant, and I haven't been participating for about 8 months. I am now of the opinion that pursuing Motif is a mistake, but if you meet the above criteria, I can clean up a snapshot of the code and ship it off to you, even though I think you would be wasting your time, in the long run. If you want to use a mostly complete Motif clone, I'd suggest using LessTif, which should be around until it really works, which, like WINE, I think will take a long time. > I would be happy to donate my already sparse free time on such a project > wherever possible. I was always reluctant to pursue it because the whole "look and feel" issue for applications. I think that the "look and feel" should be embedded in the window manager, and that the clients should make higher level requests, like "create a popup list box" or "Add a button with the label 'OK'" (this has been my opinion since at least 1988). I actually believe that the future lies with things like "VNC": http://www.uk.research.att.com/vnc/ Because VNC can replicate frame buffer contents over a network (a simplified description, to be sure), you can get rid of most of the overhead of X11 by declaring that your network transport is a replication mechanism of some kind. This basically means that there are three pieces to be built: 1) A distributed, coherent virtual framebuffer piece with an Alpha channel This is the tricky part. This basically allows applications on multiple machines to write to the same frame buffer, and to introduce clipping based on a police enforced by a management piece (traditionally, a window manager) for each virtual connection to the framebuffer. Clearly, backing store is the responsibility of the client. 2) A replication piece Ideally, you would replicate by taking a virtual framebuffer, making it a Corba object, and embedding it in a real framebuffer. 3) A direct-to-framebuffer graphics library interface This should probably resemble the Win32 API, in order to make applications easy to port. You could probably leveage the commercial backing of the WINE API library code (WINE itself continues to languish). 4) A real framebuffer object, preferrably capable of having a CORBA frambuffer object embedded in it. This *must* be very thin. Target it for no more than 512k. Expect to implement it on VESA on DOS (or DR-DOS), and expect to implement it on a single FreeBSD boot floppy or a FLASH RAM card. It must include transport interfaces. The idea would be to be able to build the thinnest dispaly and I/O possible. Targets include: http://www.franklin.com/rex/ http://www.palm.com/home.html http://www.qubit.net/ The last one in this list is the most sexy. Business Week states a target retail price of less than $350. The implied CORBA requirement allows it to all come together with applications like KDE and KOffice, which are sitting on top of X11, and as a result, tend to have a very large GUI footprint (minimally, eight times the available RAM in most portable devices). It also allows proxy (assuming a Win32 ABI) for real Windows applications. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199903061812.LAA03755>