Re: Status of my GTK efforts.

[William M. Perry]

"Jan D." <address@hidden> writes:

> Well, I'm off to christmas dinner soon, but I thought I'd drop a note
> about how the GTK work progresses
>
> 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.  Maybe 2.0 is better.  The reason is
> that some things are abstracted away in GTK.  These are the main points:

This is what I discovered in XEmacs... the main sticking point was handling
the modifier keys correctly.  I broke down and just used X directly in the
few cases necessary with gigantic 'FIXME!!!' comments in the code.

> Fonts: GTK does not let you have access to min and max bounds.  Also, it
> has a bug in 8/16 bits character handling for fonts.  Basically it
> assumes 8 bit characters for 8 bit fonts and 16 bit characters for 16 bit
> fonts.  Internally emacs uses 16 bit characters in 8 bit fonts, and
> sometimes you wan't 8 bit characters with 16 bit fonts.  This is just not
> possible with GTK 1.2.

This sounds significantly different than how XEmacs/Mule does its
handling.  I'm not sure how much I could help here...

> I filed a bug report on that, the answer was that the current font
> handling is to be removed in 2.0 with an new internationalization
> (phu...) library, pangea I think the name was.

Pango (http://www.pango.org/) is the new way of drawing text and dealing
with fonts in Gtk 2.x.  It looks pretty powerful, and could make a lot of
the unicode redisplay nice, but I have not looked at it extensively yet.

> Other minor details is that there is no ListFonts function.

Is this actually needed?  I used X specific routines in XEmacs, but that
was just to be complete in the port.  What exactly would break if you
just don't have this function?

> Error handling: GTK lets you push an "ignore error" condition and later
> pop it off.  But you can't query if an X error actually occurred.

You could try to analyze the code coming out of the g_log() routines, but
I hate heuristics like that.

> On the bright side, apart from the above, most of the basic GTK migration
> is done, that is I have a "basic" emacs, with no toolbar, menubar or
> scrollbar.  But all the editing stuff, faces, resize, events and so in is
> with GTK primitives.  I think it is what was called "self-hosting" :-)

That is great news!  Is this checked into CVS anywhere?  Would be nice to
get this type of stuff on a branch so others could play with it and help
out as required.  Does opening a GTK device from a TTY session work?

> There is much left to of course.  Moving code from the big event handling
> function to widget callbacks.  Figuring out if the image cache is really
> needed, GTK already does something like that.  How shall X resources be
> handeled, GTK way or a combination of both if X is available?

I wrestled with the X resource problem for a while in XEmacs and finally
just decided it wasn't worth it.  GTK applications do not handle X
resources at all, and I think there is an inherent conflict between them
and Gtk `styles'.  Also, I am a huge fan of doing all the face
initialization from lisp, so that settings will follow your .emacs instead
of your Xrdb settings. :)  And also follow you to another platform if you
are ever sullied by Windows.

> I am currently working in separate GTK files and with 21.1.  These
> working files (g_xterm.c does what xterm.c does and so on) obviously
> contains a lot of duplicated generic code.  I hope to be able to find
> some abstraction level where at least X and GTK can get along without too
> much code duplication.

I'm trying to do similar work in the XEmacs code - there is a lot of
duplicated code in redisplay and the event handling loop, just function
names are different.  Very annoying, but it works for a first pass.

-bp
-- 
Ceterum censeo vi esse delendam