Jan Vroonhof <jan.vroonhof(a)ntlworld.com> wrote:
Didier Verna <didier(a)xemacs.org> writes:
> (I believe that the current status of the default face's background is
> conceptually wrong; I can elaborate on this)
please elaborate.
A face is "conceptually" a set of textual attributes. This means that
faces are important where XEmacs actually draws something. Considering that
[X]Emacs frames are "conceptually" covered by the default face was a broken
and rather dangerous concept at the first place because it made people mix up
textual properties with toolkit object ones. In theory, you should be able to
separate default face properties from toolkit object properties. For instance,
people should have the right to use a blue background for XEmacs frames, while
using a green one behind all text (by specifying the default face background).
This is not currently possible.
In the early XEmacs versions, this special treatment of the default
face didn't have any bad consequences at all, because XEmacs actually drew
everything by himself. However, we have now entered the Piper Era (TM) and
widgets draw more, XEmacs draws less. As an example of a bad consequence, if
you use a background pixmap under the default face, you won't get any in the
gutters which looks very odd. Don't even mention transparency...
On a more technical plan, the current design has two bad implications:
- Some default faces properties (background) must have a special treatment,
inconsistent with the others. For instance, you have to spread the default
face background all over the Emacs windows. However, if you want underline,
you should do it only when there are actually characters (spaces included).
This makes it unavoidable to have kludges that complicate the code and make it
obscure.
- The code is also made even more complex because of functionalities that
underlying layers provide, but still are reinvented in our code. For instance,
X servers know how to put pixmaps on windows background, repaint them
correctly when expose events occur and so on. Because we reinvent this in the
XEmacs code, we have tricky geometry computations to make and more
client/server exchanges needed.
--
/ / _ _ Didier Verna
http://www.inf.enst.fr/~verna/
- / / - / / /_/ / EPITA / LRDE mailto:didier@lrde.epita.fr
/_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 53 14 59 47
94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99