Re: Compiling Emacs with GTK

[David Kastrup <dak@gnu.org>]

nfreimann <niels_freimann@yahoo.de> writes:

>  --- August <fusionfive@comhem.se> schrieb: 
>
>> With "the standard Emacs release" I mean the non-CVS
>> version. Will this
>> GUI support make it to the next release?
>
> cvs emacs offers gkt and advanced windows support
> since more than an year. Therefore I wonder that the
> new 21.4 does not support gtk.

21.4 has for a long time been touted as the next great release to
come, with lots of features and so on.  Unfortunately, a serious
security flaw necessitated a quite unplanned release in between,
preempting the version number 21.4.  21.4 is identical to 21.3, with
the single security fix applied.

In order not to confuse people, should something like this be required
again, the next _feature_ release will be called 22.1.  So 22.1 will
definitely support Windows _with_ tooltips and toolbars and images,
and Carbon in the same manner, and GTK.  It is not expected that we
will see a release 21.5, but should it surprise us in the manner that
21.4 did, it will very likely contain nothing like GTK or full Carbon
or Windows support.

> Clearly spoken, emacs without gkt and advanced windows support is
> outdated.  Its looks anachronistic and behaves crippled in linux as
> well as in windows.
>
> There is a excellent windows binary cvs emacs distribution available
> at http://nqmacs.sourceforge.net/. Its the best windows emacs
> ever. Why not supporting a binary cvs gtk2-emacs for linux at
> ftp.gnu or sourceforge.net? Whats the problem with that?

"Supporting a CVS" Emacs is an oxymoron.  The CVS Emacs is notable for
having typically dozens of changes applied daily.  Some of them are
extensive, leading to instability.  Handpicking a reasonable stable
variant, removing debug code, probably applying some fixes while
leaving out others, is work for a QA department.  It would require at
least one person working concentrated on just keeping up the quality
of such a "supported binary".  This sort of QA work does not require
as much qualification as the actual development does, but it still
requires quite a bit of work.  The resulting consistent quality would
probably at this stage of development not be considerable above the
average that we have now, but would basically just have the single
advantage of being consistent: lower chance to catch a lemon that you
would want to fix at most a few days later.

This sort of job could well be done by an average programmer: no
special Emacs programmer would be required for that.

The need does not seem as large as to cause an organized effort,
though.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum