Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!cs.utexas.edu!uunet!epiwrl!johnson
From: johnson@epiwrl.EPI.COM (Rod Johnson)
Newsgroups: comp.windows.x
Subject: XView questions
Keywords: XView
Message-ID: <3011@epiwrl.EPI.COM>
Date: 28 Nov 89 22:35:32 GMT
Organization: Entropic Processing, Inc., Washington, DC
Lines: 123


    I am in the midst of porting abaout a 30,000-line application from
SunView to XView.  I have run into some problems or have some questions
on the the following topics
        pixrects,
        menus (new menu_show() behavior),
        event_window(),
        demise of WIN_CLIENT_DATA,
        possible bug related to input event distribution,
and I am looking for help in getting some advice or answers.

    Here is a bit of background before I plunge into details.
    I have been working under the OpenWindows 1.0 Beta2 release, using the
"Converting SunView to XView" and "Summary of the XView API" manuals (with
frequent references to the "SunView Programmer's Guide").  I have written
some SunView code, including some of what is in the application I am porting;
however, my knowledge of SunView is fairly spotty, and much of the application
code was done by someone else.  This is my first brush with XView.  I've
written a little X11 code but am considerably less familiar with Xlib than
with SunView.
    The application is an interactive signal viewer/editor/manipulator for
signal-processing applications, with fairly heavy emphasis on speech.
It lets you dynamically bring up windows with various views of signals and
other data in various files.  There are a couple of dozen operations that can
be performed on a signal or a view of a signal, including zooming, scrolling,
rescaling, or marking the plot; audio playback; cut-and-paste editing
operations on the signal; and spectrogram computation.  Most of these are
invoked by first using a mouse button to bring up a menu in a window
displaying the signal, and then selecting an item from the menu.  If the
operation alters the actual signal, then all windows containing views of the
signal have to be updated.  To complicate matters further, the main program
can start up a special-purpose auxiliary program (one of several) called an
"attachment", which runs as a separate process and communicates with the main
program via pipes.  The main program and the attachment can both be
maintaining windows with coordinated views of the same signal, and selecting
a menu item in a window maintained by one program can require action in a
window maintained by the other.

    Pixrects.
    The conversion manual (section 1.13) says, "XView supports, but does not
_require_, pixrects, and is implemented purely on top of X11."  That is
ambiguous enough that it might mean that XView will supply the necessary
functionality to let code that uses pixrects run without change on non-Sun
platforms.  I suspect, however, that for portability I will be forced to
convert from using pixrects to using Xlib pixmaps or server pixmaps or some
such.  Can someone confirm whether that is the case?  I have seen a copy of a
message referring to a posting to comp.windows.x containing a guide to
converting pw_*() calls to Xlib.  The guide itself has disappeared from our
system.  Is there any chance of getting a copy?

    Menus.
    The new behavior of menu_show() has called for some reorganization,
the scope of which is still to be determined.  The existing implementation
uses the MENU_VALUE attribute of each menu item to hold a pointer to a
function for performing the required operation.  The function has the same
interface as an event_proc:  proc(canvas, event, arg).  When you click the
right mouse button in a window, the actual event_proc that fields the button
click does essentially this:

        menu = window_get(canvas, WIN_MENU);
        proc = (void (*)()) menu_show(menu, canvas, event, 0);
        proc(canvas, event, arg);

where (canvas, event, arg) are the same arguments with which the event_proc
itself was called.  Apparently this was not done originally with a
MENU_ACTION_PROC because one menu is shared by several windows, and the
procedure that is called has to be able to determine which window to operate
on.  Since the arguments to the action_proc are just (menu, menu_item), it
was not clear under SunView that an action_proc could determine the identity
of the window.  Under XView, as a stopgap, I have tried setting an action_proc
that essentially does:

	event = vu_get(menu, MENU_FIRST_EVENT);
	window = event_window(event);
	canvas = vu_get(window, CANVAS_PAINT_CANVAS_WINDOW);
	proc = (void (*)()) vu_get(menu_item, MENU_VALUE);
	proc(canvas, event, 0);

This seems to work well enough when the asynchrony between the menu_show()
and the calling of the event_proc is not an issue.  I can imagine problems
that might make it necessary to make a separate copy of the menu for each
window, but then it would become awkward to add and delete menu items
dynamically (which is sometimes necessary).  The biggest complication is
with the attachments, where the sequence of messages and acknowledgements
between the main program and the attachment may be altered; I may have to
rework the message protocol more extensively than I would prefer.  Before
I do that, I would therefore like to know whether I am overlooking a
straigntforward way to mimic the old menu behavior using the new facilities.

    event_window().
    I found this macro by poking around in include files and haven't found
any documentation for it in the API or conversion manual.  Is this a supported
feature or something I shouldn't be using?

    WIN_CLIENT_DATA.
    The application uses this attribute to get from a window to the signal
data being displayed in it.  The conversion guide lists this as a
"compatibility attribute", due to disappear in a future release.  I would
like to avoid the complication of creating and maintaining an association
table linking windows with their data; this would have to be updated
wherever the existing program updates the value of WIN_CLIENT_DATA, and
wherever it destroys or creates a window.  The arbitrary key-data storage
mentioned for generic objects in the "New Features" chapter of the conversion
manual sounds as though it might be what I'm looking for; I suppose this
refers to the new VU_KEY_DATA attributes listed under "VU_Generic and Common
Attributes."  Is any more information available on this topic?

    Input event distribution.
    Each window in the application contains a horizontal coordinate marker
that tracks the cursor position when the cursor is in the window.  In the
partially working XView version of the program, I have noticed that by holding
a mouse button down, I can move the cursor entirely out of the window, well
past the frame, and the marker continues to track the horizontal coordinate of
the cursor.  It is though the window continues to recieve LOC_DRAG events
when the cursor is no longer in the window.  Nowhere does the program refer
to WIN_GRAB_ALL_INPUT.  Is this behavior a known bug in OpenWindows?

Thanks!

Rod Johnson                                             johnson@wrl.epi.com
Entropic Speech, Inc. Washington Research Lab.          uunet!epiwrl!johnson
600 Pennsylvania Ave. S.E. Suite 202
Washington, D.C.  20003