Re: That "vision" thang...

In general, I don't think the "grief" in the current situation has to do with the difficulty of maintaining support for toolkits. Very little work has been done on them in the last 5 years, yet they continue to "work" at the level of providing *Emacs* features. It's "desktop integration" that has lagged, but that stuff probably is not very hard ... if somebody wants to actually do it. Rather, the issue is lack of developers. There are lots of XEmacs users like you who "want" desktop integration, but you "maybe have time to file a bug report". That's not a criticism of you; if that's where your life is at, maybe you *should* move to GNU Emacs, SXEmacs, or even Eclipse + vi. ;-) Of course I'd be very happy if you decide to step up your XEmacs activity in some way (even beyond your recent adoption of a package, I mean; in free software, there's always room for a volunteer to do more! ;-) This is a problem that I pointed out in the runup to the release of 21.4. GUI users don't become Emacs developers. So through GUI support we get a population of users with rather high expectations to support who do little to support themselves. The Mac stuff is quite extreme; there are like 5 Mac Emacsen, each of which has basically *one* developer. Windows is a little better, but we now have no active Windows experts, and GNU has only about three. My *vision* is that the most likely way to solve this problem is for XEmacs to provide some killer feature(s) that you can't get anywhere else, and attract people who want some such feature and happen to have appropriate platform knowledge that they'll put to good use sort of "in passing". Marcus Harnisch writes: Of XEmacs? Except for the CUA keymap issue that Aidan referred to, Ben put a huge amount of effort into Windows integration, indeed. I think that's the most important platform for eye candy, anyway, in terms of attracting users. I don't know if we want to do that, though, since they rarely "convert" to developers. Agreed. Au contraire. Themes are varied, but the look-and-feel is basically the same at a certain abstract level. For example, themes do not allow you to turn all your menu-based applications into a keystroke- based ones. They don't allow you to turn double-clicks into shift- ctrl-click on a system-wide basis, AFAIK. And, as Olivier points out, they introduce a whole new set of nonportable look-and-feel problems in the theme configuration system. Yeah, I know. Every GUI puts the "squeeze this nominally A4 but for some reason actually 1.01*A4 page into an A4 page" button somewhere different. This is exactly why I refuse to have any truck with GNOME or KDE on my own desktop. *They make my life harder.* Now, that probably makes me a less than optimal meta-maintainer for the mass of users who want an editor that is just like all the others except better. As ESR said, "Take my job, please!" :-) What we need is a proponent for GNOME-style theming arising who is also willing to coordinate the work to ensure that it works for Motif, Aqua, Windows, and (ooh! yuck!) KDE users, too. Because that has been a consistent theme of XEmacs development: abstract the interface to the console (ie, the GUI widget sets, TTYs, stdio streams, etc), and support them fairly across the board. I don't think the current Review Board is likely to abandon that principle, in the absence of a strong active developer willing to provide leadership in another direction. Steve Youngs was one such leader, but he decided (correctly, IMO) that a fork was necessary, as the rest of the Board was decidedly unsympathetic to initiatives like "remove Windows support". FWIW, I don't think that SXEmacs has gone in the GUI direction that you suggest as desirable. This is quite true. Yet (once again, CUA keymap aside) XEmacs does a pretty good job of providing both on Windows. Especially if you compare to Windows circa 2002, when Andy and Ben both deactivated. But we don't! Have you looked at src/sysdep* recently? And IMO we should not rely on toolkit functions. They are not sufficient to do what we need for proper Unicode support in MULE, while still supplying faces and all that stuff. What we need is something on the level of the Mozilla redisplay, "gecko", not the kind of simple widgets provided by toolkits. File a bug, please. I'd do it except that I won't know what, if anything, "/etc" means, so you can just cut and paste the paragraph above and expand $etc (to the empty string if appropriate :-). I suspect invoking dialogs from the keyboard will not work well in current 21.5 because of the unstable state of the window configuration code. I don't have time to do that; I might *implement* one for Xt/Xft, but somebody else must do it for GTK/Qt/Aqua/Motif/Windows/whatever. It's probably not hard. Almost certainly they all just require that you call one function that pops up the dialog and returns the appropriate kind of font name for the platform as a string. But of course the only ones of those with working/official support are Motif and Win32. The hardest part will be working around the modality that some toolkits insist on. Please do. I've long thought we need to support XKB, but I have no way to determine whether it works or not because my needs require an input method that simply steals the keyboard entire, or simply support for a vanilla QWERTY keyboard with control and meta keys. :-( I think there's a common misunderstanding of what a toolkit can actually provide for applications like Emacsen and web browsers. In the XEmacs architecture, implementing a feature that's already present in a toolkit and already used by other toolkits in XEmacs is something that can be done as a once-off contribution by a user (maybe with advice from a core developer). Implementing it the first time is hard, implementing the second one may require refactoring. After that, though, supporting a feature on additional platforms really just requires a user or two able and willing to dirty their hands with code. _______________________________________________ XEmacs-Beta mailing list XEmacs-Beta(a)xemacs.org http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta