Subject: why are windows raised when deiconified?

From: Dominik Vogt <[email-masked]>
Date: Mon, 29 Nov 1999 14:47:45 +0100

The subjects says it all.  Why isn't this configurable?  It's
hard coded into DeIconify(), just at the end of the function?

BTW, Dan, why did you move the 'raise' to the end of the
function?  This causes a funny effect:  If the window was
partially covered orivinally, the uncovered parts are drawn
first, and then the parts that were previously covered.
You may notice the window being drawn in blocks.

Bye

Dominik ^_^

-- 
Dominik Vogt, Agilent Technologies, Dept. BVS
Herrenberger Str.130, 71034 Boeblingen, Germany
phone: 07031/464-4596, fax: 07031/464-3883, [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]

---

From: Dan Espen <[email-masked]>
Date: Mon, 29 Nov 1999 09:09:40 -0500

> function?  This causes a funny effect:  If the window was

Nope.

> You may notice the window being drawn in blocks.

If you tried to put the window back in  its original position relative
to other windows that it overlapped, what would you do with additional
windows and original windows   that had been raised,  lowered, shaded,
iconified/deiconified.

I think most times when you  deiconify you want  the window at the top
and doing anything else could  get complicated.  I  know I always want
the window at the top.

I put  in  the tracing  code  you suggested  but  I can't  produce the
symptom with every startup.

--
Dan Espen
444 Hoes Lane  Room RRC 1C-214           E-mail: [email-masked]
Piscataway, NJ 08854                     Phone: (732) 699-5570
--
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: Mon, 29 Nov 1999 15:25:12 +0100

> windows and original windows   that had been raised,  lowered, shaded,

Um, aren't the window and the icon kept at the same position in the
stacking order?  I'd expect that when I iconify a window and immediately
deiconify it that the stacking order doesn't change.

> and doing anything else could  get complicated.  I  know I always want

I don't, but I'm aware that zillions of users will cry out if we
change it.  I don't see why it should get complicated though.
Simply remove the line

  RaiseWindow(tmp_win);

and the icon stays at the same position in the stacking order
(try it out).  Perhaps an option to the Iconify command will
do.

> symptom with every startup.

BTW, is that a new problem?

Bye

Dominik ^_^

---

From: Dan Espen <[email-masked]>
Date: Mon, 29 Nov 1999 09:45:05 -0500

> deiconify it that the stacking order doesn't change.

I've never looked at the stacking order code, but I would have suspected
that when a window is iconified, it would have been removed from the stack.

What you say below indicates that it doesn't.

> (try it out).  Perhaps an option to the Iconify command will

The need for an option was my main point.

If nothing  else changes between iconify/deiconify I   can see how the
option might work.  If the windows are  shuffled around a bit, between
the iconify  and deiconify, I  can't see how  it  could work.  I don't
know if having an option  that only works  under some conditions would
be a problem or not.

> BTW, is that a new problem?

No.  I figured it was all part of the iconic state problem.
Once you fixed that and this problem showed again, I decided I'd
better report it.

I've been seeing it for at least a month.  (But only occasionally.)

Now you are  probably wondering  what else  I've  seen that I  haven't
reported.

I still see  wire-frames for off screen windows.   I have  workman off
screen and I don't normally see a wire frame for it, but I think thats
probably because there is room to place  it automatically, I sometimes
see it map during restart.

---

From: Mikhael Goikhman <[email-masked]>
Date: Mon, 29 Nov 1999 16:48:09 +0200

> hard coded into DeIconify(), just at the end of the function?

Maybe new global options DeIconifyRaises/DeIconifyDoesntRaise?
The first can be a default for compatibility. I prefer the second.

Regards,
Mikhael.

---

From: Dominik Vogt <[email-masked]>
Date: Mon, 29 Nov 1999 19:36:48 +0100

> What you say below indicates that it doesn't.

:-) My mails aren't necessarily consistent.

> the iconify  and deiconify, I  can't see how  it  could work.

The stacking order code (I guess) makes no difference if the window
is iconified or not.  If you raise an icon, the window is raised too.
So it would simply work as if the window hadn't been iconified when
the stacking order was shuffled.  But in the end it's probably a
useless otion.

> Now you are  probably wondering  what else  I've  seen that I  haven't

No. I would only wish that everybody stated the version number of the
code where a problem occured initially.

> see it map during restart.

To be honest:  I'm getting desparate.  I know about a dozen or more
bugs that have to be fixed before 2.4 and that I don't see myself.
The simple truth is:  either the reporters of those bugs debug
these or we ship 2.4 with these bugs or we don't ship 2.4 at all.
It's simply too much for me.

Bye

Dominik ^_^