[MACTCL] TIP#321 (Was: [TCLCORE] CFV: Many many TIPs!)

[Daniel A. S. <da...@us...>]

On 10/09/2008, at 23:35, Donal K. Fellows wrote:

>   TIP #321: Add a tk::busy Command
>     http://tip.tcl.tk/
>   Why not?
>

> TIP#321: YES

AFAIK this TIP has unresolved outstanding issues w.r.t implementation  
on TkAqua, certainly the existing BLT code makes no sense at all for  
aqua, we cannot create a transparent subwindow on top of existing  
content as desired (there is no concept of real subwindows a la  
XWindow/HWND of a toplevel in the TkAqua implementation, these things  
are all completely emulated...).

The API and whole concept of the TIP appears very tightly bound to  
that implementation choice, so I have some difficulty seeing how one  
would come up with an alternative approach that could still fit the  
proposed API.

There is certainly the existing concept of disabled state for widgets,  
not sure why extending/generalizing that was not considered for this  
TIP, making parts of a window appear busy via this mechanism would fit  
the platfrom L&F on aqua much better for one.
In fact there appears to be no consideration for widget L&F when busy  
in the TIP at all (except for optionally setting the cursor), which is  
something that goes strongly against established UI conventions on the  
platform.

Another platform-appropriate option could be to make a whole toplevel  
busy by pulling down a sheet (window-modal dialog) e.g. containing an  
indeterminate progress bar. This would automatically result in the  
disabled L&F for the widgets in the underlying toplevel, but would not  
work as a solution to only make parts of a toplevel busy

There are certainly other Tk TIPs that have been accepted and then  
proved to be unimplementable on TkAqua (e.g. [wm manage/forget]), so  
this issue may not be an strong argument against accepting the TIP.  
Unfortunately I have no time at all at the moment to investigate this  
in more detail and/or come up with an alternative proposal...

Cheers,

Daniel

-- 
** Daniel A. Steffen                   **
** <mailto:da...@us...>  **