gmane.comp.lang.tcl.core

Jos Decoster | 1 Jul 11:38

TIP #321: Add a tk::busy Command


 TIP #321: ADD A TK::BUSY COMMAND 
==================================
 Version:      $Revision: 1.1 $
 Author:       Jos Decoster <jos.decoster_at_gmail.com>
 State:        Draft
 Type:         Project
 Tcl-Version:  8.6
 Vote:         Pending
 Created:      Thursday, 26 June 2008
 URL:          http://purl.org/tcl/tip/321.html
 WebEdit:      http://purl.org/tcl/tip/edit/321
 Post-History: 

-------------------------------------------------------------------------

 ABSTRACT 
==========

 The *blt::busy* commands can be used to make Tk widget busy, with all 
 user interaction blocked and the cursor can be changed to e.g. a clock. 
 This TIP proposes to add this useful feature to Tk. 

 RATIONALE 
===========

 BLT has a lot of very useful commands: *bgexec*, *busy*, *vector*, 
 *graph* widget, *barchart* widget, ... But getting BLT to work with the 
 latest releases of Tcl and Tk becomes more and more difficult. Some of 
 the problems I experienced are:

(Continue reading)

headers

Lars Hellström | 1 Jul 12:56

Re: TIP #321: Add a tk::busy Command

Jos Decoster skrev:
>  TIP #321: ADD A TK::BUSY COMMAND 
[snip]
>  HOLD SUBCOMMAND 
> -----------------
> 
>        *tk::busy* /window/ ?/option value/? 
> 
>        *tk::busy hold* /window/ ?/option value/? 
> 
>  Makes the widget window (and its descendants in the Tk window 
>  hierarchy) busy. /Window/ must be a valid path name of a Tk widget. The 
>  busy window is mapped the next time idle tasks are processed, and the 
>  widget and its descendants will be blocked from user interactions. 

This TIP seems to be written with the presumption that the reader 
already knows how the blt::busy command works -- is that acceptable?

What I find particularly confusing is this part about the "busy 
window". Is it the /window/ in this call, or is it rather some new 
window that is used to cover the /window/ (thus blocking events), or 
what? In the latter case, does this "busy window" have a name?

[snip]
>  FORGET SUBCOMMAND 
> -------------------
> 
>        *tk::busy forget* /window/ 
> 
>  RELEASE SUBCOMMAND

(Continue reading)

headers

Jos Decoster | 1 Jul 13:36

Re: TIP #321: Add a tk::busy Command

Hi Lars,

> This TIP seems to be written with the presumption that the reader
> already knows how the blt::busy command works -- is that acceptable?
>
> What I find particularly confusing is this part about the "busy
> window". Is it the /window/ in this call, or is it rather some new
> window that is used to cover the /window/ (thus blocking events), or
> what? In the latter case, does this "busy window" have a name?

I'll try to clarify that in the TIP.

>>        *tk::busy forget* /window/
>>        *tk::busy release* /window/
>
> In the pre-discussion, it seemed that these commands provided duplicate
> functionality, i.e., some users always used one and some users always
> used the other, the difference merely being how much resources are
> released. The TIP should probably comment upon this issue, e.g. whether
> it would be feasible to unify the two, and if not, then why.

My first tought about this was to only keep the 'forget' command and
simplify the 'isbusy' / 'names' / 'status' commands. But I changed my
mind to be more compatible with the blt commands. A minimal command
set would be:

tk::busy hold <window>  (make busy)
tk::busy forget <window> (back to normal, with freeing of all
resources allocated in hold)
tk::busy cget <window> <option>

(Continue reading)