[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: Wed, 26 Dec 2001 17:22:06 -0700 (MST)

    I may indeed.  My plan was really the opposite.  Replace as much as 
    possible with GTK calls.

That sounds like the wrong direction, because it would maximize the
amount of code which we have to maintain in a GTK version and in an X

What we want to do is minimize that amount, because it reduces the
total size and complexity of Emacs.  We can't get rid of that other
code, because we are not going to drop the support for other toolkits.

    I totaly agree about sharing code from xterm.c as much as possible.  But 
    does it really matter if we get font info using XTextExtents16 or 

It matters whether we have two versions of the code to get the font info
instead of one.  We must have the code that uses XTextExtents16.
Why have a second version as well?

    > 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

    Simply because it means less code.

No, it means more code, and more complexity.  We must keep supporting
XTread_socket.  Your way, we would have to support both that and another
way of doing the same job.

      Granted it can be 
    made to work, but we would be using undocumented stuff (I only got it 
    working by looking at the GTK source) that could break at the next GTK 

That is not good.  I need to talk with the GTK developers about this.
GTK should expose those interfaces to allow an app to maintain
its own event loop in a clean way that will continue to be supported.

***Can you please write down a specific list of the facilities you
would need in order to do this?***  I need that in order to talk
with them.

There is one way in which the GTK-based alternative code could be a
good thing to install: if on some other system (perhaps Windows,
perhaps the Mac) we could drop native support and support only
GTK-based operation.  Then the GTK-based alternative code could
replace the native code for that platform.

I don't know whether this is a reasonable thing to do on Windows
or on the Mac.  Can anyone say?

reply via email to

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