Yaakov (Cygwin Ports) wrote: > [big list of packages] All seems reasonable to me.
> Font server > Packages: libFS, fslsfonts, fstobdf, showfont, xfs, xfsinfo > The default in git master is now to use builtin fonts instead of > server-side bitmap fonts, and using the former absolutely precludes the > usage of xfs (see dix/dixfonts.c:InitFonts()). Most toolkits use > client-side fonts via fontconfig; server-side fonts is only for the most > basic X11 apps AFAICS. The advantage of this approach would be that it > removes the "XWin can't find fonts" FAQ, but I'm not sure how that would > affect Xt/Xaw apps, which can set fonts as a resource but don't use > libXft. I'm leaning toward removing the font server packages while > leaving server-side fonts enabled for now. This seems a reasonable interim step, although presumably there is some kind of migration path for those applications which only use server-side fonts. Won't -enable-built-in just transform that FAQ from "my server can't start because it can't read the fixed font" to "my apps can only use the fixed font as they can't read any of the others" ? I guess I don't understand why libXfont can't be patched to open the files in binary mode, avoiding this problem? I notice that something (presumably in the existing X installation scripts has done: mount -f -s -b "C:/cygwin/usr/X11R6/lib/X11/fonts" "/usr/X11R6/lib/X11/fonts" presumably in an effort to avoid this problem. It might be a good idea to arrange a similar thing? > Yaakov (Cygwin Ports) wrote: >> On that basis, I want to review the deprecated extensions and packages >> and discuss what should be done with them: > > Let me add one more obsolete extension: > > Windows-WM > Packages: windowswmproto, libWindowsWM, xwinwm > In 2004, xwinwm, an external multi-window WM for XWin, was released as > an experimental alternative to the builtin multiwindow mode. AFAIK no > development has happened on it since. I just tried building this, and > xwinwm doesn't compile anymore (looks like it needs a patch for > gcc-3.4), and enabling the related code in hw/xwin leads to undefined > references at link time (code refactoring?). So this is obviously going > away as well until someone gets both xwinwm and the support in hw/xwin > to build. Yeah, this confuses me also. I have worked out the server changes to build with the extWM support. These mainly relate to enabling the rootless extension (which isn't used in -rootless mode, confusingly). I don't understand what the difference is between using the extWM and using the internalWM in -multiwindow. Is it just a development convenience in that you can change, rebuild and restart the WM without having to restart the server, or does the fact it operates in rootless mode give some extra functionality? ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Cygwin-ports-general mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/cygwin-ports-general
