Subject: Re: a patch with fixes and small enhancements for wmfishtime

From: [email-masked]
Date: Thu, 31 May 2001 07:08:45 +0900 (JST)

thanks for the patch however there are a few things one needs to consider:

* dockapps run as withdrawn windows. its pretty simple. one could run a
  dockapp in a normal window, but they are sure as hell never run as an
  "icon". If I am going to provide an option, it's going to be "windowed"
  or "withdrawn", not "windowed" or "iconified" because well, uhm, say,
  blackbox won't even display iconified windows.
* thanks for the size hints stuff, that will be useful.
* thanks for the window group info
* thanks for delete window / user position /etc

The biggest reason that stuff was under #ifdef originally (until stupid
debian zealots said that nobody compiles shit anymore), is performance
reasons. If the user is only seeing win or iconwin, there is no point
drawing to both of them.

tim

-- 
・‥…━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━…‥・
     timecop at japan.co.jp | ＯＡ通信サービス株式会社 | NTT DoCoMo
  I thought everything that Linus Torvalds is involved with was divine
  perfection? Must be a problem with NEC and Sony -about Crusoe recall
・‥…━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━…‥・

--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Thu, 31 May 2001 02:41:11 +0200

On Thu, May 31, 2001 at 07:08:45AM +0900, [email-masked] wrote:
>   "icon".

No, that can't be true.  In X, "withdrawn" means "not visible at
all".  A withdrawn window can't be seen anywhere, not as a window,
not as an icon, not swallowed in a dock, nowhere.  That is the
whole point of windows being withdrawn.  The only thing I could
imagine is that the dock application maps these windows.  In this
case, another option might be useful: --in-window, --in-icon and
without any of these options, don't map the application at all.
However, mapping the window with the StateHint set to
'WithdrawnState' is still incorrect and leads to undefined
behaviour.

>   If I am going to provide an option, it's going to be "windowed"

Well, it's almost no effort to let it run in an icon because the
code without my patch does exactly this.  It provides an
IconWindowHint and afterwards draws into the icon window.  I guess
the dock maps the icon window itself - which would be a blatant
violation of everything that X and the ICCCM2 demand :-P  If this
is the case, I suggest to simply keep the map/unmap handling I
wrote, set the StateHint to withdrawn/noram/iconic, whichever the
user demands.

> reasons. If the user is only seeing win or iconwin, there is no point

It's easy to keep track of which is visible.  Whenever the
application gets a MapNotify on its main window, the main
window itself is visible, whenever it gets an UnmapNotify the
application has become iconified (which does not necessarily mean
that the icon window is actually visible).  The patch already
takes care of this.

Bye

Dominik ^_^  ^_^

--
Dominik Vogt, [email-masked]
Reply-To: [email-masked]
--
Visit the official FVWM web page at <URL:http://www.fvwm.org/>.
To unsubscribe from the list, send "unsubscribe fvwm-workers" in the
body of a message to [email-masked].
To report problems, send mail to [email-masked]