That "vision" thang...

[Marcus Harnisch]

"Stephen J. Turnbull" <stephen at 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 we
> 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
> "in passing".

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
several platforms.

> 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 for
> some reason actually 1.01*A4 page into an A4 page" button somewhere
> different.

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 my
> 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
rarely happens.

> 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) 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.

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! We
>  > 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 used for
>  > 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 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.

No, just once -- using an appropriate toolkit.

> 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.

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: 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.

Perhaps.

> 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.

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.

Regards
Marcus