So why would Tk not wait at all for the response, if we know that almost
none of
the window managers send it ?
Other toolkits can raise windows without waiting for 2 secs.
Any objection about not calling raise if vTcl runs on Linux ?
CG
|--------+------------------------------------->
| | Damon Courtney |
| | <[EMAIL PROTECTED]> |
| | Sent by: |
| | [EMAIL PROTECTED]|
| | eforge.net |
| | |
| | |
| | 03/09/2001 10:30 AM |
| | Please respond to vtcl-user|
| | |
|--------+------------------------------------->
>-----------------------------------------------------------------------------------------------------------|
|
|
| To: [EMAIL PROTECTED]
|
| cc:
|
| Fax to:
|
| Subject: Re: [vtcl-user] error in widget-tree, when klicking too fast...
|
|
|
>-----------------------------------------------------------------------------------------------------------|
> I take it you are using Unix.
>
> On Unix, there is a problem with the _raise_ command (I am
> writing _raise_ the same way they do on the Tcl Core mailing list).
>
> Anyway, _raise_ on Unix takes from 1 to 2 sec to do its job freezing
> the app in the meantime. Clicking on the widget tree probably
> causes the click to be executed right after the _raise_ but before
> the toplevel and the attributes editor are refreshed...
>
> I should probably not call _raise_ if vTcl is running Linux but
> then the toplevel wouldn't come to the foreground. This may be a
> problem if you have too many visible toplevel windows.
>
> Does anyone know a work around for _raise_ ?
>
> Also, a big problem in see in Tk is how to implement modal dialog
> boxes. Even if you set a grab you can still click on other windows
> and they will obscure the modal one (though other windows are
> inactive). You also have to _raise_ the modal dialog to make sure
> it appears in the foreground, which causes an annoying delay.
>
> What about the BLT _busy_ command ?
Jeff Hobbs actually explained this once in a news posting. I wish
I could find it for you, but I'll sum up. This basically comes from a
problem in the Window Manager, be it whatever window manager you are
using under UNIX (fvwm, olvwm, kde, etc...). It has something to do
with Tk sending the proper window notification to the manager and
waiting for a response before proceeding. The window manager is not
sending the response, so Tk waits, you guessed it, 2 seconds before
going ahead without the response.
I'm not sure that this problem can be resolved. It was basically
dropped as a non-issue because Tk is doing the write thing by the specs
while the window managers affected are not passing the correct response,
or in some cases, no response at all.
Damon
_______________________________________________
vtcl-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/vtcl-user
_______________________________________________
vtcl-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/vtcl-user
