"Stephen J. Turnbull" <stephen(a)xemacs.org> writes:
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.
And that's exactly why we need to outsource stuff. Pick a reasonable
cross platform toolkit for XEmacs and implement as much as possible
through this abstraction layer. Issues that are toolkit related will
be pushed upstream. Of course this is easier said than done.
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. ;-)
And in which way would that be better for me? Is desktop integration
of any of these significantly superior?
GUI users don't become Emacs developers. So through GUI support
get a population of users with rather high expectations to support
who do little to support themselves.
I disagree. Except maybe for some extreme cases (like thesis
assignments or similar), every developer starts out as user. I do
agree that only a fraction of new users will end up as
contributers. But even attracting just a handful would already more
than double the current active developer base.
Sex sells, they say. And XEmacs needs some serious boobs.
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
Except that the definition of "killer feature" is a bit vague. XEmacs
has plenty of killer features already. Problem is that people don't
even consider those as long as the basic stuff doesn't work right.
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.
I suspect you are right. But had we put similar effort into a cross
platform toolkit (hypothetical, because at the time these weren't in
the state that they're in now) we'd have the situation solved on
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.
What I was trying to say is that native look-and-feel of cross
platform toolkits is not the issue. Perhaps a concrete example of a
prohibiting lack in look-and-feel on some platform would help me
understand what you are worried about.
Yeah, I know. Every GUI puts the "squeeze this nominally A4 but
some reason actually 1.01*A4 page into an A4 page" button somewhere
Simpler than that: I was looking for the button that does the same as
File->Print in basically every GUI since the Apple Lisa.
This is exactly why I refuse to have any truck with GNOME or KDE on
own desktop. *They make my life harder.*
They don't for me. I use the desktop for some things but not for
others. I get mad only when it *prevents* me doing something, which
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.
Wrong approach. That'd be fives times the work.
Steve Youngs was one such leader, but he decided (correctly, IMO)
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.
Unlikely. Plus I appreciate XEmacs' Windows support.
> There is always a split to be made between [...]
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.
As I said, Windows support is one of the best these days. I forgot to
mention that drag-and-drop works nicely too.
> Xft: Of course it is not cross platform. That's my point!
> shouldn't 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 I/O.
But we don't! Have you looked at src/sysdep* recently?
Oh my God! So (X)Emacs *is* an OS.
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.
And Mozilla uses toolkits for widgets, no?
> On the other hand, the XEmacs idea that dialogs will only be
> 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 :-).
It turns out $etc is the empty string. I was too lazy to check out all
functions starting with `print-'
> And with that, of course, I mean a native font selection
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.
No, just once -- using an appropriate toolkit.
It's probably not hard. Almost certainly they all just require
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.
You mean the fact that I can't do anything else until I closed that
print dialog? I agree in theory, but in real life this doesn't bother
me very often.
> We should face the inevitable truth and not fool ourselves:
> 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
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.
But why. That same developer would spend his/her time better with
implementing *an additional* feature rather than one feature for a
number of platforms.
XEmacs-Beta mailing list