home *** CD-ROM | disk | FTP | other *** search
- Path: senator-bedfellow.mit.edu!dreaderd!not-for-mail
- Message-ID: <motif-faq/part8_1083675484@rtfm.mit.edu>
- Supersedes: <motif-faq/part8_1082292761@rtfm.mit.edu>
- Expires: 17 Jun 2004 12:58:04 GMT
- References: <motif-faq/part1_1083675484@rtfm.mit.edu>
- X-Last-Updated: 2002/01/31
- Organization: none
- Subject: Motif FAQ (Part 8 of 9)
- Newsgroups: comp.windows.x.motif,comp.answers,news.answers
- Keywords: FAQ question answer
- From: kenton@rahul.net (Ken Lee)
- Reply-To: kenton@rahul.net (Ken Lee)
- Approved: news-answers-request@MIT.EDU
- Followup-To: poster
- Summary: Motif Frequently Asked Questions (with answers).
- Originator: faqserv@penguin-lust.MIT.EDU
- Date: 04 May 2004 12:59:12 GMT
- Lines: 1044
- NNTP-Posting-Host: penguin-lust.mit.edu
- X-Trace: 1083675552 senator-bedfellow.mit.edu 567 18.181.0.29
- Xref: senator-bedfellow.mit.edu comp.windows.x.motif:75191 comp.answers:57056 news.answers:270860
-
- Archive-name: motif-faq/part8
- Last-modified: 1 FEB 2002
- Posting-Frequency: irregular
- Organization: Kenton Lee, X/Motif Consultant, http://www.rahul.net/kenton/
- URL: http://www.rahul.net/kenton/mfaq.html
- Version: 8.1
-
- -----------------------------------------------------------------------------
- Subject: 250) TOPIC: KEYSYMS
-
- -----------------------------------------------------------------------------
- Subject: 251) What is causing the messages "unknown keysym name osfDown..."?
- [Last modified: Oct 98]
-
- Answer: There is an OSF supplied addition to the /usr/lib/X11/XKeysymDB file.
- It is found on the release tape and should have been automatically installed
- if the installation procedure was followed in the Release Notes.
-
- You have to copy (or append) lib/Xm/XKeysymDB into /usr/lib/X11. This may
- require root permission. It is not clear how to fix the problem if you can't
- do this. The error comes from Xt translation table parsing and can't be fixed
- in Motif, so if you can't get root permission you may be stuck. The file is
- not copyrighted so you can install it on other systems.
-
- If X has been built so that XKeysymDB is not in this directory, and you don't
- know where it is looking, run 'strings libX11.a | grep XKeysymDB' to find the
- path.
-
- On a Sun running openwin with shared libraries, you may need to put the path
- for the library containing XKeysymDB *first* in the path list in
- LD_LIBRARY_PATH, or it may find the wrong XKeysymDB in the wrong directory.
-
- XKeysymDB simply contains the registered keysym values for the OSF keysyms.
- The OSF values are server-independent. And, all registered keysyms will be
- included in an XKeysymDB file to be shipped with X11R5.
-
- In the meantime (till all systems are X11R5+), a list of the registered
- keysyms can be found in the X11R4 release in mit/doc/Registry/Xregistry.
-
- Also note the XKEYSYMDB environment variable. Setting this to point to the
- XKeysymDB file often helps, but not always...
-
- Some people have also reported getting this error if their Motif libraries
- were built with libc headers that are not compatible with those installed on
- their system. For example, Linux has two incompatible libraries libc5 and
- glibc. You may get keysym (and other) errors if your Motif was built with
- libc5 but you run your Motif application with glibc. Contact your Motif
- vendor for information on the required libc.
-
- Ken Lee
-
- -----------------------------------------------------------------------------
- Subject: 252) What happens if I can't install Motif Keysyms?
-
- tessi!george@nosun.West.Sun.COM (George Mitchell) wrote:
-
- Here's what appears to happen if you don't have XKeysymDB in place to define
- OSF's virtual keysyms:
-
- 1. At class initialize time, for a widget (such as XmText) that uses virtual
- keysyms in its event translation table, all entries which refer to those
- keysyms fail to parse correctly. In the case of XmText, instead of ending up
- with a translation table with roughly 90 entries, you end up with one that has
- 29.
-
- 2. XKeysymDB doesn't exist, so you'd assume that KeyPress events will get
- translated to plain vanilla keysyms, right? WRONG! All Motif widgets install
- a virtual keysym translator ANYWAY! Consequently, the backspace key (for
- example) gets translated to the keysym osfBackSpace.
-
- 3. Therefore, if you augment or override your widget's translations with
- translations that refer to plain vanilla BackSpace, they will never be
- triggered, because you will NEVER see plain vanilla BackSpace, only
- osfBackSpace.
-
- 4. But you can't use osfBackSpace in an event translation entry, because you
- don't have XKeysymDB installed!
-
- Here's how I'm "dealing" with the problem right now: Motif installs its
- virtual keysym translator by calling XtSetKeyTranslator every time a
- VendorShell (or subclass) widget is created. So every time I create a shell,
- I immediately call XtSetKeyTranslator (display, XtTranslateKey) to restore the
- default translator. No more funny virtual keysyms! Now I can reinstall non-
- osfKeySym translations and have them work the way I expect.
-
- -----------------------------------------------------------------------------
- Subject: 253) Why has OSF introduced Keysyms into Motif 1.1? They weren't
- there in Motif 1.0.
-
- Answer: ellis@osf.org wrote:
-
- Virtual Keysyms are meant to provide a consistent keyboard model for Motif
- applications running in a heterogeneous environment in which proprietary (i.e.
- vendor specific) non-Motif applications may also be running.
-
- First of all, for the sake of the rest of the readers, let's explain why this
- is an issue:
-
- It would be lovely if Motif's translation tables could just use the obvious
- keysyms predefined by X. For example, there are keysyms for XK_BackSpace,
- XK_Delete, XK_Left, XK_Right, etc. Shouldn't these be the ones that are used
- in our translations? Unfortunately, the problem is not so simple. Some
- specific examples:
-
- While most vendors bind XK_BackSpace to the key at the top right
- of the standard keyboard (often engraved with a leftwards
- pointing arrow), not all do. In fact, some vendors (including DEC)
- bind that key to XK_Delete.
-
- While most vendors bind the arrow keys to XK_Up, etc, a number of
- vendors (including Sun, on some servers) bind them to function key
- keysyms.
-
- A simplistic solution would require the use of xmodmap to change the offending
- bindings. That would work swell in an all Motif environment. However, OSF's
- goal (not always perfectly achieved) is interoperability. That is, we'd like
- to make sure that both Motif and non-Motif programs can happily run in the
- same environment.
-
- It is expected that a vendor may have a wide variety of existing X-based
- software that uses the keysyms as established by that vendor for specific
- purposes. It is expected that these applications may run at the same time as
- Motif-based software. Using xmodmap to change keysyms on the server side
- could "break" the existing applications (or at the very least their
- documentation) by making some keys unavailable, or by moving the location.
-
- So, we chose not to use xmodmap. By the way, though OpenLook uses a different
- implementation (they recompile their virtual translation tables into actual
- translation tables), they basically adopted the same approach, presumably for
- similar reasons.
-
- To work properly, the virtual keysym model we implemented depends on Xlib
- finding XKeysymDB installed appropriately (which standard Motif installation
- does). This simply defines the keysyms (not the key they are bound to). This
- unfortunate piece of stupidity is necessary because MIT only includes standard
- keysyms in keysymdef.h. It should be said that our lives would be made easier
- if MIT would also see fit to include registered keysyms in keysymdef.h as
- well.
-
- Motif applications determine how to bind virtual to actual keys by looking for
- either a resource or a property on the root window which describes what to do.
- Note that this information is on the server side, so that all applications use
- the same virtual bindings regardless of where they are running. Mwm will
- happily create the property if it finds a .motifbind file in your home
- directory when it starts up. (Actually, things generally work even if none of
- this is done, since if all else fails, the Motif toolkit chooses a virtual
- bindings table to use based on the identification of the server).
-
- The actual implementation of virtual keys is made possible by a hook in the
- Intrinsics. Undoubtably, the implementation would be simpler and cleaner if
- virtual key support was more directly supported by the Intrinsics. We will be
- exploring this possibility in the future.
-
- -- Ellis
-
- -----------------------------------------------------------------------------
- Subject: 254) Why do accented characters not work with Motif applications
- linked with X11R6? What is the Compose file?
- [Last modified: June 95]
-
- Answer: Note: The list of codes below _should_ contain a backslash before
- every numeric value. My FAQ maintainence tools have been stripping the
- backslash. Sorry for the confusion...ksall@cen.com.
-
- Roman Czyborra (czyborra@cs.tu-berlin.de) writes:
-
- I've xmodmapped a few accented characters onto my keyboard. They've worked
- fine in most every window, but were dead in the Motif applications linked with
- X11R6. My LC_CTYPE has always been set to iso_8859_1, so that was not the
- problem. It turns out that I can activate the keys by patching
- $XLOCALEDIR/iso8859-1/Compose to also include the lines listed below.
-
- <nobreakspace> : "240"
- <exclamdown> : "241"
- <cent> : "242"
- <sterling> : "243"
- <currency> : "244"
- <yen> : "245"
- <brokenbar> : "246"
- <section> : "247"
- <diaeresis> : "250"
- <copyright> : "251"
- <ordfeminine> : "252"
- <guillemotleft> : "253"
- <notsign> : "255"
- <hyphen> : "255"
- <registered> : "256"
- <macron> : "257"
- <degree> : "260"
- <plusminus> : "261"
- <twosuperior> : "262"
- <threesuperior> : "263"
- <acute> : "264
- <mu> : "265"
- <paragraph> : "266"
- <periodcentered> : "267"
- <cedilla> : "240"
- <onesuperior> : "271"
- <masculine> : "272"
- <guillemotright> : "273"
- <onequarter> : "274"
- <onehalf> : "275"
- <threequarters> : "276"
- <questiondown> : "277"
- <Agrave> : "300"
- <Aacute> : "301"
- <Acircumflex> : "302"
- <Atilde> : "303"
- <Adiaeresis> : "304"
- <Aring> : "305"
- <AE> : "306"
- <Ccedilla> : "307"
- <Egrave> : "310"
- <Eacute> : "311"
- <Ecircumflex> : "312"
- <Ediaeresis> : "313"
- <Igrave> : "314"
- <Iacute> : "315"
- <Icircumflex> : "316"
- <Idiaeresis> : "317"
- <ETH> : "320"
- <Ntilde> : "321"
- <Ograve> : "322"
- <Oacute> : "323"
- <Ocircumflex> : "324"
- <Otilde> : "325"
- <Odiaeresis> : "326"
- <multiply> : "327"
- <Ooblique> : "330"
- <Ugrave> : "331"
- <Uacute> : "332"
- <Ucircumflex> : "333"
- <Udiaeresis> : "334"
- <Yacute> : "335"
- <THORN> : "336"
- <ssharp> : "337"
- <agrave> : "340"
- <aacute> : "341"
- <acircumflex> : "342"
- <atilde> : "343"
- <adiaeresis> : "344"
- <aring> : "345"
- <ae> : "346"
- <ccedilla> : "347"
- <egrave> : "350"
- <eacute> : "351"
- <ecircumflex> : "352"
- <ediaeresis> : "353"
- <igrave> : "354"
- <iacute> : "355"
- <icircumflex> : "356"
- <idiaeresis> : "357"
- <eth> : "360"
- <ntilde> : "361"
- <ograve> : "362"
- <oacute> : "363"
- <ocircumflex> : "364"
- <otilde> : "365"
- <odiaeresis> : "366"
- <division> : "367"
- <oslash> : "370"
- <ugrave> : "371"
- <uacute> : "372"
- <ucircumflex> : "373"
- <udiaeresis> : "374"
- <yacute> : "375"
- <thorn> : "376"
- <ydiaeresis> : "377"
-
-
- -----------------------------------------------------------------------------
- Subject: 255) TOPIC: UIL
-
- [NOTE: As you can see, this is a new topic area. Send me your ideas for
- answered questions pertaining to this topic.]
-
- -----------------------------------------------------------------------------
- Subject: 256) What is UIL and why is it so popular?
- [Last modified: Sept 94]
-
- Answer: UIL is the acronym for "User Interface Language", a Motif standard
- which permits separation of the user interface from application code. UIL is
- a textual description of the user interface which is compiled into binary form
- called UID ("User Interface Definition") using the Motif-provided compiler
- called "uil".
-
- It is important to realize that UIL is a static description of the UI in that
- connections between buttons and the dialogs they invoke, for example, is not
- expressed here; dynamic UI behavior appears in C code.
-
- The Period Table of Widgets, called "periodic" (delivered by many Motif
- vendors) is an example of a UIL application.
-
- There are many advantages and disadvantages of UIL applications. A few of the
- advantages are:
-
- UIL is a standard format which encourages separation of the user interface
- from application code.
-
- UIL can be read and/or written by many of the GUI builders and UIMS tools
- mentioned elsewhere in this FAQ, making your interface portable (to a degree)
- across builder tools.
-
- UIL is a much better language than C for defining a widget hierarchy: in C,
- the widget hierarchy is expressed "linearly" by referencing a previously-
- created parent widget when creating a child widget; in UIL, widget trees are
- defined more naturally using nesting.
-
- With UIL, you separate the definition of the widget tree from the application.
- You can make major changes to the look-and-feel without re-building the
- application.
-
-
- It is possible to write a "general-purpose" application that defines a library
- of callbacks. The application may "execute" any UIL file that references
- callbacks from the library.
-
-
- For a good UIL reference, see "Motif Programming Manual", Volume 6A, published
- by O'Reilly and Associates. [See "BOOKS" for details.]
-
- -----------------------------------------------------------------------------
- Subject: 257) What is Mrm?
- [Last modified: Nov 94]
-
- Answer: Mrm is the "Motif Resource Manager", a set of functions (whose names
- begin with Mrm, such as MrmFetchWidget and MrmRegisterNames) in libMrm.a which
- retrieve the widget hierarchy from the UID file, associate callbacks, and
- create the widgets.
-
- Mrm is usually discussed in books which cover UIL.
-
- Motif Programming Manual, Volume 6A
- OSF/Motif Programmers Guide
- OSF/Motif Programmers Reference Manual
-
- See the BOOKS section for detailed references.
-
- -----------------------------------------------------------------------------
- Subject: 258) How do I specify a search path for ".uid" files? Answer: Use
- the UIDPATH environment variable. It is documented on the MrmOpenHierarchy()
- man page.
-
- -----------------------------------------------------------------------------
- Subject: 259) Can I specify callback functions in resource files?
-
- Answer: To specify callbacks, you must use UIL in addition to or in place of
- resource files. You can, however, specify translations in resource files,
- which give you most of the same functionality as callback functions.
-
- Ken Lee, http://www.rahul.net/kenton/
-
- -----------------------------------------------------------------------------
- Subject: 260) How can I set a multi-line label in UIL?
- [Last modified: Sept 94]
-
- Answer: In UIL, you have to explicitly create a compound string with a
- separator. Here's what W. Scott Meeks suggests:
-
- value nl : compound_string('', seperate=true);
-
- object my_label : XmLabel
- {
- arguments
- {
- XmNlabelString = 'Here' & nl & 'is' & nl & 'the' & nl & 'Label';
- };
- };
-
-
- -----------------------------------------------------------------------------
- Subject: 261) Is there a program that can convert a UIL file to tclMotif? I
- have an old Motif program that I used on SCO unix. Now that I switched to
- Linux, I would like to "reprogram" it without the Motif libraries under Linux.
- [Last modified: Aug 95]
-
- Answer: Jan Newmarch (jan@ise.canberra.edu.au) writes:
-
- The latest version of tclMotif (v 1.3) will allow you to load uil files
- (actually, the uid files output from the uil compiler) directly into tclMotif.
- So you don't need to convert at all.
-
- The source is available at ftp.x.org. This, plus a Linux binary are also at
- ftp://ftp.canberra.edu.au/pub/motif/tclMotif (Thanks to Ben Elliston
- (ben@ise.canberra.edu.au) for correcting this URL.)
-
- -----------------------------------------------------------------------------
- Subject: 262) Why does my SCO UIL application fail to open 60 UID files?
- [Last modified: Sept 95]
-
- Answer: Make sure that you call MrmCloseHierarchy. There is no need to keep
- the file open after you fetch the widgets from it.
-
- Thanks to Tom Schutter (tom@platte.com)
-
- -----------------------------------------------------------------------------
- Subject: 263) TOPIC: ICONIFICATION and DE-ICONIFICATION
-
- Iconification/de-iconification is a co-operative process between a client and
- a window manager. The relevant standards are set by ICCCM. Mwm is ICCCM
- compliant. The toplevel (non-override-redirect) windows of an application may
- be in three states: WithdrawnState (neither the window nor icon visible),
- NormalState (the window visible) or IconicState (the icon window or pixmap
- visible). This information is contained in the WM_STATE property but ordinary
- clients are not supposed to look at that (its values have not yet been
- standardised). Movement between the three states is standardised by ICCCM.
-
- -----------------------------------------------------------------------------
- Subject: 264) How can I keep track of changes to iconic/normal window state?
-
- Answer: You can look at the WM_STATE property, but this breaks ICCCM
- guidelines. ICCCM compliant window managers will map windows in changing them
- to normal state and unmap them in changing them to iconic state. Look for
- StructureNotify events and check the event type:
-
- XtAddEventHandler (toplevel_widget,
- StructureNotifyMask,
- False,
- StateWatcher,
- (Opaque) NULL);
- void StateWatcher (w, unused, event)
- Widget w;
- caddr_t unused;
- XEvent *event;
- {
- if (event->type == MapNotify)
- printf ("normal\n");
- else if (event->type == UnmapNotify)
- printf ("iconified\n");
- else printf ("other event\n");
- }
-
-
- If you insist on looking at WM_STATE, here is some code (from Ken Sall) to do
- it:
-
- /*
- ------------------------------------------------------------------
- Try a function such as CheckWinMgrState below which returns one of
- IconicState | NormalState | WithdrawnState | NULL :
- ------------------------------------------------------------------
- */
- #define WM_STATE_ELEMENTS 1
-
- unsigned long *CheckWinMgrState (dpy, window)
- Display *dpy;
- Window window;
- {
- unsigned long *property = NULL;
- unsigned long nitems;
- unsigned long leftover;
- Atom xa_WM_STATE, actual_type;
- int actual_format;
- int status;
-
- xa_WM_STATE = XInternAtom (dpy, "WM_STATE", False);
-
- status = XGetWindowProperty (dpy, window,
- xa_WM_STATE, 0L, WM_STATE_ELEMENTS,
- False, xa_WM_STATE, &actual_type, &actual_format,
- &nitems, &leftover, (unsigned char **)&property);
-
- if ( ! ((status == Success) &&
- (actual_type == xa_WM_STATE) &&
- (nitems == WM_STATE_ELEMENTS)))
- {
- if (property)
- {
- XFree ((char *)property);
- property = NULL;
- }
- }
- return (property);
- } /* end CheckWinMgrState */
-
-
- One problem with testing WM_STATE is that a race condition is possible;
- immediately after testing it, it could change, and the logic proceeds to
- behave as if it were in the old state.
-
- -----------------------------------------------------------------------------
- Subject: 265) How can I check if my application has come up iconic? I want
- to delay initialization code and other processing.
-
- Answer: Use XtGetValues and check for the XmNinitialState value of the
- toplevel shell just before XtMainLoop. -- IconicState is iconic, NormalState
- is not iconic.
-
-
- -----------------------------------------------------------------------------
- Subject: 266) How can I start my application in iconic state?
-
- Answer: Try this from the command line:
-
- application -iconic
-
- Using the resource mechanism, set the resource XmNinitialState to IconicState
- of the toplevel shell widget (the one returned from XtInitialise).
-
- -----------------------------------------------------------------------------
- Subject: 267) How can an application iconify itself?
-
- Answer: In R4 and later, use the call XIconifyWindow. Ken Lee adds "Set
- XmNiconic on your shell. This should work in X11R6 and later patch levels of
- X11R5."
-
- For R3, send an event to the root window with a type of WM_CHANGE_STATE and
- data IconicState.
-
- void
- IconifyMe (dpy, win)
- Display *dpy;
- Window win; /* toplevel window to iconify */
- {
- Atom xa_WM_CHANGE_STATE;
- XClientMessageEvent ev;
-
- xa_WM_CHANGE_STATE = XInternAtom (dpy,
- "WM_CHANGE_STATE", False);
-
- ev.type = ClientMessage;
- ev.display = dpy;
- ev.message_type = xa_WM_CHANGE_STATE;
- ev.format = 32;
- ev.data.l[0] = IconicState;
- ev.window = win;
-
- XSendEvent (dpy,
- RootWindow (dpy, DefaultScreen(dpy)),
- True,
- (SubstructureRedirectMask | SubstructureNotifyMask),
- &ev);
- XFlush (dpy);
- }
-
-
- -----------------------------------------------------------------------------
- Subject: 268) How can an application de-iconify itself?
- [Last modified: Aug 98]
-
- Answer: Carolyn Allen writes:
-
- if(XtIsRealized(shell_widget))
- {
- Display *dpy = XtDisplay(shell_widget);
- Window win = XtWindow(shell_widget);
- Window client = XmuClientWindow(dpy,win);
- XMapRaised(dpy,client);
- }
-
-
- If all you want to do is pop the icon to the top, use XRaiseWindow(dpy,client)
- instead.
-
- -----------------------------------------------------------------------------
- Subject: 269) Why doesn't MWM display an iconify button on my dialog windows?
- [Last modified: May 95]
-
- Answer: MWM (and some other window managers) does not allow transient windows
- to be iconified. Transients are automatically unmapped when the main shell is
- iconified and they are re-mapped when the main shell is restored. If you do
- not want this transient behavior, you should use top a TopLevelShell widget
- instead of a XmDialogShell widget for your windows.
-
- Ken Lee
-
- -----------------------------------------------------------------------------
- Subject: 270) TOPIC: SPECIALIZED WIDGETS
- [Last modified: Jan 95]
-
- This section describes a few specialized widgets people have asked about. A
- _far_ more comprehensive illustrated list is maintained by Richard Offer
- (offer@sgi.com). His list covers these widget categories:
-
- Complete Listing
- Composite Widgets
- Non-Composite Widgets
- Motif 1.1 Compatible
- Motif 1.2 Compatible
- Athena Compatible
- FWF Widget Set
- By Author
- Shareware Widgets
- Commercial Widgets
-
- For Richard Offer's Widget FAQ Home Page, WWW users should see:
-
- http://reality.sgi.com/widgetFAQ/
-
-
- The Widget FAQ is also available in ASCII as:
-
- ftp://ftp.x.org/contrib/faqs/Widget.FAQ.Z
-
-
- If you don't have access to the World Wide Web, the Widget FAQ (sans pictures)
- can be obtained from ftp.x.org:
-
- /contrib/faqs/Widget.FAQ.Z
-
-
- -----------------------------------------------------------------------------
- Subject: 271) Where can I get ComboBox, SpinBox, or Tree graph widgets?
- [Last modified: Apr 98]
-
- Motif 2.0 and later include an XmContainer widget which displays hierarchal
- trees. Motif 2.0 also includes XmComboBox and XmSpinBox, which many users
- requested.
-
- For Motif 1.x versions of these widgets and listings of other types of
- widgets, see the widgets FAQ mentioned in the previous subject.
-
- -----------------------------------------------------------------------------
- Subject: 272) How can I create a transparent widget?
- [Last modified: Dec 98]
-
- Answer: The simplest way is probably to use the SHAPE protocol extension. The
- xeyes, xlogo, and oclock demo programs in X11R5 (and later) are good examples
- of using SHAPE with widgets. You should be able to use the same techniques
- with your Motif widget subclasses.
-
- Ken Lee
-
- Ken Sall (ksall@cen.com) adds: The official name for this extension is "X11
- Nonrectangular Window Shape Extension". If you have X11R5 source, the Shape
- extension document is $TOP/mit/hardcopy/extensions/shape.PS or
- $TOP/mit/doc/extensions/shape.ms. In X11R6, see
- $TOP/xc/doc/hardcopy/Xext/shape.PS or $TOP/xc/doc/specs/Xext/shape.ms. There
- is also a terse man page: $TOP/mit/man/Xext/XShape.man (X11R5) and
- $TOP/xc/doc/man/Xext/XShape.man (X11R6).
-
- Ken Lee adds: Some graphics-oriented systems (e.g., SGI, HP) include hardware
- overlay planes that support transparency directly. The APIs for accessing
- these capabilities from Motif programs are non-standard. Read your system's
- documentation or contact your vendor for more details.
-
- -----------------------------------------------------------------------------
- Subject: 273) TOPIC: CREATING WIDGETS
-
- [This section is for widget writers.]
-
- -----------------------------------------------------------------------------
- Subject: 274) What are some good references for creating widgets (subclassing
- widgets)?
- [Last modified: May 99]
-
- Answer: Ken Sall (ksall@cen.com) writes:
-
- If you have Motif 2.0 or later, see the new document provided by OSF called
- "OSF/Motif Widget Writer's Guide" in the directory:
- doc/widgetGuide/Output/draft/ps.
-
- If you have Motif 1.*, try these references (details in the BOOKS topic):
-
- Paul Asente, Donna Converse, and Ralph Swick, X Window System Toolkit,
- Second Edition, 1998.
-
- Nye, Adrian & O'Reilly, Tim,
- X Toolkit Intrinsics Programming Manual.Motif Edition, Volume 4M
-
- Flanagan, David, Editor,
- X Toolkit Intrinsics Reference Manual, Volume 5
-
-
- joe shelby (jshelby@autometric.com) writes:
-
- Alastair Gourlay, a former member of the Motif Development group at OSF, has
- written 2 articles for _The X Resource_, published by O'Reilly and Associates.
-
- The first, "Writing Motif Widgets : A Pragmatic Approach" can be found in
- Issue 6. It covers writing a XmPrimitive-derived widget, deriving from that
- widget, and writing a XmManager-derived widget. Also included are brief
- summaries of several _Xm private functions for widget writers, how to use the
- Motif 1.2 Representation Type functions, and adding the widgets to Mrm/Uil.
-
- The second, "The One-Minute Manager : Custom Motif Layout Widgets Made Easy"
- can be found in Issue 10. It expands and greatly simplifies creating
- composite widgets for Motif. Gourlay has created and released a new widget,
- the XmpGeometry widget that handles all of the geometry management issues for
- you and provides convenience functions for determiningparent and child
- widgets' perfered sizes. All the programmer has to do to derive from this
- widget is create the new resources and constraints and implement 2 new class
- methods to override the XmpGeometry's methods. Included with the XmpGeometry
- class are 3 example derived widgets.
-
- Donald L. McMinds and Joseph P. Whitty have written a book, _Writing Your Own
- OSF/Motif Widgets_, published by Prentice Hall for Hewlett-Packard
- Professional Books. Both authors work at HP's Workstation Systems Division,
- and have been involved with Motif developement since its beginnings. The book
- (which is mostly code with explanations) gives details on writing
- XmPrimitive-derived, XmManager-derived, and XmGadget-derived widgets, with one
- example widget for each. In addition, the book provides "man-pages" for
- several _Xm private functions for programmer convenience.
-
- -----------------------------------------------------------------------------
- Subject: 275) How can I achieve binary compatibility using the
- XmResolvePartOffset API?
- [Last modified: July 96]
-
- Answer: Daniel Dardailler (daniel@x.org) recently provided the following URL:
-
- http://www.x.org/people/daniel/xmresolve
- Achieving Binary Compatibility using the XmResolvePartOffset API
-
- which addresses the problem caused by the fact that many widget writers "never
- used the XmResolvePartOffsets API in their subclass code, therefore ensuring
- it will break when dynamically relinked with newer version of libXm".
-
- Unfortunately, this URL is no longer valid. Does anyone know of a new
- location? Thanks.
-
- -----------------------------------------------------------------------------
- Subject: 276) TOPIC: MISCELLANEOUS
-
- -----------------------------------------------------------------------------
- Subject: 277) How can an application be informed of signals?
- [Last modified: Jun 98]
-
- Answer: The answer differs depending on whether you're using X11R5 or X11R6.
- For those using X11R6, Ken Lee (http://www.rahul.net/kenton/) writes: In
- X11R6, the Xt library has the new XtAppAddSignal() function. Ken Lee's
- December, 1995 *The X Advisor* column has an example:
-
- http://www.rahul.net/kenton/txa/dec95.html
-
- For those using X11R5, these older responses apply:
-
- blackman@hodgkin.med.upenn.edu (David Blackman) writes:
-
- According to comp.windows.x FAQ, you shouldn't make Xt/Xlib calls from a Unix
- signal handler:
-
- "You can work around the problem by setting a flag in the interrupt handler
- and later checking it with a work procedure or a timer event which has
- previously been added."
-
- Kaleb KEITHLEY (fedora.x.org!kaleb) adds:
-
- Xt is not reentrant and it is not safe to call any Xt functions from a signal
- handler... I think [the signaling] technique is covered in the [X] FAQ. On
- most POSIX-type systems write(2) is guaranteed to be reentrant and atomic. If
- you establish a simple pipe with the pipe(2) system call, and add it as an
- XtInput with XtAppAddInput(), then you can write to the pipe in the signal
- handler. Xt will notice that input is available and call the input-handler
- proc. This technique is inherently better than setting the flag because the
- write to the pipe will result in XtAppNextEvent returning immediately without
- the latency you observe in using the flag technique. In R6 you can use the
- XtAppAddSignal function.
-
- Ken Sall (ksall@cen.com) adds: See the "Signal Handling" chapter of "Motif
- Programming Manual" by Heller and Ferguson, listed in the BOOKS topic.
-
- Paul Davey (pd@uit.co.uk) adds: The write and XtAppAddInput input method is
- often the best - but be warned it does not work on some SVR3 based Unixes,
- where a pipe may not be selected on. SCO Unix exhibits this behaviour so here
- the external flag method should be used.
-
- -----------------------------------------------------------------------------
- Subject: 278) How do I control the repeat rate on a SUN keyboard?
-
- Answer:
-
- [...]
-
- -ar1 milliseconds
- This option specifies amount of time in milliseconds
- before which a pressed key should begin to
- autorepeat.
-
- -ar2 milliseconds
- This option specifies the interval in milliseconds
- between autorepeats of pressed keys.
-
- Of course this presumes you're using a server based on the MIT sample server.
-
- Thanks to kaleb@x.org (Kaleb Keithley)
-
- -----------------------------------------------------------------------------
- Subject: 279) How can I identify the children of a manager widget?
-
- Answer: Use XtGetValues() on XmNchildren (array of widget IDs) and
- XmNnumChildren (number of widgets in array).
-
- -----------------------------------------------------------------------------
- Subject: 280) What functions can an application use to change the size or
- position of a widget?
-
- Answer: Applications should set the values of the XmNx, XmNy, XmNwidth, and
- XmNheight resources.
-
- Note that many manager widgets ignore the XmNx and XmNy resources of their
- children, relying instead on their internal layout algorithms. If you really
- want specific positions, you must use a manager widget that allows them, e.g.,
- XmBulletinBoard.
-
- Also note that some manager widgets reject size change requests from their
- children when certain resources are set (e.g., XmNresizable on XmForm).
- Others allow the the children to resize, but clip the results (e.g.,
- XmNallowShellResize on shell widgets). Make sure you have these resources set
- to the policy you want.
-
- Due to bugs, some widgets (third party widgets) do not respond to changes in
- their width and height. Sometimes, you can get them to respond correctly by
- unmanaging them, setting the resources, then managing them again.
-
- Under no circumstances should applications use routines like
- XtConfigureWidget() or XtResizeWidget(). These routines are reserved for
- widget internals and will seriously confuse many widgets.
-
- Ken Lee
-
- -----------------------------------------------------------------------------
- Subject: 281) Can I use XtAddTimeOut, XtAddWorkProc, and XtAddInput with
- XtAppMainLoop?
-
- Answer: On many systems, the obsolete XtAdd*() functions are not compatible
- with the XtAppMainLoop(). Instead, you should use newer XtAppAddTimeOut(),
- XtAppAddWorkProc(), and XtAppAddInput() functions with XtAppMainLoop()
-
- Ken Lee
-
- -----------------------------------------------------------------------------
- Subject: 282) Why does XtGetValues for XmNx and XmNwidth return extremely
- large values?
-
- Answer: You must use the 16 bit "Dimension" and "Position" data types for your
- arguments. If you use 32 bit integers, some implementations will fill the
- remaining 16 bits with invalid data, causing incorrect return values. The
- *Motif Programmer's Manual* and the widget man pages specify the correct data
- type for each resource.
-
- Ken Lee
-
- -----------------------------------------------------------------------------
- Subject: 283) Can I use XmGetPixmap() with widgets that have non-default
- visual types?
-
- Answer: XmGetPixmap() assumes that you are using the default screen depth. If
- you're using a different depth, use XmGetPixmapByDepth() instead.
-
- Ken Lee
-
- -----------------------------------------------------------------------------
- Subject: 284) What is the matter with Frame in Motif 1.2?
- [Last modified: November 92]
-
- Answer: This announcement has been made by OSF:
-
- "IMPORTANT NOTICE
-
- We have discovered two problems in the new 1.2 child alignment resources in
- XmFrame. Because some vendors may have committed, or are soon to commit to
- field releases of Motif 1.2 and 1.2.1, OSF's options for fixing them are
- limited. We are trying to deal with these in a way that does not cause
- hardship for application developers who will develop applications against
- various point versions of Motif. OSF's future actions for correction are
- summarized.
-
- WHAT YOU SHOULD DO AND KNOW
-
- 1. Mark the following change in your documentation.
-
- On page 1-512 of the OSF/Motif Programmer's Reference, change the descriptions
- under XmNchildVerticalAlignment as follows (what follows is the CORRECT
- wording to match the current implementation):
-
- XmALIGNMENT_WIDGET_TOP
- Causes the BOTTOM edge of the title area to align
- vertically with the top shadow of the Frame.
-
- XmALIGNMENT_WIDGET_BOTTOM
- Causes the TOP edge of the title area to align
- vertically with the top shadow of the Frame.
-
- 2. Note the following limitation on resource converters for Motif 1.2 and
- 1.2.1 implementations.
-
- The rep types for XmFrame's XmNentryVerticalAlignment resource were
- incorrected implemented, which means that converters will not work properly.
- The following resource settings will not work from a resource file in 1.2 and
- 1.2.1:
-
- *childVerticalAlignment: alignment_baseline_bottom
- *childVerticalAlignment: alignment_baseline_top
- *childVerticalAlignment: alignment_widget_bottom
- *childVerticalAlignment: alignment_widget_top
-
- If you wish to set these values for these resources (note they are new
- constraint resources in XmFrame) you will have to set them directly in C or
- via uil.
-
- WHAT WE WILL DO
-
- The problem described in note #1 above will not be fixed in the OSF/Motif
- implementation until the next MAJOR release of Motif. At that time we will
- correct the documentation and modify the code to match those new descriptions,
- but we will preserve the existing enumerated values and their behavior for
- backward compatibility for that release.
-
- The fix for the problem described in note #2 will be shipped by OSF in Motif
- 1.2.2.
-
- SUMMARY
-
- We are sorry for any difficulty this causes Motif users. If you have any
- questions or flames (I suppose I deserve it) please send them directly to me.
- We sincerely hope this proactive response is better for our customers than you
- having to figure it out yourselves!
-
- Libby
-
-
- -----------------------------------------------------------------------------
- Subject: 285) What is IMUG and how do I join it?
- [Last modified: July 96]
-
- Answer: CAUTION: As of March, 1996, IMUG could not be contacted. If anyone is
- aware of the status of IMUG, please send mail to me (kenton@nojunk.rahul.net).
- Thanks to Lou Farho (farho@harris.com) for this update.
-
- IMUG is the International Motif User Group founded by Quest Windows
- Corporation and co-sponsored by FedUNIX. IMUG is a non-profit organization
- working to keep users informed on technical and standards issues, to
- strengthen user groups on a local level, to increase communication among users
- internationally, and to promote the use of an international conference as a
- forum for sharing and learning more about Motif. You can join it by
-
- 1. Pay the annual membership fee of $20 USD directly to IMUG. Contact
-
- IMUG
- 5200 Great America Parkway
- Santa Clara, CA 95054
- (408) 496-1900
- imug@quest.com
-
- 2. Register at the International Motif User Conference, and automatically
- become an IMUG member.
-
- 3. Donate a pd widget, widget tool or widget builder to the IMUG Widget
- Depository and receive a free one year IMUG membership.
-
- -----------------------------------------------------------------------------
- Subject: 286) How do I set the title of a top level window?
- [Last modified: September 92]
-
- Answer: Set XmNtitle (and optionally XmNtitleEncoding) for TopLevelShells.
- (Note that this is of type String rather than XmString.) You can also set
- XmNiconName if you want its icon to show this title. For XmDialogShells, set
- the XmNdialogTitle of its immediate child, assuming it's a BulletinBoard
- subclass. These can also be set in resource files.
-
- -----------------------------------------------------------------------------
- Subject: 287) How can I disable the color scheme mechanism in CDE or HP VUE?
- [Last modified: May 97]
-
- Answer: Put this in your app-defaults file: *useColorObj: False
-
- Ken Lee
-
- -----------------------------------------------------------------------------
- Subject: 288) Can I use editres with Motif? Is there an editres tutorial?
- [Last modified: Mar 96]
-
- Answer: Editres, part of the MIT delivery, is a powerful widget tree analysis
- tool and is highly recommended. There's negligible overhead in making editres
- available to an application and many projects keep the editres "hook" active
- even for operational programs.
-
- It isn't built in to Motif (at 1.2.*), but you can do this in your
- application:
-
- #include <X11/Xmu/Editres.h>
- XtAddEventHandler(shell_widget, (EventMask) 0, True,
- (XtEventHandler) _XEditResCheckMessages, NULL);
-
- once for each shell widget that you want to react to the "click to select
- client" protocol. Then link your client with the R5 libXmu.
-
- Thanks to David Brooks, OSF, for the original answer. Jan Sandquist
- (ehsjasa@ehs.ericsson.se) supplied the current code snipet above. Joachim
- Fabini (jo@vmars.tuwien.ac.at) suggested that I remove the older use of
- "extern void _XEditResCheckMessages()" which resulted in core dumps on some
- platforms.
-
- NOTE: Ken Lee has placed his November, 1994 editres tutorial on the Web:
-
- http://www.rahul.net/kenton/editres.html
-
-
- -----------------------------------------------------------------------------
- Subject: 289) Where is the editres protocol documented?
- [Last modified: Apr 95]
-
- Answer: In /usr/include/X11/Xmu/EditresP.h.
-
- Ken Lee
-
- -----------------------------------------------------------------------------
- Subject: 290) Why does an augment translation appear to act as replace for
- some widgets? When I use either augment or override translations in
- .Xdefaults it seems to act as replace in both Motif 1.0 and 1.1
-
- Answer: By default, the translation table is NULL. If there is nothing
- specified (either in resource file, or in args), the widget's Initialize
- finds: Oh, there is NULL in translations, lets use our default ones. If,
- however, the translations have become non-NULL, the default translations are
- NOT used at all. Thus, using #augment, #override or a new table has identical
- effect: defines the new translations. The only way you can augment/override
- Motif's default translations is AFTER Initialize, using XtSetValues. Note,
- however, that Motif managers do play with translation tables as well ... so
- that results are not always easy to predict.
-
- OSF wrote: A number of people have complained about not being able to
- augment/override translations from the .Xdefaults. This is due to the
- complexity of the menu system/keyboard traversal and the necessary
- translations changes required to support the Motif Style Guide in menus. It
- cannot be fixed in a simple way. Fixing it requires re-design of the
- menus/buttons and it is planned to be fixed in 1.2.
-
- -----------------------------------------------------------------------------
- Subject: 291) How do you "grey" out a widget so that it cannot be activated?
-
- Answer: Use XtSetSensitive(widget, False). Do not set the XmNsensitive
- resource directly yourself (by XtSetValues) since the widget may need to talk
- to parents first.
-
- -----------------------------------------------------------------------------
- Subject: 292) Can I change the graphics drawn by insensitive widgets? Some
- become very difficult to read.
- [Last modified: Aug 97]
-
- Answer: There is no general mechanism for this; each widget chooses its own
- insensitive graphics. Some are customizable, however. Label and button
- widgets have a XmNlabelInsensitivePixmap resource. Others, such as the text
- widgets, have an XmNeditable resource; setting this to false is similar to
- insensitive, except tha the graphics do not change.
-
- Other possibilities would be to install an empty translation table to ignore
- input or to create an occluding InputOnly window to block input.
-
- -----------------------------------------------------------------------------
- END OF PART EIGHT
-