Prima::X11 - usage guide for X11 environment |
Prima::X11 - usage guide for X11 environment
This document describes subtle topics one must be aware when programming or using Prima programs under X11.
The document covers various aspects of the toolkit and their implementation details with guidelines of the expected use. Also, standard X11 user-level and programming techniques are visited.
--help
--display
XOpenDisplay(null)
) behavior applies.
Example:
--display=:0.1
--visual
--visual=0x23
--sync
--bg
, --fg
--bg=BlanchedAlmond
--font
--font='adobe-helvetica-medium-r-*-*--*-120-*-*-*-*-*-*'
--no-x11
Prima::Application
or otherwise
access X-depended code under such conditions causes the program to abort.
There are alternatives to use the command switch. First, there is module Prima::noX11
for the same purpose but more convenient to use as
perl -MPrima::noX11
construct. Second, there is a technique to continue execution even if connection to a X server failed:
use Prima::noX11; use Prima;
my $error = Prima::XOpenDisplay(); if ( defined $error) { print "not connected to display: $error\n"; } else { print "connected to display\n"; }
The the Prima::noX11 manpage module exports a single function XOpenDisplay
into
Prima
namespace, to connect to the X display explicitly. The display to be
connected to is $ENV{DISPLAY}
, unless started otherwise on command line ( with
--display option) or with parameter to the XOpenDisplay
function.
This technique may be useful to programs that use Prima imaging functionality and may or may not use windowing capabilites.
X11 provides XRDB, the X resource database, a keyed list of arbitrary string values stored on the X server. Each key is a combination of names and classes of widgets, each in string form. The key is constructed so the leftmost substring ( name or class ) corresponds to the top-level item in the hierarchy, usually the application name or class. Although the XRDB can be changed via native X API, it is rarely done by applications. Instead, the user creates a file, usually named .Xdefaults, which contains the database in the string form.
The format of .Xdefaults directly reflects XRDB capabilities, one of the most important of which is globbing, manifested via * ( star ) character. Using globbing, the user can set up a property value that corresponds to multiple targets:
*.ListBox.backColor: yellow
The string above means that all widgets of ListBox class must have yellow background.
The application itself is responsible for parsing the strings and querying the XRDB. Also, both class names and widget names, as well as database values are fully defined in terms of the application. There are some guidelines though, for example, colors and fonts best described in terms, native to the X server. Also, classes and names are distinguished by the case: classes must begin with the upper register letter. Also, not every character can be stored in the XRDB database ( space, for example, cannot) , and therefore XRDB API automatically converts these to _ ( underscore ) characters.
Prima defines its all set of resources, divided in two parts: general toolkit settings and per-widget settings. The general settings functionality is partially overloaded by command-line arguments. Per-widget settings are fonts and colors, definable for each Prima widget.
All of the general settings are applicable to the top-level item of widget
hierarchy, named after the application, and Prima
class. Some of these,
though, are needed to be initialized before the application instance itself is
created, so these can be accessed via Prima
class only, for example,
Prima.Visual
. Some, on the contrary, may occasionally overlap with
per-widget syntax. In particular, one must vary not to mix
Prima.font: some-font
with
Prima*font: some-font
The former syntax is a general setting, and sets the default Prima font. The latter is a per-widget assignment, and explicitly sets font to all Prima widgets, effectively ruining the toolkit font inheritance scheme. The same is valid for an even more oppressive
*font: some-font
record.
The allowed per-widget settings are colors and font settings only ( see corresponding sections ). It is an arguably useful feature to map all widget properties onto XRDB, but Prima does not implement this, primarily because no one asked for it, and also because this creates unnecessary latency when enumeration of all properties for each widget takes place.
All global settings have identical class and name, varied in the case of the
first letter. For example, to set Submenudelay
value, one can do it either
by
Prima.Submenudelay: 10
or
Prima.submenudelay: 10
syntax. Despite that these calls are different, in a way that one reaches for
the whole class and another for the name, for the majority of these properties it
does not matter. To avoid confusion, for all properties their names and class
are given as PropetyClass.propertyname
index.
Prima::Application defines set of get_default_XXX_font
functions, where each
returns some user-selected font, to be displayed correspondingly in menu,
message, window captions, all other widgets, and finally a default font. While
in other OS'es these are indeed standard configurable user options, raw X11
doesn't define any. Nevertheless, as the high-level code relies on these,
corresponding resources are defined. These are:
Prima::MDI
.
menu_font - Widget::get_default_menu_font. Default font for pull-down and
pop-up menus.
msg_font - Application::get_message_font. Used in Prima::MsgBox
.
widget_font - Widget::get_default_font.
All of the global font properties can only be set via Prima
class, no
application name is recognized. Also, these properties are identical to
--font
, --menu-font
, --caption-font
, --msg-font
, and
--widget-font
command-line arguments. The per-widget properties are font
and popupFont
, of class Font
, settable via XRDB only:
Prima*Dialog.font: my-fancy-dialog-font Prima.FontDialog.font: some-conservative-font
By default, Prima font is 12.Helvetica .
The values of the font entries are standard XLFD strings, the default
*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
pattern, where each star character can be
replaced by a particular font property, as name, size, charset, and so on. To
interactively select an appropriate font, use standard xfontsel
program from
X11 distribution.
Note, that encoding part of the font is recommended to left unspecified,
otherwise it may clash with LANG environment variable, which is used by Prima
font subsystem to determine which font to select when no encoding is given.
This advice, though, is correct only when both LANG and encoding part of a
desired font match. In order to force a particular font encoding, the property
Prima.font
must contain one.
Alternatively, and/or to reduce X font traffic, one may set
IgnoreEncodings.ignoreEncodings
property, which is a semicolon- separated
list of encodings Prima must not account. This feature has limited usability
when for example fonts in Asian encodings result in large font requests.
Another drastic measure to decrease font traffic is a boolean property
Noscaledfonts.noscaledfonts
, which, if set to 1, restricts the choice of
fonts to the non-scalable fonts only.
Recently, Prima was made to compile with Xft library, which contrary to core X
font API, can make use of client-side fonts. Plus, Xft offers appealing
features as font antialiasing, unicode, and arguably a better font syntax. The
Xft font syntax is inherited from fontconfig
library and to be consulted
from man fonts-conf
, but currently ( November 2003 ) basic font descriptions
can be composed as follows:
Palatino-12
A font with name Palatino
and size 12.
Arial-10:BI
A font with name Arial
, size 10, bold, italic. The fontconfig
syntax
allows more than that, for example, arbitrary matrix transformations, but
Prima can make use only of font name, size, and style flags.
--no-xft
--no-xft
command-line argument, and boolean UseXFT.usexft
XRDB property
can be used to disable use of the Xft library.
--no-core-fonts
fixed
fonts. The fixed
font is selected for the same reasons that X server is designed
to provide at least one font, which usually is fixed
.
It is valid to combine --no-core-fonts
and --no-xft
. Moreover,
adding --noscaled
to these gives Prima programs a 'classic' X look.
--font-priority
xft
or core
, to select a font provider mechanism
to match unknown or incompletely specified fonts against.
Default value: xft
( if compiled in ), core
otherwise.
--no-aa
X traditionally contains a color names database, usually a text file named rgb.txt. Check your X manual where exactly this file resides and what is its format. The idea behind it is that users can benefit from portable literal color names, with color values transparently adjustable to displays capabilities. Thus, it is customary to write
color: green
for many applications, and these in turn call XParseColor
to convert strings
into RGB values.
Prima is no exception to the scheme. Each widget can be assigned eight color
properties: color
, hiliteBackColor
, disabledColor
, dark3DColor
backColor
, hiliteColor
, disabledBackColor
, light3DColor
by their name:
Prima.backColor: #cccccc
Additionally, set of command-line arguments allows overriding default values for these:
--fg
- color
--bg
- backColor
--hilite-fg
- hiliteColor
--hilite-bg
- hiliteBackColor
--disabled-fg
- disabledColor
--disabled-bg
- disabledBackColor
--light
- light3DColor
--dark
- dark3DColor
X protocol works with explicitly defined pixel values only. A pixel value, maximum 32-bit value, represents a color in a display. There are two different color coding schemes - direct color and indexed color. The direct color-coded pixel value can unambiguously be converted into a RGB-value, without any external information. The indexed-color scheme represents pixel value as an index in a palette, which resided on X server. Depending on the color cell value of the palette, RGB color representation can be computed. A X display can contain more than one palette, and allow ( or disallow ) modification of palette color cells depending on a visual, the palette is attributed to.
A visual is a X server resource, containing representation of color coding
scheme, color bit depth, and modificability of the palette. X server can ( and
usually does ) provide more than one visual, as well as different bit depths.
There are six classes of visuals in X paradigm. In each, Prima behaves
differently, also depending on display bit depth available. In particular,
color dithering can be used on displays with less than 12-bit color depth. On
displays with modifiable color palette, Prima can install its own values in
palettes, which may result in an effect known as display flashing. To switch to
a non-default visual, use Prima.Visual
XRDB property or --visual
command-line argument. List of visuals can be produced interactively by
standard xdpyinfo
command from X distribution, where each class of visual
corresponds to one of six visual classes:
PseudoColor
Prima resorts to that only if X
server cannot allocate another color.
On PseudoColor
and GrayScale
Prima allocates a small set of colors, not
used in palette modifications. When a bitmap is to be exported via clipboard,
or displayed in menu, or sent to a window manager as an icon to be displayed,
it is downgraded to using these colors only, which are though guaranteedly to
stay permanent through life of the application.
As described in the previous section, X does not standardize pixel memory format for TrueColor and DirectColor visuals, so there is a chance that Prima wouldn't work on some bizarre hardware. Currently, Prima knows how to compose pixels of 15, 16, 24, and 32 bit depth, of contiguous ( not interspersed ) red-green-blue memory layout. Any other pixel memory layout causes Prima to fail.
Prima supports shared memory image X extension, which speeds up image display
for X servers and clients running on same machine. The price for this is that
if Prima program aborts, the shared memory will never be returned to the OS.
To remove the leftover segments, use your OS facilities, for example, ipcrm
on *BSD.
To disable shared memory with images, use --no-shmem
switch in command-line
arguments.
The clipboard exchange of images is incompletely implemented, since Prima does not accompany ( and neither reads ) COLORMAP, FOREGROUND, and BACKGROUND clipboard data, which contains pixel RGB values for a paletted image. As a palliative, the clipboard-bound images are downgraded to a safe set of colors, locked immutable either by X server or Prima core.
On images in the clipboard: contrary to the text in the clipboard, which can be used several times, images seemingly cannot. The Bitmap or Pixmap descriptor, stored in the clipboard, is rendered invalid after it has been read once.
The original design of X protocol did not include the notion of a window manager, and latter is was implemented as an ad-hoc patch, which results in race conditions when configuring widgets. The extreme situation may well happen when even a non-top level widget may be influenced by a window manager, when for example a top-level widget was reparented into another widget, but the window manager is not aware or this yet.
The consequences of this, as well as programming guidances are described in
Prima::Window
. Here, we describe other aspects of interactions with WMs, as
WM protocols, hints, and properties.
Prima was tested with alternating success under the following window managers: mwm, kwin, wmaker, fvwm, fvwm2, enlightment, sawfish, blackbox, 9wm, olvm, twm, and in no-WM environment.
Prima makes use of WM_DELETE_WINDOW
and WM_TAKE_FOCUS
protocols. While
WM_DELETE_WINDOW
use is straightforward and needs no further attention,
WM_TAKE_FOCUS
can be tricky, since X defines several of input modes for a
widget, which behave differently for each WM. In particular, 'focus follows
pointer' gives pains under twm and mwm, where navigation of drop-down combo
boxes is greatly hindered by window manager. The drop-down list is programmed
so it is dismissed as soon its focus is gone; these window managers withdraw
focus even if the pointer is over the focused widget's border.
Size, position, icons, and other standard X hints are passed to WM in a standard way, and, as inter-client communication manual ( ICCCM ) allows, repeatedly misinterpreted by window managers. Many ( wmaker, for example ) apply the coordinates given from the program not to the top-level widget itself, but to its decoration. mwm defines list of accepted icon sizes so these can be absurdly high, which adds confusion to a client who can create icon of any size, but unable to determine the best one.
Prima tries to use WM-specific hints, known for two window managers: mwm and
kwin. For mwm ( Motif window manager ) Prima sets hints of decoration border
width and icons only. For kwin ( and probably to others, who wish to conform to
specifications of http://www.freedesktop.org/ ) Prima uses NET_WM_STATE
property, in particular its maximization and task-bar visibility hints.
Use of these explicitly contradicts ICCCM, and definitely may lead to bugs in
future ( at least with NET_WM_STATE
, since Motif interface can hardly
expected to be changed ). To disable the use of non-standard WM properties,
--icccm
command-line argument can be set.
X does not support unicode, and number of patches were applied to X servers and clients to make the situation change. Currently ( 2003 ) standard unicode practices are not emerged yet, so Prima copes up with what ( in author's opinion ) is most promising: Xft and iconv libraries.
X11 supports 8-bit and 16-bit text string display, and neither can be used
effectively to display unicode strings. A XCreateFontSet
technique, which
combines several fonts under one descriptor, or a similarly implemented
technique is the only way to provide correct unicode display.
Also, core font transfer protocol suffers from ineffective memory
representation, which creates latency when fonts with large span
of glyphs is loaded. Such fonts, in still uncommon though standard iso10646
encoding, are the only media to display multi-encoding text without falling
back to hacks similar to XCreateFontSet
.
These, and some other problems are efficiently solved by Xft library, a superset of X core font functionality. Xft features Level 1 ( November 2003 ) unicode display and supports 32-bit text strings as well as UTF8-coded strings. Xft does not operate with charset encodings, and these are implemented in Prima using iconv charset convertor library.
Prima does not support extended input methods ( XIM etc ), primarily because the authors are not acquainted with CIJK problem domain. Volunteers are welcome.
Prima supports UTF8 text in clipboard via UTF8_STRING
transparently,
although not by default.
Prima::Application-> wantUnicodeInput(1)
is the easiest ( see the Prima::Application manpage ) way to initiate UTF8 clipboard text exchange.
Due to the fact that any application can take ownership over the clipboard
at any time, open
/close
brackets are not strictly respected in X11
implementation. Practically, this means that when modern X11 clipboard daemons
( KDE klipper, for example ) interfere with Prima clipboard, the results may
not be consistent from the programmer's view, for example, clipboard contains
data after clear
call, and the like. It must be noted though that this
behavior is expected by the users.
Raw X11 provides no such GUI helpers as double-click event, cursor, or menu. Neither does it provide the related time how often, for example, a cursor would blink. Therefore Prima emulates these, but allows the user to reprogram the corresponding timeouts. Prima recognizes the following properties, accessible either via application name or Prima class key. All timeouts are integer values, representing number of milliseconds for the corresponding timeout property.
Default value: 500
Default value: 500
Default value: 200
Default value: 200
Default value: 200
Prima::Button
in autoRepeat
mode uses these timeouts for
emulation of a key press.
Scrollfirst
is a 'first' timeout.
Default value: 200
Scrollfirst
, but after it is expired.
Default value: 50
0x??
.
Various visuals provide different color depth and access scheme. Some X
stations have badly chosen default visuals (for example, default IRIX
workstation setup has 8-bit default visual selected), so this property can be
used to fix things. List of visuals, supported by a X display can be produced
interactively by standard xdpyinfo
command from X distribution.
Identical to --visual
command-line argument.
See the Color manpage for more information.
Default value: 5 ( default values for wheeldown and wheelup are current de-facto most popular settings ).
Default value: 4
The famous 'use the source' call is highly actual with Prima. However, some
debug information comes compiled in, and can be activated by --debug
command-line key. Combination of letters to the key activates debug printouts
of different subsystems:
Example:
--debug=xf
Also, the built-in X API XSynchronize
call, which enables X protocol
synchronization ( at expense of operation slowdown though ) is activated with
--sync
command-line argument, and can be used to ease the debugging.
Dmitry Karasik, <dmitry@karasik.eu.org>.
Prima, the Prima::gp-problems manpage, the Prima::Widget manpage, Nye A, Xlib programming manual. O'Reilly & Associates, 1995.
Prima::X11 - usage guide for X11 environment |