rlh2@ukc.ac.uk (Richard Hesketh) (04/08/90)
The following test program shows up a problem when it comes to knowing
where shells are positioned in Xt.
Compile the program with
cc -o postest postest.c -lXaw -lXmu -lXt -lXext -lX11
.. and run it with the following ..
postest -geometry +200+200
Now press the button. What value do you get printed? Under twm
(X11R4-no fixes), for me, the following is printed:
Position of toplevel returned by GetValues() = +202+221
Now this is not what I gave it! Infact this is the *real* position of
the toplevel window on the screen.
Who is correct? Is the toolkit correct for returning the absolute
position on the screen or should it return the *real* geometry .. taking
into account that the window manager has reparented the window and
decorated it (I know the shellWidget knows about reparenting already) ?
Is the window manager correct in moving my window down and to the left to make
way for its decorations?
I ask this because I have an application that needs to save state and wants
to know where it is so that next time it is started up it can be placed in the
same place. If I take the current values returned by GetValues() my
windows gradually drift off the screen!
Surely my program should not need to know that a window manager is
running (what is the shell widget for!) and have walk the window tree to find
the logical position on the screen? Has the idea that applications
do not need to know that a window manager is running been dropped 8-) ?
I would really like to know whether I need to walk the window heirarchy
or not.
Thanks,
Richard Hesketh : @nsfnet-relay.ac.uk:rlh2@ukc.ac.uk
: rlh2@ukc.ac.uk ..!mcvax!ukc!rlh2
---
Computing Lab., University of Kent at Canterbury,
Canterbury, Kent, CT2 7NF, United Kingdom. Tel: +44 227 764000 ext 3682/7620
-----<cut here for postest.c <--------
#include<X11/Intrinsic.h>
#include<X11/StringDefs.h>
#include<X11/Xaw/Command.h>
/* ARGSUSED */
position(w, client_data, call_data)
Widget w;
XtPointer client_data, call_data;
{
Position x, y;
XtVaGetValues(XtParent(w), XtNx, &x, XtNy, &y, NULL);
printf("Position of toplevel returned by GetValues() = +%d+%d\n",x, y);
}
main(argc, argv)
unsigned int argc;
char **argv;
{
Widget toplevel, but;
toplevel = XtInitialize("bugtest", "BugTest", (XrmOptionDescRec *)NULL,
0, &argc, argv);
but = XtCreateManagedWidget("bugTestLabel", commandWidgetClass,
toplevel, (ArgList)NULL, 0);
XtAddCallback(but, XtNcallback, position, (XtPointer)NULL);
XtRealizeWidget(toplevel);
XtMainLoop();
}
-----<end of postest.c<-------swick@ATHENA.MIT.EDU (Ralph R. Swick) (04/09/90)
Position of toplevel returned by GetValues() = +202+221
Note that this is also what you'll get from XtTranslateCoords(w,0,0,...),
so there's consistency.
Is the toolkit correct for returning the absolute
position on the screen or should it return the *real* geometry
but but but the absolute position _is_ the real geometry !?
Is the window manager correct in moving my window down and to the left to make
way for its decorations?
The wm is pretty much "correct" no matter what it does, so long as
it follows the user's wishes. In this case the shell's window gravity
indicates which way you should get moved to respect the user's geometry string.
I have an application that needs to save state and wants
to know where it is so that next time it is started up it can be placed in the
same place.
This part of the state you should probably leave up to the window (or
session) manager. (Why don't you also want to preserve stacking order?)
Retrieving a geometry string so that you can resign from the session and
then re-joining it with the "same" geometry will require more help
from the wm. You might be able to hack a sufficient substitute by
assuming that the wm will place you at a consistent offset from your
requested geometry and 9dynamically) measuring that offset.rlh2@ukc.ac.uk (R.L.Hesketh) (04/10/90)
In article <9004091646.AA23161@lyre.MIT.EDU> swick@ATHENA.MIT.EDU (Ralph R. Swick) writes: > Is the toolkit correct for returning the absolute > position on the screen or should it return the *real* geometry >but but but the absolute position _is_ the real geometry !? By "real" I mean the geometry that the user gives to the application either directly from the command line or via the resource database .. plus of course any movements the user has made using the window manager. >This part of the state you should probably leave up to the window (or >session) manager. (Why don't you also want to preserve stacking order?) Agreed .. but where are the session managers? I will be writing an equivalent of a window manager (actually a button manager) which will co-exist with the window manager. I probably won't have problems knowing the geometry then because my button windows will not be under the control of the window manager but under control of the button manager. >Retrieving a geometry string so that you can resign from the session and >then re-joining it with the "same" geometry will require more help >from the wm. You might be able to hack a sufficient substitute by >assuming that the wm will place you at a consistent offset from your >requested geometry and 9dynamically) measuring that offset. The hack I have used is to walk up the window tree and get the geometry of the parent window which is the child of the root window. By a best guess (it works under twm 8-) this should have the right geometry. It would be useful for users who currently don't have a session manager (most of us I guess) to be able to find out exactly where our windows are so that we can set up the resource database (of course we shouldn't be hacking these anyway if we had resource editors - coming soon) correctly. I currently have 4 different screen sizes I have to set for my environment to look similar on each one. What I am thinking of is a fix to xwininfo which takes into account the reparenting done by the window manager. Currently you have to subract the relative values from the absolute values .. minus any border width given by the window manager!