[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Status of my GTK efforts.

From: Richard Stallman
Subject: Re: Status of my GTK efforts.
Date: Tue, 25 Dec 2001 14:39:46 -0700 (MST)

    It has been an interesting learning experience.  Both of emacs and
      GTK.  The sad news is that there is no way to make a "GTK only"
      port using GTK 1.2 and probably not 1.3 either.

I am not completely sure what a "GTK-only port" would be, but if it
means avoiding direct access to X, that is not our design goal.

Instead, our goal is to share as much as possible of the existing
code--to *avoid* writing GTK-based replacements for Xlib-based code
that works ok in the GTK-using version of Emacs.  In particular, the
font-handling code in xfaces.c should be shared if this is possible.
We also want to keep the amount of GTK-specific code in redisplay
small (though it need not be zero).

Have you been heading in the wrong direction?

    Fonts:  GTK does not let you have access to min and max bounds.

Isn't this handled by the code in xfaces.c that we want to share
anyway?  The font-handling code in xterm.c is also desirable to share.

    Other minor details is that there is no ListFonts function.

That is part of the font-handling code in xterm.c that we want
to share, not replace.

    There is much left to of course.  Moving code from the big event 
    handling function to widget callbacks.

We would like to share the XTread_socket code.  To maintain two
different pieces of code to do that job would be a substantial extra
burden--why do you propose doing it that way

      How shall X 
    resources be handeled, GTK way or a combination of both if X is available?

On general principles, they should be handled the X way, because
that's already written in xrdb.c.  We don't want the added complexity
of two different versions of this code.  Why do you propose something
else?  What would the advantage be?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]