"cargo" (alias "tag") - a suggestion for 8.6-final
ZB
#v+
-tags tagList
Specifies a set of tags to apply to the item. TagList consists of a list
of tag names, which replace any existing tags for the item. TagList may
be an empty list.
#v-
I'm wondering, could it be hard to equip every widget with such ability?
It would be quite useful, to have the possibility to add arbitrary value
(could be even limited to text, like in case of canvas tags) inserted in
such "cargo" field (so it was named in Clipper).
--
ZB
Neil Madden
There already is such an ability:
set myfield($widget) $somevalue
If you want the variable to be tied to the lifetime of the widget, then
use a command delete trace on the widget.
-- Neil
ZB
> There already is such an ability:
>
> set myfield($widget) $somevalue
>
> If you want the variable to be tied to the lifetime of the widget, then
> use a command delete trace on the widget.
I suppose that you see, it's not what I meant. One could ask, for example:
"why this tag in canvas items, when one can set mytag($c_item) $somevalue".
--
ZB
Neil Madden
> Dnia 08.04.2009 Neil Madden <n...@cs.nott.ac.uk> napisał/a:
>
>> There already is such an ability:
>>
>> set myfield($widget) $somevalue
>>
>> If you want the variable to be tied to the lifetime of the widget, then
>> use a command delete trace on the widget.
>
> I suppose that you see, it's not what I meant. One could ask, for example:
> "why this tag in canvas items, when one can set mytag($c_item) $somevalue".
Because canvas tags carry style (options) and behaviour (bindings) that
the canvas needs to know about. If you want either of these things for
arbitrary widgets then look at the Ttk stuff (styles) and bindtags
(behaviour). If you just want to associate arbitrary data with a widget,
then use a variable.
-- Neil
dkf
> There already is such an ability:
>
> set myfield($widget) $somevalue
>
> If you want the variable to be tied to the lifetime of the widget, then
> use a command delete trace on the widget.
Or use a megawidget framework, which basically just hides that stuff
behind the scenes for you.
Donal.
ZB
> If you just want to associate arbitrary data with a widget,
> then use a variable.
You seem to (mis)understand, that I want to associate arbitrary data with
a widget "just to have them associated", and nothing more. Wrong.
Consider following example:
pack [button .b -command { puts %W } -text "Click me"]
I would to have after click just ".b" in response. But "bind substitutions"
doesn't work here (it's just an example! It's not the only situation).
Of course, such situation could be solved - if I recall properly, Kaitschu
gave nice tip - but my general idea is "solutions instead of workarounds".
And so the idea is to have such "cargo", and possibility to fetch its
contents using "bindings". According to example: I'm clicking the button
- and I can easily take the "cargo". Be it just widget name, or any other
data I can need.
The second example (still another example, that's not all) could be making
menus easier. Instead using option database, all the menu entries could be
queried directly, so there would be no more need for:
option add *#application#menubar#file.help $filehelp
The third one: "ballon help" could be also tied directly to any chosen
widget - instead of the need to search any table/list on each "mouse over"
event, there could be just quick check, whether "cargo" has any value... all
such situation can be handled more "natural", intuitive way.
Besides: OO is going to be introduced into new TCL. Wouldn't it be more
"in spirit of OO" to encapsulate such "cargo" into widget?
I can recall a discussion, where - if I remember correctly - DKF wrote,
that having influence on variable contents directly via associated widget
is great advantage of Tk (and indeed it is), so I really can't understand,
why actually avoid another great advantage.
Of course, unless it really requires dramatic changes(?) in the code - but
if not...?
--
ZB
Bryan Oakley
be a good idea. Yes, there are workarounds with variables, and yes one
could write a TclOO wrapper around every widget to get the same
effect, but why use a workaround when we could easily add this feature
to every widget? (And of course by "we" I mean "someone other than
myself" :-\ )
If nothing else, this would help with the maintainability of code.
Imagine a block of code like this:
someRandomWidget .container.top.foo ...
set cargo(.container.top.foo) "hello, world"
Now, if you decide to rename .container.top.foo you now have two
pieces of code you must update instead of one. Or, if you move the
lines of code into a procedure you now need to move two lines, and you
need to remember to declare cargo as global, etc.
Also, consider the case where, inside a binding you want to access
this information. Using the variable workaround you would have to do
something like:
proc handleEvent {w} {
global cargo
if {[info exists cargo($w)]} {
if {[dict exists $cargo($w) foo]} {
doSomethingClever
}
}
}
If instead this was a standard option, your code could now look like
this:
proc handleEvent {w} {
if {[dict exists [$w cget -cargo] foo]]} {
doSomethingClever
}
}
Personally I think the latter is an improvement. Of course I cheated
in the second example by assuming the widget has the -cargo option
which might not be true for all widgets (eg: extensions), and I could
do the same in the variable-based example by assuming that cargo($w)
exists. That being said, I still like the concept of attaching custom
data to a widget. From an application-writers perspective, this gives
more more flexibility with fewer lines of code, what's not to like
about that?
What sort of data would I potentially keep with a widget? Perhaps an
index that points to context sensitive help. Or, I might keep an undo
stack, or a copy of the original value. Think of a label widget that
automatically truncates it's text and adds "..." if the widget is
resized smaller than it's preferred size -- you need to keep the
unadulterated original value that you can refer to as the widget
grows and shrinks. Better to keep that with the widget than in a
global variable, IMO. Or, I could use it to keep track of a "dirty"
bit that gets set when the original value of a radiobutton or
checkbutton changes. Or I could store a database primary key that
points to where the data for the widget came from.
So, yeah, I think ZB's idea is a good one. I can think of lots of
benefits to this idea.
--bryan
Neil Madden
> Dnia 08.04.2009 Neil Madden <n...@cs.nott.ac.uk> napisał/a:
>
>> If you just want to associate arbitrary data with a widget,
>> then use a variable.
>
> You seem to (mis)understand, that I want to associate arbitrary data with
> a widget "just to have them associated", and nothing more. Wrong.
>
> Consider following example:
>
> pack [button .b -command { puts %W } -text "Click me"]
>
> I would to have after click just ".b" in response. But "bind substitutions"
> doesn't work here (it's just an example! It's not the only situation).
>
> Of course, such situation could be solved - if I recall properly, Kaitschu
> gave nice tip - but my general idea is "solutions instead of workarounds".
> And so the idea is to have such "cargo", and possibility to fetch its
> contents using "bindings". According to example: I'm clicking the button
> - and I can easily take the "cargo". Be it just widget name, or any other
> data I can need.
I'm not sure I understand what you are after. Can you provide some
pseudo-code showing what you want to achieve? It seems to me that you
want an extra option -cargo (or something) added to each widget, and for
binding scripts and -command callbacks to allow you to substitute this
value. Is that correct?
pack [button .b -cargo "Some data" -command {puts %C} -text "Click me"]
where %C is substituted with the value of the -cargo option?
>
> The second example (still another example, that's not all) could be making
> menus easier. Instead using option database, all the menu entries could be
> queried directly, so there would be no more need for:
>
> option add *#application#menubar#file.help $filehelp
>
> The third one: "ballon help" could be also tied directly to any chosen
> widget - instead of the need to search any table/list on each "mouse over"
> event, there could be just quick check, whether "cargo" has any value... all
> such situation can be handled more "natural", intuitive way.
Again, I don't understand either of these examples, or how they relate
to canvas tags.
> Besides: OO is going to be introduced into new TCL. Wouldn't it be more
> "in spirit of OO" to encapsulate such "cargo" into widget?
>
> I can recall a discussion, where - if I remember correctly - DKF wrote,
> that having influence on variable contents directly via associated widget
> is great advantage of Tk (and indeed it is), so I really can't understand,
> why actually avoid another great advantage.
>
> Of course, unless it really requires dramatic changes(?) in the code - but
> if not...?
Sure, you can use a mega-widget framework to associate arbitrary options
and other data with a widget. See snit, etc.
-- Neil
Neil Madden
> It looks like I'm in the minority in agreeing with ZB that this would
> be a good idea. Yes, there are workarounds with variables, and yes one
> could write a TclOO wrapper around every widget to get the same
> effect, but why use a workaround when we could easily add this feature
> to every widget? (And of course by "we" I mean "someone other than
> myself" :-\ )
>
> If nothing else, this would help with the maintainability of code.
> Imagine a block of code like this:
>
> someRandomWidget .container.top.foo ...
> set cargo(.container.top.foo) "hello, world"
>
> Now, if you decide to rename .container.top.foo you now have two
> pieces of code you must update instead of one. Or, if you move the
> lines of code into a procedure you now need to move two lines, and you
> need to remember to declare cargo as global, etc.
Umm...
proc mywidget {w args} {
someRandomWidget $w {*}$args
set ::cargo($w) "hello, world"
return $w
}
Is that really such a maintenance nightmare? Seems straight-forward to
me, and if that much coding is too much effort then just [package
require snit].
>
> Also, consider the case where, inside a binding you want to access
> this information. Using the variable workaround you would have to do
> something like:
>
> proc handleEvent {w} {
> global cargo
> if {[info exists cargo($w)]} {
> if {[dict exists $cargo($w) foo]} {
> doSomethingClever
> }
> }
> }
>
> If instead this was a standard option, your code could now look like
> this:
>
> proc handleEvent {w} {
> if {[dict exists [$w cget -cargo] foo]]} {
> doSomethingClever
> }
> }
This is a strawman -- if you're allowed to assume that the -cargo option
exists, then the other code can also assume that the cargo array element
exists:
proc handleEvent w {
if {[dict exists $::cargo($w) foo]} {
doSomethingClever
}
}
Even shorter!
>
> Personally I think the latter is an improvement. Of course I cheated
> in the second example by assuming the widget has the -cargo option
> which might not be true for all widgets (eg: extensions), and I could
> do the same in the variable-based example by assuming that cargo($w)
> exists. That being said, I still like the concept of attaching custom
> data to a widget. From an application-writers perspective, this gives
> more more flexibility with fewer lines of code, what's not to like
> about that?
Because then you have to pack all your data into a single option. Why do
that when you can use multiple variables or use a mega-widget extension
that provides arbitrary extension of a widget with new options and
methods? This seems like a solution in search of a problem, at least one
that isn't already adequately (and comprehensively) solved by other means.
Let's also not forget the major downside of a single -cargo option: what
happens when multiple extensions want to associate data with a single
widget? Do they just silently overwrite each other's data? Variables
already solve this problem: each extension has its own array of
associated data in its own namespace.
-- Neil
Andreas Leitgeb
freedom on the number and names of custom options.
There may be conventions, such as: start your custom options with
prefix "user", or risk that a new flag added by the maintainer (who
is advised *not* to add new options with "user") may collide at some
point in future. If the user wants, he can also add his "-foo" option,
but if that option is later added to the widget by the widget's
maintainer, the user must not whine :-)
> proc handleEvent {w} {
> if {[dict exists [$w cget -cargo] foo]]} {
> doSomethingClever
> }
> }
proc handleEvent {w} {
doSomethingClever [$w cget -foo]
}
ZB
> Is that really such a maintenance nightmare?
It's not because of "nightmare"; I wanted to propose a solution, that seems
(at least to me, and to Bryan) much more natural, is even a bit "OO-ish"
(everything kept in the same place), and will make the living of every
TCl-script creator easier. I suppose, it's far more intuitive, to look for
such "associated value" directly by testing some widget-parameter - instead
of an external variable.
Of course, we could compose such useful complex widgets (like panes) from
the simplest ones (label, frame...) - but that complex ones are there not
without a reason.
So, if it wouldn't mean much, much additional work - consider, please, if
such "cargo" could be worthy to add.
--
ZB
ZB
> I'm not sure I understand what you are after. Can you provide some
> pseudo-code showing what you want to achieve? It seems to me that you
> want an extra option -cargo (or something) added to each widget, and for
> binding scripts and -command callbacks to allow you to substitute this
> value. Is that correct?
>
> pack [button .b -cargo "Some data" -command {puts %C} -text "Click me"]
>
> where %C is substituted with the value of the -cargo option?
Yes, I would to have possibility to extract the contents of "cargo" both
using %C, and via "cget".
>> option add *#application#menubar#file.help $filehelp
>>
>> The third one: "ballon help" could be also tied directly to any chosen
>> widget - instead of the need to search any table/list on each "mouse over"
>> event, there could be just quick check, whether "cargo" has any value... all
>> such situation can be handled more "natural", intuitive way.
>
> Again, I don't understand either of these examples, or how they relate
> to canvas tags.
It's not related to canvas, it was just another example for how using
"cargo" will make another thing easier, and how one could use then more
"natural" methods to complete specific task.
> Sure, you can use a mega-widget framework to associate arbitrary options
> and other data with a widget. See snit, etc.
Yes, I'm aware of that - and you're aware, it's not I was talking about.
--
ZB
rfoxmich
widgets have a resource
XmNuserData which was a pointer to arbitrary data that could be
associated with the widget.
This was quite useful to me in my Motif days. It allowed callbacks to
be dynamically parameterized
(the parameterization of a callback on a widget can change with
time).
While you could argue that you could achieve the same result by
dynamically removing and reinstating
callbacks with a different static parameterization, that would require
that the code doing the re-parameterization know a lot more about the
widget, its properties and its extant callbacks than separation of
church and state should allow.
Yes, there are many other ways to accomplish this as Neil and Donal
point out. In Tcl/Tk if I need this I wrap the widget in a
snit::widget all in all being able to just send the widget itself to
an event handler and then extract widget specific data from the event
handler is, I think a useful thing, and makes generic event handlers
much easier to write, as well as the code that establishes them in the
first place.
On Apr 8, 11:32 am, ZB <zbREMOVE_THIS@AND_THISispid.com.pl> wrote:
> Dnia 08.04.2009 Neil Madden <n...@cs.nott.ac.uk> napisa³/a:
ZB
> I'd go even one step further, and allow complete (well, almost)
> freedom on the number and names of custom options.
Or - for example - it could be a list, like in case of canvas tags.
No idea, however, would be implementation of "cargo list" more painful
than single variable. If not (or not much) - list (or unlimited number,
as you propose) could give even more flexibility.
--
ZB
John Seal
news:slrngtp61h.2u7...@localhost.localdomain...
> The second example (still another example, that's not all) could be making
> menus easier. Instead using option database, all the menu entries could be
> queried directly, so there would be no more need for:
>
> option add *#application#menubar#file.help $filehelp
I don't recognize the # syntax in the option pattern; is it a way of
specifying options for menu entries? If so, would you point me to where
this is documented? Thanks.
Bryan Oakley
>
> Umm...
>
> proc mywidget {w args} {
> someRandomWidget $w {*}$args
> set ::cargo($w) "hello, world"
> return $w
> }
>
> Is that really such a maintenance nightmare?
yes.
You forgot to add support for reaping the variable when the widget
goes away. Yes, it's only a line of code but you forgot it. And so do
I sometimes. And that line of code needs to be tested. And I have to
write that wrapper for every widget. And ...
It's not a nightmare, but it's an opportunity for the core to make my
job easier. Adding user data to virtual events could be done with
global variables too, but the -data / %d features that were added were
quite useful. I think this request solves a problem of equal
magnitude.
> ...
> Let's also not forget the major downside of a single -cargo option: what
> happens when multiple extensions want to associate data with a single
> widget? Do they just silently overwrite each other's data? Variables
> already solve this problem: each extension has its own array of
> associated data in its own namespace.
Now *there's* a straw man! What if multiple extensions want to change
the label on a single widget? Or the text in my text or entry widget?
Do they just silently overwrite each others values? Youbetcha. What if
an extension chooses to use the same variable name I do? We can't
prevent such abuse, does that mean we shouldn't have any user settable
options at all for fear that some extension will overwrite them?
It sounds like you're saying "oh, that sounds so useful that many
people will want to use it, won't that be a problem?!?" (tongue
*firmly* planted in cheek :-)
Don't assume I'm looking for answers to any of the above questions,
I'm just giving food for thought.
Gerald W. Lester
We just need one (e.g. -userdata or -cargo or -whatever) because this is Tcl
and ETIAS. So if I need multiples, I pass the -userdata the string
representation of a dictionary.
--
+------------------------------------------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
ZB
> Yes, there are many other ways to accomplish this as Neil and Donal
> point out. In Tcl/Tk if I need this I wrap the widget in a
> snit::widget all in all being able to just send the widget itself to
> an event handler and then extract widget specific data from the event
> handler [..]
But wouldn't it be just "more natural" to have a possibility to just add
some value, that can be fetched back later?
--
ZB
Andreas Leitgeb
>>> I'd go even one step further, and allow complete (well, almost)
>>> freedom on the number and names of custom options.
>> Or - for example - it could be a list, like in case of canvas tags.
We *need* nothing (status quo), but it would be *convenient* to have a
-cargo option (whatever its name), and it would be *more convenient* to
be able to add any option that is not already used elsewhere, and thereby
getting rid of the extra dict-layer.
The second step subsumes the first one: if you can add any option, then
your can also add a -cargo / -userdata option, and store a dict inside
it, of course.
Again:
This thread is *not at all* about what anyone *needs*, but only about
a change in Tk that might make the life of programmers more convenient.
ZB
>> option add *#application#menubar#file.help $filehelp
>
> I don't recognize the # syntax in the option pattern; is it a way of
> specifying options for menu entries? If so, would you point me to where
> this is documented? Thanks.
It's a method patented ;) by Arndt Roger Schneider - from our
correspondence (a year ago):
The data is retrieved with option get <window> property defaultvalue
so in the previous example
option add *menu.help something
- ->
set help [option get .menu help nothing]
produces "something"
the important thing about menus is --however--
that the real menu .menu doesn't exist at all...
so the data is stored under the assumed "real" window name,
which uses # instead of . (dot) -- except for the first dot.
For more details you should ask Roger rather - except from a few exercises
at that time, since the option database solution wasn't too comfortable to
me, I was making my menus more "traditional way" (which doesn't mean "the
best", neither "most comfortable" one).
And because of this my sugestion; menus are example of task, that will be
easier to accomplish, and more intuitive way (menus, "balloons", etc.).
--
ZB
ZB
> We just need one (e.g. -userdata or -cargo or -whatever) because this is Tcl
> and ETIAS. So if I need multiples, I pass the -userdata the string
> representation of a dictionary.
So, it won't mean more work. Perhaps it could be added into incoming
8.6 then?
--
ZB
Don Porter
> So, it won't mean more work. Perhaps it could be added into incoming
> 8.6 then?
Tk 8.6 is feature frozen. Make your new feature plans for later releases.
--
| Don Porter Mathematical and Computational Sciences Division |
| donald...@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|______________________________________________________________________|
ZB
>> So, it won't mean more work. Perhaps it could be added into incoming
>> 8.6 then?
>
> Tk 8.6 is feature frozen. Make your new feature plans for later releases.
What a pity. :( So, perhaps in 8.7 then?
--
ZB
Bruce Hartweg
> Gerald W. Lester <Gerald...@cox.net> wrote:
>> ZB wrote:
>>> Dnia 08.04.2009 Andreas Leitgeb <a...@gamma.logic.tuwien.ac.at> napisa³/a:
>>>> I'd go even one step further, and allow complete (well, almost)
>>>> freedom on the number and names of custom options.
>>> Or - for example - it could be a list, like in case of canvas tags.
>> We just need one (e.g. -userdata or -cargo or -whatever)
>
> We *need* nothing (status quo), but it would be *convenient* to have a
> -cargo option (whatever its name),
agreed, not needed but convenient
and it would be *more convenient* to
> be able to add any option that is not already used elsewhere, and thereby
> getting rid of the extra dict-layer.
>
This I disagree with, by allowing multiple any random options
you lose the ability to abreviate options, and intorudce a whole
new class of simple typo bugs (e.g. where you silently get
a user data field called -wdith with a value of 50, and cannot
figure out why the widget size isn't behaving correctly)
Bruce
dkf
> But wouldn't it be just "more natural" to have a possibility to just add
> some value, that can be fetched back later?
Not really, especially if libraries and applications fight over the
value. That would actively be worse. Once you start doing the
machinery to manage options more thoroughly, you've got a large part
of the core of a megawidget system. But you could also just use Snit
without having to write lots of extra code. Hmmm...
Donal.
Gerald W. Lester
Andreas,
The need was in reference to how many options -- not if we can not do this
currently some other way.
dkf
> I don't recognize the # syntax in the option pattern; is it a way of
> specifying options for menu entries? If so, would you point me to where
> this is documented? Thanks.
It's a scheme that was first popularized, so far as I know, in the
book _Effective Tcl/Tk Programming_. It could have been in use in Itcl
before that.
Donal.
ZB
> On 8 Apr, 18:18, ZB <zbREMOVE_THIS@AND_THISispid.com.pl> wrote:
>> But wouldn't it be just "more natural" to have a possibility to just add
>> some value, that can be fetched back later?
>
> Not really, especially if libraries and applications fight over the
> value. That would actively be worse.
Why libraries and applications should be "fighting over the value" that
is controlled directly by user? That is, actually, not related to widget
at all - with a little exception, that it's kept by some kind of "widget's
container"?
I can't understand.
--
ZB
George Peter Staplin
Try implementing a megawidget using that, and then inherit the properties
and methods of that megawidget. The -cargo would make things more
difficult if used for that purpose. Also the difference between an
application and library is often not clear in some code. Good code is
often reused, though of course there is an application-specific layer that
you can't often reuse.
I think ultimately we need a better option parsing framework, and some sort
of extendable options for widgets. I did this with NexTk, and most people
have overlooked that. Now NexTk is dead, and I work as a software
engineer, so I have no time for NexTk, or rather lack time I would want to
spend on it, and probably will continue to.
Implementing new options in NexTk was trivial.
ntk_label .l -text Hello
.l ::add-keys -twiddle bits
Now say you want to run some code when the user tries to change -twiddle you
do something like this:
.l ::add-callback -twiddle [list my-twiddle-callback .l]
proc my-twiddle-callback {label value} {
if {$value eq "bits" || $value eq "bobs"} {
# Do allow changing the current -twiddle value.
return 1
}
return -code error "-twiddle wasn't bits or bobs."
}
Using the options was also very easy.
puts [.l -text] ;#prints hello
#Set the -text value:
.l -text "Hi from Tcl!"
You can add methods, you can add traces to these options, and do all sorts
of things I won't mention here.
The underlying framework used for this was at first called [structure], and
then became [objstructure] in the third rewrite. You could have widget
inheritance, and you could even use objstructure as a prototype object
system for general purposes, and I have in some cases.
-George
ZB
> Try implementing a megawidget using that, and then inherit the properties
> and methods of that megawidget.
To avoid any misunderstanding: you mean a "complex widget", collected from
a simpler ones?
There doesn't have to be any problem: creator of such widget should be
aware, that one of the "cargo" fields should be left for the end-users
disposal, and it'll be the "cargo" of the entire megawidget.
> The -cargo would make things more difficult if used for that purpose.
You know: it's the second (or even third?) time in this thread, when I've
got the feeling, that I proposed something, that is even better than I
thought at the very beginning. Just because I read the fears of kind "they
will fight to use it".
> Also the difference between an application and library is often not clear
> in some code. Good code is often reused, though of course there is an
> application-specific layer that you can't often reuse.
It's up to the creator. "Cargo" itself won't spoil anyone's code.
> I think ultimately we need a better option parsing framework, and some sort
> of extendable options for widgets. I did this with NexTk, and most people
> have overlooked that. [..]
You know: I'm speaking as user of such tools, not the creator. At least
"not yet creator" - maybe some day. I'm still learning; there's quite a lot
to master.
I hope, you can restart your development one day.
--
ZB
Andreas Leitgeb
One can fix that: Demand any such user-option be introduced
(i.e.: declared) first. (As either per-widget or per-Class.)
Andreas Leitgeb
>> We *need* nothing (status quo), but it would be *convenient* to have a
>> -cargo option (whatever its name), and it would be *more convenient* to
>> be able to add any option that is not already used elsewhere, and thereby
>> getting rid of the extra dict-layer.
> currently some other way.
It's the same argument for each step: each step is not *needed*, but
each step makes programming easier - either by no longer needing to
maintain a separate variable (or array-element), or by no longer having
to care for dict-key-value-extraction, and making setting of individual
user-options *much* easier.
$w conf -userfoo xy -userbar yz ;# leave -usersnafu at what it was
Now, do this with a dict...
possible but boooooring ;-)
Whether each step is worth it or not, that would be on the TCT to decide.
John Seal
news:020337b6-4ba9-494b...@r28g2000vbp.googlegroups.com...
> It's a scheme that was first popularized, so far as I know, in the
> book _Effective Tcl/Tk Programming_. It could have been in use in Itcl
> before that.
Thanks, Donal. So it's just a way of setting and retrieving private values,
using helpful names that represent a hierarchy that doesn't actually exist
as separate widgets, i.e., menu entries. So the following comment in the
menu man page still holds:
"At present it is not possible to use the option database to specify values
for the options to individual entries. "
So, no tooltips for menus or their entries. :-(
dkf
> So, no tooltips for menus or their entries. :-(
You can do it for menus since they're widgets, but their entries don't
really have separate names in the option-database sense. OTOH, I tend
to prefer to use other mechanisms for doing menus anyway.
Donal.
Neil Madden
> On Apr 8, 9:19 am, Neil Madden <n...@cs.nott.ac.uk> wrote:
>> Umm...
>>
>> proc mywidget {w args} {
>> someRandomWidget $w {*}$args
>> set ::cargo($w) "hello, world"
>> return $w
>> }
>>
>> Is that really such a maintenance nightmare?
>
> yes.
>
> You forgot to add support for reaping the variable when the widget
> goes away. Yes, it's only a line of code but you forgot it. And so do
> I sometimes. And that line of code needs to be tested. And I have to
> write that wrapper for every widget. And ...
Which is exactly why people use mega-widget frameworks like Snit. All
these details are solved.
>
> It's not a nightmare, but it's an opportunity for the core to make my
> job easier. Adding user data to virtual events could be done with
> global variables too, but the -data / %d features that were added were
> quite useful. I think this request solves a problem of equal
> magnitude.
>
>> ...
>> Let's also not forget the major downside of a single -cargo option: what
>> happens when multiple extensions want to associate data with a single
>> widget? Do they just silently overwrite each other's data? Variables
>> already solve this problem: each extension has its own array of
>> associated data in its own namespace.
>
> Now *there's* a straw man! What if multiple extensions want to change
> the label on a single widget? Or the text in my text or entry widget?
> Do they just silently overwrite each others values? Youbetcha.
Sure, but the label and text widget contents are quite specific and
visible things -- if an extension messes with these things then it is
usually pretty obvious from the documentation and purpose of the
extension that that is what it does. Arbitrary data is a completely
different kettle of fish.
What if
> an extension chooses to use the same variable name I do?
Use a namespace.
We can't
> prevent such abuse, does that mean we shouldn't have any user settable
> options at all for fear that some extension will overwrite them?
Of course not, *most* options do not cause a problem. Trying to cram all
non-core data into a "kitchen sink" option is not a smart move.
>
> It sounds like you're saying "oh, that sounds so useful that many
> people will want to use it, won't that be a problem?!?" (tongue
> *firmly* planted in cheek :-)
That is almost exactly what I'm saying -- yes, it probably will be
useful. Yes, that will almost certainly lead to clashes. Given that the
utility is already addressed by extensions such as snit, without any of
the downsides, what is the need here?
-- Neil
ZB
> Which is exactly why people use mega-widget frameworks
...not everyone. Some prefer to keep their scripts simpler.
> Sure, but the label and text widget contents are quite specific and
> visible things -- if an extension messes with these things then it is
> usually pretty obvious from the documentation and purpose of the
> extension that that is what it does. Arbitrary data is a completely
> different kettle of fish.
The solution is simple, already told by Ramon: no extension should "mess
with these things". We can complete the statement with: "...the extension
- in case of need - can use mega-widget framework, like Snit", right?
>> It sounds like you're saying "oh, that sounds so useful that many
>> people will want to use it, won't that be a problem?!?" (tongue
>> *firmly* planted in cheek :-)
>
> That is almost exactly what I'm saying -- yes, it probably will be
> useful. Yes, that will almost certainly lead to clashes.
As I wrote already, the original idea has been implemented over 20 years
ago (or even more) in Clipper. It's quite a lot of time, enough for
collecting experience in using option of such kind (arbitrary data added by
user). And now you are free to quote *any* complaints - from that about
a quarter of century - saying, that "cargo" in Clipper led to any "clashes".
There are plenty of extensions for Clipper, some of them you can find at:
http://www.the-oasis.net/ftpmaster.php3?content=ftpclip.htm
Waiting impatiently.
> Given that the utility is already addressed by extensions such as snit,
> without any of the downsides, what is the need here?
I'm not sure, what "utility" you're talking about. Original idea was about
new option. Just about _option_.
--
ZB
Neil Madden
> Dnia 16.04.2009 Neil Madden <n...@cs.nott.ac.uk> napisał/a:
>
>> Which is exactly why people use mega-widget frameworks
>
> ...not everyone. Some prefer to keep their scripts simpler.
Snit is pretty simple for basic usage. There exist even more minimal
mega-widget frameworks if you prefer. Indeed, it is quite simple to
create one for just this functionality:
# set an option on a widget
proc property {w option args} {
upvar #0 $w opts
bind $w <Destroy> [list unset -nocomplain $w]
set opts($option) {*}$args
}
# Use
button .b -text "Hello!"
property .b -tooltip "A test tooltip!"
puts "Tooltip: [property .b -tooltip]"
>
>> Sure, but the label and text widget contents are quite specific and
>> visible things -- if an extension messes with these things then it is
>> usually pretty obvious from the documentation and purpose of the
>> extension that that is what it does. Arbitrary data is a completely
>> different kettle of fish.
>
> The solution is simple, already told by Ramon: no extension should "mess
> with these things". We can complete the statement with: "...the extension
> - in case of need - can use mega-widget framework, like Snit", right?
Why one rule for applications and a different one for extensions? Given
that the solution for extensions also works for applications, and
without any such drawbacks. It seems to me that extensions are precisely
where this functionality would be most useful, e.g. the balloon help
example you gave as a motivating use-case.
>
>>> It sounds like you're saying "oh, that sounds so useful that many
>>> people will want to use it, won't that be a problem?!?" (tongue
>>> *firmly* planted in cheek :-)
>> That is almost exactly what I'm saying -- yes, it probably will be
>> useful. Yes, that will almost certainly lead to clashes.
>
> As I wrote already, the original idea has been implemented over 20 years
> ago (or even more) in Clipper. It's quite a lot of time, enough for
> collecting experience in using option of such kind (arbitrary data added by
> user). And now you are free to quote *any* complaints - from that about
> a quarter of century - saying, that "cargo" in Clipper led to any "clashes".
>
> There are plenty of extensions for Clipper, some of them you can find at:
>
> http://www.the-oasis.net/ftpmaster.php3?content=ftpclip.htm
>
> Waiting impatiently.
I can't find any mention of a "cargo" facility in Clipper from a Google
search (just lots of pages about ships). Can you provide a more precise
link discussing the functionality?
>
>> Given that the utility is already addressed by extensions such as snit,
>> without any of the downsides, what is the need here?
>
> I'm not sure, what "utility" you're talking about. Original idea was about
> new option. Just about _option_.
Right, but that option has a purpose: that is its utility, and that is
addressed by better means already.
-- Neil
ZB
> Snit is pretty simple for basic usage.
But you'll agree, that using just option will be even simpler?
>> The solution is simple, already told by Ramon: no extension should "mess
>> with these things". We can complete the statement with: "...the extension
>> - in case of need - can use mega-widget framework, like Snit", right?
>
> Why one rule for applications and a different one for extensions?
To avoid clashes (pay attention, that I'm not the one, who's afraid).
> Given that the solution for extensions also works for applications, and
> without any such drawbacks. It seems to me that extensions are precisely
> where this functionality would be most useful, e.g. the balloon help
> example you gave as a motivating use-case.
OK, as I wrote answering to DKF - quoting myself:
#v+
It has been told already, that it can be even a dictionary, not just a
string. What's the problem then with:
a) Detecting, whether has there been any "cargo" dictionary already
established, and if so:
b) Check-out its keys, to not overwrite something?
#v-
> I can't find any mention of a "cargo" facility in Clipper from a Google
> search (just lots of pages about ships). Can you provide a more precise
> link discussing the functionality?
Look for standard OO-extensions for Clipper, like: "error class", "get
class", "tbrowse class", "tbcolumn class". All of these are standard
extensions, distributed along with compiler - and _aren't_ utilities
provided by "3rd party vendors".
All of the classes mentioned above have "cargo" in their set of variables.
Example: http://www.tek-tips.com/viewthread.cfm?qid=1220900&page=7
> Right, but that option has a purpose: that is its utility, and that is
> addressed by better means already.
OK, a different meaning for a word then - still learning, you know...
--
ZB
Neil Madden
>>> The solution is simple, already told by Ramon: no extension should "mess
>>> with these things". We can complete the statement with: "...the extension
>>> - in case of need - can use mega-widget framework, like Snit", right?
>> Why one rule for applications and a different one for extensions?
>
> To avoid clashes (pay attention, that I'm not the one, who's afraid).
But prohibiting the use of something isn't really a solution to avoid
clashes, is it?
>
>> Given that the solution for extensions also works for applications, and
>> without any such drawbacks. It seems to me that extensions are precisely
>> where this functionality would be most useful, e.g. the balloon help
>> example you gave as a motivating use-case.
>
> OK, as I wrote answering to DKF - quoting myself:
>
> #v+
> It has been told already, that it can be even a dictionary, not just a
> string. What's the problem then with:
> a) Detecting, whether has there been any "cargo" dictionary already
> established, and if so:
> b) Check-out its keys, to not overwrite something?
> #v-
>
This is sounding awfully complicated. What was wrong with the simple
code I just posted? It solves these problems already.
>> I can't find any mention of a "cargo" facility in Clipper from a Google
>> search (just lots of pages about ships). Can you provide a more precise
>> link discussing the functionality?
>
> Look for standard OO-extensions for Clipper, like: "error class", "get
> class", "tbrowse class", "tbcolumn class". All of these are standard
> extensions, distributed along with compiler - and _aren't_ utilities
> provided by "3rd party vendors".
>
> All of the classes mentioned above have "cargo" in their set of variables.
>
> Example: http://www.tek-tips.com/viewthread.cfm?qid=1220900&page=7
The first piece of code on that page includes the comment:
/*
* These #defines use the browse's "cargo" slot to hold the
* "append mode" flag for the browse. The #defines make it
* easy to change this later (e.g. if you need to keep
* several items in the cargo slot).
*/
In other words, there are clashes with the "cargo" slot, and they are
worked around by adding layers of macros.
-- Neil
ZB
>>> Why one rule for applications and a different one for extensions?
>>
>> To avoid clashes (pay attention, that I'm not the one, who's afraid).
>
> But prohibiting the use of something isn't really a solution to avoid
> clashes, is it?
So "better to prohibit *that something*" at all?
> This is sounding awfully complicated.
That's your opinion.
> What was wrong with the simple
> code I just posted? It solves these problems already.
Maybe - but I'm not using Snit. Your proposal seems to be: "use Snit
everytime when you're using Tk". So Snit has to solve a problem caused by
non-existence of the "cargo" option. And so - in my opinion - it's better
solve the problem, than using workarounds.
> The first piece of code on that page includes the comment:
>
> /*
> * These #defines use the browse's "cargo" slot to hold the
> * "append mode" flag for the browse. The #defines make it
> * easy to change this later (e.g. if you need to keep
> * several items in the cargo slot).
> */
>
> In other words, there are clashes with the "cargo" slot, and they are
> worked around by adding layers of macros.
See? The people were using "cargo", they were aware, how to use it - and
nobody has been harmed. Anything else?
I'm sorry: no real arguments in your reply.
--
ZB
Neil Madden
> Dnia 16.04.2009 Neil Madden <n...@cs.nott.ac.uk> napisał/a:
>
>>>> Why one rule for applications and a different one for extensions?
>>> To avoid clashes (pay attention, that I'm not the one, who's afraid).
>> But prohibiting the use of something isn't really a solution to avoid
>> clashes, is it?
>
> So "better to prohibit *that something*" at all?
Yes - given that there are existing alternatives that are usable
everywhere and do not suffer from the same problems.
>
>> This is sounding awfully complicated.
>
> That's your opinion.
>
>> What was wrong with the simple
>> code I just posted? It solves these problems already.
>
> Maybe - but I'm not using Snit. Your proposal seems to be: "use Snit
> everytime when you're using Tk". So Snit has to solve a problem caused by
> non-existence of the "cargo" option. And so - in my opinion - it's better
> solve the problem, than using workarounds.
My solution didn't use snit -- it used a 3 line proc. If you wish to add
something to the core Tk, you need to come up with a convincing argument
why the 3 line proc is not sufficient or is too labourious.
>
>> The first piece of code on that page includes the comment:
>>
>> /*
>> * These #defines use the browse's "cargo" slot to hold the
>> * "append mode" flag for the browse. The #defines make it
>> * easy to change this later (e.g. if you need to keep
>> * several items in the cargo slot).
>> */
>>
>> In other words, there are clashes with the "cargo" slot, and they are
>> worked around by adding layers of macros.
>
> See? The people were using "cargo", they were aware, how to use it - and
> nobody has been harmed. Anything else?
They worked around its limitations. As you just said "it's better [to]
solve the problem, than using workarounds."
-- Neil
ZB
>> So "better to prohibit *that something*" at all?
>
> Yes - given that there are existing alternatives that are usable
> everywhere and do not suffer from the same problems.
"Cargo" doesn't suffer from anything. Did you find any *complaints* (not
to be confused with macros) from the side of Clipper people?
>>> This is sounding awfully complicated.
>>
>> That's your opinion.
>>
>>> What was wrong with the simple
>>> code I just posted? It solves these problems already.
>>
>> Maybe - but I'm not using Snit. Your proposal seems to be: "use Snit
>> everytime when you're using Tk". So Snit has to solve a problem caused by
>> non-existence of the "cargo" option. And so - in my opinion - it's better
>> solve the problem, than using workarounds.
>
> My solution didn't use snit -- it used a 3 line proc. If you wish to add
> something to the core Tk, you need to come up with a convincing argument
> why the 3 line proc is not sufficient or is too labourious.
3 line proc? Fix for lack of one little option requires usage of entire
additional package. Or perhaps are you going to say, that Snit has 3 lines
of code?
>> See? The people were using "cargo", they were aware, how to use it - and
>> nobody has been harmed. Anything else?
>
> They worked around its limitations. As you just said "it's better [to]
> solve the problem, than using workarounds."
Nobody said, that "cargo" hasn't any limitations. Entire Tk toolkit has
its limitations - so I'm proposing how to remove one of that limitations.
Introducing useful option is solution - using package with hundreds lines
of code instead, yes: this is the workaround.
--
ZB
ZB
> My solution didn't use snit -- it used a 3 line proc.
You mean that one?
# set an option on a widget
proc property {w option args} {
upvar #0 $w opts
bind $w <Destroy> [list unset -nocomplain $w]
set opts($option) {*}$args
}
# Use
button .b -text "Hello!"
property .b -tooltip "A test tooltip!"
puts "Tooltip: [property .b -tooltip]"
If so:
1) It hasn't 3 lines (let's drop that ";" tricks).
2) It uses external variable - it has been told already, that it's much,
much more convenient to keep the widget-related along with the widget
3) It's a "workaround for today", it isn't real solution.
--
ZB