On Wed, Mar 17, 2004 at 11:13:16AM +0000, Tom Payne wrote:
> - It's too high level because I can't just replace the string drawing code
> to use Xft: I have to duplicate everything else in the drawing engine too.
> - It's too low level because I can't write a Gtk-based drawing engine that
> uses Gtk input boxes for the minibuffers.
Something gtk-based would not be a drawing engine but a reimplementation of
all of Ion's policies into something totally different.
It is not currently easy to simply replace a part of the drawing engine, but
with small modifications inheritence should allow for that; see a part of
a discussion I had with Andreas Happe below.
> - display extra information in tabs, specifically the tab index so I don't
> have to count tabs to use my Mod+<n> shortcut to jump to the <n>th tab.
This is something that frames should implement, not the drawing engine.
> - provide a much high level interface, something like:
> draw_frame(<dimensions>, <list-of-tabs>, ...)
> do_minibuffer(<prompt>, <completion-func>, ...)
> do_menu(<location>, <menu-items>, ...)
No. In the current implementation drawing engines don't have to know
anything about the objects they're used to draw (but they do have that
information), and that's how it should be. With your proposed method the
drawing engines would have to have specific support for all possible
objects and extended always when a new object is added, and that is a
maintenance nightmare.
--Older discussion follows--
Actually, it might be possible to do this whole xftde thing by inheritance
with only a few minor change to the original de that should not affect the
"stable" status of it:
* dementbrush_init should be fixed to use the brush's dynfuns for
font access.
* destyle_init should be globally visible instead of static.
* Replace one occurence of debrush_get_text_width with
grbrush_get_text_width
* Make debrush_do_draw_string a dynfun. (Simply getting rid of the function
and using grbrush_draw_string introduces performance penalties in
the form of string concatenation as I don't want to extend the grbrush
API.)
* The following functions in init.c should be made globally visible as:
get_border -> de_get_border
get_text_align -> de_get_text_align
get_transparent_background -> de_get_transparency
Possibly also
get_colour_group -> de_get_colour_group
get_extra_cgrps -> de_get_extra_cgrps
depending on how you implement mapping between X and Xft colours, if
you plan to go ahead with this.
What you need to do now is:
* Create an XftDEStyle structure that has the original DEStyle structure
as first entry and then contains the font information for the stynle
(__leave DEStyle.font NULL__), and (this is the ugly part) possibly
extra colour information for all the colour groups.
* Make XftDEBrush, XftDETabBrush, etc. inherit their DE counterparts,
but specify new font-related routines, the slave brush request routine,
and, of course, the destructor/deinitialisation routine.
* The "GC creation" and "Border widths" sections in brush.c can be ignored,
but of most of the rest of the functions (and the styles variable) in it
Xft versions should be created (that call the originals much of the time)
as we don't want the XftDE styles on the same list as DE styles, and the
brush lookup routines need to create different brushes.
* Implement dexft versions of the stuff in init.c starting
from de_do_define_style.
* Create xftdelib.lua
[NOTE: Ion3 no longer has delib.lua, it is all C.]
* See 'pinfo libtool' for help on how to make your module depend on
'de.(so|a)'.
There might be something else that I have missed, but that looks like the
necessary set of things to do.
--
Tuomo
