dheller@cory.Berkeley.EDU (Dan Heller) (08/21/88)
Yes, once again, we revisit the problems with transient shell widgets. for some reason, they are always positioned at 0,0 on the display regardless of any and all efforts attempting to create or move them to other places. I know that there was once a discussion about this several weeks ago, but I unfortunately missed the outcome of the discussion (if anything was resolved). There was a program posted about the same time which demonstrated how one would use popup shells and it was very helpful, but it used an override shell widget. If you simply rename it to use the transient shell widget, then you'll see the problem I'm describing -- the shell is mapped at 0 0 rather than the position indicated. In an attempt to see a program which used transient shell widgets, I did a grep in the contrib tree (as distributed by the source we received) and found that "xman" was the only program which tried to make use of it. So, I ran the program and got the transient shell to come up -- and guess where it mapped itself? You got it -- I really need to know what the reason for this is and try to fix it because it is appearing to cause other windows to do the same thing! Consider the following... I have a main application which contains a basic "core" widget (to draw graphics into) and a widget above it which has a callback to display an RLTMenu-type menu. One of the items in that menu will call a function to create a popup widget of type transient or override shell widget ... This widget contains a box widget which contains two label widgets, and a command widget. Everythng acts as described: the transient shell appears at 0,0 if it gets created (e.g. you have to select the menu item). However, the thing that really is ruining things is that if I have this transient shell widget contain a particular widget type (which I wrote, but it's similar to the viewport widget), then when the main application gets created and mapped onto the screen, that *application* gets mapped to 0,0! HUH!? I haven't even called XtPopup or anything yet. I did an XtCreatePopup... but haven't realized it or used any routines which reference it or any of its children. Note, this *only* happens if this transient shell contains this special widget once.. How can *anything* inside of a transient shell widget cause the main application to be physically moved to 0,0? This is why I'm suspicious that whatever is causing the transient shell to get mapped to 0,0 regardless of all efforts otherwise is affecting other widgets. Dan Heller <island!argv@sun.com>
rlh2@eagle.ukc.ac.uk (Richard Hesketh) (08/23/88)
In Article 4540 of comp.windows.x, Dan Heller writes: > .. >Yes, once again, we revisit the problems with transient shell widgets. >for some reason, they are always positioned at 0,0 on the display .. I have just finished a set of routines which create popup and static menus from a editor created description file. I can have fixed popups or cursor relative popups. For two particular types of menu buttons I use the following translations: /* for buttons of static menus which pop up fixed position menus */ static String fp_sButtonTranslations = "<Btn1Down>: popdown(%d) set() notify() set_popup(%d %d) MenuPopup(%s)"; /* for buttons of static menus which pop up cursor relative menus */ static String cr_sButtonTranslations = "<Btn1Down>: popdown(%d) set() notify() set_popup(%d %d TRUE) MenuPopup(%s)"; The popdown() action pops down any popup menus at this current menu level. The set_popup() action basically just positions the popup menu relative to the button which popped it up (ah!). The MenuPopup() action is registered by the shellWidgetClass and pops up and realizes the named (hence the %s) Shell widget. set_popup() ... offset_x = is_relative ? event->xbutton.x + shell_x : shell_x; offset_y = is_relative ? event->xbutton.y + shell_y : shell_y; XtTranslateCoords(w, offset_x, offset_y, &x, &y); #ifndef SHELL_BUG XtMoveWidget(popupshell, x, y); #else XtSetArg(args[0], XtNx, x); XtSetArg(args[1], XtNy, y); XtSetValues(popupshell, (ArgList)args, 2); #endif --- w is the menu button widget who wants to popup a sub-menu. popupshell is the popup widget already created previously using XtCreatePopupShell(). is_relative is set TRUE if "TRUE" is passed as a third parameter. XtTranslateCoords() returns the root relative x and y positions of w + the offsets given as the second and third parameters. If is_relative is TRUE then the popup is treated as cursor relative and the offsets are calculated from the current position of the cursor. At the moment there is a bug in the Shell code so you cannot do a XtSetValues() and change the original created position. Until it is fixed in R3 use XtMoveWidget() as indicated above. > >There was a program posted about the same time which demonstrated how one >would use popup shells and it was very helpful, but it used an override >shell widget. If you simply rename it to use the transient shell widget, >then you'll see the problem I'm describing -- the shell is mapped at 0 0 >rather than the position indicated. > There was a bug in that program in the positioning routine but if I remember right it was to do with passing parameters. I use both transient and override shells depending on whether I need static or dynamic popup menus. I've just changed all "overrides" to "transients" and everything worked *identically*. > >I really need to know what the reason for this is and try to fix it >because it is appearing to cause other windows to do the same thing! > .... > It is strange what you describe. I cannot simulate your problem so I have no good answer except that you try the positioning and then do a MenuPopup() and see what happens then. Somewhere along the line a geometry request is being made to the applications toplevel shell and the window manager is allowing a reposition. I suspect it could have something to do with your own viewport type of widget. Has it a geometry manager which makes geometry requests if it feels it needs to be bigger or in a different position? Does your widget feel that it *must* always be at 0,0 ? >Dan Heller <island!argv@sun.com> ---- One thing though. Under uwm (I haven't tried other window managers) the transient widget don't behave as advertised. They don't get iconised when the application is iconised. A bug? I hope the above is of some help. More info can be obtained directly from me. Has anybody else got routines to generate menus from description files. In other words are there any public domain menu editors out there? -- Richard Hesketh : rlh2@ukc.ac.uk {backbone}!mcvax!ukc!rlh2 --- Computing Lab., University of Kent at Canterbury, Canterbury, Kent, CT2 7NF, England.