Re: [TCLCORE] Questions regarding: Do not use widget names for script names

[Harald O. <har...@el...>]

Hi Donal,
thanks for the message.
That sounds all very complicated.
Wouldn't it possible:
- to use a default class name (like TkMain) ?
- Modify the class name by an explicit option (like wish.exe 
-toplevelclassname myname). We already have options support and the 
current mechanism ignores it. So (wish.exe -- scale) still sees "scale" 
as class name.
I see no way out.
Or we disable this on MS-Windows (as it is a Linux feature where we have 
those resource data bases) and the Linux folks may continue the error 
dance... I understand, that it is a neat feature, that automatically, a 
resource data base key is chosen in dependency of the script name. But 
that is not, what is implemented. It just takes an arbitrary argument 
and uses it as toplevel class name (as key for the resource data base).

But, in my case, it is not a script name. A script name is passed by the 
"-f" option and should always be. In my case, it is arguments passed to 
the args array, which may be arbitrary.

Anyway, the train to change this for 9.0 has left a year ago. It may 
happen in the future. Tk needs so much love...

Thanks for all,
Harald

Am 08.08.2024 um 10:40 schrieb Donal Fellows:
> Trouble is, it's a consequence of quite a few other things. In particular, the default name of the main widget and the main widget class are derived from the name of the script (because they've got to be *something* non-empty and there isn't a better choice; the names can't contain ".") and that has many downstream consequences, especially in bindings and option handling, where matching the class of a standard widget can be "fun". I've no idea what a better default for name and class name would be.
> 
> The best option as a user is to set the name and class by setting options in argv prior to creating the main widget, which is by genuine arguments when using wish. The arguments are parsed when creating the main widget prior to making the X11 Widget instance, so you don't have time to do much script trickery (unless you do [package require Tk] in tclsh). Indeed, it's probably a good idea to do that for every toplevel widget (or frame that can become a toplevel). It's irritating that you can only do this on widget creation, but that's one of the times when this information is needed most acutely; I don't see that changing. Note that whatever we do to alter the behaviour of Tk, I think I'll still recommend this.
> 
> The best option for Tk 9.0 would probably be to alter the widget class names, likely to prefix them with "Tk"... except that this is really quite likely to have impacts on more complex scripts (and I've no idea how to handle Ttk there, as the style mechanism also tangles into this). I guess that 9.0 would be the time to do this, but it's going to be annoying to users and isn't strictly necessary. We can simply let the current situation continue.
> 
> It's not as bad as using 'open' as the name of a photo image (a fairly likely choice if you've not much experience) as that causes really very noticeable weird breakage. Explicitly naming photo images is an attractive nuisance if you ask me...
> 
> Donal.
> 
>> -----Original Message-----
>> From: Harald Oehlmann <har...@el...>
>> Sent: Tuesday, August 6, 2024 7:20 AM
>> To: tcl...@li...
>> Subject: Re: [TCLCORE] Questions regarding: Do not use widget names for
>> script names
>>
>> Am 05.08.2024 um 23:30 schrieb Paul Obermeier:
>>> A question to the Tcl core team.
>>>
>>> Are there plans for Tcl9 to remove the (unexpected) behaviour, that
>>> script file names are not allowed to have the names of widgets, as
>>> described ex. here:
>>> https://stackoverflow.com/questions/37087930/error-unknown-option-
>> stat
>>> e-occurs-when-running-a-script-named-button-tcl
>>>
>>> Although an experienced Tcl'er I recently stumbled across that problem
>>> when writing a simple test script and it took me some time to remember
>>> that behaviour.
>>> It does not seem to be mentioned in the official documentation.
>>>
>>> Paul
>>
>> +1
>>
>> I took months to find those errors. My use case was "wish.exe scale" and the
>> Tk class was overwritten and some widgets did not work any more.
>>
>> Well
>>
>> + 1000
>>
>> to get rid of this.
>>
>> Thanks,
>> Harald