[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Status of my GTK efforts.
William M. Perry
Re: Status of my GTK efforts.
Mon, 24 Dec 2001 09:10:08 -0500
Gnus/5.090004 (Oort Gnus v0.04) XEmacs/21.5 (asparagus, i686-pc-linux)
"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.
Ceterum censeo vi esse delendam