geb@amber.Rational.COM (Gary Barnes) (02/02/90)
My application has a popup menu. That menu is implemented as a transientShellWidget. This all works just fine. What I want to do is to give the user the option of making the popup menu a permanent window on his screen. I want to de-transient the transientShell. What I've tried is to turn off override_redirect and then do a PopUp. This gets the window onto the screen but the window is still not a "real" permanent window. This is best illustrated by an open-look type window manager. The window is decorated by a push-pin which means that the user just clicks on the push-pin and the window goes away. I've also tried turning off the WM_TRANSIENT_FOR property but that hasn't made any difference. I looked in the ICCCM but didn't find anything that seemed to indicate that this was expected/possible behavior for a window. Question: Can I, and how can I, turn an existing transientShellWidget window into the equivalent of an applicationShellWidget window? Is this supported or even allowed under ICCCM? I'd just destroy the menu widgets and recreate them differently if a) it were not so very "expensive" in time to do so (about 10 seconds) and b) if certain vendor implementations of the Xt intrinsics didn't belly up when you did an XtDestroy on anything more complicated than a single widget. Hints? Suggestions? Gary E. Barnes geb@rational.com
kit@EXPO.LCS.MIT.EDU (Chris D. Peterson) (02/03/90)
> My application has a popup menu. That menu is implemented as a > transientShellWidget. This all works just fine. > What I've tried is to turn off override_redirect and then do a PopUp. Transients should not set overrideRedirect (By default), so turning this off should have no effect. > I've also tried turning off the WM_TRANSIENT_FOR property but that hasn't > made any difference. The ICCCM only requires window managers to look at these properties on a mapping transition. Have you tried to change the properties, and then unmap/remap the window? > I'd just destroy the menu widgets and recreate them differently... You could have two copies of your menus, and only show one. Expensive in memory, but it would be fast. Chris D. Peterson MIT X Consortium Net: kit@expo.lcs.mit.edu Phone: (617) 253 - 9608 Address: MIT - Room NE43-213
hvr@kimba.Sun.COM (Heather Rose) (02/04/90)
In article <597@igor.Rational.COM> geb@amber.Rational.COM (Gary Barnes) writes: > >What I want to do is to give the user the option of making the popup menu a >permanent window on his screen. I want to de-transient the transientShell. > >window. This is best illustrated by an open-look type window manager. >The window is decorated by a push-pin which means that the user just clicks on >the push-pin and the window goes away. The way the OpenLook XView toolkit deals with this is different for specific situations and implementations. If the application programmer has a static menu, then the code below is all the programmer needs to do to generate a pinnable menu. If you have a dynamic menu, then the process becomes a bit more involved. But for these purposes, a static menu case is sufficient. The method to generate the pinned menu would be all the application programmer would need to worry about in the case of the XView toolkit. The ability to pin a menu is supplied by the toolkit. Then it is the toolkit which implements the optimal solution for the current working environment. For example, I'll elaborate on how XView approaches the time versus space problem of pinnable menus. In the 1.0 and 1.0.1 implementation of XView, it will create the command frame for your pinned menu when the menu is created. This was done because the servers X11R3 and OpenWindows 1.0 were not quite fast enough to generate the popup frame on the fly. To save time, we chose to use space. In the 1.1 implementation of XView, it will create the command frame when the menu is pinned. This was done because the servers, X11R4 and OpenWindows 1.1 are fast enough to generate the popup frame on the fly. So here we chose to use time to save space since time is now cheaper. Since XView does not use an X11 window for each button created, this was a reasonable thing to do. However, if your toolkit creates each button as a window, the issue needs to be re-visited. In summary, you face a typical time versus space trade off. And the solution you choose has as much to do with your working environment outside the application as within it. Regards, Heather -------------------------- The XView toolkit is supplied with X11R4 in the contrib section. This example is taken from the O'Reilly XView Programmer's Manual. It can be found on line with the XView toolkit source in XView/clients/examples. /* * xv_menu.c - * Demonstrate the use of an XView menu in a canvas subwindow. * Menu is brought up with right mouse button and the selected * choice is displayed in the canvas. Allows menu to be pinned. */ #include <xview/xview.h> #include <xview/canvas.h> Frame frame; main(argc,argv) int argc; char *argv[]; { Canvas canvas; Menu menu; void my_notify_proc(), my_event_proc(); extern void exit(); xv_init(XV_INIT_ARGC_PTR_ARGV, &argc, argv, NULL); frame = (Frame)xv_create(NULL, FRAME, FRAME_LABEL, argv[0], NULL); canvas = (Canvas)xv_create(frame, CANVAS, XV_WIDTH, 300, XV_HEIGHT, 200, NULL); menu = (Menu)xv_create(NULL, MENU, MENU_TITLE_ITEM, "Junk", MENU_STRINGS, "Yes", "No", "Maybe", NULL, MENU_NOTIFY_PROC, my_notify_proc, MENU_ITEM, MENU_STRING, "Save", MENU_NOTIFY_PROC, my_notify_proc, MENU_PULLRIGHT, xv_create(canvas, MENU, MENU_GEN_PIN_WINDOW, frame, "Save", MENU_ITEM, MENU_STRING, "Update Changes", MENU_NOTIFY_PROC, my_notify_proc, NULL, NULL), NULL, MENU_ITEM, MENU_STRING, "Quit", MENU_NOTIFY_PROC, exit, NULL, NULL); xv_set(canvas_paint_window(canvas), WIN_CONSUME_EVENTS, WIN_MOUSE_BUTTONS, NULL, WIN_EVENT_PROC, my_event_proc, /* associate the menu to the canvas win so we can retrieve it easily */ WIN_CLIENT_DATA, menu, NULL); window_fit(frame); window_main_loop(frame); } /* * my_notify_proc - Display menu selection in frame header. */ void my_notify_proc(menu, menu_item) Menu menu; Menu_item menu_item; { xv_set(frame, FRAME_LABEL, xv_get(menu_item, MENU_STRING), NULL); } /* * my_event_proc - Call menu_show() to display menu on right mouse button push. */ void my_event_proc(window, event) Xv_Window window; Event *event; { if (event_action(event) == ACTION_MENU && event_is_down(event)) { Menu menu = (Menu)xv_get(window, WIN_CLIENT_DATA); menu_show(menu, window, event, NULL); } }
marbru@auto-trol.UUCP (Martin Brunecky) (02/04/90)
In article <131190@sun.Eng.Sun.COM> hvr@sun.UUCP (Heather Rose) writes: >In article <597@igor.Rational.COM> geb@amber.Rational.COM (Gary Barnes) writes: >> >>What I want to do is to give the user the option of making the popup menu a >>permanent window on his screen. I want to de-transient the transientShell. >>window. This is best illustrated by an open-look type window manager. >>The window is decorated by a push-pin which means that the user just clicks on >>the push-pin and the window goes away. Open Look calls it push-pin menus, some other people call it tear-off-menus, and some others may have other names. We consider the ability to change popup menu into a static one (Override shell -> Transient shell) very importatnt (our applications tend to have large and complex menu trees) Since we base our solutions on Xt (and Motif), we can not rely on Open Look WM or XView. Rather, we have implemented our own solution. Basically, to tear-off a part of menu cascade, we reparent the composite widget (menu) from original override shell (menushell) to a new transient shell. And the same when going backwards - note, we'w popped-down the override shell when we "stole" it's menu. Now, since the whole transition is user controlled, we must add a tear-off button (togglebutton), and some callbacks since the application may want to know what happened. I posted my fragment of reparenting code here a while ago, however, there is a little bit more to it - like a shell with a ter-off button and callbacks. Now, I would like to use my approach with Motif menus and shells (existing code uses our own widgets, R3 based). Unfortunatelly, it won't be that easy, because of the way Motif does business with menu cascades and shells in particular (I just wish they were not trying to be that much smarter than Intrinsics). > -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=* Martin Brunecky marbru@auto-trol.COM (303) 252-2499 {...}ncar!ico!auto-trol!marbru Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404
asente@decwrl.dec.com (Paul Asente) (02/06/90)
A far easier way to do this is to create menus that are potentially permanent in transient shells with the XtNoverrideRedirect resource TRUE. To make the menu permanent, make XtNoverrideRedirect FALSE. -paul asente asente@decwrl.dec.com decwrl!asente
marbru@auto-trol.UUCP (Martin Brunecky) (02/07/90)
In article <2674@bacchus.dec.com> asente@decwrl.dec.com (Paul Asente) writes: >A far easier way to do this is to create menus that are potentially permanent >in transient shells with the XtNoverrideRedirect resource TRUE. To make the >menu permanent, make XtNoverrideRedirect FALSE. > That's RIGHT. Unfortunatelly, most of us use toolkits which don't give us too much freedom of shell choice. Motif, for example, creates "hidden" shells behind our back ( this aparently came from XUI ) which are "shared" between multiple submenus. If I'd make such a menu permanent (tear-off), other submenu activation would fail badly. In addition, override shells (used for menus) do not handle all the properties used by transient shells. Plus, in Motif world, I can not substitute any other shell for Motif's XmMenuShell, since the entire menu system has heavy dependencies on this shell (and simply dies without it). [ I don't blame Intrinsics; I just have to live in an imperfect word of toolkits which "improved" Intrinsics ]. -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=* Martin Brunecky marbru@auto-trol.COM (303) 252-2499 {...}ncar!ico!auto-trol!marbru Auto-trol Technology Corp. 12500 North Washington St., Denver, CO 80241-2404