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
Marcus Harnisch writes:
What is the current state?
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.
Embarassingly, to a new user, Win32 support appears to integrated
best of all platforms. I am not talking about technical details or
internal functionality here! I am talking about "look and feel".
And, BTW, what is "native look-and-feel" these days anyway?
to various skinnable and themeable applications (audio players, and
certain webbrowsers), this is a thing of the past.
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.
I had to switch to Office2007 recently, which was definitely a long
overdue upgrade (from '97). But it took me *several minutes* until
I figured how to print my freakin' document.
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
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
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.
There is always a split to be made between having a particular
application behave the same way on every platform, so that experienced
users will feel home immediatly even when switching from, say, Unix to
Windows or vice versa -- or whether that application should be as
tightly integrated into each platform's user interface to make it look
familiar to new users (experienced on the platform perhaps but not
with the application itself), even at the expense of confusing
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.
Xft: Of course it is not cross platform. That's my point! We
have to worry about stuff like that. We should rely on toolkit
functions for display the same way as we rely on the OS for file
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.
On the other hand, the XEmacs idea that dialogs will only be used
functions called via menu should be relaxed. Some functions on
platforms don't work reasonably well without a dialog. M-x
print-buffer/-region/etc. in Win32
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
> Sure, I'm working on that. That's one of the main
reasons I don't
> really consider 21.5 to be releasable.
And with that, of course, I mean a native font selection dialog...
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.
It might be that the world around us has moved on to XKB.
Maybe I'll find the time for a bug report over the weekend.
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. :-(
We should face the inevitable truth and not fool ourselves: Any
toolkit decision will cause grief for a subset of XEmacs users --
just as the current situation does for some.
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
XEmacs-Beta mailing list