On Sun, 23 Sep 2012, Jelle Hermsen wrote: > It would be great if you would only need to teach one configuration > header about an OS, defining a bunch of have_something macros in > there. However, this will be quite a bit of work, especially when you > consider the support for legacy systems and OSses we can't easily test > on.
We have config/cf/* for that. You can see that NetBSD.cf is there and probably (generations ago) it might have even worked. FreeBSD.cf was from the times around FreeBSD 2.1.7 - 3.0. You might want to check current X.org cf files - some definitions are similar. > I guess we're not just in it for getting things up and running purely > for old time sake right? For me - get RPC/ToolTalk running with IPv6 (requires RPC-TI that BSDs got from NetBSD by the way). And some form of Unicode support. (I am still using rxvt-unicode instead of dtterm because of this). There is a lots of security work to be done - ToolTalk was considered as notoriously insecure. We have thousands of potential buffer overflows in the code. >At one point it might be a good idea to split up the several >applications and libraries that make up CDE. I was always amazed how much energy is spent into packaging. For fans of packaging and dependencies there few relatively simple things to be done: 1. figuring out how much out of current xorg cf files - from ftp://ftp.cs.cuhk.edu.hk/pub/X11/individual/util/xorg-cf-files-1.0.4.tar.bz2 can be used in our build. Maybe even we could sneak our HaveSomething changes into the official xorg-cf distribution and just depend on that. We have separate set of .cf files for dtinfo, which still does not work. 2. figuring out if CDE can be built using stock imake (I guess yes) 3. documentation build - I think that newer (current?) nsgmls won't work with the documentation files/templates we have. Some work is certainly required to give up some of the bundled third party stuff like nsgmls. 4. testing the build with other makes (BSD and GNU makes should work) and compilers (most parts that I tried compile with clang just fine). > CDE might also benefit from a better website. Go ahead :) > I would love to hear what plans there are on this aspect. Frankly I don't know. My primary motivation is sentimental - I did use CDE as my primary work environment since ca. 1994 till ca. 1998 on AIX. I just like the blinking LED on the front panel, design of the dtgreet login screen and the WaterDrops.pm backdrop. Is there anything that CDE may bring to the world? One futuristc example: Everyone seems to depend those days on Microsoft Active Sync to synchronize their calendars and rpc.cmsd provides some alternative (of course it's *way* different and not very practical today). I remember exchanging calendar events between AIX users and machines in the past. Maybe with IPv6, ToolTalk and rpc.cmsd and other services we could have a peer-to-peer desktop environment that does not need to rely on "cloud" stuff like dropbox to exchange things. Just a dream :) //Marcin ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ cdesktopenv-devel mailing list cdesktopenv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cdesktopenv-devel
