DOCUMENT ID: 1046-02
SYNOPSIS: How do XView objects map to OLIT widgets?
OS RELEASE:
PRODUCT: Solaris x86
KEYWORDS: XView objects map OLIT widget
DESCRIPTION:
How do XView objects map to OLIT widgets?
SOLUTION:
If porting an XView application to OLIT, it's useful to know how basic
XView packages map to OLIT, however it is critical to understand that
trying to replace XView calls with OLIT calls could be tedious since the
toolkit architectures are quite different.
Often a better approach is to first re-write the skeleton User Interface
in OLIT, and once the static interface is running and looks correct,
then add in the callback and event handler framework. After this is
complete, then take on the hardest task: porting the working guts of the
XView application to OLIT.
The benefit of this approach is that the port becomes modularized and
the entire application doesn't need to be ported before it can be run
and tested. The drawback is that this requires basic knowledge of Xt
programming and OLIT and thus a time investment up front. (Reading
Chapters 1-4 of the Pew/Young OLIT Programming book will give an
excellent introduction to Xt/OLIT basics: Widgets, widget instance
trees, resource management, etc).
To help understand the differences, below is information about how XView
objects/packages map (or don't!) to OLIT.
........................................................................
XView: Frame <-> OLIT: Shell Widget
The Intrinsics provides the "Shell" widget class which is the top-most
widget in an application window and is responsible for communication
with the window manager.
To provide particular types of windows, Xt & OLIT provide subclasses of
"Shell" which implement specific behavior. For example, The XView "Base
Frame" is equivalent to the Xt "ApplicationShell"; the XView "Command
Frame" is equivalent to the Xt "TransientShell" (or the OLIT
"PopupWindowShell", which is a subclass of TransientShell).
A Shell widget by itself provides no real window layout policies; both
layout and sizing behavior are determined by the type of Manager widget
created as the child of the shell. This differs from the XView Frame
package which takes care of tiling the subwindows within the window.
See "SubWindow Layout" section below for more info on this topic.
For more information on the Shell widget classes:
-Pew/Young OLIT book, Section 4.2.4 "The Shell
Widget Class"
-OLIT3.0 Reference Manual, pp.1-15 thru 1-44
"resources(3w)"
XView: SubWindow Layout <-> OLIT: Manager Widgets
XView provides SubWindow (or "pane") layout by allowing the various
SubWindow types (canvas, text, panel, tty) to be created as direct
children of the Frame, and the Frame manages a tile layout policy for
these subwindows.
Xt/OLIT takes a much more flexible approach to laying out the objects.
In Xt, it's only important to consider 2 different types of widgets:
ones which can contain children (any subclass of the Xt Widget meta
class "Composite") and ones which cannot have children (any subclass of
the OLIT Widget meta class "Primitive"). For example, the "Shell"
widget is a special subclass of Composite which can only have 1 child;
And the "ScrollBar" is a subclass of Primitive and can have no children.
It is quite possible (and often useful) to nest Composite widgets!
OLIT provides a variety of different "Manager" widgets (all subclasses
of Composite) which implement different types of sizing/layout policies
for children placed within them. It is up to the application to choose
the Manager widget which best fits the type of SubWindow layout in the
application. The different Manager widgets which are typically used to
layout SubWindows within an application window are:
-RubberTile: allows children to be tiled vertically or tiled
horizontally. Also allows a "weight" to be assigned to each child,
which designates the percentage of size change that child should absorb
if the window is resized.
-Form: allows children to be positioned relative to the the Form's edge,
or relative to each other. This allows children to grow and shrink
without ever overlapping each other.
-BulletinBoard: allows children to be placed at fixed x,y positions;
overlapping is allowed.
-ScrolledWindow: manages horizontal and/or vertical scrollbars &
scrolling for it's child (most commonly it's child is a DrawArea or
TextEdit, but it could also be another Manager....).
-FooterPanel: allows 2 tiled children - top child absorbs all height
changes. bottom child (footer), always remains the same height and
'floats' on the bottom.
OLIT Manager widgets have built in Geometry Management capabilities
which allow widgets to be added/removed dynamically while still
maintaining it's size/layout policy. There is no need for equivalents
to the XView "window_fit()", "window_fit_height()", "window_fit_width()
macros.
For more information on laying out Objects in a window, see:
-Pew/Young OLIT book, Section 4.3.3 "Manager Widgets"
-OLIT3.0 Reference Manual, "RubberTile(3w)","Form(3w)",
"BulletinBoard(3w)","ScrolledWindow(3w)", "FooterPanel(3w)"
......................................................................
XView: Canvas <-> OLIT: DrawArea Widget
The DrawArea widget provides a canvas & window which can be used to
render Xlib drawing. The application gets notification of expose &
resize events via it's XtNexposeCallback and XtNresizeCallback
callbacks. Xt Event handlers can be used to get input events such as
keyboard and mouse events. There is no separate concept of a
"paint_window" - in the OLIT DrawArea, the canvas and the paint_window
are the same object.
All pure Xlib code should be portable. To get a handle to the
DrawArea's window-id (drawable), use XtWindow().
The DrawArea itself does not include scrolling behavior, but both
vertical and horizontal scrolling can be easily obtained by creating the
DrawArea as a child of the ScrolledWindow widget. The ScrolledWindow
automatically manages the "view" of the actual canvas.
The size handling in a DrawArea is controlled by it's parent Manager
widget (i.e. different Managers will provide different sizing
behavior). See above section on "SubWindow".
OLIT does not support anything equivalent to the "OPENWIN" package
(different views into the same canvas; splittable views of the same
canvas; etc). It is however possible to create a "virtual" canvas, but
this must be implemented by the application by managing the scrolling in
the ScrolledWindow.
For more information on the DrawArea widget class:
-Pew/Young OLIT book, Section 4.3.3.3 "The DrawArea Widget"
-Pew/Young OLIT book, Section 9.3 "Example: A File Viewer"
-OLIT3.0 Reference Manual, pp.1-75 thru 1-79 "DrawArea(3w)"
......................................................................
XView: Panel <-> OLIT: ControlArea, Form or BulletinBoard
In OLIT, any Manager widget may contain panel-type items such as
buttons, textfields, sliders, etc, however certain Managers are commonly
used because of their size/layout policies:
-ControlArea: lays out children tiled in rows & columns (number of
rows/columns is specified via resources); does not resize it's children
in response to external resizes.
-Form: allows children to be positioned relative to the the Form's edge,
or relative to each other. This allows children to grow and shrink
without ever overlapping each other; children can be specified to be
resized or not upon external resizes.
-BulletinBoard: allows children to be placed at fixed x,y positions;
overlapping is allowed; does not resize it's children in response to
external resizes. XView only allows PANEL_ITEMS to be placed inside a
Panel while OLIT treats a panel like any other Manager widget - it can
contain virtually any type of widget (i.e. one could easily create a
mult-line text area (TextEdit), or small canvas (DrawArea) inside a
panel).
XView: Panel Items <-> OLIT: Primitive Widgets
One of the largest differences between XView and OLIT Panel objects is
that XView builds in the support for labels on these items via the
attribute, PANEL_LABEL_STRING, while OLIT requires the additional
creation of a widget to display a label. This is done by first creating
a Caption widget (setting XtNlabel to be the label string) and then
creating the panel item as the child of the Caption.
Below are the general mappings for Panel Items...
XView: PANEL_BUTTON <-> OLIT: OblongButton,MenuButton
OLIT provides 2 different widgets to implement push buttons with and
without the menu/menumark. In XView, a button becomes a menu button
when a menu is created and attached via an attribute. The OLIT
MenuButton creates the menu automatically and the application adds the
menu choices to it.
XView: PANEL_CHOICE <-> OLIT: Exclusives & Nonexclusives
XView treats a choice item as a single object with different choice
strings. In OLIT, a choice item is built by creating either an
Exclusives or Nonexclusives widget as the container and then creating
choice items as it's children. Choice item widgets include RectButtons
and CheckBoxes.
XView: PANEL_ABBREV_MENU_BUTTON <-> OLIT: AbbrevMenuButton
XView: PANEL_CHOICE_STACK <-> OLIT: AbbrevMenuButton
To get a PANEL_CHOICE_STACK equivalent to XView, one must build it in
OLIT by creating an AbbrevMenuButton (which automatically creates the
menu which the application adds the choices to) and then creating a
StaticText widget next to it to display the "current" value. The
application must make sure to update the StaticText "current" widget to
reflect changes in the choice.
XView: PANEL_LIST <-> OLIT: ScrollingList
XView: PANEL_MESSAGE <-> OLIT: StaticText
XView: PANEL_NUMERIC_TEXT <-> OLIT: No Equivalent
(note: a NumericField widget is planned for a future release of OLIT)
XView: PANEL_SLIDER <-> OLIT: Slider
XView: PANEL_GAUGE <-> OLIT: Gauge
XView: PANEL_TEXT <-> OLIT: TextField
To understand more about these Widgets, see:
-Pew/Young OLIT book, Section 4.3.2.X
-OLIT3.0 Reference Manual, "OblongButton(3w)", "MenuButton(3w)",
"AbbrevMenuButton(3w)", "Exclusives(3w)", "NonExclusives(3w)", "RectButton(3w)",
"CheckBox(3w)", "Slider(3w)", "Gauge(3w)", "Caption(3w)", "StaticText(3w)",
"TextField(3w)", "ScrollingList(3w)"
......................................................................
XView: Text Subwindow <-> OLIT: TextEdit
Both XView's Textsw package and OLIT's TextEdit widget provide much of
the same functionality (full window text editing ability) through
different APIs. To understand more about OLIT's API to manipulate the
text, see:
-Pew/Young OLIT book, Section 4.3.4.3 "The TextEdit Widget"
-OLIT3.0 Reference Manual, "TextEdit(3w)","textedit(3w)", "textbuffer(3w)"
In OLIT, to get horizontal and/or vertical scrolling for the TextEdit
widget, create it as the direct child of a ScrolledWindow.
OLIT's TextEdit default menu currently only supports the basic OPEN LOOK
edit operations (Cut,Copy,Paste,Undo), whereas XView's Textsw menu
supports a broad spectrum of operations including file loading/saving
(this must be programmed by the application in OLIT).
......................................................................
XView: TTY SubWindow <-> OLIT: NO Equivalent
......................................................................
XView: Menus <-> OLIT: MenuShell
The difference between OLIT and XView menus is similar to the difference
between their choice item object. XView treats the Menu as a single
object, within which item strings and callbacks are set, while OLIT
considers a menu to be a hierarchy of existing OLIT widgets.
In OLIT, menus are built by first creating a MenuShell (or
MenuButton/AbbrevMenuButton), then getting the widget ID of it's
menupane (via the XtNmenuPane resource) (note: this menupane is actually
just a controlarea widget created automatically by the MenuShell code).
Then, the application adds choice item widgets as children of the
menupane. Choice item widgets can be OblongButtons, MenuButtons (OLIT
will automatically implement a pullright in this case), or a choice
object (as described in above "PANEL_CHOICE" section above).
In OLIT, because the choice items are individual widgets, they can be
easily customized in both appearance and behavior. In order for the
application to get "called" when one of the items is selected, it needs
to set the appropriate callback on that item (i.e. for OblongButton,
it's the XtNselect callback).
It's simple to implement the equivalent of XView's Menu-generating procs
in OLIT. This can be done by registering an XtNpopupCallback procedure
on the MenuShell. This procedure will get called BEFORE the menu gets
popped up, allowing for dynamic creation of menus. If the menu is to be
destroyed on popdown, an XtNpopdownCallback can be registered on the
MenuShell - this proc will get called just AFTER the menu is popped
down.
For more detailed information on OLIT Menus, see:
-Pew/Young OLIT book, Section 4.3.6.2 "The MenuShell Widget"
-OLIT3.0 Reference Manual, "Menu(3w)","MenuButton(3w)"
......................................................................
XView: Notice <-> OLIT: NoticeShell
For information on OLIT Notices, see:
-Pew/Young OLIT book, Section 4.3.6.1 "The NoticeShell Widget"
-OLIT3.0 Reference Manual, "NoticeShell(3w)"
......................................................................
XView: Icon Package <-> OLIT: no equivalent
In OLIT, the method for setting an icon for an application is to create
either a bitmap or a window using standard Xlib, and then set one of the
following resources to point to that handle on the toplevel shell of the
application:
-XtNiconBitmap
-XtNiconWindow (See Q20 for example code)
......................................................................
XView: Nonvisual Objects <-> OLIT: Resources & Xt Routines
Xt/OLIT provides both routines and some widget resources to allow the
application to get handles on these X objects:
XView: XV_DISPLAY <-> OLIT: XtDisplay(widget)
XView: XV_SCREEN <-> OLIT: XtScreenOfObject(widget)
XView: SERVER Package <-> OLIT: no equivalent (must use Xlib)
......................................................................
XView: Server Image Package <-> OLIT: No equivalent
OLIT makes no abstraction about images stored in the server. In OLIT,
to create/manipulate such images, simply use Xlib Pixmap/Bitmap
routines.
To set images as labels for buttons in OLIT, create an XImage (using
Xlib) and set the XtNlabelImage resource on the button to point to that
image structure. Currently OLIT only supports Ximages (not Pixmaps) as
labels for buttons.
......................................................................
XView: Font Package <-> OLIT: No equivalent
OLIT makes no abstraction about the fonts accessible in the server. In
OLIT, there are essentially 3 methods for accessing fonts:
1. Use standard Xlib (XLoadQueryFont()) to get the handle to an
XFontStruct*. Then the handle to this structure can be passed as a
value to the resource, XtNfont.
2. Use the varargs interface for setting widget resources and take
advantage of Xt's built in fontname-string to XFontStruct* converter
(which does the loading for you):
XtVaSetValues(button, XtVaTypedArg, XtNfont, XtRString, "times-roman-14",
strlen("times-roman-14")+1, NULL);
3. Set the font outside the application using a resource file (this
also allows the user to customize the font!).
......................................................................
XView: CMS Handling <-> OLIT: No equivalent
OLIT makes no abstraction about the colors or colormaps. In OLIT, there
are essentially 3 methods for accessing and manipulating colors:
1. Use standard Xlib color routines to allocate/de-allocate colors.
2. Use the varargs interface for setting widget resources and take
advantage of Xt's built in colorname-string to Pixel converter (which
does the allocating for you):
XtVaSetValues(button, XtVaTypedArg, XtNbackground, XtRString, "blue",
strlen("blue")+1, NULL);
3. Set colors outside the application using a resource file (this also
allows the user to customize colors!).
DATE APPROVED: 10/02/95