Subject: Notification: incoming/371

From: [email-masked]
Date: Wed, 2 Jun 1999 08:06:34 -0500 (CDT)

FVWM Bug Tracking notification

new message incoming/371

Message summary for PR#371
	From: [email-masked]
	Subject: Tcl/Tk raise command causes fvwm/app to pause
	Date: Wed, 2 Jun 1999 08:06:32 -0500 (CDT)
	0 replies 	0 followups

====> ORIGINAL MESSAGE FOLLOWS <====

---

From: Bob Woodside <[email-masked]>
Date: Wed, 02 Jun 1999 12:28:58 -0400

Andy <[email-masked]>, masquerading as [email-masked],
wrote:
> 
> The Tk command "raise" causes fvwm to pause for about 2 seconds.

	I don't think so. I tried your example, and got no delay. 

	Also, my TkZip utility (http://www.pcnet.com/~proteus/TkZip) does
toplevel raises all over the place (politely and judiciously, of course 
:-)), and I've never noticed any delay, under FVWM's from version 1
through this morning's CVS (and Tk versions from 4.0 to 8.1).

	TiK must be doing something more involved than just a raise when a new
IM comes in; but I'm not familiar with TiK, so I've no idea what. I'd
try to test it, but I'm not sure what I'd do with it, since I'm not an
AOL IM user - is it feasible to test it without being one?

	Can you give us any idea what else might be going on besides the raise?
Also, does TiK use any of the popular Tk extensions, or is it straight
Tcl/Tk?

- Bob
--
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: [email-masked]
Date: Wed, 2 Jun 1999 13:26:11 -0400

> 	I don't think so. I tried your example, and got no delay. 

Ok, I will reinstall 2.3.3 and try and produce a short test case.

> AOL IM user - is it feasible to test it without being one?

Ok, well it does change the title right before it does the raise.
However the option just controls a if statement around the
raise command.  When the raiseim option on it pauses, when off
it doesn't pause.  

I'm not trying to promote aim, but you can go to http://www.aol.com/aim 
and register for an account for free fairly quickly.  If this is impossible 
I can send you the user/pass for a test account that you can use.  (ie
I will go there for you. :)  Then go to http://www.aim.aol.com/tik
to download.

> Also, does TiK use any of the popular Tk extensions, or is it straight

This is just straight Tcl/Tk.  I really don't know other then E has the exact 
same problem.  I get bug reports from tons of linux users about it, so it was 
added to the FAQ.  Since I use fvwm I could always say not a problem, until
now. :) Maybe if I should fool around with reordering the title changing and 
the raising.

Andy

---

From: [email-masked]
Date: Wed, 2 Jun 1999 14:09:33 -0400

Here is a simple test with the current CVS tree as of about 
ten minutes ago, so you don't nee TiK or an AIM account.  If I 
comment out the "wm title" line it doesn't help, only commenting 
out the "raise" line removes the delay.  IM Took is usually 2 
seconds on my machine, except for the first one.

uname -a: SunOS barney 5.7 Generic sun4u sparc SUNW,Ultra-5_10
    wish: 8.0.4

Andy

#!/usr/local/bin/wish
proc im {msg} {
    set b [clock seconds]
    .im.text insert end "$msg"
    wm title .im $msg
    raise .im
    update
    set e [clock seconds]
    puts "$msg IM Took: [expr {$e - $b}] seconds"
}

toplevel .im
text .im.text
pack .im.text -in .im
update

for {set i 1} {$i < 10} {incr i} {
    im Test$i
}

---

From: Bob Woodside <[email-masked]>
Date: Wed, 02 Jun 1999 19:48:29 -0400

[email-masked] wrote:
> ten minutes ago...

	Now this is really weird! 

	First, I get exactly the same results you do, right down to the 2
second interval, on my Linux box.

	Second, I get no delay under 2.2, or under 2.0.46.

	Third, just to see what would happen, I added a "raise ." immediately
after the "raise .im". The result: "Test$n IM Took: 0 seconds" all the
way through! I got the same result with 30 or so runs of the test.

	It looks as though no delay occurs if the raise actually has something
to do - i.e., there is actually a higher window in the stacking order
for the target window to be raised above. But, when the window is
already at the top of the pile, the delay happens.

	Now, I haven't really looked at the window raising code since the
post-2.2 layer logic went in, so I don't know what might have introduced
this quirk. (Say...have we been stealing code from E?) Does anybody else
have any ideas?

- Bob