Conference bulova::decw_jan-89_to_nov-90

Re: .0

No, it isn't possible; the biggest problem would be getting rid of the
title bar and menu bar.  Several people have asked for this feature but it
hasn't made it to the top of the wish list.

				-- Bob

    
    Aw, come on.  Even xterm on X10 did it :-)
    
    

Making the small window isn't really the problem. The window manager will insist
on sticking it's decorations on everything. Sounds like what's really needed is
a window manager that understands "live icons...'

And since it's X, just take a few months and roll your own. I'm sure that your
thesis advisor will understand :-)

James

    
    Hey, an icon window is just a window...  Calendar updates the time,
    so why not do a little magic?
    

Have you noticed how SLOW it is for calendar to update the time?  It does
not magic; it does it all "right" by telling the window manager with a
property.  Not practical for frequent changes.  (Barely practical for once
a minute; I turned mine off!)

Burns

    
    Hey, isn't X11 magic?  Can't anyone *directly* write to the icon
    window?
    

If you want to come right down to it, UIS is even more magical than X, but...

Sure, you can write to the icon window if you can find it...  Of coure the
window manager might not remember to tell you if it got an expose event for
it, or if it had to gray it out.  And the method you use to find the window
and the other hackery you have to do might not work with HPWM or any other
window manager you might choose to use.

Etc.

Burns

> Sure, you can write to the icon window if you can find it...

I thought you could tell the WM (through a hint) to use a window *you*
provide for the icon.  At least that is what the ICCCM says...  Don't you
put the window into the icon_window field of the WM_HINTS property?

1) The decwindows window manager is not completely ICCCM compliant.
2) Those things are hints.
3) You should attempt query what the wm can do and do the right thing.  See
   kaleid (in DW_EXAMPLES) for some hints on what you can try.

Dick

    
    
    re: .8
    Yes those things are hints,  that is the point.
    A "hint" is a property,  and everytime you change
    it alot of round trips are created.  
    
    So if the icon is changed once every minute,  alot
    of client-server traffic (between your client - server -
    and window manager) is generated once every minute.
      

> re: .8
> Yes those things are hints,  that is the point.
> A "hint" is a property,  and everytime you change
> it alot of round trips are created.  
> So if the icon is changed once every minute,  alot
> of client-server traffic (between your client - server -
> and window manager) is generated once every minute.
      
Sorry, but I think you are mistaken.

The ``hint'' in this case is a *WINDOW ID*.  You don't change it once
you put it into the WM_HINTS property!  There is no traffic associated
with this ``hint'' after you set it up the first time.

All the WM is supposed to do is to map the specified window when the
application is set to ICONIC state.  The only traffic to the server
should be that associated with maintaing the icon window, such as 
handling events, etc.

But since they are hints, the window manager can choose to ignore them and
still be compliant.  What you have to do is make the client query which types of
icons are supported use the one that is most desirable.  Or you have to act
as though they are all supported and see what happens  8^{).

Dick

    I'm a bit confused.  Is the overall goal here to hack the window
    manager (or ICCCM) for the pleasure of it or to accomplish the
    following rational task: transform the user interface such that it no
    longer has the on-screen appearance of x cm� but the appearance of
    x*0.5 or x*0.1 cm�.
    
    It seems to me that the application programmer is the best judge of how
    to achieve that and the program can easily implement it.
    
    Other replies seem to point to this problem: a conflict over determining
    the appearance of the icon between the application and the window. 
    manager.  This is a war that should not be fought.

re: Note 976.12 -< You must make sure you give a "useful" hint. >-

> But since they are hints, the window manager can choose to ignore them and
> still be compliant.

So what?  A well behaved application does not try to force an icon appearance
upon the WM or the user.  I was simply pointing out that the mechanism for
doing this exists under the ICCCM, and that DECTerm could easily implement it.
I don't know what the DEC supplied WM would do with such a hint, but I *do* know
that there are WMs that would do the right thing.

> What you have to do is make the client query which types of
> icons are supported [and] use the one that is most desirable.

Or, more simply, let the user decide through customization.

re: Note 976.13 -< You want a smaller UI, right? >-

> I'm a bit confused.  Is the overall goal here to hack the window
> manager (or ICCCM) for the pleasure of it

Re read the base note.  No one has suggested hacking the ICCCM.

> or to accomplish the
> following rational task: transform the user interface such that it no
> longer has the on-screen appearance of x cm� but the appearance of
> x*0.5 or x*0.1 cm�.
> It seems to me that the application programmer is the best judge of how
> to achieve that and the program can easily implement it.
    
I don't follow you.  A `live' icon window *is* implemented by the application program.
The only issue is how to convince a window manager to use the window so implimented as
the icon.

    re: .11
    
    I mention hints because the icon pixmap is a "hint"
    in WM_HINTS.  And WM_HINTS is a window property.
     
    What I am referring to is the fact that when you
    change the icon such as the time in the calendar
    icon,  there is alot of client-server traffic.
    In calendar's case,  they are probably changing
    Icon Name and not pixmap - which still incurs the
    traffic.   To change an icon pixmap so that it emulates
    what is happening in the terminal,  with today's X
    and window manager and ICCCM this is what we have.
    
    Agreed.  It would be nice to have a window manager
    controlled icon that is just a little tiny terminal
    emulator. 
    
    You could probably create some override redirect window
    which does something like this - and the window manager
    would not interfere.

>    In calendar's case, they are probably changing Icon Name and not pixmap
    
    The iconName is changed once a minute, the iconPixmap and iconifyPixmap
    once a day.
    
    The iconWindow stuff works, although I seem to remember there being
    some restrictions on window size (or, at least, how much the WM
    displays).
    
    Regards,
    
    Marios

re: Note 976.15 -< Override-redirect >-

> I mention hints because the icon pixmap is a "hint"
> in WM_HINTS.  And WM_HINTS is a window property.
     
Please, you are not hearing what I am saying (reading what I am
typing?)!  I *DID NOT SAY* to use the icon_pixmap field of the
WM_HINTS property.  I said to use the icon_window field of the
WM_HINTS.  This field is not a pixmap;  it is a window id.  *YOU
DO NOT NEED TO CHANGE THE WM_HINTS EVER AGAIN*! The only traffic
is then that needed to maintain the contents of the icon window.

Of course, I don't know what the DEC WM would do, but the ICCCM
states that ``Most, but not all window managers will support
icon windows;  those that do not are likely to have a user interface
in which small windows that behave like icons are completely 
inappropriate, so that clients SHOULD NOT ATTEMPT TO REMEDY THE
OMISSION BY WORKING AROUND IT''.  (Emphasis mine)

Based on this I think that your suggestion is not consistent with the
ICCCM:

> You could probably create some override redirect window
> which does something like this - and the window manager
> would not interfere.

BTW, is there a DECWindows developer here who can tell us
what DECTerm will do with the icon_window field in WM_HINTS?
I don't have the motivation to subscribe to the decterm
conference.

Re: .18

DECterm doesn't touch the icon_window field.  It sets the iconName, iconPixmap
and iconifyPixmap resources in the shell widget, and doesn't touch the
WM_HINTS directly.

				-- Bob

Is there a DECWindows developer around who knows what the
DEC Window Manager would do if someone were to give it
a window ID in the WM_HINTS icon_window field?

    You could just try it and see - you'll probably
    get the default pixmap in the icon window.
    This is why I keep bringing up pixmaps.  I haven't
    attempted to find all the possible ways to work
    around not using a pixmap -- maybe you'll find one.
    
    DEC window manager is very closely tied to the
    Toolkit and the DECwindows Style Guide as are
    all the DECwindows applications. 
                                                       

I'm not a DECwindows developer, but I can answer this question.  Passing a
window in the icon_window field of the XWMHints structure most definitely works
with the DECwindows window manager.  The WM displays your icon_window (if there
is one) when the
application is iconized.  If there is no icon_window, it displays the
icon_pixmap.  If there isn't an icon_pixmap, you get the default square-divided-
into-four-panes DECwindows icon.  When your application is expanded from the
icon, the icon is displayed as the icon_pixmap with a stipple pattern to grey it
out.  Once again, if you don't have an icon_pixmap, you get the default icon.

An example of a working application that does this is the kaleidoscope program.
Sources can be found in PSW::PSW$DUA1:[WINALSKI.KALEID]KALEID.C.

--PSW

If you are using the small icons.  You get the iconify pixmap in the icon.
You do not get an icon window.

Dick

    You get the default pixmap in the icon if you don't
    include a pixmap in the hint.  It doesnt matter what
    size icon you have decided to use and it doesnt matter if
    you have included an icon window in the hints.
    
    If someone has some code that gets the window manager
    to not put a default pixmap in the icon, then by all 
    means, post it here.