[comp.windows.x] Additional inputs after XtRealizeWidget

walton@harpsichord.cis.ohio-state.edu (Brian Walton) (05/03/89)

I am using the Athena widgets and I currently realize a toplevel widget and
all its children by calling XtRealizeWidget(toplevel).  Before XtRealizeWidget
returns control to my program, I have to press one of the mouse buttons.
After pressing the button, all the child widgets are mapped and visiable on
the screen.  My question:  After starting my program (e.g. testprogram<CR>),
is there some way of mapping the toplevel and its children without any 
mouse or keyboard inputs?

Thanks in advance for all help offered.

kit@EXPO.LCS.MIT.EDU (Chris D. Peterson) (05/06/89)

> I am using the Athena widgets and I currently realize a toplevel widget and
> all its children by calling XtRealizeWidget(toplevel).  Before XtRealizeWidget
> returns control to my program, I have to press one of the mouse buttons.
> After pressing the button, all the child widgets are mapped and visiable on
> the screen.  My question:  After starting my program (e.g. testprogram<CR>),
> is there some way of mapping the toplevel and its children without any 
> mouse or keyboard inputs?


You are a bit confued about program flow.

Here is what really happens.

1) Create and Manage Widgets.

2) RealizeWidgets 
   The widgets get windows, but they are not actually displayed on the screen
   yet.  This will happen when the contents of the buffer that is used to
   store client events is sent to the server. 

3) XtMainLoop()

   This is where the widget's windows actually get mapped to the screen.
   Remember unless you call XFlush() no events will get processed unless 
   your program is currently in XtMainLoop().  Thus if you are off doing
   computation somewhere no events can be processed, the X Server will just
   queue them up until your client returns to XtMailLoop() again.

Thus in your simple program the program has already falled into XtMainLoop() 
when the window manager rubberbands the window asking for placement.

Now about the question of how to place windows w/o user interaction. 

What is happening is that the window manager is asking the user to specify a 
location for the window.  It is an assumption of the X model that the person
who decides where windows are to be placed is the user (there some exceptions
to this rule such as menus and dialog boxes, but for most applicataions the
user should decide where to put the windows).   If you as a user
would like to have an application come up in a specific location without
mouse interaction you have two choices.

1) you can use the command line argument -geometry and a geometry spec.

2) you can put a geometry specification in your resource file.

Now it is possible for the application to fool the window manager into thinking
that the user has asked for a particular location for the window.  This can
be done in a toolkit application by either putting a geometry resource
in a app-defaults file or by hard codeing a geometry specification into
the application.  I think that hard-coding geometry information is
really annoying behavior, but we are in the business of providing as
little policy as possible so if you want to hard code it in we have
made it possible.


						Chris D. Peterson     
						MIT X Consortium 

Net:	 kit@expo.lcs.mit.edu
Phone:   (617) 253 - 9608	
Address: MIT - Room NE43-213