[WINDOWMAN] Re: GNOME hints from E

Alfredo Kojima (kojima@milonga.ilea.ufrgs.br)
Fri, 6 Nov 1998 09:18:26 -0200 (EDT) 


Marko: we tried to subscribe to the mailing list, but 
were haing trouble with your address. Please try
subscribing yourself to windowman-request@sorted.org


Summary of comments from Raster and Alfredo:

Mark = Marko.Macek@iname.com
Raster = raster@redhat.com
Alfredo = Alfredo Kojima <kojima@milonga.ilea.ufrgs.br>
Icewm = http://www.kiss.uni-lj.si/~k4fr0235/icewm/

WM Hints:

- WIN_... prefix.        [ Mark ]

   I deciced to use this one to make it neutral to everyone (WM_ is
   reserved for X guys). Not GNU, not GNOME, not icewm, not E, not KDE, ...
   I vote for keeping this, because it is already implemented and used.

   There is no XA_ prefix.

Yes, I was reading a old file.

   [Alfredo]
   >%%%%% I  still think it should be named _GNU_WM_ICONS etc.
   >%%%%% WIN_ is not ICCCM compliant.

   It is not? Why? Because of '_'?

No. ICCCM says that WM_ is reserved for the X consortium, and
vendor specific (in this case, us) should prepend the hint
name with a _ and the vendor name (I cant thikn of a good neutral
name, so I chose GNU. It could be anything else.) So, according
to ICCCM 2.0, window hints that dont come from the X consortium
should be named _vendor_WM_hintname, like _DEC_WM_whatever,
_MOTIF_WM_whatever or _OL_WM_whatever. We could use
_GNOME_WM_whatever too, but if you insist on keep using WIN_
thats ok with me, although it wont make a difference on backwards
compatibility (since you seem to want to merge all hints into a single
property).

 
- WIN_LAYER_MENU  [ Mark ]

   Not there yet, but could be added as:

   #define WIN_LAYER_MENU            12

   Menus are supposed to be above everything, right? Alfredo?

Yes. It wouldnt be very unpleasant if a menu popped up below anothr
window...

- WIN_STATE:

   - WIN_STATE_ICONIFIED [ Mark ]

       It is there as WIN_STATE_MINIMIZED

raster removed it in his implementation.


   - WIN_STATE_STICKY  [ Raster ]

      in WinMgr.h this is called WinStateAllWorkspaces

      This needs to be synchronized. I belive my name is less ambigous. ?

Yes. Or omnipresent, wich is short and descriptive ;)

       [Alfredo]
       >%%%% Sticky should not be a state. It is an attribute.

      It can be changed by the user/app. Just like minimization, ...

Yes, but not everything that can be changed by the user/app is a state.

   - WIN_STATE_HIDDEN [ Mark ]

      [Alfredo]
      >%%%% I dont understand this HIDDEN. When will the app be
      >%%%% visible but not be in the taskbar? Maybe it should be
      >%%%% the oposite (present in the taskbar but window not visible).

      In icewm there is also the window list (window, not menu).
      A window can be hidden and it only appears in the window list,
      but has no desktop or taskbar icon.

      If window is present on taskbar, but not visible you are
      in a WIN_STATE_MINIMIZED.

This should be generalized, so. In any state where the application
is not visible at all (no windows nor icons are mapped), it should be
considered as HIDDEN. 


   - WIN_STATE_FIXED_POSITION [ Raster ]


- WIN_STATE vs WM_STATE

   [Alfredo]
   >That should be ok, but letting the app choose in wich one to look
   >can have some problems. By making it a convention that if _GNU_WM_STATE
   >is set (and the wm is still running), the app should *always* look
   >at _GNU_WM_STATE. This will remove any problems with races too.

   If the application supports it and needs any of the new states, yes.


- WIN_WORKAREA  [ Mark ]

   [Alfredo]
   >%%%% Agreed. It would be usefull if this was present in the client's
   >%%%% window, instead of the root window. This way, the window manager
   >%%%% can figure the workarea by itself.

   There is only one workarea at the time. The property is READ ONLY
   and being on root window is OK. Applications should not modify this
   property ever.

   However, work area could change when workspaces are switched. Icewm
   doesn't currently allow it. Two things could be done:
      - have the property contain the workspace number
      - have the property contain the work area for all workspaces

If at all necessary, I prefer the first one. Can you give an
example of when a client would want to know the workarea?


- WIN_CLIENT_LIST [ Raster ]

    [Alfredo]
    >%%%% I dont like this very much. The tasklist app can get a list of managed
    >%%%% windows with XQueryTree() and then use the hints in the top level
    >%%%% window to figure if it is managed. Or use the selection mechanism
    >%%%% to retrieve the list of managed clients. Anyway, if this is going
    >%%%% to be E specific, it should be renamed _E_WM_CLIENT_LIST
    
    Personally, I think some kind of notification mechanism, like in KWM
    hints could be useful. It has to handle more than one listener though.

There is no need to do that if the selection mechanism is used. It will
handle as many listeners there are.
    
- WIN_PROTOCOLS [ Mark ]

   It could be improved, but it is only a problem if the WM crashes.

- WIN_CLIENT_MOVING [ Raster ]

   It think it is broken. It should not be used anyway. toolbars popping
   in and out of the window automatically when dragged are a bad UI anyway.

   We need a message to send to WM to start move/resize:
      for mouse events:
         x, y of mouse click
         button, state
         window edges picked (top,left,right,bottom or none)
         ??
      for key events
         window edges picked (top,left,right,bottom or none)
         ??
   A wm can start resizing with this info.

I think thats better too. 

   
- timestamps

   Timestamps in events should not be CurrentTime. They should be
   timestamps of user events that caused the operation.