Re: Status of my GTK efforts.

[Jan D.]

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