Warren Turkal writes: > > Is there any chance of upstream acceptance of this type of work? A lot of > the utility binaries should be pretty easy to break out the xc hierarchy. >
This issue is coming up from time to time and I have jet failed to understand the benefit of breaking out things out of the xc hirachy. In fact I can think of a very few things where this may be worthwhile doing. Applications: You can roughly split applications into three groups: 1. system/query: xvidtune, xdpyinfo, xlsfonts, xfd ... 2. applications: xterm, xedit... 3. minor apps/toys: xeyes, oclock, xclock, xcalc ... I would say 1. needs to be shipped with the server core. xrandr belongs in there, too. Most of these apps are meant to either allow for checking the status of the server (for debugging etc) or serve as sample implementations of a functionality which would be absorbed in a GUI base system. Any package in 2 may be worthwhile to be shipped separately. But why bother at all about 3? Libs: The libs can be split up in three cathegories: 1. low level C-bindings for the protocol: libXv, libXcursor, ... 2. Xlib and friends. 3. Toolkits. libXt, libXaw ... I would say 1. needs to be shipped within xc/ as it reflects the version of the extensions shipped with the server. Some people are talking about shipping 2. separately. This could be done, of course, still, I don't see a huge benefit. And why bother about 3 at all? These toolkits are mostly used by legacy applications, they are not under heavy development. The Servers: Building then separately is difficult. To many common parts. The drivers could be built separately but we have an SDK for that. Egbert. _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
