[Top][All Lists]

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

Re: Status of my GTK efforts.

From: Jan D.
Subject: Re: Status of my GTK efforts.
Date: Wed, 26 Dec 2001 04:47:42 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7+) Gecko/20011221

    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.

As I see it, an GTK-only port would be code that works on platforms that GTK is ported to, without using platform specific code in Emacs (be it X, w32, mac). Instead GTK would take care of the platform differences.

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?

I may indeed. My plan was really the opposite. Replace as much as possible with GTK calls. That way I would get a good grip on what is generic and what is specific. Using that knowledge, one could refactor out the specific parts and keep the really generic parts. The specific parts would then be the interface or porting level that had to be rewritten for each specific platform.

Using Xlib as the abstraction level works as well. But using GTK on anything other than X would probably be hard or at least confusing.

I really don't have any preferencs, I see this as a way to learn about Emacs and GTK (I've already learned a lot). If there is a policy to use Xlib, I can do that as well (it will probably be easier).

    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.

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 gdk_text_extents? Or a (hypotetical) function x_get_font_extents that does the right thing depending if we are using X, GTK or something else? We get another function call, granted it is some performance loss, but the gain in portability is great. On the other hand, I really don't now the policy for portablility in Eamcs, it may not be an important issue.

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

Simply because it means less code. GTK already does some of what XTread_socket does (like refreshing keyboard mappings), and some things are not possible to handle at all without using GTK callbacks (like WM protocols that deletes windows). When I say "at all" I really mean "without great difficulty". It is possible, it is just software, anything is possible.

And of course portability as mentioned before. Using GTK defined callback greatly enhances the possibility of using GTK on non-X platforms.

After working with it for a while I must say that the event loop of GTK does not play nice with other (non-GTK) event code. It is hard to get right (GTK does all kinds of event buffering, filtering and event compression). It really wants it own event loop. 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 version.

Personally, I'd be happy to reuse XTread_socket, but I think it would be ugly.

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?

Traditionally, GTK applications don't use the X way (which I don't agree with on principle, I like .Xdefaults :-). But the advantages if Emacs used the GTK way would be (apart from portability), that one could write Emacs themes to change the look and feel. This is just eye-candy, but seems to matter a lot to users.

        Jan D.

reply via email to

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