Module component list updated [was Re: Modularization development notes]

[Jim Gettys]

I put together a straw man grouping and put it in the wiki a long time
ago... (pre-wiki conversion).  It went through some serious revision as
we did various prototype stuff last year.

Probably worth digging up.
				- Jim


On Wed, 2005-04-20 at 10:48 -0700, Alan Coopersmith wrote:
> Are we going to break every single app out into a separate module/package
> or do we want a logical grouping?   We've already discussed this with Xpm
> & fontconfig, bundling those apps into their libraries.
> 
> Other possible "logical groupings" I see in the list:
> 
> ICE: lib/ICE & programs/iceauth
> SM: lib/SM, programs/xsm & programs/smproxy
> Xv: lib/Xv & programs/xvinfo
> Xcursor: lib/Xcursor & programs/xcursorgen
> XKB-clients: xkbevd, xkbprint, xkbutils, setxkbmap
> XKB-core: libxkbfile, xkbcomp (since they're both client & server)
> Xt-resource-clients: appres, editres, listres, viewres
> Xprint-clients: programs/xphelloworld, xplsprinters, xprehashprinterlist
> DPS: lib/dps, lib/dpstk, dpsexec, dpsinfo, texteroids, makepsres
> X-core-clients: xhost, xauth, xdpyinfo, xset, xwininfo, xlsatoms, xlsclients,
> 	xprop, xmodmap
> 	(xdpyinfo is probably most commonly updated to add new extensions
> 	 that it's useful to report specific details of, so could possibly
> 	 be separate)
> xfs-clients: xfsinfo, fslsfonts, fstobdf, showfont
> X-core-font-clients: xfd, xfontsel, xlsfonts
> X-core-fonts: lib/font, mkfontdir, mkfontscale, bdftopcf
> xwd: xwd, xwud, xpr
> demos/samples: xgc, xdbedizzy
> x-proxy: xfwp, proxymgr, xfindproxy (should probably document xfwp as
> 	deprecated in favor of ssh with X forwarding, but I believe
> 	the others work with lbxproxy and other proxies as well)
> X-input-clients: xsetmode, xsetpointer
> 
> clients that should go away: xmh  (does anyone still use this?  it's been
>   years since I used mh, but even then everyone I knew had switched to exmh
>   for GUI and nmh for command line)
> 
> I suppose the question here is how useful is it to keep these separate or
> are they only likely to be wanted as a group?   And of course, do these
> groupings end up in a dependency graph that's a tree, with no loops or
> other complications?
>