Menu
▾
▴
tcl-core
|
From: Donal K. F. <don...@ma...> - 2008-11-21 16:05:38
|
This is a Call For Votes on the following "small and practical" TIPs that I identified from my message earlier this week. (The other ones are in the process of being baked more.) TIP #171: Change Default <MouseWheel> Bindings Behavior TIP #197: Text Widget Persistant Cursor TIP #210: Add 'tempname' Subcommand to 'file' TIP #238: Fire Event when Widget Created TIP #284: New 'invoke' and 'namespace invoke' Commands TIP #306: Auto-Naming Widgets TIP #307: Make TclTransferResult() Public TIP #335: An API for Detecting Active Interpreters TIP #336: Supported Access To interp->errorline TIP #337: Make TclBackgroundException() Public TIP #338: Embedder Access to Startup Scripts of *_Main() Please send your votes to the tcl-core mailing list by 12:00 GMT next Friday (i.e. [clock format 1227873600]). My votes follow: TIP #171: YES TIP #197: YES TIP #210: YES TIP #238: YES TIP #284: YES TIP #306: YES TIP #307: YES TIP #335: YES TIP #336: YES TIP #337: YES TIP #338: YES Donal. |
|
From: Jan N. <nij...@us...> - 2008-11-21 16:55:19
|
2008/11/21 Donal K. Fellows <don...@ma...>:
> This is a Call For Votes on the following "small and practical" TIPs
> that I identified from my message earlier this week. (The other ones are
> in the process of being baked more.)
I cannot find a reason to reject any of those..... so:
TIP #171: YES
TIP #197: YES
TIP #210: YES
TIP #238: YES
TIP #284: YES
TIP #306: YES
TIP #307: YES
TIP #335: YES
TIP #336: YES
TIP #337: YES
TIP #338: YES
Some small remark about TIP #338 (there is no patch submitted, so I just
mention it here........)
> There will need to be some care taken for existing users of these routines via
> the private stubs table. The ability to compile against Tcl 8.6 headers, yet
> run against a pre-8.6 stubs table will likely be lost.
I think that problem can be prevented by changing genStubs.tcl.
currently we generate:
#ifndef Tcl_SetStartupScript
#define Tcl_SetStartupScript \
(tclIntStubsPtr->tcl_SetStartupScript) /* 178 */
#endif
change that to:
#undef Tcl_SetStartupScript
#define Tcl_SetStartupScript \
(tclIntStubsPtr->tcl_SetStartupScript) /* 178 */
Then we have this feature for all such functions.
Then, if someone somehow includes tclInt.h, the version in the
private stub table will be taken, otherwise the one in the public stub
table. Source compatibility restored :-)
Regards,
Jan Nijtmans
|
|
From: <dg...@ni...> - 2008-11-21 18:16:29
|
Quoting "Jan Nijtmans" <nij...@us...>: > Some small remark about TIP #338 (there is no patch submitted, ... Just for the record, the patch isn't submitted yet since I haven't yet set aside time to puzzle out the thread-safety issues. If done wrong, exposure of these routines will lead to a repeat of Tcl Bug 801429. DGP |
|
From: Joe E. <jen...@fl...> - 2008-11-21 18:47:39
|
Donal K. Fellows wrote: > TIP #210: Add 'tempname' Subcommand to 'file' TIP#210: YES. > TIP #307: Make TclTransferResult() Public > TIP #337: Make TclBackgroundException() Public > TIP #338: Embedder Access to Startup Scripts of *_Main() TIP #307: YES. TIP #337: YES. TIP #338: YES. Useful stuff from the private interface that deserves to be public. > TIP #336: Supported Access To interp->errorline TIP #336: YES. Opaque Tcl_Interp *s at last! > TIP #306: Auto-Naming Widgets TIP#306: NO. This one does not play nicely with third-party widget sets or with megawidget packages. For the former, it places additional constraints on widget constructors. I have no idea how it will interact with the latter, though I suspect the answer is "not very well". I did a quick spot-check: with the proposed patch, tktable and the tile widgets automagically start supporting autonaming -- but only by accident -- while canvas3d, all BLT widgets, and tkhtml will break in new and exciting ways if you try to use the autonaming feature. I don't believe the proposed feature -- a minor convenience that only works some of the time -- is worth adding. > TIP #284: New 'invoke' and 'namespace invoke' Commands TIP#284: SEND IT BACK. I don't think this one got the API right, and it doesn't appear to add any new functionality. If "SEND IT BACK" is not a legal vote, then: TIP#284: NO. I need to think about these some more: > TIP #335: An API for Detecting Active Interpreters I thought this was going to be amended to specify Tcl_IsInterpActive() instead of Tcl_GetNumLevels(). The title of the TIP changed, but not the specification? TIP#335: TENTATIVE NO. If it's amended to specify Tcl_IsInterpActive() or something similar, then YES. > TIP #171: Change Default <MouseWheel> Bindings Behavior Definitely need to look at this some more. It just doesn't smell right to me. One thing in particular: instead of going through all sorts of rigamarole at the scripting level to redirect MouseWheel events to the widget under the pointer on Windows, wouldn't it make more sense to simply not redirect them to the focus window in the first place (see tkEvent.c, InvokeFocusHandlers)? That's how it's currently done on OSX. I suspect it also interferes with some of the ttk::* widgets. > TIP #197: Text Widget Persistant Cursor > TIP #238: Fire Event when Widget Created Don't know yet. --Joe English jen...@fl... |
|
From: Donald G P. <dg...@ni...> - 2008-11-24 18:01:52
|
Quick ones first: TIP #171: Change Default <MouseWheel> Bindings Behavior TIP #171: PRESENT TIP #197: Text Widget Persistant Cursor TIP #197: PRESENT TIP #238: Fire Event when Widget Created TIP #238: PRESENT TIP #306: Auto-Naming Widgets TIP #306: PRESENT TIP #307: Make TclTransferResult() Public TIP #307: YES TIP #335: An API for Detecting Active Interpreters TIP #335: YES TIP #336: Supported Access To interp->errorline TIP #336: YES TIP #337: Make TclBackgroundException() Public TIP #337: YES TIP #338: Embedder Access to Startup Scripts of *_Main() TIP #338: YES Still pondering the other two. -- | Don Porter Mathematical and Computational Sciences Division | | don...@ni... Information Technology Laboratory | | http://math.nist.gov/~DPorter/ NIST | |______________________________________________________________________| |
|
From: Donald G P. <dg...@ni...> - 2008-11-24 18:40:22
|
Donal K. Fellows wrote: >> TIP #210: Add 'tempname' Subcommand to 'file' TIP #210: NO I'd love to say yes, but I'm going to let deadline rush convince me to back garbage. The implementation patch does not apply to the head. Basic examination reveals that the patch does not implement what's proposed in the TIP. Not even the subcommand name is the same. So I have no patch to review, and no confidence about what's really proposed here. NO (NOT READY FOR REVIEW, LET ALONE VOTING) -- | Don Porter Mathematical and Computational Sciences Division | | don...@ni... Information Technology Laboratory | | http://math.nist.gov/~DPorter/ NIST | |______________________________________________________________________| |
|
From: Donald G P. <dg...@ni...> - 2008-11-24 18:59:47
|
Donal K. Fellows wrote: >> TIP #284: New 'invoke' and 'namespace invoke' Commands TIP #284: INCOMPLETE The patch implements only a [namespace invoke] command and not the [invoke] command that is also proposed. I'm ambivalent on the value of these additions. A chance to try it out might give me the interface confidence to push me off the fence. Since that's not a legal vote, I'll say TIP #284: NO -- | Don Porter Mathematical and Computational Sciences Division | | don...@ni... Information Technology Laboratory | | http://math.nist.gov/~DPorter/ NIST | |______________________________________________________________________| |
|
From: Donald G P. <dg...@ni...> - 2008-11-24 19:03:40
|
Donald G Porter wrote: > Donal K. Fellows wrote: >>> TIP #284: New 'invoke' and 'namespace invoke' Commands > > TIP #284: INCOMPLETE In the spirit of TIP 323, if TIP 284 does get approval, I'd like the "cmd" argument to be optional, and have [*invoke] Do Nothing Gracefully when given no command to invoke. -- | Don Porter Mathematical and Computational Sciences Division | | don...@ni... Information Technology Laboratory | | http://math.nist.gov/~DPorter/ NIST | |______________________________________________________________________| |
|
From: Donal K. F. <don...@ma...> - 2008-11-24 22:22:26
|
Donald G Porter wrote: > TIP #210: NO > > I'd love to say yes, but I'm going to let deadline > rush convince me to back garbage. > > The implementation patch does not apply to the head. > > Basic examination reveals that the patch does not > implement what's proposed in the TIP. Not even > the subcommand name is the same. Of course it doesn't. I fixed the TIP rather than futzing around with a patch that's utterly wrong in many ways that were identified years ago. If the TIP was of the functionality in the patch, I'd vote against it. Donal. |
|
From: Donald G P. <dg...@ni...> - 2008-11-24 22:32:13
|
Donal K. Fellows wrote: > Of course it doesn't. I fixed the TIP rather than futzing around with a > patch that's utterly wrong in many ways that were identified years ago. > If the TIP was of the functionality in the patch, I'd vote against it. OK, then the remaining flaw in the TIP is that it still references the broken implementation. -- | Don Porter Mathematical and Computational Sciences Division | | don...@ni... Information Technology Laboratory | | http://math.nist.gov/~DPorter/ NIST | |______________________________________________________________________| |
|
From: Koen D. <ko...@re...> - 2008-11-25 13:58:28
|
Joe English wrote:
> TIP#306: NO.
>
> This one does not play nicely with third-party widget sets
> or with megawidget packages. For the former, it places additional
> constraints on widget constructors. I have no idea how
> it will interact with the latter, though I suspect the answer
> is "not very well".
The TIP describes how mega-widget packages can support the auto-naming scheme. It's really a minor effort.
When the TIP was first discussed on this list, Will Duquette (the author of Snit) said he would like to see it happen.
Note that the TIP doesn't break compatibility: any application that works today (which obviously doesn't use auto-naming), will continue to work in the future.
>> TIP #171: Change Default <MouseWheel> Bindings Behavior
>
> Definitely need to look at this some more. It just
> doesn't smell right to me. One thing in particular:
> instead of going through all sorts of rigamarole at
> the scripting level to redirect MouseWheel events
> to the widget under the pointer on Windows, wouldn't
> it make more sense to simply not redirect them to
> the focus window in the first place (see tkEvent.c,
> InvokeFocusHandlers)? That's how it's currently done
> on OSX. I suspect it also interferes with some of
> the ttk::* widgets.
In the past, there has been some discussion about this TIP, and several potential issues were raised. For example, the current implementation goes in an infinite loop with the following simple code:
pack [text .t]
bind .t <MouseWheel> {puts "wheel"}
# Now try to scroll the text widget with the mousewheel
Part of the discussion involved promoting the <MouseWheel> event to <Tab> status, but there was no agreement on that. Nevertheless, it seems this TIP is going to be accepted now...
I agree with Joe that an alternative approach would be better: redirecting the mousewheel events to the widget under the mouse pointer. In fact, I'm already doing that (in my own Tk builds) since a long time. See below for the patch.
--Koen
Index: generic/tkEvent.c
===================================================================
RCS file: /cvsroot/tktoolkit/tk/generic/tkEvent.c,v
retrieving revision 1.37
diff -u -r1.37 tkEvent.c
--- generic/tkEvent.c 8 Nov 2008 18:44:39 -0000 1.37
+++ generic/tkEvent.c 25 Nov 2008 11:34:05 -0000
@@ -246,17 +246,7 @@
return 1;
}
- /*
- * MouseWheel events are not focus specific on Mac OS X.
- */
-
-#ifdef MAC_OSX_TK
-#define FOCUS_DIRECTED_EVENT_MASK (KeyPressMask|KeyReleaseMask)
-#else
-#define FOCUS_DIRECTED_EVENT_MASK (KeyPressMask|KeyReleaseMask|MouseWheelMask)
-#endif
-
- if (mask & FOCUS_DIRECTED_EVENT_MASK) {
+ if (mask & (KeyPressMask|KeyReleaseMask)) {
(*winPtrPtr)->dispPtr->lastEventTime = eventPtr->xkey.time;
*winPtrPtr = TkFocusKeyEvent(*winPtrPtr, eventPtr);
if (*winPtrPtr == NULL) {
Index: win/tkWinX.c
===================================================================
RCS file: /cvsroot/tktoolkit/tk/win/tkWinX.c,v
retrieving revision 1.58
diff -u -r1.58 tkWinX.c
--- win/tkWinX.c 27 Apr 2008 22:39:17 -0000 1.58
+++ win/tkWinX.c 25 Nov 2008 11:34:08 -0000
@@ -1006,6 +1006,16 @@
ThreadSpecificData *tsdPtr = (ThreadSpecificData *)
Tcl_GetThreadData(&dataKey, sizeof(ThreadSpecificData));
+ /* Redirect mousewheel events to the widget under the pointer. */
+ if (message == WM_MOUSEWHEEL) {
+ POINTS rootPoint = MAKEPOINTS(lParam);
+ POINT pos;
+ pos.x = rootPoint.x;
+ pos.y = rootPoint.y;
+ hwnd = WindowFromPoint(pos);
+ winPtr = (TkWindow *) Tk_HWNDToWindow(hwnd);
+ }
+
if (!winPtr || winPtr->window == None) {
return;
}
@@ -1103,11 +1113,6 @@
break;
case WM_MOUSEWHEEL:
- /*
- * The mouse wheel event is closer to a key event than a mouse event
- * in that the message is sent to the window that has focus.
- */
-
case WM_CHAR:
case WM_UNICHAR:
case WM_SYSKEYDOWN:
|
|
From: Jeff H. <je...@ac...> - 2008-11-25 20:21:15
|
Koen Danckaert wrote: > Joe English wrote: >> TIP#306: NO. >> >> This one does not play nicely with third-party widget sets or with >> megawidget packages. For the former, it places additional >> constraints on widget constructors. I have no idea how it will >> interact with the latter, though I suspect the answer is "not very >> well". > > The TIP describes how mega-widget packages can support the > auto-naming scheme. It's really a minor effort. > > When the TIP was first discussed on this list, Will Duquette (the > author of Snit) said he would like to see it happen. > > Note that the TIP doesn't break compatibility: any application that > works today (which obviously doesn't use auto-naming), will continue > to work in the future. This is so blatantly wrong with a 30 second glance at what's important that anyone who voted yes deserves a right spanking. This TIP would break BWidgets, and I don't need to look any further. The TIP blatantly warns on this issue. Stop the insanity and poor thinking - you break something as basic as that, you will _not_ make a happy community. Jeff |
|
From: Donal K. F. <don...@ma...> - 2008-11-25 20:56:46
|
Jeff Hobbs wrote: > This is so blatantly wrong with a 30 second glance at what's important > that anyone who voted yes deserves a right spanking. This TIP would > break BWidgets, and I don't need to look any further. The TIP blatantly > warns on this issue. Stop the insanity and poor thinking - you break > something as basic as that, you will _not_ make a happy community. I've been thinking about this in more depth too, and I've remembered something about the (rather nasty) guts of Tk that pertains. Every component of a Tk pathname (i.e. 'a', 'b' and 'c' from '.a.b.c') is a Tk_Uid. I've no idea why, but it's how it is; might be related to option database handling I suppose. What this means is that if you are generating pathnames using a counter you've got a memory leak that you cannot plug. (Or at least not short of firing up Tk in a new thread and discarding the entire old one!) This means that production code really ought instead to be reusing names as much as possible, and yet the auto-naming feature was always something that's only really useful for production code in the first place. Now, I don't know about you, but I reckon that a "production-only" feature that production-level code shouldn't use is a bit silly. And fixing this is really hard (the Tk_Uid mess is the worst mistake in Tk by far, in particular because it is wormed in so deep) and certainly won't happen in a minor release. Alas, this means I'm changing my vote. TIP#306: NO (a double-whammy of problems with megawidgets and Tk_Uid) I just wish I'd thought about this earlier. :-( Donal. |
|
From: Jeff H. <je...@ac...> - 2008-11-25 22:10:04
|
Donal K. Fellows wrote: > Every component of a Tk pathname (i.e. 'a', 'b' and 'c' from '.a.b.c') > is a Tk_Uid. I've no idea why, but it's how it is; might be related to > option database handling I suppose. What this means is that if you are > generating pathnames using a counter you've got a memory leak that you > cannot plug. (Or at least not short of firing up Tk in a new thread and > discarding the entire old one!) This means that production code really > ought instead to be reusing names as much as possible, and yet the > auto-naming feature was always something that's only really useful for > production code in the first place. > > Now, I don't know about you, but I reckon that a "production-only" > feature that production-level code shouldn't use is a bit silly. And > fixing this is really hard (the Tk_Uid mess is the worst mistake in Tk > by far, in particular because it is wormed in so deep) and certainly > won't happen in a minor release. For reference, Tk_Uids are a compat layer over XIds, unique atoms from a time when 128MB of memory was a lot. They are like refcounting strings in a way. However, Tk's use of them hasn't been the most friendly, and indeed downright contradictory (canvas items are Tk_Uids, but are monotonically increasing numbers). Tcl_Objs would be the better fit (introduced years later to Tcl), but they can't replace Tk_Uids in place. :-/ Jeff |
|
From: Jan N. <jan...@gm...> - 2008-11-25 23:47:55
|
2008/11/25 Jeff Hobbs <je...@ac...>:
> This is so blatantly wrong with a 30 second glance at what's important
> that anyone who voted yes deserves a right spanking. This TIP would
> break BWidgets, and I don't need to look any further. The TIP blatantly
> warns on this issue. Stop the insanity and poor thinking - you break
> something as basic as that, you will _not_ make a happy community.
Please, don't spank me.... ;-)
I'm not that familiar with BWidgets, but the given arguments
convince me to change my vote to NO as well.....
Regards,
Jan Nijtmans
|
|
From: Jeff H. <je...@ac...> - 2008-11-25 23:55:34
|
Jan Nijtmans wrote: > 2008/11/25 Jeff Hobbs <je...@ac...>: >> This is so blatantly wrong with a 30 second glance at what's important >> that anyone who voted yes deserves a right spanking. This TIP would >> break BWidgets, and I don't need to look any further. The TIP blatantly >> warns on this issue. Stop the insanity and poor thinking - you break >> something as basic as that, you will _not_ make a happy community. > > Please, don't spank me.... ;-) > > I'm not that familiar with BWidgets, but the given arguments > convince me to change my vote to NO as well..... Let me note that I strongly favor some auto-naming of widgets. I advocate it and use it in the Perl/Tkx binding that I wrote. However, it conflicts with years of standard coding style in Tcl, especially wrt megawidget libraries. After looking a little further, snidgets could be made to support this at the base level in one code spot (the advantage of such a system). However, many older systems spread out there widget creation among the widgets in a way that is more fragile. Shall I take the opportunity to push TIP#180 again? ;) Jeff |
|
From: Damon C. <da...@tc...> - 2008-11-26 00:30:40
|
> Let me note that I strongly favor some auto-naming of widgets. I
> advocate it and use it in the Perl/Tkx binding that I wrote. However,
> it conflicts with years of standard coding style in Tcl, especially
> wrt
> megawidget libraries. After looking a little further, snidgets
> could be
> made to support this at the base level in one code spot (the advantage
> of such a system). However, many older systems spread out there
> widget
> creation among the widgets in a way that is more fragile.
>
> Shall I take the opportunity to push TIP#180 again? ;)
I would like to note that not only should TIP 180 support the
auto-naming of widgets, I would go one step further and say that TIP
180 should also support some sort of standard, default option on all
widgets to create an "alias" of sorts. Then, I would add a single
configure command that handles them.
90% of the widgets created in Tk are forgotten in the code
because we don't care or need to know anything about them. This is
made even more so by things like -variable and -textvariable which
almost let us completely ignore the widget itself. For the other 10%,
we all end up coding some crap like:
global w
set w(myEntry) [entry .e]
$w(myEntry) configure -background blue
This is where the new option comes in. Something like:
entry .e -alias myEntry
configure myEntry -background blue
Throw in the auto-naming stuff, and you've got yourself a nice
way to work with what you care about and lose the rest in the noise.
D
|
|
From: Jeff H. <je...@ac...> - 2008-11-26 00:41:38
|
Damon Courtney wrote:
>> Let me note that I strongly favor some auto-naming of widgets. I
>> advocate it and use it in the Perl/Tkx binding that I wrote. However,
>> it conflicts with years of standard coding style in Tcl, especially
>> wrt
>> megawidget libraries. After looking a little further, snidgets
>> could be
>> made to support this at the base level in one code spot (the advantage
>> of such a system). However, many older systems spread out there
>> widget
>> creation among the widgets in a way that is more fragile.
>>
>> Shall I take the opportunity to push TIP#180 again? ;)
>
> I would like to note that not only should TIP 180 support the
> auto-naming of widgets, I would go one step further and say that TIP
> 180 should also support some sort of standard, default option on all
> widgets to create an "alias" of sorts. Then, I would add a single
> configure command that handles them.
>
> 90% of the widgets created in Tk are forgotten in the code
> because we don't care or need to know anything about them. This is
> made even more so by things like -variable and -textvariable which
> almost let us completely ignore the widget itself. For the other 10%,
> we all end up coding some crap like:
>
> global w
>
> set w(myEntry) [entry .e]
> $w(myEntry) configure -background blue
>
> This is where the new option comes in. Something like:
>
> entry .e -alias myEntry
> configure myEntry -background blue
>
> Throw in the auto-naming stuff, and you've got yourself a nice
> way to work with what you care about and lose the rest in the noise.
Skip -alias, consider -tags (would any known widget conflict at the
widget creation level?).
button .b -tags toolbar
button .c -tags {toolbar edge}
configure toolbar -state disabled
...
I simulate this at the higher level now. It may be asking too much for
8.6, but possibly worth considering.
Jeff
|
|
From: Damon C. <da...@tc...> - 2008-11-26 00:44:28
|
> Skip -alias, consider -tags (would any known widget conflict at the
> widget creation level?).
>
> button .b -tags toolbar
> button .c -tags {toolbar edge}
> configure toolbar -state disabled
> ...
>
> I simulate this at the higher level now. It may be asking too much
> for 8.6, but possibly worth considering.
Yes. My brain was moving too fast when I posted, but this is
exactly what I recommend. In fact, I use a system I wrote called
Tktags that does just this sort of thing. In fact, it does exactly
what you describe here except for the fact that you have to tag the
widgets yourself since they don't support a -tags option.
Damon
|
|
From: Jeff H. <je...@ac...> - 2008-11-26 00:47:00
|
Damon Courtney wrote:
>> Skip -alias, consider -tags (would any known widget conflict at the
>> widget creation level?).
>>
>> button .b -tags toolbar
>> button .c -tags {toolbar edge}
>> configure toolbar -state disabled
>> ...
>>
>> I simulate this at the higher level now. It may be asking too much
>> for 8.6, but possibly worth considering.
>
> Yes. My brain was moving too fast when I posted, but this is
> exactly what I recommend. In fact, I use a system I wrote called
> Tktags that does just this sort of thing. In fact, it does exactly
> what you describe here except for the fact that you have to tag the
> widgets yourself since they don't support a -tags option.
The benefit of external tagging is that any widget can be tagged (even
older ones). This is why I like how tklib tooltip works. Should we add
a -tooltip to widgets, or ?
Jeff
|
|
From: Damon C. <da...@tc...> - 2008-11-26 05:20:49
|
> The benefit of external tagging is that any widget can be tagged
> (even older ones). This is why I like how tklib tooltip works.
> Should we add a -tooltip to widgets, or ?
Ok, then. So, I've already got a package that does the external
tagging, and it does a pretty good job of it too. Should we just push
that toward tklib and then work on pushing both the tooltip and tags
stuff into the ::tk namespace for core inclusion?
I do sort of like the process of vetting an extension through the
(tk|tcl)libs before core inclusion as it not only works the kinks out
but gets real-world use and some feedback.
My current package adds a tag and a configure command to the root
namespace, but they can just easily go into ::tk or whatever.
::tk::tag add foo .e1 .e2
::tk::tag configure foo -state disabled
etc...
D
|
|
From: Eric B. <eri...@fr...> - 2008-11-27 01:25:13
|
Damon Courtney a écrit :
>> The benefit of external tagging is that any widget can be tagged
>> (even older ones). This is why I like how tklib tooltip works.
>> Should we add a -tooltip to widgets, or ?
>>
>
> Ok, then. So, I've already got a package that does the external
> tagging, and it does a pretty good job of it too. Should we just push
> that toward tklib and then work on pushing both the tooltip and tags
> stuff into the ::tk namespace for core inclusion?
>
> I do sort of like the process of vetting an extension through the
> (tk|tcl)libs before core inclusion as it not only works the kinks out
> but gets real-world use and some feedback.
>
> My current package adds a tag and a configure command to the root
> namespace, but they can just easily go into ::tk or whatever.
>
> ::tk::tag add foo .e1 .e2
>
> ::tk::tag configure foo -state disabled
>
> etc...
>
>
Hello,
I use another package which abstracts even more things:
To invoke do_something whenever file_open changes:
appstate bind file_open do_something
To toggle state of .e1 and .e2 according to file_open and readonly:
appstate bindstate {file_open && !readonly} .e1 .e2
Just change the variable, and the GUI is updated, like -textvariable:
appstate set file_open 1
...
--
Eric
|
|
From: Donal K. F. <don...@ma...> - 2008-11-26 09:03:00
|
Jeff Hobbs wrote: > Shall I take the opportunity to push TIP#180 again? ;) Thinking about it, I suspect that what we get out of #180 isn't going to be in 8.6 as we just haven't got the time to finish cooking it before beta. On the other hand we should push on and get it into tklib (well, assuming we can now do it in pure Tcl). Like that it can get the public exposure it needs to get its feature set finalized, and we can see what *actually* is too slow for Tcl... It's a shame, as I'd identified #180 as important. Ho hum. Donal. |
|
From: Will D. <wi...@wj...> - 2008-11-26 01:22:51
|
On Nov 25, 2008, at 12:22 PM, Jeff Hobbs wrote:
> Koen Danckaert wrote:
>> Joe English wrote:
>>> TIP#306: NO.
>>>
>>> This one does not play nicely with third-party widget sets or with
>>> megawidget packages. For the former, it places additional
>>> constraints on widget constructors. I have no idea how it will
>>> interact with the latter, though I suspect the answer is "not very
>>> well".
>>
>> When the TIP was first discussed on this list, Will Duquette (the
>> author of Snit) said he would like to see it happen.
I vaguely recall that; and Snit does indeed support autonaming of
widgets using the %AUTO% syntax, e.g., [label $win.%AUTO%]. I
don't recall ever looking at the syntax shown in the TIP, though;
and using a single "%" character as the string to be replaced
strikes me as asking for trouble.
Will
------------------------------------------------------------------
will -at- wjduquette.com | Catch our weblog,
http://foothills.wjduquette.com/blog | The View from the Foothills
|
|
From: Michael K. <mi...@mu...> - 2008-11-26 02:08:15
|
On the auto-naming of widgets, I've long felt that it's a bit silly we have to name them ourselves at all. I don't care what the widget names are, only that I know what they are so I can interact with them. If I'm caring what the actual name is, it probably means I've hardcoded it in several places, which is going to make it a hassle to modify the code later to restructure/extend the GUI. I'd prefer to let the parent in the hierarchy do the naming. Perhaps this would largely be a matter just of convention, or perhaps there would be a wrapper around Tcl_CreateObjCommand to create widget commands that handle this automatically, but I would suggest: 1. A widget creation command (e.g. "frame"), when given no arguments or the first argument doesn't start with ".", gets a fully automatic name assignment that's a child of "." (or a child of nothing if a toplevel). e.g., set top [toplevel] ;# -> .toplevel1 set frame [frame] ;# -> .frame1 set frame [frame] ;# -> .frame2 set frame [frame .f] ;# -> .f 2. The parent should be capable of creating widgets and assigning names to them in its hierarchy itself. Maybe this would be done with a subcommand specified to that Tcl_CreateObjCommand wrapper (Tk_CreateWindowObjCommand?), or maybe something like "." as a subcommand is suitably unique and (pardon the pun) on point: set top [toplevel] ;# -> .toplevel1 set frame [$top . frame] ;# -> .toplevel1.frame1 set button [$frame . button] ;# -> .toplevel1.frame1.button1 The wrapper would see that "." is the first argument and treat the second argument as a widget creation command (no matter what it is), inserting a unique name as its first argument (or, I guess, treat the first two as ensembles). 3. Maybe, for cases where you actually do care what the name is, extend (1) and (2) a little bit such that if the first argument doesn't start with "-" and doesn't contain any dots, then it's a parent-relative name: set bob [frame bob] ;# -> .bob set top [toplevel] ;# -> .toplevel1 set bob [$top . frame bob] ;# -> .toplevel1.bob set ok [$bob . button ok] ;# -> .toplevel1.bob.ok -- Michael Kirkham President & CEO Muonics, Inc. http://www.muonics.com/ |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X