Conference bulova::decw_jan-89_to_nov-90

To restate in fewer lines-- if you first do a:

	wmh.flags = StateHint;
	wmh.initial_state = IconicState;
	XSetWMHints(XtDisplay(top_level),XtWindow(top_level),&wmh);

Then deiconify manually and do a:

	    XtSetArg(arg,XtNnoIconify, True)
	    XtUnmapWidget(top_level);
	    XtSetValues(top_level,&arg,1);
	    XtMapWidget(top_level);

The widget window disappears AND the icon disappears.  Also, I just 
found that if you set XtNoiconify to True then set initial_state to 
iconic it crashes the WM.

Is there a way to talk to the WM without blowing its brains??

Qar 3625

    Creating a dialog box that does not have an iconify
    button indicates that iconification is not permitted
    for that dialog box.   Attempting to then iconify
    the window programmatically is not supported - fyi.

Re: .3

Why? An application might not want iconification based on the window-manager
supplied mechanism, but why can't it supply its own?

Kevin

    What's an icon anyway?
    
    If you mean a resource managed by the window manager, then you either
    use the window manager's mechanisms or you don't.
    
    If you mean the on-screen appearance of a pixmap which is (typically)
    smaller than the application which it symbolically represents, then, by
    all means, an application can create it's own icon: appearance _and_
    interaction semantics, and window manager treats them passively.

    re: .4
    
    I didnt say that you can not programmatically
    iconify a window.   What I mean to say is that
    you can not programmatically iconify a window
    that you have set up without an iconify button.
    
    If you wish not to have window manager control
    over a window,  then this is a different problem
    altogether.  I am referring to window manager
    controlled windows.

>    you can not programmatically iconify a window
>    that you have set up without an iconify button.

This is a red herring because you can obviously keep track of whether 
or not you have an iconify button and disallow programmed 
iconification where appropriate, though it would be nice if the WM 
didn't crash if you forgot!

However, the original problem boils down to once you have
programatically iconified using wm_hints, deiconifed manually, then you
cannot unmap/map the window without reiconifying it.  I even tried 
resetting wm_hints to normal and still couldn't unmap/map without
iconifying.

    I believe this may be a style guide issue...
    If you don't have an iconify button you don't
    want to ever iconify.
    
    I don't know about the other problem.

.8

I would strongly disagree.  It is a wm bug not a style guide issue.  Not
all applications with which dxwm must work will be style guide compliant.
It is probably reasonable to assume that they will be ICCCM compliant.
What does the ICCCM say about this?  I would find it reasonable that some
applications would want to override the window manager when active but
would provide some means for iconifying (and thus return control to the
wm).  A typical example would be an IC layout application which might take
control of the whole screen (override redirect, width and height = root size)
and provide its own button for iconification.

No iconify button may only mean that the application wants to provide its
own mechanism to tell when iconify should happen.

I repeat that I have not checked the ICCCM on this but it is clearly not
a "style" issue.  A "style" issue would be whether XUI applications should
use this mechanism not whether it should work.

Dick Schoeller

    If there is no iconify button,  then there is no
    icon created for the dialog box.  If there is no
    icon,  what is the window manager supposed to
    iconify the dialog box into?  Whether you tell
    the window manager to iconify programmatically
    or via a button,  it doesn't matter, there's
    no icon.
    
    If you wish to just get the dialog box out of
    the user's face,  then just unmap the window.
    If you wish to do something then unmap the
    window and create your own mechanism,  then
    feel free -- just please don't set no_iconify
    in DEC_WM_HINTS. 
    
    Somehow we have to provide a way to create
    dialog boxes which users can NOT iconify.
    This is how we did it,  you set no_iconify in
    DEC_WM_HINTS.   If the window manager is informed 
    you don't want to iconify the window,  then there
    will be no icon created.   We can not just
    change this functionality because thousands
    of other dialog boxes are relying on us to
    NOT iconify their window.
    
    This came about due to an alleged bug,  and
    what the window manager interprets no_iconify as
    meaning.
    
    I suppose if we had no iconify button, and still have 
    an icon and then the ability to iconify is still there.
    The user is still able to iconify so Im not sure what it
    has bought you really.

Also, given the recent move to adopt OSF/Motif as our strategic UI style,
what do we want to worry about being XUI conformant?

As .9 points out, it really isn't a style guide issue anyway.

James

.10

What I read your note to say is: "Because of the way in which we implemented
dxwm, this idea can't work".  It does not say that we COULDN'T have
implemented it otherwise.  It does not say that we DID implement it RIGHT.
It only says, "That's the way it is, so tough!"  So my question would be,
"Why MUST it be that way?"  (Note, I did not ask why it is that way).

The big problem I see here is the insistence that when you have an icon box
you must have an icon in it for active, iconifiable windows.  As far as I
know that is not an ICCCM requirement.  If there were only icons present for
the iconified windows then one could be put there for any window that got
iconified no matter how it got that way.

Dick

      
    I was merely describing what .0's bug is.
    
    The bug is:
    The no_iconify_button boolean (that gets set in .0
    and .1's examples) indicates to the window
    manager whether you wish to use the button or not.
    This boolean does NOT indicate "now iconify the window,  now
    de-iconify the window" which is what .0 was attempting to
    do. 
    
    This is purely a technical point - changing the meaning
    of the boolean no_iconify_button will break many applications. 
                                         
    That is all this note was about,  a bug.  I don't doubt
    there are other ways to iconify, some better and some worse.
    
    The window manager is an implementation of the style guide.
    Page 2-3 of the style guide describes the relationship between
    the iconify button and the icon in the icon box.
    
    The suggestions/ideas "to be able to iconify a window
    whether the iconify button exists or not" have been noted.
      
    

>    The bug is:
>    The no_iconify_button boolean (that gets set in .0
>    and .1's examples) indicates to the window
>    manager whether you wish to use the button or not.
>    This boolean does NOT indicate "now iconify the window,  now
>    de-iconify the window" which is what .0 was attempting to
>    do. 

I'm .0 and that's not what I was attempting to do.  What I was 
attempting was INDEPENDENT control over existence of an iconify button 
and trying to achieve iconification by programmed control.  Two bugs 
appeared.

1) If you've turned of the icon button and programmed iconify it 
crashes the window manager.  This isn't too important to me because 
you've given it inconsistent commands and it is easy to avoid.  On the 
other hand the WM shouldn't go bye-bye.

2) The worse bug appered because to make the icon button state take
effect you have to unmap/map and once you've set wm_hints to force 
iconification then mapping always makes it iconify.  That might even 
be acceptable except that if you catch when the user deiconifies in a 
structure notify callback and reset wm_hints it doesn't work, either.
So, if you force iconification, the user clicks to deiconify, any 
subsequent map will iconify.  If you reset wm_hints in an independent 
operation (another button callback) then you can map without 
iconification.  I think the WM errs when it does not keep wm_hints 
consistent with the last state of the window and then uses it on 
subsequent maps no matter what has intervened.

re -2:  I agree that "that's the way it is, tough!" is not an answer.
Incidentally, that's also what was said about even being able to 
change the iconifiable (lower and resize, too) on the fly.  Changing 
the gizmos, by the way, seems to work fine as long as the map to make 
it take effect doesn't get crossed up with wm_hints being confused.

>    The suggestions/ideas "to be able to iconify a window
>    whether the iconify button exists or not" have been noted.

That's ok, but the user can keep track of whether or not there is a 
button pretty easily.  The problem is with manual deiconification 
leaving wm_hints inconsistent.
      
I think Motif makes it all moot, anyway.

Bruce    

re: .-1

>>I agree that "that's the way it is, tough!" is not an answer.
>>...
>>I think Motif makes it all moot, anyway.

Don't you see a connection here?

-steve-

    re: .14
    
    2)
    
    The initial_state in WM_HINTS is being used to
    define the initial state of the window.  This
    is settable by the client, not the window manager.
    
    "The value of the initial_state field determines the
    state the client wishes to be in at the time the
    top-level window is mapped from Withdrawn state." -
    p. 22 Inter-Client Communication Conventions Manual,
    Public Review Report dated 11th May 1989.
    
    Motif wm does the same thing in regard
    to initial_state field.  I am reporting this so you
    know what to expect when you pick up a copy of
    a Motif wm - don't beat up the messenger :-).
    
    Motif wm should be setting a property called
    WM_STATE to reflect current state. (at least
    the spec. says so)  So,  in that sense, Motif
    "makes it all moot, anyway".