view release on metacpan or  search on metacpan

pod/Prima/X11.pod  view on Meta::CPAN

=item *

C<--dark> - dark3DColor

=back

=head2 Visuals

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 modifiability 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 C<Prima.Visual> XRDB property or C<--visual>
command-line argument.  List of visuals can be produced interactively by
standard C<xdpyinfo> command from X distribution, where each class of visual
corresponds to one of six visual classes:

=over

=item StaticGray

All color cells are read-only, and contain monochrome values only.  A typical
example is a two-color, black-and-white monochrome display.  This visual is
extremely rarely met.

=item GrayScale

Contains modifiable color palette, and capable of displaying monochrome values
only. Theoretically, any paletted display on a monochrome monitor can be
treated as a GrayScale visual. For both I<GrayScale> and I<StaticGray> visuals
Prima resorts to dithering if it cannot get at least 32 evenly spaced gray
values from black to white.

=item StaticColor

All color cells are read-only.  A typical example is a PC display in a 16-color
EGA mode.  This visual is rarely met.

=item PseudoColor

All color cells are modifiable. Typically, 8-bit displays define this class for
a default visual. For both I<StaticColor> and I<PseudoColor> visuals dithering
is always used, although for C<PseudoColor> Prima resorts to that only if X
server cannot allocate another color.

On C<PseudoColor> and C<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 always to
stay permanent through life of the application.

=item TrueColor

Each pixel value is explicitly coded as RGB. Typical example are 16, 24, or 32-bit
display modes. This visual class is the best in terms of visual quality.

=item DirectColor

Same as I<TrueColor>, but additionally each pixel value can be reprogrammed.
Not all hardware support this visual, and usually by default it is not set.
Prima supports this mode in exactly same way as I<TrueColor> without additional
features.

=back

=head1 Images

As described in the previous section, X does not standardize pixel memory
format for I<TrueColor> and I<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, C<ipcrm>
on *BSD.

To disable shared memory with images, use C<--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.

=head1 Window managers

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 guidance are described in
C<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, enlightenment, sawfish, blackbox, 9wm, olvm, twm,
and in no-WM environment.

=head2 Protocols

Prima makes use of C<WM_DELETE_WINDOW> and C<WM_TAKE_FOCUS> protocols.  While
C<WM_DELETE_WINDOW> use is straightforward and needs no further attention,
C<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.

=head2 Hints

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.

=head2 Non-standard properties

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 C<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 C<NET_WM_STATE>, since Motif interface can hardly
expected to be changed ).  To disable the use of non-standard WM properties,
C<--icccm> command-line argument can be set.

=head1 Unicode

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.

=head2 Fonts

X11 supports 8-bit and 16-bit text string display, and neither can be used
effectively to display unicode strings. A C<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 C<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 converter library.

=head2 Input

Prima does not support extended input methods ( XIM etc ), primarily because
the authors are not acquainted with CIJK problem domain. Volunteers are
welcome.

=head2 Clipboard

Prima supports UTF8 text in clipboard via C<UTF8_STRING> transparently,
although not by default.

   Prima::Application-> wantUnicodeInput(1)

is the easiest ( see L<Prima::Application> ) way to initiate UTF8 clipboard
text exchange.

Due to the fact that any application can take ownership over the clipboard
at any time, C<open>/C<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 C<clear> call, and the like. It must be noted though that this
behavior is expected by the users.

=head1 Other XRDB resources

=head2 Timeouts

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.

=over

=item Blinkinvisibletime.blinkinvisibletime: MSEC

Cursor stays invisible MSEC milliseconds.

Default value: 500

=item Blinkvisibletime.blinkvisibletime: MSEC

Cursor stays visible MSEC milliseconds.

Default value: 500

=item Clicktimeframe.clicktimeframe MSEC

If 'mouse down' and 'mouse up' events are follow in MSEC, 'mouse click'
event is synthesized.

Default value: 200

=item Doubleclicktimeframe.doubleclicktimeframe MSEC

If 'mouse click' and 'mouse down' events are follow in MSEC, 'mouse double click'
event is synthesized.

Default value: 200

=item Submenudelay.submenudelay MSEC

When the used clicks on a menu item, which points to a lower-level menu window,
the latter is displayed after MSEC milliseconds.

Default value: 200

=item Scrollfirst.scrollfirst MSEC

When an auto-repetitive action, similar to keystroke events resulting from a
long key press on the keyboard, is to be simulated, two timeout values are used
- 'first' and 'next' delay. These actions are not simulated within Prima core,
and the corresponding timeouts are merely advisable to the programmer. Prima
widgets use it for automatic scrolling, either by a scrollbar or by any other
means.  Also, C<Prima::Button> in C<autoRepeat> mode uses these timeouts for
emulation of a key press.

C<Scrollfirst> is a 'first' timeout.

Default value: 200

=item Scrollnext.scrollnext MSEC

A timeout used for same reasons as C<Scrollfirst>, but after it is expired.

Default value: 50

=back

=head2 Miscellaneous

=over

=item Visual.visual: VISUAL_ID

Selects display visual by VISUAL_ID, which is usually has a form of C<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 C<xdpyinfo> command from X distribution.

Identical to C<--visual> command-line argument.

See L<Color> for more information.

=item Wheeldown.wheeldown BUTTON

BUTTON is a number of X mouse button event, treated as 'mouse wheel down'
event.

Default value: 5 ( default values for wheeldown and wheelup are current de-facto
most popular settings ).

=item Wheelup.wheelup BUTTON

BUTTON is a number of X mouse button event, treated as 'mouse wheel up' event.

Default value: 4

=back

=head1 Debugging

The famous 'use the source' call is highly actual with Prima. However, some
debug information comes compiled in, and can be activated by C<--debug>
command-line key. Combination of letters to the key activates debug printouts
of different subsystems:

=over

=item *

C - clipboard

=item *

E - events subsystem

=item *

F - fonts

=item *

M - miscellaneous debug info

=item *

P - palettes and colors

=item *

X - XRDB

=item *

A - all of the above

=back

Example:

   --debug=xf

Also, the built-in X API C<XSynchronize> call, which enables X protocol
synchronization ( at expense of operation slowdown though ) is activated with
C<--sync> command-line argument, and can be used to ease the debugging.

=head2 GTK

Prima can be compiled with GTK, and can use its colors and font scheme, and
GTK file dialogs. This can be disabled with C<--no-gtk> command line switch.

On MacOSX, GTK usually comes with Quartz implementation, which means that
Prima will get into problems with remote X11 connections. Prima tries to detect
this condition, but if trouble persists, please use C<--no-gtk> switch (and
please file a bug report so this can be fixed, too).

=head2 Quartz

Prima can be compiled with Cocoa library on MacOSX, that gives access to
screen scraping functionality of Application.get_image, that is otherwise is
non-functional with XQuartz. To disable it, use C<--no-quartz> runtime switch.

=head1 AUTHOR

Dmitry Karasik, E<lt>dmitry@karasik.eu.orgE<gt>.

=head1 SEE ALSO

L<Prima>, L<Prima::gp-problems>, L<Prima::Widget>,
Nye A, Xlib programming manual. O'Reilly E<amp> Associates, 1995.