[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Status of my GTK efforts.
Status of my GTK efforts.
Mon, 24 Dec 2001 14:29:37 +0100
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.7+) Gecko/20011221
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:
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.
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.
Other minor details is that there is no ListFonts 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.
Keysyms: You can't query keyboard mapping from GTK.
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
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 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.
Also, a move to CVS must be done, as I understand there is more w32 and
macintosh things there. This would also have to be considered when
trying to find some more or less "generic" GUI interface (probably a lot
"less" in the first attempt :-)
But before that, the fun stuff :-) can be done, dialogs, menubars,
toolbars and scrollbars (well, the last bit might not be that fun...).
And of course clean up of the code :-)
I must say, I am impressed with the stability of the code base of emacs,
even if it shows it's age in some places, being pre-GUI, it does not use
much callbacks at all for instance, fun to see references to X10 in the
code (I don't remember there was an X10 emacs) and so on. But the core
emacs happily moves along, there have not been many modifications needed
in other files besides the X ones (basically adding an #ifdef in
keyboard.c, dispextern.h and fileio.c).
That's about it. As I have two weeks off now, I hope I can squeeze in a
couple of full days hacking, so progress can be done a bit faster than
up to now.
- Status of my GTK efforts.,
Jan D. <=