Overview of Motif 2.0®
Originally published in the X/Journal, 1995.
Five years after its appearance on the market, OSF/Motif has become the major Graphical User Interface (GUI) technology for Open Systems, as well as a de jure standard (IEEE P1295). The previous version of OSF/Motif (Release 1.2) introduced major new features such as internationalization, drag-and-drop and tear-off menus. Those features were intended to allow application developers to produce interoperable, easy to use applications for a worldwide market. As a result, this technology has been selected to become the basis of the Common Desktop Environment jointly developed by HP, IBM, Novell and SunSoft, proposed to become an X/Open standard.
Every Motif release contains new features that help the end user community (e.g. drag and drop in 1.2) or the developer's community: programming features that are invisible from the end users but make developer's life much easier (e.g. representation types in 1.2). OSF Motif 2.0 is no exception. It includes items for developers such as the extensibility framework and the uniform transfer model, and extension for end users such as virtual screen support and workspace management. And it also contains new widgets that actually serve both the end user community and the programmers.
For end users, Motif 2.0 presents the following new features reviewed in this paper:
For software developers, Motif 2.0 provides:
The remainder of this paper provides an overview of all the changes in Motif 2.0. The next section reviews the features most visible to a desktop end-user: virtual screen management, workspace management, and the new widgets. The following sections concern the toolkit and detail respectively the extensibility framework, new features in the toolkit, namely Uniform Transfer Model, reorganization of the menu system as well as miscellaneous enhancements.
Finally, it describes how the UIL technology has been enhanced to support the extensibility framework and how it has become architecture neutral with regards to the underlying operating system and computer processor.
The different tasks involved in controlling the desktop can generally be grouped into seveal categories: file management, style management, session management, window management and workspace management. The philosophy of OSF's design is that the control of each aspect of a desktop should be left to an appropriate manager specifically designed to manage a particular task or group of tasks relating to the desktop.
File management includes tasks relating to manipulating files and invoking applications that control the data files. Examples of such file manager are Apple's Finder, or the Common Desktop File Manager. Session management involves tasks relating to the saving and restoring of a user's environment. The environment not only includes the set of active applications, but also the environment settings they are running under, such as preferred fonts or screen configuration. A session manager must be capable of performing a controlled shutdown of a user's environment and a restoration of the environment at a later time. File management includes tasks relating to manipulating files and invoking applications that control the data files. Examples of such file manager are Apple's Finder, or the CDE File Manager. Style management is the set of panels through wich a user can customize the environment to set preferences such as preferred color schemas, define keyboard auto-repeat delay, set mouse double click time-out, etc.
Window Management consists in the control of windows layout and stacking on the screen as well as minimized windows (also called icons) placement, optionally using an icon box. Workspace management involves controlling the aspects of windows and application organization on the desktop beyond the confines of the windows actually visible on the screen. The basic concept is to allow the user to gather semantically related applications in one place: a workspace (sometimes also called a room). The user can then move back and forth between workspaces without having all applications simultaneously visible on the screen, but only those applications that belong to the current workspace.
The Workspace Manager and the Window Manager roles are related, they cannot operate independently, however they are distinct. OSF Motif 2.0 introduces two new major features on the desktop: virtual screen management inside MWM and a Workspace Management Protocol supported by MWM.
Virtual window management is a feature that has been long requested by many OSF/Motif users. Prior to Motif 2.0, placement of windows in the Motif Window Manager (MWM) by the user was limited to the hardware display screen.
With Motif 2.0 virtual screen management, this limitation of Mwm no longer exists. Virtual screen support provides the user with the ability to place application windows anywhere on a virtual screen area, much larger than the real screen. The real screen consists of a viewport on the virtual screen, displaying a small part of it. Client windows located outside of that viewport are not visible. Users can place applications anywhere on that virtual screen, moving undesired windows off of the display screen, or bringing them back into view. This allows many more windows to be opened without cluttering the user's screen.
Virtual screen management is very similar to a scrolled window: the user views only a part of the total area. Except that there is no scrollbar on a screen to scroll it! Therefore, the Motif Window Manager had to implement a mechanism to pan the real screen over the virual screen, thus replacing the scrollbar.
This mechanism is implemented as follows. Mwm supports the virtual screen by moving top-level windows to any location that a window can be placed using the X Window system. This allows a user to position windows on a root window of virtually unlimited size. Because of this, there is no pre-set limit on where the user may pan to. As opposed to other comparable systems which restricts motion to the size of a pseudo-root window,
The user freely move windows in all directions using one of three techniques offered: jumping to a specific location on the virtual desktop, panning, and interactive panning. The difference between panning and interactive panning is that panning is a single operation that pans the display by a pre-specified amount. Interactive panning is linked with the mouse and causes the virtual desktop to continuously be repositioned as the mouse is moved.
Mwm 2.0 also has some useful resources that may be used to modify the behavior of the virtual screen. Since a user may not wish to have all windows on a display moved, it is possible to pin windows down so that they remain relative to the display screen. This is especially useful when using an application that causes interactive panning such as the panner demo. If this window is not pinned down, it can be exceedingly difficult to control!
In the workspace paradigm, the user organizes the environment in explicit multiple workspaces. Each workspace has a name and the user simply moves from one workspace to the other by clicking on the name in a menu.
Note that the notion of workspace management and virtual screen are orthogonal. In Motif 2.0, each workspace corresponds to a virtual screen. As shown on figure below, users should think of a stack of workspaces, where each workspace maps to a virtual screen. When switching workspace, a user raises the new workspace on top of the stack. Since the workspace is a virtual screen, there may be invisible or partly visible windows. There are cases where this feature is required.
For example, if you consider a documentation workspace, in which the user wants to have several pages from several documents, but the real screen is only large enough to display a little more than one page.
Window Management and Workspace Management are related, they deal with the very same application windows. The Window Manager and and the Workspace Manager must communicate, so that the Window Manager does not systematically display any window from any application.
When an application starts anew, the Workspace Manager must be able to figure whether or not its windows should be displayed. When the user switches workspace, the Workspace Manager must tell the Window Manager what windows to remove from the screen and what windows to show.
OSF has defined for OSF/Motif 2.0, a workspace management protocol. This protocol regulates communication between the window manager and the workspace manager.
The protocol is fully supported by MWM. MWM can interoperate with any Workspace Manager supporting the protocol.
On the other hand, OSF is only providing a demo of a workspace manager client. The provided user-interface of that client is minimal and is not meant to fully support the potential use of workspace management. OSF intents here is to provide a standard protocol such that vendors and ISV can implement industrial strength, task oriented, workspace manager clients
Toolkits available on the PC offer a different set of controls than Motif. In general, where they offer similar functionality, Motif is more flexible and tends to include more features. However, some controls in the PC toolkits do not have corresponding controls in Motif 1.2.
In order to match this functionality, OSF issued a Request For Widgets inJuly 1992. The widgets that were selected through this process are a multiple-font text widget (from Digital), a Container and a Note book (both from IBM), a combo-box also called drop down list (from Lotus). Finally OSF included also a thermometer-like scale and a spin box widget.
Container is a critical widget for the direct manipulation, object-oriented, world toward which application software is moving. A container object offers views of the objects that the application can handle. Through direct manipulation, the user can select, move, copy or delete these objects, drag them into other applications, or drop new objects into the container.T he Container widget is a very powerful tool for application writers. In the future, potentially every application should be implemented with a Main Window and a Container. The menubar of the Main Window specifies the generic operations on objects, and the container displays the objects. A double click on an object activates it, and popup menus can be available for specific operations on the objects.
A Container can contain hierarchical objects that can be decomposed into further objects The container widget offers three kind of views:
First, a container may display the objects in the typical large icon view. In this view every object (a top level object of the tree) is displayed as an icon with a label. The Container widgets supports different types of layout for those icons. The most popular are
In the tree view every object at the top level of the hierarchy is displayed with a small icon. If the object has sub-objects attached, the hierarchical organization is displayed with lines and indentation reflecting the tree structure.
For very large hierarchies, which would take too much space, the container widget offers a browsing facility. For each level of the hierarchy, the application can first decide whether or not the information below that level should be displayed; second tell the container whether or not the user should be allowed to browse further.
If the user is not allowed to explore that branch of the tree, a mini-icon is displayed called the collapsed pixmap.
If the user is allowed to explore that branch of the tree, a mini-icon is displayed called the the expand pixmap. Clickking on the expand pixmaps displays one more level in the hierarchy. As this new level is displayed, the mini-icon is turned into a collapse pixmap: when clicking again on the icon, that tree branch is removed from the view.
The detailed view displays a table where each row represents an object and each item in the row a property of that object. The application is responsible for providing the detail data and the rendition attributes for it to be displayed.
The container widget supports all the selection modes from the LIst widget: a container in detailed mode is basically a tabular list. In addition it supports two other techniques in the icon view:
The Container widget uses heavily uses the new Icon Gadget from Motif 2.0. An icon gadget implements the functionality required for Container. It associates a small pixmap, a large pixmap and a label to be displayed as a small or large icon. It handles the double click. A major advantage of Icon Gadget is that it takes advantage of the general gadget caching facility from Motif. If the same icon is used hundreds times, it actually allocates once in memory the shared resources.
The Note Book is another powerful widget, simulating a real note bookwhich allows the application to display one page among a stack of pages, maintaining a constant page size. The Notebook widget includes pages, tabs, a status area, and the page scroller. It stacks its page children so that all page children occupy the same area just like real-world book's pages. Tabs simulates notebook tabs. Major tabs are used for dividing pages into several sections, and minor tabs are used for subdividing the sections. The page scroller is used for switching the current page to back and forth. Finally the Notebook provides tab scrollers for scrolling major and minor tabs when it cannot display all tabs.Tab scrollers are visible and enabled only when there is not enough space to display all the major tabs or the minor tabs appropriate to the page.
Major tabs displayed on the side of the Note Book allow the user to quickly access to the data. Once a primary tab is chosen (e.g., a chapter), the minor tabs appear in the orthogonal direction (e.g. sections) and allow further indexing inside the relevant parts of the document.
Pages, tabs, status areas, and the page scroller are created by the application as children of the Notebook widget. Any Motif widget may be a page of the Notebook. A major tab or a minor tab may be attached to a page by creating a tab child of the Notebook and setting a constraint to the page number of the targetted page. Note that the notebook widget makes heavy use of the traits of its children widget to invoke their class methods. A tab, either a major tab or a minor tab, must be a Motif widget that has the activatable trait (such as a push button). Tabs in a Notebook are associated with a page number, not attached to any actual page widget. Therefore, it is possible to have a tab with an empty page. Destroying a page widget leaves an empty page. (It does not "tear" the page out of the XmNotebook.)
The page scroller child is not associated with a certain page. There is only one valid page scroller per Notebook and it must carry the navigator trait. Since the application of the Notebook can provide page numbers, it is possible to have duplicated pages and empty pages. An empty page is a page slot where no page is inserted. This page displays just blank background unless the application provides some visual information to this empty area while processing. Note that this feature is very useful for applications that have to display hundreds (or even thoudands) of pages. It is not required to have hundreds of physical pages in memory. An application may actually use only one physical empty page, provide the adequate tab indexing for the real number of pages it supports, and only update the contents of the (single) physical page with the
This makes it possible to implement Help systems with a large number of pages using only one actual page widget.
A status area child is any Motif widget that is to be used for describing the associated page. A status area widget is also attached to a page by the page number constraint resource. Therefore, it is possible to have multiple status area widgets, only the most recently managed one displayed.
The Note Book widget is a versatile tool. It can be used for
A Note Book allows a developer to very quickly prototype all kinds of applications that display organized information such as a card filer, an agenda or a calendar application.
As its name indicates Combo Box combines the capabilities of a single line text widget and a list widget; allowing users to type in information and also providing a list of possible choices to complete the text entry field. The list can either be displayed at all times or can be dropped down by the user. That's why combo box is sometimes referred to as "drop down list".
When the list portion of the combo box is hidden, users are given a visual cue, a downward-pointing arrow next to the text field. These drop-down combo boxes are desirable when presentation space is limited, or when users will complete the text entry field more often by typing text than by choosing the entry field text from the list. The dropdown ComboBox list should popup in the visible area of the screen but should stay aligned with the text field (i.e. at the bottom edge of the screen, the List will be drop "up").
The application programmer simply provides an array of strings that will fill the list. Each string becomes an item in the list, with the first string becoming the item in position 1, the second string becoming the item in position 2, and so on. The list can actually be maniplated with the regular API of the XmList widget.
Similarly, the text entry may be accessed by using XmTextField API. The size of the list is set by specifying the number of items that are visible in the list (XmNvisibleItemCount). If the number of items in the list exceeds the number of items that are visible, a vertical scroll bar will appear that allows the user to scroll easily through a large number of items.
A ComboBox allows a single item to be selected in two ways: by scrolling through the List and selecting the desired item; or by entering text into the text entry field. Selecting an item from the list causes that item to be displayed in the text portion of the ComboBox. The single line text field in a ComboBox can be either editable or non-editable. If the text field is editable, the user can type directly into it to enter a new list item. If the application wishes to validate the entered text, it can do so by installing a XmNmodifyVerifyCallbacks on the text field. If the text field is non-editable, typing text invokes a matching algorithm that attempts to match the entered text with items in the list.
This is a text widget supporting various rendition attributes (e.g. multiple fonts, multiple colors). This widget is not a complete formatting document editor, such as commercially available products. It is merely a text widget with rendition attributes. However it can be useful in many other contexts than desktop publishing. For example a CASE tools could highlight syntactic errors of a program source code using a different color.
This widget named CSText for Compound String Text, takes an XmString argument (a strings markep up with tags) and a rendition table.
Each tag associated with a substring should correspond to an entry in the rendition table specifying how the string is to be rendered (font, color)
Although more modest the Spin Button widget offers a quick way of selecting, cycling, or setting a value within a range. It can be used by a very large range of applications. The spin button functionality can be implemented using the existing Motif Arrow Button widget and a label widget. However, the spin button widget makes it much easier for the developer and uses quite a bit less memory.
This is a long-demanded widget in OSF/Motif for applications that have to display some output-only data, The Motif scale is an input/output widget, meant for representing values that can be changed by the user, is impractical for that purpose.
Although Motif 1.2 offers most of the behavior found on the PC market (MS Windows and OS/2) and skill transfer to Motif is immediate, a few differences remained that have been removed.
One of the problems Motif developers are facing is the complexity of developing new widgets for their applications. Subclassing Motif widgets without the source code of the parent class is a challenge with Motif 1.2. Even developing a new class from the superclass source code is not always an easy task. There are four sets of issues for the widget developer:
OSF has addressed these issues by developing an extensibility framework for Motif that will significantly help OSF/Motif widget developers and application programmers. This framework includes four parts.
The Trait abstraction was first introduced by Xerox during the development of the Star [Xe82]. A trait is a characteristic of an object that can be expressed by a set of methods/data applied to, or carried by the object holding that trait. At a higher level, a trait implements a behavior that can be shared by different objects of a system without requiring any particular hierarchical relationship between these objects, or any particular implementation of the trait.
For example, let's consider the I am a navigator trait. This trait characterizes the fact that an object can set a value between a minimum and a maximum value, regardless of the particular mehod used to set the value or the particular look and feel. A navigator can be implemented by a scrollbar, a thermometer like control or even a choice in the list of all possible values. The navigator It provides the abtraction which guarantees that any object carrying this trait can be used to navigate arbitrarilty between two values.
The I am a navigator trait implements methods that maket it possible for clients of the object carrying the trait to set and get the min/max/current value independenlty of the implementation.
In Motif 2.0 both the XmScrollBar (an XmPrimitive subclass) widget and the XmSpinBox (an XmManager subclass) hold the I am a navigator trait, and they can both inherit or specialize the methods of that trait.
Therefore the traits mechanism makes it possible to implement a form of multiple inheritance on top of the Xt object oriented framework, which only supports single inheritance. In the Motif 2.0 model, traits are seen as light abstract classes (sometimes called mix-ins).
Traits also make it possible to implement a form of polymorphism on the various widgets. For example if a trait has a setvalue method, it can be used to set values of resources that actually have a different name e.g a trait::setvalue() replaces XtSetValues() on mutiple XmNresource names.
A side effect of traits is potential reduction of code size in applications. In many cases a Motif Manager widget would check the class of its children. Doing so requires access to the class pointer, and at link time, linking the class pointer global variable usually links chained modules in the application. Because those tests are replaced in the Manager code with checking the children's traits, the spaghetti effect is eliminated.
Traits also augment code re-use inside Motif. A widget writer can simply decide to inherit a Trait from another widget. It then inherits the class methods implemented by the OSF engineers at no cost...
Many new functions are documented in Motif 2.0 to help widget writers. Those function can be classed in various categories:
Miscellaneous functions such as obtaining the user's HOME directory, or printing a warning message to the user.
There are two kinds of interfaces currently available from C++ to a system such as the X toolkit. The first kind is a wrapper, a C++ class which contains a pointer to another object and which presents an interface to the other object. The second kind of interface are the C++ toolkits. None of these C++ interfaces satisfied OSF extensibility goal:
Consequently, a major design requirement was that an object be at the same time, both a true C++ objects and an Intrinsics object. Unfortunately, this requirement removed the possibility of using an existing solution.
How do we satisfy the goal of making objects both C++ and Intrinsics objects?
To fulfill this the object must undergo both the initialization which the Intrinsics supply as well as that of C++. For the object to correspond in C++ and the Intrinsics, we must exploit the correspondence of inheritance in C++ to the structure of the Intrinsics widgets. In both cases, each succeeding subclass's instance data is placed in memory. Thus we end up with a C++ object with the form, using the example class of StaticText, as shown in figure 2.
The Intrinsics have two kinds of objects defined for each widget class, class records and class instances. These are separated since C has no mechanism to handle class versus instance data. But the class record also serves as a metaclass metaphor. As a metaclass it allows the programmer to modify class creation and destruction behavior and define the side effects which occur when the object's values are manipulated through a call to the Intrinsics Core class method SetValues.
In particular we have two defined pairs of classes which form the base for all subclassing which is to occur.
XmCxxPrimitive (widget class) with XmCxxPrimitiveClass (widget class record) provide the interface to the XmPrimitive widget class.
XmCxxManager (widget class) with XmCxxManagerClass (widget class record) provide the interface to the XmManager widget class.
These C++ base classes are abstract classes, that is they are not intended to be instantiated by the widget user. This is very much like XmPrimitive and XmManager which are generally not instantiated.
To prove and test the viablity of this technology, OSF provides on the Motif2.0 Widget Writers book, several examples of new widgets developed in C++, named StaticText and Grid. The class hierarchy is shown in figure 3 of the derived classes StaticText and Grid. This also shows the general structural relationship of the C++ class hierarchy and the Intrinsics class hierarchy.
Figure 1: Class Hierarchy
This new book shows how you can create your own Motif widgets.
The ideal reader already knows a lot about the Intrinsics. If you've ever tried to write an Athena, OpenLook, or Motif widget, then this book will carry you to Motif hacker nirvana. Likewise, if you are already a cracker-jack Motif application, programmer but feel that there is something missing in your life, buy this book. But let's not get carried away. Writing widgets, even with the pleasant guidance of the book, will remain a strenuous task.
The source code for eight example widgets accompany theOSF/Motif Widget Writer's Guide. We have dubbed these widgets the Exm widget set. The book explains the important features of these examples. These examples demonstrate many aspects of responsible widgeting. You can feel free to borrow as much code as you like from these widgets or even to subclass directly from them.
The book consists of two parts: a guide part and a reference part. The guide part starts with a short tutorial and then talks you through the following topics:
The reference part of the book provides reference pages on the following topics:
OSF/Motif 1.2 provide the application programmer and widget writer with a number of different mechanisms to interchange data between applications. There are four forms of data transfer supported within Motif:
In any case, a data transfer can be characterized by the fact that
Each particular transfer mechanism in Motif requires a new programming effort to accommodate, and thus there is a burden on the programmer if all modes are to be supported, which is recommended by the Style Guide.
In Motif 2.0, OSF has implemented a new mechanism to unify access to the different mechanisms. Further, this mechanism allows the application programmer the ability to extend the functionality of toolkit supplied widgets in the area of data interchange.
The model is indeed very simple:
The convert callback is called each time the user has requested some data through any mechanism. The programmer only needs to provide a buffer containing the data and the name of the data type (an atom). Motif automatically transfers the data and frees the memoery after the data has been received.
Similarly, the selection callback tells the programmer that data has arrived.
Motif popup menus haven't been simple to program. Once a popup menu is created, it does not pop up automagically on the screen a button press occurs; some programming is required to make it popup. It had the sense of a task left incomplete, particularly since the code would popup a menu when invoked from the Menu key of the keyboard.
There are some other issues in the Motif 1.2 popup system. Substantial programming is required If the application programmer wants a different menu in some children of a manager, for example a different menu for every kind of graphical object in a DrawingArea. The current menus cannot, without outside assistance, work on a tree of widgets. If the parent widget has more than one menu which can be popped up then the application would need to determine the right one. Moreover, If there were grand-children of the manager widget which had their own popups, then the application would need to determine which child the pointer is in.
So, for many systems which use popup menus for a number of areas in the widget tree, complex code would be required to find the right menu for the current cursor location.
To summarize, we wanted
For the most simple specification of an automatic popup, nothing else needs to be done by the application programmer other than creating the popup menu associated with its manager.
At the same time this feature was implemented, the menu system source code was re-organized. For histroical reasons, the menu system in Motif 1.x has been coded as a single huge module. This module has been split in 2.0 into several modules, making the code easier to understand and maintain for OSF. The menu system also uses two new traits: activatable and MenuSavvy. Those traits greatly facilitate the task of programming new kinds of button widgets, which was difficult with the 1.x releases.
Last year, several companies grouped together to create an Open Desktop software, by integrating pieces coming from the various companies, some of which were not using the Motif look and feel in their former products. The Open Desktop is based on Motif, but a few modifications were made intially in 1.2 to provide a better desktop, but also to facilitate transition to Motif for the OpenLook users
The Motif File Selection Box offers a powerful but complex filtering mechanism for file selection. The Motif File Selection Box is offering all the power of the UNIX file system to users. This known to be adequate for UNIX gurus, but the CDE User Model group has come up with a design that seems better suited for the "average" user.
A feature of the Motif FSB for the UNIX literate is that it allows filtering on files as well as directories. For example a user may wildcard for the *.ps files in all directories of all users, using wildcard pattern " /users/*/*/*.ps ". As a result the directories names of the matching files may differ, which requires to have the complete path names showed in the lists. Since the names can be long, scrolled lists are needed.
But this functionality is not required to the casual user. What most users want is to specify a directory and then filter the files in this directory using a wildcard. Since all matching files and directories are relative to the base directory, it is not necessary any more to display the full path names. Only the subdirectories are showed in the directory list and the file names in the file list. Hence scrollbars are not needed in this case: it looks muchbetter and it feels more inttuitive.
That's basically what the CDE FSB only provides: it replacses the regular Filter control from with two controls: the "base" directory entry and a wild-card entry for file name pattern.
o SF did not want to break existing applications documentations that would not match exactly what users see on the screen. We also wanted to maintain the 1.2 behavior available to UNIX gurus. So, it was decided to maintain both the old and the new styles. However the new CDE style has become the default since it has higher usability for most users.
The Motif Style Guide allows for multiple sort of pointer devices that may have one or more buttons. These buttons are referred to by symbolic names (e.g. BSelect, BMenu, BDrag) characterizing their usage. Normally these symbolic names are bound to a particular button. Typically, a three button mouse is used on workstations and BSelect is mapped on Button1, BDrag on Button2 and BMenu on Button3.
The OpenLook Style Guide used to map BAdjust on Button2 by default. When migrating to Motif, a lot of users, used to adjust the selection with Button2 would then by mistake start a drag, leading to undesired results...
To facilitate migration of OpenLook users to Motif, it was decided to offer an option in Motif controlled by a resource enableSelectDrag to use Button1 for both BSelect and BDrag.
Note that this is a resource that can be set the end-user in the .Xdefaults file. So a user can choose its preferred behavior.
In general, a BMenu press over an object in Motif is supposed to bring context dependent menu about the object. So what's a BMenu press supposed to do inside a Cascade button: logic would say it is supposed to bring a menu about the menu! Howver, most users don;t understand it that way: they think that BMenu should pulldown the menu.
An option was added to make this possible. Note that this is consistent with the Motif style guide, which allows both behavior.
Motif offers string manipulation through an abstract object called XmString. The XmString abstraction that associates a possibly multi-lingual string with the encoding informattion attached to each locale and rendition to be used for a particular substring.
In Motif 1.2, the XmString abstraction supports the display with multipe fonts, with some work: the programmer has to create separately the character string that use a different font, associate that string with a tag, and match that tag with a font. In Motif 2.0, the rendition is both simplified and extended. First it is extended to support not only multiple fonts, but also multiple colors, and TAB marks as well. It is simplified with the availability of a new API. That new API offers a construction of the XmString
XmStrings are the abstraction in Motif that associates a possibly multi-lingual string with the encoding informattion attached to each locale and rendition to be used for a particular sub-string. Toggle Button Enhancements
When used as check marks, toggle buttons (on-off buttons) are not optimally usable in Motif 1.x releases: users are sometime confused whether the etched-in look means On or Off. Also the 3D effect used for the etched-in or etched-out look is not always perceptible in unusual light conditions (e.g. submarines) or screens with limited color range. This has lead to enhancing ToggleButton widget to support three new features:
Support has been added for right to left languages. Many of the Motif widgets now automatically reverse the geometry when the direction is "right-to-left". For example the Form widget automatically switches the left margin and the right margin as well as the attachment constraints. The result is that developers can design applications using the internationalization facilities and specify a constrained layout that will work in both left-to-right and right-to-left environment.
Motif 2.0 requires that applications now be linked with the Xpm library. This library is freely available from the contrib directory of the X Consortium, and it is duplicated on the Motif tape as well. Xpm supports makes it possible to support muti-color pixmap icons instead of two colors bitmaps.
The Motif 1.x Paned Window widget can only have horizontally separated panes. Motif 2.0 is adding a vertical mode.
New conversion methods were added so that a user can specify a window size in inches, millimeters or typographical points.
A new resource was added to specify whether XmList takes ownership of the primary selection when a selection is made from it. A keyboard navigation facility has been added allowing the user to navigate directly to a n item by typing the first character of the item. This is of course mostly useful in lists organized by alphabetical order.
The 1.2 list widget does not exhibit very good start-up performance with large lists of serveral thousands items. An optimization was found in the algorithms and memory allocation strategy that reduces the start-up time of List widget by more than 30% on a typical workstation.
Several resource were added to the XmScreen widget to allow per-screen behavior.
A new resource was added to specify whether pixmaps or bitmaps should be used in an application. If bitmaps are used, the application is limited to two-colors icons or stipples, but it uses much less memory (typically 8 times less on 8bits color screen).
A set of resources were added to provide control of the color schemes to the application. The goal of those new resources makes it possible for an application
Color intensive applications generally want to control the color schema and color allocation in order to optimize their own algorithms and usage of the colormap. For example, on a system with 256 entries in the colormap, an application may want to use all 256 colors for its own usage. Then there are no colors left for the Motif toolkit. What it can do with Motif 2.0 is to plug its own allocation function. Then, each time Motif needs a new color, it calls that function. The application can decide then to "loan" to Motif one of the colors it uses already, that is very similar, or possibly identical.
A new screen resource allows an application to customize the bitmap that is used by Motif for the rendering of insensitive visuals. Support is added also for application that want to display menus in overlay planes. Menus can now be displayed in a different visual that the application.
As of Motif 1.2, users can customize the keyboard mapping by defining a keymap between virtual keys (e.g. osfCancel) and real keys (e.g Cancel or Escape) and then run the xmbind command to bind the real keys to the virtual keys. However a single real key can be assigned to a single virtual key.
In Motif 2.0 each virtual key can be associated with mutiple real keys, allowing users to use for example both the Escape key or the Cancel key to cancel an operation. Of course, errors can occur if a user wrongly maps the same real key to mutiple virtual keys.
Several enhancements were made to Drag and Drop. Applications are not supposed to use those features since the Uniform Transfer Model provides them with a easy to use and comprehensice API. The following features are useful fr sophisticated applications that are adavanced in drag and drop technology.
A function has been added to query whether any widget is a dropsite or not. A generic application-wide dragStartCallback has been added, such that an application can be aware and take action for any drag occuring at any time in the application.
To provide better drag and drop feedback to the user, Motif 2.0 makes it possible to provide feedback with the drag icon changing in real time to convey the side effects that a drop would have if it occured at the current location of the mouse cursor. These visuals are based on the individual item or items that are being dragged.
Another enhancement that has no APi, but is fairly visble to end users: drag-scroll suppor. It occurs, especially on small screens, that users drag some data from one place and want to drop it into a place that is actually hidden, scrolled out in a scrolled window. Users then have to drop the icon on the desktop, scroll the destination to be visible again, and restart the drag. Drag scrolling avoids that: the user simply moves the cursor over the scrollbar direction control and pauses. After a (customizable) delay, the scrolled window automatically starts moving itself making the destination to appear. As soon as the user moves the cursor, scrolling stops.
The scrollbar widget has been extended to supports a look and feel ala OpenStep, where both up and down controls are close together at one end of the scrollbar, as opposed to one control at each end. A new resource was added such that application have more control over the visual of the slider.
It is practically impossible with Motif 1.2 for an application to implement a scrolled window that has a fixed title or a status bar inside the scrolled window area. Motif 2.0 makes it a possible to have one or more arbitrarys control to be displayed non scrollable in either direction.
Using this feature, one can implement a spreasheet application very simply with a column title (that cannot be scrolled out vertically) a rows title (that cannot be scrolled out horizontally) and a RowColumn widget for the cells. MainWindow, a subclass of ScrolledWindow, inherits this feature too.
Drawing Area is now traversable with the keyboard, making it possible for users to traverse to a drawing area, and gets its associated functions (e.g. popup menus).
A number of performance enhancements were achieved. Those are mostly enhancements on very specific items that we could measure and establish clear goals. The major enhancements are described below
The memory used by an XmString that uses a single font and less than 256 bytes (256 characters in Latin based language environments) is less than it used to be. Note this kind of strings represent most of the strings displayed in a typical user interface: menu items, list items, labels. At the same time, XmString memory size of every XmString has been reduced by 4 bytes (from Motif 1.2) for every string that consists of less than 256 characters and uses a single encoding, a single color and a single font, which is most of cases. Copying of XmString is now managed by reference counting in 2.0, which makes XmString copy much faster and uses no memory. Since Motif does a lot of XmString copies internally, that should reduce the memory size used by many applications, which do not release the memory of an XmString after they passed it to a widget.
The startup time for List widget has been decreased by over 35% from Motif 1.2. This is particularly noticeable for applications that handle large list of several hundred items.
In general, the amount of resources allocated in the X server and the clients side, and the number of round trips between client and server has been decreased. Client side memory is decreased by using bitmaps instead of pixmaps whenever possible. In Motif 1.2, when a widget uses a background pixmap, a pixmap is allocated using the depth of screen. In 2.0 if only 2 colors are used a bitmap is used instead.
Finally an optimization was found such that less mouse events would be generated from the X server when using gadgets.
Since OSF introduces an extensibility framework. it was necessary to reflect that in the UIL language: once a developer has developed a new widget, that new widget should be usable from UIL as well. However, one does not want to have to generate a new compiler for every new widget supported. It was necessary for OSF to develop a mechanism such that the UIL compiler could dynamically incorporate new widgets to be acceprtable in UIL source files and generate appropriate binary uid code.
o SF had received in the past numerous enhancements request because theat uid generated files are in the 1.x series not architecture neutral. You have to compile the same UIL source file for every targeted platform. Moreover it only supports 32 bits platforms.
With OSF/Motif 2.0, we have developed a new UIL technology that reaches those three objectives simultaneously
Figure 3 below shows a diagram explaining how the system works.
Note that the architecture neutral format is still dependent on 32 bits vs 64 bits architecture. A UIL file compiled on a 32 bits architecture can be read on any other 32 bits architecture, but not on a 64 bits architecture. A UIL file compiled on a 64 bits architecture can be read on any other 64 bits architecture, but not on a 32 bits architecture. This design decision was made because the memory used for 64 bits architecture is about twice the size of that used on 32 bits, and we did not want the 32 bits platforms to encur a 100% penalty.
The OSF/Motif toolkit is now a mature technology that has become a standard both in IEEE 1295 and X/Open.
Although Motif evolution in terms of extending the toolkit functionality is limited, there are still areas of improvements. Three major items are considered for the next release of OSF/Motif:
But market needs for User Environment technology are not limited to toolkit technology. The evolution of distributed, open, cooperative applications, and the requirements for interoperability, have created new needs.
OSF is now at a crossroads for determining the future of its User Environment Component. Of course the OSF/Motif technology can be enhanced. A Request For Widgets was issued in 1992 by OSF and, as a result of that Open Process, new widgets are incorporated into OSF/Motif 2.0. But OSF must also think of more significant technology updates for the future of its User Environment Component. Eventually a new desktop technology might make OSF/Motif invisible to the programmer because a new layer of abstraction would hide it from the programmer, but it will still be there!
© 1995-2010 Sales Enquiries Site Index