Mercurial > hg > xemacs-beta
comparison man/internals/internals.texi @ 2438:6c7488f5350a
[xemacs-hg @ 2004-12-14 10:01:41 by stephent]
doc Xft issues <87acshnqr2.fsf@tleepslib.sk.tsukuba.ac.jp>
| author | stephent |
|---|---|
| date | Tue, 14 Dec 2004 10:01:52 +0000 |
| parents | 8f3d34b5fc05 |
| children | 6a51753a5f65 |
comparison
equal
deleted
inserted
replaced
| 2437:807b51903ed4 | 2438:6c7488f5350a |
|---|---|
| 13393 | 13393 |
| 13394 These modules implement the @dfn{console} Lisp object type. A console | 13394 These modules implement the @dfn{console} Lisp object type. A console |
| 13395 contains multiple display devices, but only one keyboard and mouse. | 13395 contains multiple display devices, but only one keyboard and mouse. |
| 13396 Most of the time, a console will contain exactly one device. | 13396 Most of the time, a console will contain exactly one device. |
| 13397 | 13397 |
| 13398 @strong{This model may no longer suffice.} The X Window System (at | |
| 13399 least) now supports a variety of input devices, including touchscreens | |
| 13400 and tablets, as well as the traditional keyboard and mouse, and may even | |
| 13401 be able to support multiple instances of a single type of input device | |
| 13402 (especially pointing devices) on a single console. | |
| 13403 | |
| 13398 Consoles are the top of a lisp object inclusion hierarchy. Consoles | 13404 Consoles are the top of a lisp object inclusion hierarchy. Consoles |
| 13399 contain devices, which contain frames, which contain windows. | 13405 contain devices, which contain frames, which contain windows. |
| 13400 | 13406 |
| 13401 | 13407 |
| 13402 | 13408 |
| 13418 The device subsystem defines all the methods and provides method | 13424 The device subsystem defines all the methods and provides method |
| 13419 services for not only device operations but also for the frame, window, | 13425 services for not only device operations but also for the frame, window, |
| 13420 menubar, scrollbar, toolbar, and other displayable-object subsystems. | 13426 menubar, scrollbar, toolbar, and other displayable-object subsystems. |
| 13421 The reason for this is that all of these subsystems have the same | 13427 The reason for this is that all of these subsystems have the same |
| 13422 subtypes (X, TTY, NeXTstep, Microsoft Windows, etc.) as devices do. | 13428 subtypes (X, TTY, NeXTstep, Microsoft Windows, etc.) as devices do. |
| 13429 | |
| 13430 @strong{This abstraction is probably broken} (as of late 2004), at least | |
| 13431 for X consoles, with the advent of the @strong{Xft} library. Xft is a | |
| 13432 complete break from the traditional approach to text rendering in the | |
| 13433 X11 environment, since fonts are composed of glyphs rendered by | |
| 13434 @emph{client-side} code. These glyphs are then transmitted to the | |
| 13435 server as sets of trapezoids, and displayed by the @strong{XRender} | |
| 13436 extension (where available; the X11 core protocol can also be used, but | |
| 13437 this is slow). The XRender extension is especially attractive because | |
| 13438 it allows modern image composition techniques to be used to render | |
| 13439 antialiased fonts. | |
| 13440 | |
| 13441 By contrast, the traditional approach renders fonts on the server side | |
| 13442 as a collection of bitmaps. It is also possible use a @emph{font | |
| 13443 server} that knows how to render antialiased fonts, but for some reason | |
| 13444 this approach has never caught on. | |
| 13445 | |
| 13446 The problem that this creates for XEmacs is that the traditional (and | |
| 13447 still popular) widget sets, the various Athena variants and the Motif | |
| 13448 widget set, are based on the server-side rendering model. Thus, even if | |
| 13449 XEmacs-specific widgets (such as the basic text window, the Lucid | |
| 13450 menubar, and the recently added tab control) can be adapted to render | |
| 13451 text via Xft, older widgets (such as buttons and labels) and ``modern'' | |
| 13452 widgets derived from traditional widgets (the progress gauge) still | |
| 13453 expect their font resources to be converted to server-side fonts. Then | |
| 13454 text is rendered by calls to the core protocol via Xlib, rather than by | |
| 13455 calls to the XRender protocol via Xft. | |
| 13456 | |
| 13457 It's even possible to imagine a situation where a widget is composed of | |
| 13458 components which draw their own text (@emph{predefined widgets}) as well | |
| 13459 as new components which can draw using more modern methods. Handling | |
| 13460 this will either require reworking the Emacs face mechanism to provide a | |
| 13461 way to determine whether this widget can use that font, or ways to give | |
| 13462 each of several different widgets, even different components of a given | |
| 13463 widget, a different face property. This is already an issue, as widgets | |
| 13464 generally derive their font from the gui-element face, but this might | |
| 13465 not be appropriate for widgets embedded in a buffer. | |
| 13466 | |
| 13467 There seem to be two overall ways to go. | |
| 13468 | |
| 13469 @enumerate | |
| 13470 @item | |
| 13471 Add face information to the Lucid widget library, and extend the | |
| 13472 coverage of that library to device types that aren't supported by it yet | |
| 13473 (MS Windows, and maybe TTY). | |
| 13474 | |
| 13475 @item | |
| 13476 Create a lighter-weight interface, perhaps an extension of the device | |
| 13477 interface, that allows widgets to access face information from the | |
| 13478 device it is implemented on. | |
| 13479 @end enumerate. | |
| 13423 | 13480 |
| 13424 | 13481 |
| 13425 | 13482 |
| 13426 @example | 13483 @example |
| 13427 @file{frame-msw.c} | 13484 @file{frame-msw.c} |