Conference bulova::decw_jan-89_to_nov-90

Re: .0

Here's a really ugly idea: send bogus button down and button up events using
the coordinates of your iconify button!

				-- Bob

    
    Yup.  Pretty ugly.  I was just wondering since the concept of an "icon"
    seems to be purely a window-manager function and doesn't appear to have
    any controls outside of the wm "hints".  So since I couldn't figure it
    out, I thought I'd try here.  Simulating a button is fine as long as
    override redirect isn't TRUE.
    
    My only idea at this point is to create a bogus window with a icon and
    the initial state set to ICON.  Then trap the attempt to map the window
    on the expand, and instead map the "real" window.  I just wish the
    documentation on events was clearer...
    
    

>     ...since the concept of an "icon" seems to be purely a window-manager
>     function...

I agree.  Section 4 of the icccm seems to prohibit (well... strongly
discourage) normal clients from causing iconification except by using
the WM_HINTS.initial_state property.  Note that the iconify button is
normally created by the WM and not the client, right?

I often wish I had a way to say ``iconify everything!'', but I think this
should be a WM function.

    
    Actually, what I'd *really* prefer is a standard set of messages that
    I could send to the window manager (like iconify me please).  For
    instance I've grown accustomed to being able to do a CTRL-SHIFT-REMOVE
    to shrink my terminal window...
    
    

> Actually, what I'd *really* prefer is a standard set of messages that
> I could send to the window manager (like iconify me please).  For
> instance I've grown accustomed to being able to do a CTRL-SHIFT-REMOVE
> to shrink my terminal window...
    
Section 4.1.4 of the ICCCM provides just such a set!  To chang your window
state from normal to iconic you send a specific ClientMessage to the window
to be iconified.

    
    You send it *to* the window to be changed!  Pretty sick, I guess the
    idea being that the window manager "intercepts" the message.  It
    fits the model though...
    
    

The following does work. The name 'initial_state' is a leftover. The window
manager does give attention to this hints after initial mapping of the window.
Note 57 in HARBOR::DECWINDOWS_FT1 notes file discussed the same topic.

    void iconize(dpy, w)
	Display * dpy;
	Window w;

        {
        XWMHints hints;

        hints.flags = StateHint;
        hints.initial_state = IconicState;  /* Change NormalState to
                                               NormalState to get reverse
                                               effect */

        XSetWMHints(dpy, w, &hints);
        return;
        }

Good luck!

Now if I could just get the window ID of my
DECterm window :-(

>>               <<< Note 935.8 by CSSE32::MERMELL "Window Pain" >>>
>>
>> Now if I could just get the window ID of my
>> DECterm window :-(

  The way that I have been doing it is to run a program that gives the
window id of the window that has current input focus.  When you get this
value you can then define a logical, put it in a mailbox, whatever...

  Kind of ugly but if you need the id this way works.  I got the idea
from the SET_TITLE program from the DW_EXAMPLES conference.

					-=> Jim <=-

					

    
    It's more than just ugly, but I'll refrain from using the words that
    I describe the SET TITLE mechanism by...
    
    

	There are at least two programs in the examples conference that
	can find DECterm window ids.  One works off of the window with
	the input focus.  A second searches the window tree and prints
	the ids of all of the DECterm windows.  I think both programs
	are VMS only.  They aren't supported (hack hack hack).

	Dan

	I tried the following.  Nothing happens: the window remains a non-icon.

	"widget" is a file_selection widget.  I call the iconize program
	from within one of "widget's" callbacks.

	  Widget  widget;
	  Display *display;
	  Window  window;

	  DwtFetchWidget (			/* fetch file_selection widget */
		      hierarchy,
		      "filewindow",
		      ToplevelWidget,
		      &widget	
		      &class);	
	    .    .    .

	  display = DwtGetDisplay (widget);	/* arguments for iconize      */
	  window  = XtWindow (widget);
	  iconize(display, window);
	  return;	  			/* return to mainloop	      */

	    .    .    .

	  void iconize(dpy, w)

	    Display * dpy;
	    Window w;

	  {
	      XWMHints hints;

	      hints.flags = StateHint;
	      hints.initial_state = IconicState;
	      XSetWMHints(dpy, w, &hints);
	      return;
	  }

Change 	  

    window  = XtWindow (widget);

to 

    window  = XtWindow (XtParent(widget));

Jatin

	Thanks, Jatin,

	But, it doesn't work.  I have the following:

	  for ( scratchwidget = widget ; 		/* get a shell	*/
		  !XtIsShell( scratchwidget);
		  scratchwidget = XtParent( scratchwidget));

	  window  = XtWindow (scratchwidget);
	  iconize(display, window);


	The "for" loop is unnecessary; i.e., XtParent(widget) is the same as
	the scratchwidget from the "for" loop.

	Does it matter that "widget" is a file-selection widget?

	Regards, Robert.

When displayed, does the file selection widget have the 'icon' button at left
top ? Otherwise this will not work (i.e.) it will only iconize with the parent.

Jatin

	Thanks again, Jatin,

	It works now.  I had a silly mistake in the code.  Ain't it always
	the way?

	Anyhow, your advice to use  window = XtWindow( XtParent( widget ))
	works fine.

	Regards, Robert.

	PS  My silly mistake: I'd tried NormalState in the "hints" structure
	to see what would happen, and I forgot to set it back to IconicState.
	Debugging rule:  Read _all_ the damn code!

    
    Sorry to [repeatedly] beat a dead horse, but I am still having a
    problem getting this to work in a UIL based application.  The UIL
    contains 3 widgets: a main_window, which has a menu_bar, which
    in turn has a push_button.
    
    	Selected code is as follows:
    	
    	Display *dpy;
    	widget toplevel, main_w;
    	main()
    	{
    	DwtInitializeDRM();
    	toplevel = XtInitialize("MyAppl", "dummy_class", NULL,
    						0, NULL, NULL);
	...
    	dpy = XtOpenDisplay(toplevel);
    	...
    	DwtFetchWidget(s_hierarchy, "MyMainWind", toplevel, 
    			&main_w, &dummy_class);
    
    	XtManageChild(main_w);
    	XtRealize(toplevel);
    
 /* push_button calls back to iconify() */
    void iconify();
	{
    	XWMHints xwmh = {StateHint, NULL, IconicState, 0, 0, 0, 0, 0, 0)
    	XSetWMHints(dpy, XtWindow(toplevel), &xwmh);
    
    	/* NOTHING HAPPENS when this function is called */
    
    		I have also tried: 
    			XtWindow(XtParent(toplevel)) /* returns 0 */
    			XtWindow(XtParent(main_w))   /* doesn't work */
    			XtWindow(main_w)	     /* ditto */
    
    	I assume I am doing something wrong here.  Anyone have any ideas?
    
    	BTW: VMS V5.3 / DECW V2.0 
    		Thanks in advance....
    			Frank
    
    

>>    	dpy = XtOpenDisplay(toplevel);

I think:

    	dpy = XtDisplay(toplevel);

-steve-

    Thanks,  Steve, but my code does say that.  Sorry about my fat fingers.
    But,   even with XtDisplay, it doesn't work.
    
    
    :-( Frank
    

    
    I stand corrected.  The code does work - on a  VAXstation  3100.
    Unfortunately, I have been developing the project on  a VT1000,
    which seems to disregard the XSetWmHints call.  I'll try posting
    a note in that conference.
    
    	FRANK
    

    Doesn't the ICCCM point out that a window manager is free to ignore the
    WmHints? Iconizing your application without the user clicking on the
    iconize button is not a portable feature because not all window
    managers support the idea of icons. Since the VT1000 has its own WM it
    is free to do as it will with the WmHints.
    
    Dan