chan@hpfcmgw.HP.COM (Chan Benson) (10/17/89)
I'm looking for some info about XView. o When is the next release of source? o Are there major changes from the alpha release planned? o Is anyone else out there attempting a port to a SYS V strain of Un*x? Basically I'm trying to decide whether to wait for the release with R4 before making major changes to workaround the hacked wait3 I get with HP-UX. -- Chan Benson HP Fort Collins chan@hpfcla.hp.com hplabs!hpfcla!chan
tomj@snowking.ebay.sun.COM (Tom Jacobs) (10/24/89)
Chan Benson writes: > I'm looking for some info about XView. > > o When is the next release of source? We're hoping to update expo in about four weeks. This will be equivalent to the R4 donation. > o Are there major changes from the alpha release planned? The most major change will be the expansion of XView semantic event structure to include the XEvent that caused the semantic event. New semantic VUID-type events will be added for the XEvent types not previously exposed. > o Is anyone else out there attempting a port to a SYS V > strain of Un*x? Yes, there is a generic SVR4 port that is part of SVR4 from AT&T and there is also a SVR3.2 port in the works. > Basically I'm trying to decide whether to wait for the release with > R4 before making major changes to workaround the hacked wait3 I get > with HP-UX. > > -- Chan Benson > HP Fort Collins > chan@hpfcla.hp.com > hplabs!hpfcla!chan I'd suggest waiting a few more weeks until we update EXPO with the R4 donation. I couldn't find any mail from you about your wait3() hack in our xviewbugs@sun.com mail archive. Please forward that hack and we'll see if we can find an acceptable work-around. Thanks! Tom Jacobs (tomj@sun.com -or- ..!sun!tomj) Sun Microsystems, Inc. Mountain View, CA
johnson@epiwrl.EPI.COM (Rod Johnson) (11/29/89)
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. 20003james@apollo.gl.pitt.edu (05/31/90)
I am working on a graphics project and I am using Xview. I have the OReilly book on xview which has helped alot, but I am having problems with colormaps, using static and dynamic colormaps. Basically I am trying to load up an image, whether it be a rasterfile or some other format isn't really the problem. How can I do this efficiently. Other than setting each pixel with XDrawPoint and changing the foreground for each pixel. I started looking at the xloadimage source, but there is a lot to look through. Does anyone know where I can get the xviewsun source.? I seem to have deleted the source and kept the binary. I think this would be helpful. Or has anyone worked with something similar with xview. Loading a rasterfile on a canvas with a specified colormap... Please send mail to: james@apollo.gl.pitt.edu Thanks, Douglas
jimf@SABER.COM (05/31/90)
| Does anyone know where I can get the xviewsun source.? I'm pretty sure the xviewsun you're talking about was part of my original xbgsun distribution. Xloadimage was supposed to replace xbgsun/xviewsun since there were several flaws in its color handling and image transfer functions. If you really want the source I still have it archived but I don't think it'd be a good teacher. Xloadimage is much better, although it doesn't support TrueColor or DirectColor displays. The apropos code for color handling is all in send.c. There's really not very much. The idea is to try the following in sequence: * try to allocate all needed colors shareable. * if we can't do that and it's a dynamic visual type, create a new colormap. * allocate as many colors as we need or can allocate read/write. * if this fails, modify the image to fit the number of colors we allocated. The code which does this, simplified somewhat, follows (this hasn't been compiled and tested, don't be surprised if something isn't quite right). This doesn't do colormap reduction and assumes you want to use the default visual. -- cut here -- /* code to handle allocation of color entries. this assumes that * COLORMAPSIZE is the size of the colormap you want and you have * red[] green[] and blue[] arrays describing your colormap. disp * and scrn are the X display and screen indicators. */ Visual *visual; unsigned long xpixel[COLORMAPSIZE]; /* array of pixel values X gave us */ XColor xcolor; Colormap cmap; int pixel, b; visual= DefaultVisual(disp, scrn); cmap= DefaultColormap(disp, scrn); xcolor.flags= DoRed | DoGreen | DoBlue; /* these are the only visuals that this code supports */ switch(visual->class) { case PseudoColor: case GrayScale: case StaticColor: case StaticGray: break; default: printf("sendImageToX: unsupported display visual\n"); exit(1); } /* allocate colors shareable (if we can) */ for (pixel= 0; pixel < COLORMAPSIZE; pixel++) { xcolor.red= red[pixel]; xcolor.green= green[pixel]; xcolor.blue= blue[pixel]; if (! XAllocColor(disp, cmap, &xcolor)) if ((visual->class == StaticColor) || (visual->class == StaticGray)) { printf("sendImageToX: XAllocColor failed on a static visual\n"); exit(1); } else { /* shareable color allocation failed. free allocations we had made * and allocate a private colormap. */ for (b= 0; b < pixel; b++) XFreeColors(disp, cmap, xpixel[b], 1, 0); cmap= XCreateColormap(disp, RootWindow(disp, scrn), visual, AllocNone); /* find allocate read/write color cells and count how many we have */ for (pixel= 0; pixel < COLORMAPSIZE; pixel++) if (!XAllocColorCells(disp, cmap, False, NULL, 0, &xpixel[pixel], 1)) break; if (pixel < COLORMAPSIZE) { printf("Can't allocate enough colors!\n"); exit(1); } /* store image colors in private colormap */ for (b= 0; b < pixel; b++) { xcolor.pixel= xpixel[b]; xcolor.red= red[b]; xcolor.green= green[b]; xcolor.blue= blue[b]; XStoreColor(disp, cmap, &xcolor); } break; } xpixel[pixel]= xcolor.pixel; } /* at this point cmap will be the appropriate colormap and xpixel will * map the current pixel values to the pixel values you should use * when talking to the server. */ -- cut here -- If you're doing image processing, you have to modify your image's pixel values to match the new colormap. The code to do this and to transfer the image to a pixmap is also in send.c. I hope this is useful, jim frost saber software jimf@saber.com
kbj@JUPITER.RISC.COM (Ken Johnson) (10/11/90)
I've created a frame which contains a panel and a canvas. I want the
panel to behave like an apple menubar. SO far I've gotten the canvas working
and two menu buttons in the panel. The problem is that the panel/menubar
is huge and make the window look like crap. I tried window_fit on the
panel and the frame and that doesn't help. ANy suggestions to shrink the
panel without having to hand code the size of the buttons and stuff?
/* ------------------------------------------------------------------------- */
Ken Johnson Phone: 805-373-4487
Rockwell International Science Center Comnet: 273-4487
1049 Camino Dos Rios A-18 e-mail: kbj@risc.com
Thousand Oaks, CA 91360
If enough data is collected,
anything may be proven by statistical methods....
/* ------------------------------------------------------------------------- */cflatter@ZIA.AOC.NRAO.EDU (Chris Flatters) (10/11/90)
Ken Johnson writes: > I've created a frame which contains a panel and a canvas. I want the > panel to behave like an apple menubar. SO far I've gotten the canvas working > and two menu buttons in the panel. The problem is that the panel/menubar > is huge and make the window look like crap. I tried window_fit on the > panel and the frame and that doesn't help. ANy suggestions to shrink the > panel without having to hand code the size of the buttons and stuff? The window_fit macro (actually window_fit_height is more appropriate here) is equivalent to: xv_set (panel, WIN_FIT_HEIGHT, 0, WIN_FIT_WIDTH, 0, NULL); the WIN_FIT attributes take the margin to leave around the window contents. Zero is a special value which instructs XView to choose its own margin. It seems rather conservative in doing this. You should try setting WIN_FIT_HEIGHT explicitly rather than using the macros. xv_set (panel, WIN_FIT_HEIGHT, 1, NULL) will get you the narrowest possible panel. The margins above and below the buttons will be the same as for the OpenWindows file manager or mail tool. Chris Flatters