1=head1 NAME 2 3Prima::X11 - usage guide for X11 environment 4 5=head1 DESCRIPTION 6 7This document describes subtle topics one must be aware when programming or 8using Prima programs under X11. 9 10The document covers various aspects of the toolkit and their implementation 11details with guidelines of the expected use. Also, standard X11 user-level and 12programming techniques are visited. 13 14=head1 Basic command-line switches 15 16=over 17 18=item C<--help> 19 20Prints the command-line arguments available and exits. 21 22=item C<--display> 23 24Sets X display address in Xlib notation. If not set, standard Xlib ( 25C<XOpenDisplay(null)> ) behavior applies. 26 27Example: 28 29 --display=:0.1 30 31=item C<--visual> 32 33Sets X visual, to be used by default. Example: 34 35 --visual=0x23 36 37=item C<--sync> 38 39Turn off X synchronization 40 41=item C<--bg>, C<--fg> 42 43Set default background and foreground colors. Example: 44 45 --bg=BlanchedAlmond 46 47=item C<--font> 48 49Sets default font. Example: 50 51 --font='adobe-helvetica-medium-r-*-*--*-120-*-*-*-*-*-*' 52 53=item C<--no-x11> 54 55Runs Prima without X11 display initialized. This switch can be used for programs 56that use only OS-independent parts of Prima, such as image subsystem or PostScript 57generator, in environments where X is not present, for example, a CGI script. 58Obviously, any attempt to create instance of C<Prima::Application> or otherwise 59access X-depended code under such conditions causes the program to abort. 60 61There are alternatives to use the command switch. First, there is module C<Prima::noX11> 62for the same purpose but more convenient to use as 63 64 perl -MPrima::noX11 65 66construct. Second, there is a technique to continue execution even if connection 67to a X server failed: 68 69 use Prima::noX11; 70 use Prima; 71 72 my $error = Prima::XOpenDisplay(); 73 if ( defined $error) { 74 print "not connected to display: $error\n"; 75 } else { 76 print "connected to display\n"; 77 } 78 79The L<Prima::noX11> module exports a single function C<XOpenDisplay> into 80C<Prima> namespace, to connect to the X display explicitly. The display to be 81connected to is C<$ENV{DISPLAY}>, unless started otherwise on command line ( with 82--display option) or with parameter to the C<XOpenDisplay> function. 83 84This technique may be useful to programs that use Prima imaging functionality 85and may or may not use windowing capabilites. 86 87=back 88 89=head1 X resources database 90 91X11 provides XRDB, the X resource database, a keyed list of arbitrary string 92values stored on the X server. Each key is a combination of names and classes 93of widgets, each in string form. The key is constructed so the leftmost 94substring ( name or class ) corresponds to the top-level item in the hierarchy, 95usually the application name or class. Although the XRDB can be changed via 96native X API, it is rarely done by applications. Instead, the user creates a 97file, usually named .Xdefaults, which contains the database in the string form. 98 99The format of .Xdefaults directly reflects XRDB capabilities, one of the most 100important of which is globbing, manifested via * ( star ) character. Using 101globbing, the user can set up a property value that corresponds to multiple 102targets: 103 104 *.ListBox.backColor: yellow 105 106The string above means that all widgets of ListBox class must have yellow 107background. 108 109The application itself is responsible for parsing the strings and querying the 110XRDB. Also, both class names and widget names, as well as database values are 111fully defined in terms of the application. There are some guidelines though, 112for example, colors and fonts best described in terms, native to the X server. 113Also, classes and names are distinguished by the case: classes must begin with 114the upper register letter. Also, not every character can be stored in the 115XRDB database ( space, for example, cannot) , and therefore XRDB API 116automatically converts these to _ ( underscore ) characters. 117 118Prima defines its all set of resources, divided in two parts: general toolkit 119settings and per-widget settings. The general settings functionality is 120partially overloaded by command-line arguments. Per-widget settings are fonts 121and colors, definable for each Prima widget. 122 123All of the general settings are applicable to the top-level item of widget 124hierarchy, named after the application, and C<Prima> class. Some of these, 125though, are needed to be initialized before the application instance itself is 126created, so these can be accessed via C<Prima> class only, for example, 127C<Prima.Visual>. Some, on the contrary, may occasionally overlap with 128per-widget syntax. In particular, one must vary not to mix 129 130 Prima.font: some-font 131 132with 133 134 Prima*font: some-font 135 136The former syntax is a general setting, and sets the default Prima font. The 137latter is a per-widget assignment, and explicitly sets font to B<all> Prima 138widgets, effectively ruining the toolkit font inheritance scheme. The same is 139valid for an even more oppressive 140 141 *font: some-font 142 143record. 144 145The allowed per-widget settings are colors and font settings only ( see 146corresponding sections ). It is an arguably useful feature to map all widget 147properties onto XRDB, but Prima does not implement this, primarily because no 148one asked for it, and also because this creates unnecessary latency when 149enumeration of all properties for each widget takes place. 150 151All global settings have identical class and name, varied in the case of the 152first letter. For example, to set C<Submenudelay> value, one can do it either 153by 154 155 Prima.Submenudelay: 10 156 157or 158 159 Prima.submenudelay: 10 160 161syntax. Despite that these calls are different, in a way that one reaches for 162the whole class and another for the name, for the majority of these properties it 163does not matter. To avoid confusion, for all properties their names and class 164are given as C<PropetyClass.propertyname> index. 165 166=head1 Fonts 167 168=head2 Default fonts 169 170Prima::Application defines set of C<get_default_XXX_font> functions, where each 171returns some user-selected font, to be displayed correspondingly in menu, 172message, window captions, all other widgets, and finally a default font. While 173in other OS'es these are indeed standard configurable user options, raw X11 174doesn't define any. Nevertheless, as the high-level code relies on these, 175corresponding resources are defined. These are: 176 177=over 178 179=item * 180 181font - Application::get_default_font 182 183=item * 184 185caption_font - Application::get_caption_font. Used in C<Prima::MDI>. 186 187=item * 188 189menu_font - Widget::get_default_menu_font. Default font for pull-down and 190pop-up menus. 191 192=item * 193 194msg_font - Application::get_message_font. Used in C<Prima::MsgBox>. 195 196=item * 197 198widget_font - Widget::get_default_font. 199 200=back 201 202All of the global font properties can only be set via C<Prima> class, no 203application name is recognized. Also, these properties are identical to 204C<--font>, C<--menu-font>, C<--caption-font>, C<--msg-font>, and 205C<--widget-font> command-line arguments. The per-widget properties are C<font> 206and C<popupFont>, of class C<Font>, settable via XRDB only: 207 208 Prima*Dialog.font: my-fancy-dialog-font 209 Prima.FontDialog.font: some-conservative-font 210 211By default, Prima font is 12.Helvetica . 212 213=head2 X core fonts 214 215The values of the font entries are standard XLFD strings, the default 216C<*-*-*-*-*-*-*-*-*-*-*-*-*-*-*> pattern, where each star character can be 217replaced by a particular font property, as name, size, charset, and so on. To 218interactively select an appropriate font, use standard C<xfontsel> program from 219X11 distribution. 220 221Note, that encoding part of the font is recommended to left unspecified, 222otherwise it may clash with LANG environment variable, which is used by Prima 223font subsystem to determine which font to select when no encoding is given. 224This advice, though, is correct only when both LANG and encoding part of a 225desired font match. In order to force a particular font encoding, the property 226C<Prima.font> must contain one. 227 228Alternatively, and/or to reduce X font traffic, one may set 229C<IgnoreEncodings.ignoreEncodings> property, which is a semicolon- separated 230list of encodings Prima must not account. This feature has limited usability 231when for example fonts in Asian encodings result in large font requests. 232Another drastic measure to decrease font traffic is a boolean property 233C<Noscaledfonts.noscaledfonts>, which, if set to 1, restricts the choice of 234fonts to the non-scalable fonts only. 235 236=head2 Xft fonts 237 238Prima can compile with Xft library, which contrary to core X font API, can make 239use of client-side fonts. Plus, Xft offers appealing features as font 240antialiasing, unicode, and arguably a better font syntax. The Xft font syntax 241is inherited from C<fontconfig> library and to be consulted from C<man 242fonts-conf>, but currently ( November 2003 ) basic font descriptions can be 243composed as follows: 244 245 Palatino-12 246 247A font with name C<Palatino> and size 12. 248 249 Arial-10:BI 250 251A font with name C<Arial>, size 10, bold, italic. The C<fontconfig> syntax 252allows more than that, for example, arbitrary matrix transformations, but 253Prima can make use only of font name, size, and style flags. 254 255The XFT library does internal memory management that is not necessary optimal 256for text with large amount of glyphs, f.ex. chinese. If display of these text is slow, 257try to increase memory for glyph caching by setting 258 259 Xft.maxglyphmemory: 10485760 260 261(f.ex. for 10M per program cache) to the input for your xrdb. 262 263=over 264 265=item C<--no-xft> 266 267C<--no-xft> command-line argument, and boolean C<UseXFT.usexft> XRDB property 268can be used to disable use of the Xft library. 269 270=item C<--no-core-fonts> 271 272Disables all X11 core fonts, except C<fixed> fonts. The C<fixed> 273font is selected for the same reasons that X server is designed 274to provide at least one font, which usually is C<fixed>. 275 276It is valid to combine C<--no-core-fonts> and C<--no-xft>. Moreover, 277adding C<--noscaled> to these gives Prima programs a 'classic' X look. 278 279=item C<--font-priority> 280 281Can be set to either C<xft> or C<core>, to select a font provider mechanism 282to match unknown or incompletely specified fonts against. 283 284Default value: C<xft> ( if compiled in ), C<core> otherwise. 285 286=item C<--no-aa> 287 288If set, turns off Xft antialiasing. 289 290=back 291 292=head1 Colors 293 294=head2 XRDB conventions 295 296X traditionally contains a color names database, usually a text file named 297F<rgb.txt>. Check your X manual where exactly this file resides and what is 298its format. The idea behind it is that users can benefit from portable literal 299color names, with color values transparently adjustable to displays 300capabilities. Thus, it is customary to write 301 302 color: green 303 304for many applications, and these in turn call C<XParseColor> to convert strings 305into RGB values. 306 307Prima is no exception to the scheme. Each widget can be assigned eight color 308properties: C<color>, C<hiliteBackColor>, C<disabledColor>, C<dark3DColor> 309C<backColor>, C<hiliteColor>, C<disabledBackColor>, C<light3DColor> by their name: 310 311 Prima.backColor: #cccccc 312 313Additionally, set of command-line arguments allows overriding default values for these: 314 315=over 316 317=item * 318 319C<--fg> - color 320 321=item * 322 323C<--bg> - backColor 324 325=item * 326 327C<--hilite-fg> - hiliteColor 328 329=item * 330 331C<--hilite-bg> - hiliteBackColor 332 333=item * 334 335C<--disabled-fg> - disabledColor 336 337=item * 338 339C<--disabled-bg> - disabledBackColor 340 341=item * 342 343C<--light> - light3DColor 344 345=item * 346 347C<--dark> - dark3DColor 348 349=back 350 351=head2 Visuals 352 353X protocol works with explicitly defined pixel values only. A pixel value, 354maximum 32-bit value, represents a color in a display. There are two different 355color coding schemes - direct color and indexed color. The direct color-coded 356pixel value can unambiguously be converted into a RGB-value, without any 357external information. The indexed-color scheme represents pixel value as an 358index in a palette, which resided on X server. Depending on the color cell 359value of the palette, RGB color representation can be computed. A X display can 360contain more than one palette, and allow ( or disallow ) modification of 361palette color cells depending on a visual, the palette is attributed to. 362 363A visual is a X server resource, containing representation of color coding 364scheme, color bit depth, and modificability of the palette. X server can ( and 365usually does ) provide more than one visual, as well as different bit depths. 366There are six classes of visuals in X paradigm. In each, Prima behaves 367differently, also depending on display bit depth available. In particular, 368color dithering can be used on displays with less than 12-bit color depth. On 369displays with modifiable color palette, Prima can install its own values in 370palettes, which may result in an effect known as display flashing. To switch to 371a non-default visual, use C<Prima.Visual> XRDB property or C<--visual> 372command-line argument. List of visuals can be produced interactively by 373standard C<xdpyinfo> command from X distribution, where each class of visual 374corresponds to one of six visual classes: 375 376=over 377 378=item StaticGray 379 380All color cells are read-only, and contain monochrome values only. A typical 381example is a two-color, black-and-white monochrome display. This visual is 382extremely rarely met. 383 384=item GrayScale 385 386Contains modifiable color palette, and capable of displaying monochrome values 387only. Theoretically, any paletted display on a monochrome monitor can be 388treated as a GrayScale visual. For both I<GrayScale> and I<StaticGray> visuals 389Prima resorts to dithering if it cannot get at least 32 evenly spaced gray 390values from black to white. 391 392=item StaticColor 393 394All color cells are read-only. A typical example is a PC display in a 16-color 395EGA mode. This visual is rarely met. 396 397=item PseudoColor 398 399All color cells are modifiable. Typically, 8-bit displays define this class for 400a default visual. For both I<StaticColor> and I<PseudoColor> visuals dithering 401is always used, although for C<PseudoColor> Prima resorts to that only if X 402server cannot allocate another color. 403 404On C<PseudoColor> and C<GrayScale> Prima allocates a small set of colors, not 405used in palette modifications. When a bitmap is to be exported via clipboard, 406or displayed in menu, or sent to a window manager as an icon to be displayed, 407it is downgraded to using these colors only, which are though guaranteedly to 408stay permanent through life of the application. 409 410=item TrueColor 411 412Each pixel value is explicitly coded as RGB. Typical example are 16, 24, or 32-bit 413display modes. This visual class is the best in terms of visual quality. 414 415=item DirectColor 416 417Same as I<TrueColor>, but additionally each pixel value can be reprogrammed. 418Not all hardware support this visual, and usually by default it is not set. 419Prima supports this mode in exactly same way as I<TrueColor> without additional 420features. 421 422=back 423 424=head1 Images 425 426As described in the previous section, X does not standardize pixel memory 427format for I<TrueColor> and I<DirectColor> visuals, so there is a chance that 428Prima wouldn't work on some bizarre hardware. Currently, Prima knows how to 429compose pixels of 15, 16, 24, and 32 bit depth, of contiguous ( not 430interspersed ) red-green-blue memory layout. Any other pixel memory layout 431causes Prima to fail. 432 433Prima supports shared memory image X extension, which speeds up image display 434for X servers and clients running on same machine. The price for this is that 435if Prima program aborts, the shared memory will never be returned to the OS. 436To remove the leftover segments, use your OS facilities, for example, C<ipcrm> 437on *BSD. 438 439To disable shared memory with images, use C<--no-shmem> switch in command-line 440arguments. 441 442The clipboard exchange of images is incompletely implemented, since Prima does 443not accompany ( and neither reads ) COLORMAP, FOREGROUND, and BACKGROUND 444clipboard data, which contains pixel RGB values for a paletted image. As a 445palliative, the clipboard-bound images are downgraded to a safe set of colors, 446locked immutable either by X server or Prima core. 447 448On images in the clipboard: contrary to the text in the clipboard, which can be 449used several times, images seemingly cannot. The Bitmap or Pixmap descriptor, 450stored in the clipboard, is rendered invalid after it has been read once. 451 452=head1 Window managers 453 454The original design of X protocol did not include the notion of a window 455manager, and latter is was implemented as an ad-hoc patch, which results in 456race conditions when configuring widgets. The extreme situation may well happen 457when even a non-top level widget may be influenced by a window manager, when 458for example a top-level widget was reparented into another widget, but the 459window manager is not aware or this yet. 460 461The consequences of this, as well as programming guidances are described in 462C<Prima::Window>. Here, we describe other aspects of interactions with WMs, as 463WM protocols, hints, and properties. 464 465Prima was tested with alternating success under the following window managers: 466mwm, kwin, wmaker, fvwm, fvwm2, enlightment, sawfish, blackbox, 9wm, olvm, twm, 467and in no-WM environment. 468 469=head2 Protocols 470 471Prima makes use of C<WM_DELETE_WINDOW> and C<WM_TAKE_FOCUS> protocols. While 472C<WM_DELETE_WINDOW> use is straightforward and needs no further attention, 473C<WM_TAKE_FOCUS> can be tricky, since X defines several of input modes for a 474widget, which behave differently for each WM. In particular, 'focus follows 475pointer' gives pains under twm and mwm, where navigation of drop-down combo 476boxes is greatly hindered by window manager. The drop-down list is programmed 477so it is dismissed as soon its focus is gone; these window managers withdraw 478focus even if the pointer is over the focused widget's border. 479 480=head2 Hints 481 482Size, position, icons, and other standard X hints are passed to WM in a 483standard way, and, as inter-client communication manual ( ICCCM ) allows, 484repeatedly misinterpreted by window managers. Many ( wmaker, for example ) 485apply the coordinates given from the program not to the top-level widget 486itself, but to its decoration. mwm defines list of accepted icon sizes so 487these can be absurdly high, which adds confusion to a client who can create 488icon of any size, but unable to determine the best one. 489 490=head2 Non-standard properties 491 492Prima tries to use WM-specific hints, known for two window managers: mwm and 493kwin. For mwm ( Motif window manager ) Prima sets hints of decoration border 494width and icons only. For kwin ( and probably to others, who wish to conform to 495specifications of http://www.freedesktop.org/ ) Prima uses C<NET_WM_STATE> 496property, in particular its maximization and task-bar visibility hints. 497 498Use of these explicitly contradicts ICCCM, and definitely may lead to bugs in 499future ( at least with C<NET_WM_STATE>, since Motif interface can hardly 500expected to be changed ). To disable the use of non-standard WM properties, 501C<--icccm> command-line argument can be set. 502 503=head1 Unicode 504 505X does not support unicode, and number of patches were applied to X servers and 506clients to make the situation change. Currently ( 2003 ) standard unicode 507practices are not emerged yet, so Prima copes up with what ( in author's 508opinion ) is most promising: Xft and iconv libraries. 509 510=head2 Fonts 511 512X11 supports 8-bit and 16-bit text string display, and neither can be used 513effectively to display unicode strings. A C<XCreateFontSet> technique, which 514combines several fonts under one descriptor, or a similarly implemented 515technique is the only way to provide correct unicode display. 516 517Also, core font transfer protocol suffers from ineffective memory 518representation, which creates latency when fonts with large span 519of glyphs is loaded. Such fonts, in still uncommon though standard iso10646 520encoding, are the only media to display multi-encoding text without falling 521back to hacks similar to C<XCreateFontSet>. 522 523These, and some other problems are efficiently solved by Xft library, a 524superset of X core font functionality. Xft features Level 1 ( November 2003 ) 525unicode display and supports 32-bit text strings as well as UTF8-coded strings. 526Xft does not operate with charset encodings, and these are implemented in Prima 527using iconv charset convertor library. 528 529=head2 Input 530 531Prima does not support extended input methods ( XIM etc ), primarily because 532the authors are not acquainted with CIJK problem domain. Volunteers are 533welcome. 534 535=head2 Clipboard 536 537Prima supports UTF8 text in clipboard via C<UTF8_STRING> transparently, 538although not by default. 539 540 Prima::Application-> wantUnicodeInput(1) 541 542is the easiest ( see L<Prima::Application> ) way to initiate UTF8 clipboard 543text exchange. 544 545Due to the fact that any application can take ownership over the clipboard 546at any time, C<open>/C<close> brackets are not strictly respected in X11 547implementation. Practically, this means that when modern X11 clipboard daemons 548( KDE klipper, for example ) interfere with Prima clipboard, the results may 549not be consistent from the programmer's view, for example, clipboard contains 550data after C<clear> call, and the like. It must be noted though that this 551behavior is expected by the users. 552 553=head1 Other XRDB resources 554 555=head2 Timeouts 556 557Raw X11 provides no such GUI helpers as double-click event, cursor, or menu. 558Neither does it provide the related time how often, for example, a cursor would 559blink. Therefore Prima emulates these, but allows the user to reprogram the 560corresponding timeouts. Prima recognizes the following properties, accessible 561either via application name or Prima class key. All timeouts are integer 562values, representing number of milliseconds for the corresponding timeout 563property. 564 565=over 566 567=item Blinkinvisibletime.blinkinvisibletime: MSEC 568 569Cursor stays invisible MSEC milliseconds. 570 571Default value: 500 572 573=item Blinkvisibletime.blinkvisibletime: MSEC 574 575Cursor stays visible MSEC milliseconds. 576 577Default value: 500 578 579=item Clicktimeframe.clicktimeframe MSEC 580 581If 'mouse down' and 'mouse up' events are follow in MSEC, 'mouse click' 582event is synthesized. 583 584Default value: 200 585 586=item Doubleclicktimeframe.doubleclicktimeframe MSEC 587 588If 'mouse click' and 'mouse down' events are follow in MSEC, 'mouse double click' 589event is synthesized. 590 591Default value: 200 592 593=item Submenudelay.submenudelay MSEC 594 595When the used clicks on a menu item, which points to a lower-level menu window, 596the latter is displayed after MSEC milliseconds. 597 598Default value: 200 599 600=item Scrollfirst.scrollfirst MSEC 601 602When an auto-repetitive action, similar to keystroke events resulting from a 603long key press on the keyboard, is to be simulated, two timeout values are used 604- 'first' and 'next' delay. These actions are not simulated within Prima core, 605and the corresponding timeouts are merely advisable to the programmer. Prima 606widgets use it for automatic scrolling, either by a scrollbar or by any other 607means. Also, C<Prima::Button> in C<autoRepeat> mode uses these timeouts for 608emulation of a key press. 609 610C<Scrollfirst> is a 'first' timeout. 611 612Default value: 200 613 614=item Scrollnext.scrollnext MSEC 615 616A timeout used for same reasons as C<Scrollfirst>, but after it is expired. 617 618Default value: 50 619 620=back 621 622=head2 Miscellaneous 623 624=over 625 626=item Visual.visual: VISUAL_ID 627 628Selects display visual by VISUAL_ID, which is usually has a form of C<0x??>. 629Various visuals provide different color depth and access scheme. Some X 630stations have badly chosen default visuals (for example, default IRIX 631workstation setup has 8-bit default visual selected), so this property can be 632used to fix things. List of visuals, supported by a X display can be produced 633interactively by standard C<xdpyinfo> command from X distribution. 634 635Identical to C<--visual> command-line argument. 636 637See L<Color> for more information. 638 639=item Wheeldown.wheeldown BUTTON 640 641BUTTON is a number of X mouse button event, treated as 'mouse wheel down' 642event. 643 644Default value: 5 ( default values for wheeldown and wheelup are current de-facto 645most popular settings ). 646 647=item Wheelup.wheelup BUTTON 648 649BUTTON is a number of X mouse button event, treated as 'mouse wheel up' event. 650 651Default value: 4 652 653=back 654 655=head1 Debugging 656 657The famous 'use the source' call is highly actual with Prima. However, some 658debug information comes compiled in, and can be activated by C<--debug> 659command-line key. Combination of letters to the key activates debug printouts 660of different subsystems: 661 662=over 663 664=item * 665 666C - clipboard 667 668=item * 669 670E - events subsystem 671 672=item * 673 674F - fonts 675 676=item * 677 678M - miscellaneous debug info 679 680=item * 681 682P - palettes and colors 683 684=item * 685 686X - XRDB 687 688=item * 689 690A - all of the above 691 692=back 693 694Example: 695 696 --debug=xf 697 698Also, the built-in X API C<XSynchronize> call, which enables X protocol 699synchronization ( at expense of operation slowdown though ) is activated with 700C<--sync> command-line argument, and can be used to ease the debugging. 701 702=head2 GTK 703 704Prima can be compiled with GTK, and can use its colos and font scheme, and 705GTK file dialogs. This can be disabled with C<--no-gtk> command line switch. 706 707On MacOSX, GTK usually comes with Quartz implementation, which means that 708Prima will get into problems with remote X11 connections. Prima tries to detect 709this condition, but if trouble persists, please use C<--no-gtk> switch (and 710please file a bug report so this can be fixed, too). 711 712=head2 Quartz 713 714Prima can be compiled with Cocoa library on MacOSX, that gives access to 715screen scraping functionality of Application.get_image, that is otherwise is 716non-functional with XQuartz. To disable it, use C<--no-quartz> runtime switch. 717 718=head1 AUTHOR 719 720Dmitry Karasik, E<lt>dmitry@karasik.eu.orgE<gt>. 721 722=head1 SEE ALSO 723 724L<Prima>, L<Prima::gp-problems>, L<Prima::Widget>, 725Nye A, Xlib programming manual. O'Reilly E<amp> Associates, 1995. 726 727