laymon@nepal.steinmetz (Marc A Laymon) (06/28/88)
I want to create a popup menu which acts like a SunView menu, i.e. active while right
button is down, select on right button up. I have been using the (??HP??) menu widget,
which has the default behavior of active with all buttons up and select when the left
button is pressed and released. I tried to change the behavior to what I want using
XtParseTranslationTable and XtOverrideTranslations but this did not to work. I have
created my own graphic widget which pops up my menu when the right button is pressed
and unpops it when the right button is released. However, this causes the widget
(== window) to be redrawn, losing the contents, even though I have SaveUnder set to
true for my popup shell and menu widget. Losing the widget contents also happens if I
resize the outermost window. (I am using TWM.) I would like to be able to save and
restore the random contents of my graphic window, but can't seem to find such functions
in the X documentation. I tried using XCreatePixMap and XCopyArea, but I am not sure
what the arguments for XCopyArea should be. A PixMap for the source and the window for
the destination ?
Can anyone tell me how to get the behavior I want ? My code to create the popup menu
is shown below. Thanks in advance.
/*******************************************************************
*/
void create_popup_menu ()
{
extern XtTranslations XtParseTranslationTable () ;
XtTranslations new_translation ;
Arg widget_args[10];
static MenuItemsList menu_list[] =
{
{"COMPLETE", command1_callback, (caddr_t) 0, 0},
{"SPAWN", spawn_graphics_window, (caddr_t) 0, 0},
{"EXIT", quit_callback, (caddr_t) 0, 0},
{NULL, NULL, NULL, NULL}
} ;
static Arg menu_list_args[] =
{
{XtNmenuItemsList, (XtArgVal) menu_list }
} ;
static char my_default_translations[] =
"Button3<EnterWindow>: highlight() \n\
Button3<LeaveWindow>: unhighlight() \n\
<Btn3Up>: notify()" ;
static XtActionsRec actionsList[] =
{
{"highlight", MyHighlight},
{"unhighlight", MyUnhighlight},
{"notify", MyNotify}
} ;
g_menu_popup = XtCreatePopupShell ("demo menu",
shellWidgetClass,
g_toplevel,
NULL, 0);
XtSetArg (widget_args[0], XtNsaveUnder, 1) ;
XtSetValues (g_menu_popup, widget_args, ONE) ;
g_my_menu = XtCreateManagedWidget ("mylist",
menuWidgetClass,
g_menu_popup,
(ArgList) menu_list_args,
XtNumber (menu_list_args));
new_translation = XtParseTranslationTable (my_default_translations) ;
XtSetArg (widget_args[0], XtNsaveUnder, 1) ;
XtSetValues (g_my_menu, widget_args, ONE) ;
XtOverrideTranslations (g_my_menu, new_translation) ;
g_my_menu->core.widget_class->core_class.actions = actionsList ;
g_my_menu->core.widget_class->core_class.num_actions = XtNumber (actionsList) ;
} /* end CREATE_POPUP_MENU */
Marc Laymon ARPANET: laymon@nepal.steinmetz.ge.com
GE Corp. R&D USENET: steinmetz!nepal!laymon
Schenectady, NYRWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) (06/28/88)
Date: 27 Jun 88 22:30:42 GMT
From: steinmetz!nepal!laymon@itsgw.rpi.edu (Marc A Laymon)
Losing the widget contents also happens if I
resize the outermost window.
This is a known misfeature of current MIT servers.
I would like to be able to save and
restore the random contents of my graphic window, but can't seem to find such functions
in the X documentation.
Save-under and backing-store are the right thing to use. Unfortunately, most
servers don't yet support them. The correct solution is to beat on server
implementors, or pitch in and contribute server code.pds@quintus.uucp (Peter Schachte) (06/30/88)
In article <19880628120158.9.RWS@KILLINGTON.LCS.MIT.EDU> RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) writes: > I would like to be able to save and > restore the random contents of my graphic window >Save-under and backing-store are the right thing to use. Unfortunately, there's a flaw with backing store: you can't insist on it. So when you write your application, you have to allocate your own bitmap to back up your window, and have to blt it to the window every time it changes. The server could implement backing store much more efficiently, since IT knows when part of your window is going to be obscured, and can copy out the contents first. User programs can't do that, so they have to keep their own backing bitmap up-to-date all the time. Am I missing something? Is there a better way to maintain a window that's too complex for display lists? Is there a reason the server can't do backing store as efficiently as I've indicated? -Peter Schachte pds@quintus.uucp ..!sun!quintus!pds
RWS@ZERMATT.LCS.MIT.EDU (Robert Scheifler) (06/30/88)
Date: 29 Jun 88 20:20:29 GMT
From: quintus!pds@unix.sri.com (Peter Schachte)
Unfortunately, there's a flaw with backing store: you can't insist on
it.
You can't insist on it because there are servers out there (e.g., the
X terminal that was being shown at Usenix) with a fixed amount of
memory, and they simply can't commit to all backing store requests.diamant@hpfclp.SDE.HP.COM (John Diamant) (07/02/88)
> Unfortunately, there's a flaw with backing store: you can't insist on > it. > > You can't insist on it because there are servers out there (e.g., the > X terminal that was being shown at Usenix) with a fixed amount of > memory, and they simply can't commit to all backing store requests. Yes, that's true. Unfortunately, that makes it considerably less useful than it would be otherwise. If you have an application that needs backing store or something like it to run effectively (a paint program that allows arbitrary pixels to be turned on and off is an example) then you are forced to maintain your own backing store via pixmaps and/or images, since you can never be assured that the server will honor your backing store. That means even if it has the memory and will honor all uses of it, you still have to manange your own duplicate copy. That's a waste of time and resources (though you still get the benefit of the server's ability to be more efficient in handling it when it can). What might help would be a way to ask the server to reserve backing storage space for a particular window such that it could decide at the beginning whether it had the maximum space required and reserve it right then. If it refuses (whether it had the space or not), then the application could fall back to the local maintenance approach. This would avoid the redundancy for most servers (workstations with large virtual memory). John Diamant Software Development Environments Hewlett-Packard Co. ARPA Internet: diamant@hpfclp.sde.hp.com Fort Collins, CO UUCP: {hplabs,hpfcla}!hpfclp!diamant
dshr@SUN.COM (David Rosenthal) (07/04/88)
> That means even if > it has the memory and will honor all uses of it, you still have to manange > your own duplicate copy. That's a waste of time and resources (though you > still get the benefit of the server's ability to be more efficient in > handling it when it can). > That's also the way to make sure that your application will work across a wide range of server implementations. Making applications portable and inter-operable is never free - but customers in general prefer the products whose developers paid these costs. David.
diamant@HPFCLP.SDE.HP.COM (John Diamant) (07/05/88)
> > That means even if > > it has the memory and will honor all uses of it, you still have to manange > > your own duplicate copy. That's a waste of time and resources (though you > > still get the benefit of the server's ability to be more efficient in > > handling it when it can). > That's also the way to make sure that your application will work across a > wide range of server implementations. No, it's worse than that. If servers were required to tell you whether they would provide backing store for a particular window, then applications could use that information wisely. The server would still be at liberty to refuse (for reasons of its own, including no backing store implemented) and the application would have to fall back to making its own. So, it would be just as portable as now. However, with the present situation, backing store doesn't prevent the application writer from duplicating the work already being done by the server, because he has no way of knowing whether the server will come through. That doubles the memory requirement for any use of backing store (one copy maintained by the server and one by the client), which severely limits its utility. > Making applications portable and > inter-operable is never free - but customers in general prefer the products > whose developers paid these costs. I never suggested anything that wasn't portable or inter-operable. Customers don't like software that is slow and a memory hog, which is the result of attempting to use backing store in the present protocol. All that it requires is that servers be up front and commit to how much (if any) backing store they will maintain. If the answer is none, that's fine. John Diamant Software Development Environments Hewlett Packard Co. ARPA Internet: diamant@hpfclp.sde.hp.com Fort Collins, CO UUCP: {ihnp4!hpfcla,hplabs}!hpfclp!diamant