tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] The -blockcursor option of text widgets

[Christian W. <Chr...@t-...>]

On 04/02/2025 08:56 PM, Christian Werner wrote:

> …
> Meanwhile the patch evolved to work on Windows and MacOS, too, see
>
>   https://www.androwish.org/home/info/b8894bb57964415f

Some more iterations later the patch is now in a branch in the
Tk repo thanks to Harald, who followed it closely and tested
especially on Win32.

 From my point of view, the block cursor now is working, although
the code of the patch is still debatable and possibly could be
improved and/or simplified.

However, some concerns regarding Tk came up, which can be read in
the comments to ticket https://core.tcl-lang.org/tk/info/5d0bc3cf

My conclusions so far:

* Most likely, the block cursor is fine on MacOS, so please test.

   No actions needed on this platform, hopefully.

* On X11 and Win32 TIP#621 is in the way: it implements run-time
   linking of ICU for determining bounds of glyph clusters among
   other features. And Tk 9.x uses these functions for navigating
   e.g. by cursor keys through the chars in a text widget. However,
   since both, X11 and Win32 font rendering isn't glyph cluster
   aware at all, this leads to rather ugly behavior which Harald
   documented in the ticket.

   Action required: it must be decided, if tk::startOfCluster and
   tk::endOfCluster with ICU backing is to be used in Tk's text
   widget or not. If not, the block cursor will be fine. If it
   shall be used, the whole complexity of char measurement in the
   guts of Tk must be improved to take glyph clustering into
   account when measuring the pixel widths of char sequences.

Cheers,
Christian

Re: [TCLCORE] CFV warning: TIP #626: Command arguments > 2^31 elements

[Jan N. <jan...@gm...>]

Op vr 4 apr 2025 om 12:21 schreef apnmbx-public:
> I haven't been reviewing it since you have been continuing with your
> commits. Since I can only afford the time for one full review, I wanted to
> wait till you are done. *If* you feel the implementation and test suite is
> more or less complete, I will review over the weekend. Let me know
> accordingly

Then, go ahead.

I'm sure some "bigdata" testcases need to be adapted: They
no longer give an error-message but will work as expected
now. I don't have a machine with enough memory to
do this. And those testcases cannot run in GITHUB
CI anyway.

       Jan Nijtmans

[TCLCORE] TCL/Tk biweekly telco on 7th of April, 2025 12:00 UTC on https://meet.jit.si/TclMonthlyMeetup

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

Dear Tcl/Tk team,

please allow me to invite anybody to the telco:
Where: https://meet.jit.si/TclMonthlyMeetup
When: 2025-04-07 12:00 UTC

Possible agenda:

0) Eventual surprise guest with special question
1) TIP 715 - platform support definitions.
    -> ToDo: add deprecation process
2) TIP 710 - development workflow and TIP process
3) TIP 700: Documentation
4) TIP 714 - "image types photo" - ready for vote?
5) Github for orphaned extensions started
6) bytecode compiler optimization by Donal Fellows
7) Conference news
8) Next biweekly telco - 21st of April 12:00 UTC is Eastern-Monday - is 
not possible for me.
9) Any other business

Other meetings:
8th of April 1:00 UTC Monthly Virtual Meetup on same jitsi
5th of May 12:00 UTC: Biweekly telco

Thank you all,
Harald

Re: [TCLCORE] CFV warning: TIP #626: Command arguments > 2^31 elements

[<apn...@ya...>]

Jan,

I haven't been reviewing it since you have been continuing with your
commits. Since I can only afford the time for one full review, I wanted to
wait till you are done. *If* you feel the implementation and test suite is
more or less complete, I will review over the weekend. Let me know
accordingly

/Ashok

-----Original Message-----
From: Jan Nijtmans <jan...@gm...> 
Sent: Friday, April 4, 2025 1:56 PM
To: Donald G Porter <don...@ni...>
Cc: tcl...@li...
Subject: Re: [TCLCORE] CFV warning: TIP #626: Command arguments > 2^31
elements

Op wo 2 apr 2025 om 18:33 schreef Donald G Porter:
> Looking at this again, I notice the call to deprecate Tcl_CreateCommand.
>
> I think that's a bad idea. I think the ability to define string-based
extension and application commands should live forever.
>
> I like Tcl continuing to support extension via the simplest C language
tools imaginable, writing what is very close to a main() routine.  The
continuing interoperability with the oldest textbooks is also appealing to
me.

Understood. I don't have much problems keeping that, it's just a tiny
bit of wrapper functionality.The TIP and implementation is modified now.

@Ashok, how is your review going?

Thanks!
        Jan Nijtmans


_______________________________________________
Tcl-Core mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] CFV warning: TIP #626: Command arguments > 2^31 elements

[Jan N. <jan...@gm...>]

Op wo 2 apr 2025 om 18:33 schreef Donald G Porter:
> Looking at this again, I notice the call to deprecate Tcl_CreateCommand.
>
> I think that's a bad idea. I think the ability to define string-based extension and application commands should live forever.
>
> I like Tcl continuing to support extension via the simplest C language tools imaginable, writing what is very close to a main() routine.  The continuing interoperability with the oldest textbooks is also appealing to me.

Understood. I don't have much problems keeping that, it's just a tiny
bit of wrapper functionality.The TIP and implementation is modified now.

@Ashok, how is your review going?

Thanks!
        Jan Nijtmans

Re: [TCLCORE] TIP 714: image driver photo formats

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

Am 03.04.2025 um 11:59 schrieb Jan Nijtmans:
> Op do 3 apr 2025 om 10:43 schreef Harald Oehlmann:
>> To my understanding, this function may be added to the stubs table.
> 
> Done:
>       https://core.tcl-lang.org/tk/info/ea22295e23f2b625
> 
> Hope this helps,
>        Jan Nijtmans

Thanks, great, I appreciate.

Take care,
Harald

Re: [TCLCORE] TIP 714: image driver photo formats

[Jan N. <jan...@gm...>]

Op do 3 apr 2025 om 10:43 schreef Harald Oehlmann:
> To my understanding, this function may be added to the stubs table.

Done:
     https://core.tcl-lang.org/tk/info/ea22295e23f2b625

Hope this helps,
      Jan Nijtmans

Re: [TCLCORE] TIP 714: image driver photo formats

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

TIP 714 and its implementation is totally new.
Thanks for Emiliano for the proposal and implementation:

https://core.tcl-lang.org/tips/doc/trunk/tip/714.md

It now features the great intuitive result:

% image types photo
format {svg ppm png gif default} file {svg ppm png gif} write {ppm png gif}

The implementation has no incompatibilities, as no public structure is 
changed and no option is added to "image" (which has incompatibilities 
on abbreviations).

The implementation is now "black magic" including thread attached data 
and a hash table.

There is a new public Tk function.
To my understanding, this function may be added to the stubs table.
Perhaps it is already, I don't know.
I can not do this.
"stubs" is black magic using #defines and is to my knowledge old 
technology, as it does something like dynamic linking, what is anyway 
done for dlls by the operating system.

Thanks for any review !

Take care,
Harald

Re: [TCLCORE] The -blockcursor option of text widgets

[Christian W. <Chr...@t-...>]

On 04/01/2025 10:57 PM, Christian Werner wrote:

> …
> Nevertheless, it gives a more natural feedback resembling a good old vi
> in a good old terminal. And wasn't that the original intention and means
> of existence of the block cursor option?

Meanwhile the patch evolved to work on Windows and MacOS, too, see

   https://www.androwish.org/home/info/b8894bb57964415f

Cheers,
Christian

Re: [TCLCORE] TIP 714: image driver photo formats

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

Am 02.04.2025 um 18:37 schrieb Emiliano:
> On Wed, 2 Apr 2025 08:37:57 +0200
> Harald Oehlmann <har...@el...> wrote:
> 
>> Am 02.04.2025 um 02:24 schrieb Emiliano:
>>> On Tue, 1 Apr 2025 21:12:18 +0200
>>> Harald Oehlmann <har...@el...> wrote:
>>>
>>>> Am 01.04.2025 um 18:21 schrieb Emiliano G:
>>>>> El mar, 1 abr 2025 a las 7:56, Harald Oehlmann
>>>>> (<har...@el...>) escribió:
>>>>> Sadly there's no requirements of the capabilities a type should
>>>>> support, besides the required fields of the Tk_ImageType structure.
>>>>> All subcommands and options supported by the image instance are
>>>>> defined by the type.
>>>>
>>>> Well, I thought, exposing the structure is a first step.
>>>> Many photo format handlers don't support the data or write option.
>>>> I have never seen that the "-file" or "-data" is not supported.
>>>> But as the code allows to have those as NULL pointers, it might be
>>>> reasonable to expose this.
>>>>
>>>>>> As modifying a C structure is expensive, I like most general interfaces
>>>>>> on the C level. Any specific function may then be added on the script level.
>>>>>
>>>>> At C level, we can´t modify the structure Tk_ImageType. That ship has
>>>>> sailed. But we can define a simple interface for type managers to
>>>>> register an info procedure. This data can be kept along with the type
>>>>> linked list in the threadSpecificData structure in generic/tkImage.c
>>>>> (a hashtable with keytype TCL_ONE_WORD_KEYS? smuggle the pointer into
>>>>> the reserved field of Tk_ImageType structure? Bring your paint)
>>>>>
>>>>> A trivial example would be
>>>>>
>>>>> Tk_SetTypeInfoProc((Tk_ImageType *) &myImageType, (Tk_ImageInfoProc *)
>>>>> myTypeInfo); /* definition of  Tk_ImageInfoProc pending! */
>>>>>
>>>>> (I know, I'm bad at naming things).
>>>>> This way, type managers willing to register an info procedure can do
>>>>> so without having to do any rewrite. When the script level command to
>>>>> retrieve this information is called, myTypeInfo will return said info
>>>>> in human readable form.
>>>>>
>>>>> As for the format, I think a dictionary of properties is a good
>>>>> format, given the wide range of information that different type
>>>>> managers can handle. It's their responsibility to provide useful or
>>>>> relevant information to the user. Of course "photo" could take the
>>>>> lead and define a standard set of keys or, at least, "expected to be
>>>>> there" keys.
>>>>
>>>> Sorry, this is far bejond my capabilities.
>>>> I tried to make the sample extension thread save using the
>>>> threadSpecificData and it only core dumps.
>>>> Sorry, no possibility from my side here.
>>>> This is black magic.
>>>>
>>>> If you want to go this route, please go on and take the TIP over.
>>>>
>>>> Remark, that the proposed infra-structure is not only for introspection.
>>>> There are also commands imaginable, which do something like setting
>>>> default values.
>>>>
>>>> Thanks for all, I appreciate.
>>>>
>>>> I will copy your message to the TIP soon.
>>>
>>> Dear Harald:
>>>
>>> I've commited a PoC implementation of what I've been discussing in the tip-714-alt branch. Toghether with the changes in generic/tkImage.c supporting the functionality, the main change is in tkWindow.c, when I call Tk_SetTypeInfoProc() after calling Tk_CreateImageType() for the photo image type only. The implementation of the callback function is in generic/tkImgPhoto.c . Also, the script level call is shoehorned in the [image types ?type?] command, inspired by Christian's post. After those changes I get
>>>
>>> % image types
>>> photo bitmap
>>> % image types photo
>>> format {svg ppm default png gif}
>>> % image types bitmap
>>> % image types nosuchtype
>>> %
>>>
>>> This new function Tk_SetTypeInfoProc() is the only one intended to be public, and it allows image type managers to register a callback function to provide information about the type *after* the image type itself is created. As proposed, the output format is a dictionary of properties->values, which can be handled at script level with the standard dict commands.
>>>
>>> All the fine details can be adjusted: the name of the script and C level command/function, the behaviour of the callback C function wrt non-existent image types, its signature, you name it. Just bring your favourite paint color.
>>>
>>> As for the dictionary returned by the photo image type itself wrt available formats, I think a better format will be
>>>
>>>     format {read {svg ppm default png gif} write {ppm default png gif}} ...; #other keys
>>>
>>> to tell apart formats that can be read from formats that can be written, allowing different format lists between tk_getOpenFile and tk_getSaveFile.
>>>
>>> Regards
>>>
>>
>> Dear Emiliano,
>> thanks, great. I have time tomorrow and will remove my stuff and adapt
>> the TIP to your great proposal.
>>
>> Thanks for all,
>> Harald
>>
> 
> Tangentially related to this TIP, I have two questions I couldn't answer myself:
> 
> 1) Why is the Tk_ImageType structure documented up to the Tk_ImageDeleteProc member? What happened to the following member Tk_ImagePostscriptProc? is it deprecated? FWIW, Blt's picture type uses it.

I have no idea. Specially, the structure has 2 additional (nextPtr and 
reserved) which are not documented neither.
The interface is IMHO very week. The passed memory is only referenced 
and not copied to a save place.

> 2) The list of image types is stored in thread specific data. Once registered, it remains until the current thread is deleted. What if the user [unload]s the dll with the support code? Also, this means that the types list is shared among all the interpreters in the thread. Is this desirable?

Oh, it will crash for sure. DLL unload was invented far later than this 
image code. We would need an unregister method for this.

As you probably know: my tries to make the unload of the sample 
extension thread save also failed with a core dump.
I think, that the infra-structure here is just to complicated for a 
normal programmer.
In addition, TCL is a dynamic language and dll unload is IMHO a 
desireable feature.

Thanks for all,
Harald

Re: [TCLCORE] TIP 714: image driver photo formats

[Emiliano <emi...@gm...>]

On Wed, 2 Apr 2025 08:37:57 +0200
Harald Oehlmann <har...@el...> wrote:

> Am 02.04.2025 um 02:24 schrieb Emiliano:
> > On Tue, 1 Apr 2025 21:12:18 +0200
> > Harald Oehlmann <har...@el...> wrote:
> > 
> >> Am 01.04.2025 um 18:21 schrieb Emiliano G:
> >>> El mar, 1 abr 2025 a las 7:56, Harald Oehlmann
> >>> (<har...@el...>) escribió:
> >>> Sadly there's no requirements of the capabilities a type should
> >>> support, besides the required fields of the Tk_ImageType structure.
> >>> All subcommands and options supported by the image instance are
> >>> defined by the type.
> >>
> >> Well, I thought, exposing the structure is a first step.
> >> Many photo format handlers don't support the data or write option.
> >> I have never seen that the "-file" or "-data" is not supported.
> >> But as the code allows to have those as NULL pointers, it might be
> >> reasonable to expose this.
> >>
> >>>> As modifying a C structure is expensive, I like most general interfaces
> >>>> on the C level. Any specific function may then be added on the script level.
> >>>
> >>> At C level, we can´t modify the structure Tk_ImageType. That ship has
> >>> sailed. But we can define a simple interface for type managers to
> >>> register an info procedure. This data can be kept along with the type
> >>> linked list in the threadSpecificData structure in generic/tkImage.c
> >>> (a hashtable with keytype TCL_ONE_WORD_KEYS? smuggle the pointer into
> >>> the reserved field of Tk_ImageType structure? Bring your paint)
> >>>
> >>> A trivial example would be
> >>>
> >>> Tk_SetTypeInfoProc((Tk_ImageType *) &myImageType, (Tk_ImageInfoProc *)
> >>> myTypeInfo); /* definition of  Tk_ImageInfoProc pending! */
> >>>
> >>> (I know, I'm bad at naming things).
> >>> This way, type managers willing to register an info procedure can do
> >>> so without having to do any rewrite. When the script level command to
> >>> retrieve this information is called, myTypeInfo will return said info
> >>> in human readable form.
> >>>
> >>> As for the format, I think a dictionary of properties is a good
> >>> format, given the wide range of information that different type
> >>> managers can handle. It's their responsibility to provide useful or
> >>> relevant information to the user. Of course "photo" could take the
> >>> lead and define a standard set of keys or, at least, "expected to be
> >>> there" keys.
> >>
> >> Sorry, this is far bejond my capabilities.
> >> I tried to make the sample extension thread save using the
> >> threadSpecificData and it only core dumps.
> >> Sorry, no possibility from my side here.
> >> This is black magic.
> >>
> >> If you want to go this route, please go on and take the TIP over.
> >>
> >> Remark, that the proposed infra-structure is not only for introspection.
> >> There are also commands imaginable, which do something like setting
> >> default values.
> >>
> >> Thanks for all, I appreciate.
> >>
> >> I will copy your message to the TIP soon.
> > 
> > Dear Harald:
> > 
> > I've commited a PoC implementation of what I've been discussing in the tip-714-alt branch. Toghether with the changes in generic/tkImage.c supporting the functionality, the main change is in tkWindow.c, when I call Tk_SetTypeInfoProc() after calling Tk_CreateImageType() for the photo image type only. The implementation of the callback function is in generic/tkImgPhoto.c . Also, the script level call is shoehorned in the [image types ?type?] command, inspired by Christian's post. After those changes I get
> > 
> > % image types
> > photo bitmap
> > % image types photo
> > format {svg ppm default png gif}
> > % image types bitmap
> > % image types nosuchtype
> > %
> > 
> > This new function Tk_SetTypeInfoProc() is the only one intended to be public, and it allows image type managers to register a callback function to provide information about the type *after* the image type itself is created. As proposed, the output format is a dictionary of properties->values, which can be handled at script level with the standard dict commands.
> > 
> > All the fine details can be adjusted: the name of the script and C level command/function, the behaviour of the callback C function wrt non-existent image types, its signature, you name it. Just bring your favourite paint color.
> > 
> > As for the dictionary returned by the photo image type itself wrt available formats, I think a better format will be
> > 
> >    format {read {svg ppm default png gif} write {ppm default png gif}} ...; #other keys
> > 
> > to tell apart formats that can be read from formats that can be written, allowing different format lists between tk_getOpenFile and tk_getSaveFile.
> > 
> > Regards
> > 
> 
> Dear Emiliano,
> thanks, great. I have time tomorrow and will remove my stuff and adapt 
> the TIP to your great proposal.
> 
> Thanks for all,
> Harald
> 

Tangentially related to this TIP, I have two questions I couldn't answer myself:

1) Why is the Tk_ImageType structure documented up to the Tk_ImageDeleteProc member? What happened to the following member Tk_ImagePostscriptProc? is it deprecated? FWIW, Blt's picture type uses it.

2) The list of image types is stored in thread specific data. Once registered, it remains until the current thread is deleted. What if the user [unload]s the dll with the support code? Also, this means that the types list is shared among all the interpreters in the thread. Is this desirable?

-- 
Emiliano <emi...@gm...>

Re: [TCLCORE] CFV warning: TIP #626: Command arguments > 2^31 elements

[Donald G P. <don...@ni...>]

On 3/20/25 11:50, Jan Nijtmans wrote:
> This is a CFV warning for TIP #626. for Tcl 9.1+:
>      Command arguments > 2^31 elements
>      <https://core.tcl-lang.org/tips/doc/trunk/tip/626.md>
>
> If you think this is a bad idea, speak up now. If not,
> I'll start the vote in a few days.

Looking at this again, I notice the call to deprecate Tcl_CreateCommand.

I think that's a bad idea. I think the ability to define string-based extension and application commands should live forever.

I like Tcl continuing to support extension via the simplest C language tools imaginable, writing what is very close to a main() routine.  The continuing interoperability with the oldest textbooks is also appealing to me.

-- 
| Don Porter            Applied and Computational Mathematics Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

Re: [TCLCORE] TIP 714: image driver photo formats

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

Am 02.04.2025 um 02:24 schrieb Emiliano:
> On Tue, 1 Apr 2025 21:12:18 +0200
> Harald Oehlmann <har...@el...> wrote:
> 
>> Am 01.04.2025 um 18:21 schrieb Emiliano G:
>>> El mar, 1 abr 2025 a las 7:56, Harald Oehlmann
>>> (<har...@el...>) escribió:
>>> Sadly there's no requirements of the capabilities a type should
>>> support, besides the required fields of the Tk_ImageType structure.
>>> All subcommands and options supported by the image instance are
>>> defined by the type.
>>
>> Well, I thought, exposing the structure is a first step.
>> Many photo format handlers don't support the data or write option.
>> I have never seen that the "-file" or "-data" is not supported.
>> But as the code allows to have those as NULL pointers, it might be
>> reasonable to expose this.
>>
>>>> As modifying a C structure is expensive, I like most general interfaces
>>>> on the C level. Any specific function may then be added on the script level.
>>>
>>> At C level, we can´t modify the structure Tk_ImageType. That ship has
>>> sailed. But we can define a simple interface for type managers to
>>> register an info procedure. This data can be kept along with the type
>>> linked list in the threadSpecificData structure in generic/tkImage.c
>>> (a hashtable with keytype TCL_ONE_WORD_KEYS? smuggle the pointer into
>>> the reserved field of Tk_ImageType structure? Bring your paint)
>>>
>>> A trivial example would be
>>>
>>> Tk_SetTypeInfoProc((Tk_ImageType *) &myImageType, (Tk_ImageInfoProc *)
>>> myTypeInfo); /* definition of  Tk_ImageInfoProc pending! */
>>>
>>> (I know, I'm bad at naming things).
>>> This way, type managers willing to register an info procedure can do
>>> so without having to do any rewrite. When the script level command to
>>> retrieve this information is called, myTypeInfo will return said info
>>> in human readable form.
>>>
>>> As for the format, I think a dictionary of properties is a good
>>> format, given the wide range of information that different type
>>> managers can handle. It's their responsibility to provide useful or
>>> relevant information to the user. Of course "photo" could take the
>>> lead and define a standard set of keys or, at least, "expected to be
>>> there" keys.
>>
>> Sorry, this is far bejond my capabilities.
>> I tried to make the sample extension thread save using the
>> threadSpecificData and it only core dumps.
>> Sorry, no possibility from my side here.
>> This is black magic.
>>
>> If you want to go this route, please go on and take the TIP over.
>>
>> Remark, that the proposed infra-structure is not only for introspection.
>> There are also commands imaginable, which do something like setting
>> default values.
>>
>> Thanks for all, I appreciate.
>>
>> I will copy your message to the TIP soon.
> 
> Dear Harald:
> 
> I've commited a PoC implementation of what I've been discussing in the tip-714-alt branch. Toghether with the changes in generic/tkImage.c supporting the functionality, the main change is in tkWindow.c, when I call Tk_SetTypeInfoProc() after calling Tk_CreateImageType() for the photo image type only. The implementation of the callback function is in generic/tkImgPhoto.c . Also, the script level call is shoehorned in the [image types ?type?] command, inspired by Christian's post. After those changes I get
> 
> % image types
> photo bitmap
> % image types photo
> format {svg ppm default png gif}
> % image types bitmap
> % image types nosuchtype
> %
> 
> This new function Tk_SetTypeInfoProc() is the only one intended to be public, and it allows image type managers to register a callback function to provide information about the type *after* the image type itself is created. As proposed, the output format is a dictionary of properties->values, which can be handled at script level with the standard dict commands.
> 
> All the fine details can be adjusted: the name of the script and C level command/function, the behaviour of the callback C function wrt non-existent image types, its signature, you name it. Just bring your favourite paint color.
> 
> As for the dictionary returned by the photo image type itself wrt available formats, I think a better format will be
> 
>    format {read {svg ppm default png gif} write {ppm default png gif}} ...; #other keys
> 
> to tell apart formats that can be read from formats that can be written, allowing different format lists between tk_getOpenFile and tk_getSaveFile.
> 
> Regards
> 

Dear Emiliano,
thanks, great. I have time tomorrow and will remove my stuff and adapt 
the TIP to your great proposal.

Thanks for all,
Harald

Re: [TCLCORE] TIP 714: image driver photo formats

[Emiliano <emi...@gm...>]

On Tue, 1 Apr 2025 21:12:18 +0200
Harald Oehlmann <har...@el...> wrote:

> Am 01.04.2025 um 18:21 schrieb Emiliano G:
> > El mar, 1 abr 2025 a las 7:56, Harald Oehlmann
> > (<har...@el...>) escribió:
> > Sadly there's no requirements of the capabilities a type should
> > support, besides the required fields of the Tk_ImageType structure.
> > All subcommands and options supported by the image instance are
> > defined by the type.
> 
> Well, I thought, exposing the structure is a first step.
> Many photo format handlers don't support the data or write option.
> I have never seen that the "-file" or "-data" is not supported.
> But as the code allows to have those as NULL pointers, it might be 
> reasonable to expose this.
> 
> >> As modifying a C structure is expensive, I like most general interfaces
> >> on the C level. Any specific function may then be added on the script level.
> > 
> > At C level, we can´t modify the structure Tk_ImageType. That ship has
> > sailed. But we can define a simple interface for type managers to
> > register an info procedure. This data can be kept along with the type
> > linked list in the threadSpecificData structure in generic/tkImage.c
> > (a hashtable with keytype TCL_ONE_WORD_KEYS? smuggle the pointer into
> > the reserved field of Tk_ImageType structure? Bring your paint)
> > 
> > A trivial example would be
> > 
> > Tk_SetTypeInfoProc((Tk_ImageType *) &myImageType, (Tk_ImageInfoProc *)
> > myTypeInfo); /* definition of  Tk_ImageInfoProc pending! */
> > 
> > (I know, I'm bad at naming things).
> > This way, type managers willing to register an info procedure can do
> > so without having to do any rewrite. When the script level command to
> > retrieve this information is called, myTypeInfo will return said info
> > in human readable form.
> > 
> > As for the format, I think a dictionary of properties is a good
> > format, given the wide range of information that different type
> > managers can handle. It's their responsibility to provide useful or
> > relevant information to the user. Of course "photo" could take the
> > lead and define a standard set of keys or, at least, "expected to be
> > there" keys.
> 
> Sorry, this is far bejond my capabilities.
> I tried to make the sample extension thread save using the 
> threadSpecificData and it only core dumps.
> Sorry, no possibility from my side here.
> This is black magic.
> 
> If you want to go this route, please go on and take the TIP over.
> 
> Remark, that the proposed infra-structure is not only for introspection.
> There are also commands imaginable, which do something like setting 
> default values.
> 
> Thanks for all, I appreciate.
> 
> I will copy your message to the TIP soon.

Dear Harald:

I've commited a PoC implementation of what I've been discussing in the tip-714-alt branch. Toghether with the changes in generic/tkImage.c supporting the functionality, the main change is in tkWindow.c, when I call Tk_SetTypeInfoProc() after calling Tk_CreateImageType() for the photo image type only. The implementation of the callback function is in generic/tkImgPhoto.c . Also, the script level call is shoehorned in the [image types ?type?] command, inspired by Christian's post. After those changes I get

% image types
photo bitmap
% image types photo
format {svg ppm default png gif}
% image types bitmap
% image types nosuchtype
%

This new function Tk_SetTypeInfoProc() is the only one intended to be public, and it allows image type managers to register a callback function to provide information about the type *after* the image type itself is created. As proposed, the output format is a dictionary of properties->values, which can be handled at script level with the standard dict commands.

All the fine details can be adjusted: the name of the script and C level command/function, the behaviour of the callback C function wrt non-existent image types, its signature, you name it. Just bring your favourite paint color.

As for the dictionary returned by the photo image type itself wrt available formats, I think a better format will be

  format {read {svg ppm default png gif} write {ppm default png gif}} ...; #other keys

to tell apart formats that can be read from formats that can be written, allowing different format lists between tk_getOpenFile and tk_getSaveFile.

Regards

-- 
Emiliano

Re: [TCLCORE] The -blockcursor option of text widgets

[Christian W. <Chr...@t-...>]

On 04/01/2025 10:25 PM, Christian Werner wrote:

> after some playing with the text widget's -blockcursor option my conclusion…

I should have admitted, that the POC patch is not ideal, since it leaves
artefacts of the double drawing of the character under the cursor due to
antialiasing, when the xft font rendering is in effect.

Nevertheless, it gives a more natural feedback resembling a good old vi
in a good old terminal. And wasn't that the original intention and means
of existence of the block cursor option?

BR,
Christian

[TCLCORE] The -blockcursor option of text widgets

[Christian W. <Chr...@t-...>]

Dear fellow readers of the core mailing list,

after some playing with the text widget's -blockcursor option my conclusion
is unfortunately, that it is almost unusable when turned on, at least when
the default options of the text widget are in place, which is a very common
use case.

Rationale: the block cursor in its active state (INSERT_ON) draws a rectangle
in the text widget's foreground color. Following that drawing the text is drawn
in the text widget's foreground color resulting in a rectangle in the text
widget's foreground color, i.e.  without any information which was in place
when the widget/cursor was in inactive (INSERT_OFF) state. This makes the
block cursor indefinitely hiding the character under the cursor when the
-insertofftime option is set to zero. Bluntly, the "-blockcursor 1" option
is not usable at all since it's invention, BTW this was in 2003.

Here is a POC how it can be remedied:

---8><---
--- old/tkTextDisp.c
+++ new/tkTextDisp.c
@@ -15,6 +15,7 @@
  
  #include "tkInt.h"
  #include "tkText.h"
+#include "tk3d.h"
  
  #if defined(_WIN32) && !defined(PLATFORM_SDL)
  #include "tkWinInt.h"
@@ -2444,10 +2445,13 @@
  				 * must make sure it's large enough to hold
  				 * line. */
  {
-    TkTextDispChunk *chunkPtr;
+    TkTextDispChunk *chunkPtr, tmpChunk, *otherChunkPtr = NULL;;
      TextDInfo *dInfoPtr = textPtr->dInfoPtr;
      Display *display;
      int height, y_off;
+    struct TextStyle tmpStyle;
+    TkBorder *borderPtr;
+    CharInfo ci;
  #ifndef TK_NO_DOUBLE_BUFFERING
      const int y = 0;
  #else
@@ -2539,6 +2543,38 @@
  	     * here.
  	     */
  
+	    if (textPtr->insertCursorType &&
+		    ((textPtr->flags & (GOT_FOCUS | INSERT_ON)) ==
+			(GOT_FOCUS | INSERT_ON)) &&
+		    (chunkPtr->nextPtr != NULL) &&
+		    (chunkPtr->nextPtr->displayProc == CharDisplayProc) &&
+		    (chunkPtr->nextPtr->numBytes > 0)) {
+		/*
+		 * Make a temporary chunk for displaying the text
+		 * within the block cursor later on.
+		 */
+
+		otherChunkPtr = &tmpChunk;
+		*otherChunkPtr = *(chunkPtr->nextPtr);
+		otherChunkPtr->undisplayProc = NULL;
+		otherChunkPtr->numBytes = 1;
+		tmpStyle = *otherChunkPtr->stylePtr;
+		otherChunkPtr->stylePtr = &tmpStyle;
+		tmpStyle.bgGC = None;
+		borderPtr = (TkBorder *) textPtr->border;
+		tmpStyle.fgGC = borderPtr->bgGC;
+		ci = *((CharInfo *) (otherChunkPtr->clientData));
+		otherChunkPtr->clientData = (ClientData) &ci;
+		ci.numBytes = 1;
+		if ((ci.chars[0] == '\n') ||
+			(ci.chars[0] == ' ') || (ci.chars[0] == '\t')) {
+		    /*
+		     * Ignore newline and other whitespace.
+		     */
+
+		    otherChunkPtr = NULL;
+		}
+	    }
  	    continue;
  	}
  
@@ -2569,6 +2605,28 @@
  		    display, pixmap, dlPtr->y + dlPtr->spaceAbove);
  	}
  
+	if ((otherChunkPtr != NULL) && (textPtr->tkwin != NULL) &&
+		!(textPtr->flags & DESTROYED)) {
+	    /*
+	     * Draw text within the block cursor.
+	     */
+
+	    int x = otherChunkPtr->x + dInfoPtr->x - dInfoPtr->curXPixelOffset;
+
+	    if ((x + otherChunkPtr->width <= 0) || (x >= dInfoPtr->maxX)) {
+		/*
+		 * See note above.
+		 */
+
+		x = -otherChunkPtr->width;
+	    }
+	    otherChunkPtr->displayProc(textPtr, otherChunkPtr, x,
+		    y + dlPtr->spaceAbove, dlPtr->height - dlPtr->spaceAbove -
+		    dlPtr->spaceBelow, dlPtr->baseline - dlPtr->spaceAbove,
+		    display, pixmap, dlPtr->y + dlPtr->spaceAbove);
+	    otherChunkPtr = NULL;
+	}
+
  	if ((textPtr->tkwin == NULL) || (textPtr->flags & DESTROYED)) {
  	    /*
  	     * A displayProc called in the loop above invoked a binding
---8><---

I've tested it in an X11 environment. No idea if this works in Win32 or MacOS.

Cheers,
Christian

Re: [TCLCORE] TIP 715 - Supported platforms and build environments for Tcl/Tk 9.1

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

Folks,
TIP 715 was updated by the given information.

Thanks for any comment !

Harald

Re: [TCLCORE] TIP 714: image driver photo formats

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

Donal,
thanks for the message. For me, the proposed interface has the maximum 
functionality and is intuitive.

"image handler photo formats" contains all necessary information in an 
extendable way.

Extendability is IMHO important, to not end with something like:
image create photo -format [list svg -scaletoheight 120pt] -file test.svg

Or do you see this differently?
Thanks for all,
Harald

Am 01.04.2025 um 13:28 schrieb Donal Fellows:
> My general take is simple enough: try to imagine what would be an ideal 
> interface from Tcl, and adjust the real interface to be as much like 
> that as possible, bearing in mind the realities of what is possible. It 
> can be better to do a larger change while retaining a legacy API (see 
> [trace]) than to struggle on with something less than perfect for the 
> sake of minimalism in changes.
> 
> Donal.
> 
> -------- Original message --------
> From: Harald Oehlmann <har...@el...>
> Date: 01/04/2025 11:56 (GMT+00:00)
> To: tcl...@li...
> Subject: Re: [TCLCORE] TIP 714: image driver photo formats
> 
> I understand that the name of the new subcommand is not optimal.
> The TIP contains all current proposals.
> 
> In addition, the TIP contains a drafted specification of the
> capabilities subcommand.
> Any opinions welcome, if this makes sense or may just be removed.
> The returned list item names are not beautiful neither.
> Please comment and I will change the specification.
> 

Re: [TCLCORE] handling loops interruption within a 'try'

[Donal F. <don...@ma...>]

The original code doesn't work because [while] converts TCL_BREAK into TCL_OK (or is bytecode-compiled to something equivalent). By the time it gets to the [try], it's already gone. Differentiating these is a sufficiently unusual requirement that we have no explicit support for it.

Donal.

-------- Original message --------
From: Csaba Nemethi <csa...@t-...>
Date: 01/04/2025 15:21 (GMT+00:00)
To: tcl...@li...
Subject: Re: [TCLCORE] handling loops interruption within a 'try'

The following *restructured* code works for me as expected:


proc p {}
     while {[some_expensive_query]} {

         # ....

         if {[some_intervening_condition]} {
             return -code break ;# -level 1
         }

         # ....
     }
}

try {
     p
} on break {} {
     puts " ---- break ----"
     puts "Loop interrupted by break"
} on ok {} {
     puts "Loop completed normally"
} finally {
     puts "done"
}


Am 01.04.25 um 07:27 schrieb Massimo Manghi:
> I apologize for (ab)using this mailing list to ask a question that maybe
> has a trivial answer.
>
> I just can't have the 'on break' clause be triggered in a loop
> controlled by a 'try' construct
>
> try {
>      while {[some_expensive_query]} {
>
>          # ....
>
>          if {[some_intervening_condition]} {
>              return -code break -level 0
>          }
>
>          # ....
>      }
> } on break {} {
>      puts " ---- break ----"
>      puts "Loop interrupted by break"
> } on ok {} {
>      puts "Loop completed normally"
> } finally {
>      puts "done"
> }
>
> and you have a normal termination even though the loop was interrupted
> prematurely by [some_intervening_condition]
>
> I can get what I want by raising an exception with 'throw' and then
> using the trap clause which allows extra control over the cause of the
> exception (-errorcode receives no special treatment unless the option -
> code error is passed) but what is the purpose of the 'on break' clause
> if it's not handling a break?
>
>   -- Massimo
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!HEnJRLIzKYhQhoP6uLmD3-X_vyVjELprni_4haY-9QlMVUvAsyae59IdzAhgOQCvj9KRwmBTjlRcm33Vj8Nf9D110XEqyXSCArc5BMUn$[lists[.]sourceforge[.]net]

--
Csaba Nemethi  https://urldefense.com/v3/__https://www.nemethi.de__;!!PDiH4ENfjr2_Jw!HEnJRLIzKYhQhoP6uLmD3-X_vyVjELprni_4haY-9QlMVUvAsyae59IdzAhgOQCvj9KRwmBTjlRcm33Vj8Nf9D110XEqyXSCAsaHg4WY$[nemethi[.]de]  mailto:csa...@t-...



_______________________________________________
Tcl-Core mailing list
Tcl...@li...
https://urldefense.com/v3/__https://lists.sourceforge.net/lists/listinfo/tcl-core__;!!PDiH4ENfjr2_Jw!HEnJRLIzKYhQhoP6uLmD3-X_vyVjELprni_4haY-9QlMVUvAsyae59IdzAhgOQCvj9KRwmBTjlRcm33Vj8Nf9D110XEqyXSCArc5BMUn$[lists[.]sourceforge[.]net]

Re: [TCLCORE] handling loops interruption within a 'try'

[Csaba N. <csa...@t-...>]

The following *restructured* code works for me as expected:

proc p {}
     while {[some_expensive_query]} {

         # ....

         if {[some_intervening_condition]} {
             return -code break ;# -level 1
         }

         # ....
     }
}

try {
     p
} on break {} {
     puts " ---- break ----"
     puts "Loop interrupted by break"
} on ok {} {
     puts "Loop completed normally"
} finally {
     puts "done"
}


Am 01.04.25 um 07:27 schrieb Massimo Manghi:
> I apologize for (ab)using this mailing list to ask a question that maybe 
> has a trivial answer.
> 
> I just can't have the 'on break' clause be triggered in a loop 
> controlled by a 'try' construct
> 
> try {
>      while {[some_expensive_query]} {
> 
>          # ....
> 
>          if {[some_intervening_condition]} {
>              return -code break -level 0
>          }
> 
>          # ....
>      }
> } on break {} {
>      puts " ---- break ----"
>      puts "Loop interrupted by break"
> } on ok {} {
>      puts "Loop completed normally"
> } finally {
>      puts "done"
> }
> 
> and you have a normal termination even though the loop was interrupted 
> prematurely by [some_intervening_condition]
> 
> I can get what I want by raising an exception with 'throw' and then 
> using the trap clause which allows extra control over the cause of the 
> exception (-errorcode receives no special treatment unless the option - 
> code error is passed) but what is the purpose of the 'on break' clause 
> if it's not handling a break?
> 
>   -- Massimo
> 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

-- 
Csaba Nemethi  https://www.nemethi.de  mailto:csa...@t-...

Re: [TCLCORE] TIP 714: image driver photo formats

[Donal F. <don...@ma...>]

My general take is simple enough: try to imagine what would be an ideal interface from Tcl, and adjust the real interface to be as much like that as possible, bearing in mind the realities of what is possible. It can be better to do a larger change while retaining a legacy API (see [trace]) than to struggle on with something less than perfect for the sake of minimalism in changes.

Donal.

-------- Original message --------
From: Harald Oehlmann <har...@el...>
Date: 01/04/2025 11:56 (GMT+00:00)
To: tcl...@li...
Subject: Re: [TCLCORE] TIP 714: image driver photo formats

I understand that the name of the new subcommand is not optimal.
The TIP contains all current proposals.

In addition, the TIP contains a drafted specification of the
capabilities subcommand.
Any opinions welcome, if this makes sense or may just be removed.
The returned list item names are not beautiful neither.
Please comment and I will change the specification.

Re: [TCLCORE] TIP 714: image driver photo formats

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

Dear Tk team,

thanks for the feed-back by Ashok, Paul and Emiliano.
There are no comments rejecting this TIP.

TIP 714 is now updated.

I understand that the name of the new subcommand is not optimal.
The TIP contains all current proposals.

In addition, the TIP contains a drafted specification of the 
capabilities subcommand.
Any opinions welcome, if this makes sense or may just be removed.
The returned list item names are not beautiful neither.
Please comment and I will change the specification.

I have thought two days on the proposal by Emiliano.
Thanks for the pointer to BLT's "picture" image type handler.
This is awesome work.
It may also be possible that this type may by enhanced by this TIP like 
configuring default values or querying option lists like dither methods, 
which may be used in selection boxes later on.

I think, more generic options may later be created on the script level.
For example, a formats method for all image types:

set formats {}
foreach type [image types] {
     if {![catch {image handler $type formats} myFormats]} {
         lappend formats {*}$myFormats
     }
}

Or a photo ensemble, which returns the capabilities:
proc photo {option format} {
     switch -exact $option {
         writesupported {
             return [expr {"write" in [image handler photo capabilities]}]
         }
     }
}

As modifying a C structure is expensive, I like most general interfaces 
on the C level. Any specific function may then be added on the script level.

And of cause, I am not insisting in implementing or proposing this.
I started it, as I see the usage and I already know the code a bit due 
to the metadata extension. Any opinion "stop now, this is useless" is 
welcome!

Thanks for all,
Harald

[TCLCORE] handling loops interruption within a 'try'

[Massimo M. <mas...@ri...>]

I apologize for (ab)using this mailing list to ask a question that maybe 
has a trivial answer.

I just can't have the 'on break' clause be triggered in a loop 
controlled by a 'try' construct

try {
     while {[some_expensive_query]} {

         # ....

         if {[some_intervening_condition]} {
             return -code break -level 0
         }

         # ....
     }
} on break {} {
     puts " ---- break ----"
     puts "Loop interrupted by break"
} on ok {} {
     puts "Loop completed normally"
} finally {
     puts "done"
}

and you have a normal termination even though the loop was interrupted 
prematurely by [some_intervening_condition]

I can get what I want by raising an exception with 'throw' and then 
using the trap clause which allows extra control over the cause of the 
exception (-errorcode receives no special treatment unless the option 
-code error is passed) but what is the purpose of the 'on break' clause 
if it's not handling a break?

  -- Massimo

Re: [TCLCORE] Announcing the tcltk-depot Github organization for extensions

[<apn...@ya...>]

Two additional notes:

 

Thanks to Clif for support through TCA.

 

Also, in case anyone is wondering, the existing tcltk organization was also
considered to host the extensions. It was thought better to have a separate
organization for a couple of reasons. First, hosting extensions under tcltk
could possibly imply the extensions were under the control / responsibility
of the TCT. That is very much not the case. Second, tcltk is a mirror of the
source hosted on core fossil and not the primary location for pull requests,
tickets etc. It would be a point of confusion if some repositories under
tcltk were primary and others were not.

 

/Ashok 

 

 

From: apnmbx-public--- via Tcl-Core <tcl...@li...> 
Sent: Monday, March 31, 2025 4:51 PM
To: tcl...@li...
Subject: [TCLCORE] Announcing the tcltk-depot Github organization for
extensions

 

Announcing the tcltk-depot organization https://github.com/tcltk-depot .

 

TL;DR a central repository for "orphaned" extensions under the auspices of
TCA and maintained by the community. Details as per the README below.

 

(Brian, your TclX update for Tcl 9 could be a candidate.)

 

Current admins are Clif, Harald and myself. Note this is not under the
purview of the TCT.

 

The org has just been set up and is currently empty. Orphaned packages will
be added over time. Please raise a ticket for candidate packages that might
be added following the procedure in the README. Active contributors would be
most welcome.

 

README.md

 

This Github organization, owned by the Tcl Community Association, hosts
repositories for Tcl/Tk packages and applications, in particular those that
are no longer maintained by the original author(s). The intent is to avoid
proliferation of forks by providing a centralized location for users to
download as well as provide patches.

See Repositories
<https://github.com/orgs/tcltk-depot/repositories?q=visibility%3Apublic+arch
ived%3Afalse>  for a list of currently hosted packages.

Requesting an addition

To request addition of a package, please raise a ticket
<https://github.com/tcltk-depot/.github/issues>  with a public URL of the
repository to be added along with contact information of the original
owner/maintainer if available. Ideally, this source repository would have
merged any existing patches or forks.

Note that addition of a repository here does not change the license or
copyright of the package.

Contributing

The tcltk-depot administrators are not responsible for maintenance and
upkeep of the hosted packages. The intent is that this will be a community
effort. If willing to help in this regard,

*         for a one-time contribution to a specific package, create a pull
request (preferred) or create a ticket with an attached patch in that
package's repository

*         for ongoing contributions to one (or a few) repositories, raise a
ticket <https://github.com/tcltk-depot/.github/issues>  in the organization
(not package) to become a collaborator on those repositories

*         for contributing to multiple repositories, it would be easiest to
join tcltk-depot as a member, again by raising a ticket
<https://github.com/tcltk-depot/.github/issues>  in the organization.

 

[TCLCORE] Announcing the tcltk-depot Github organization for extensions

[<apn...@ya...>]

Announcing the tcltk-depot organization https://github.com/tcltk-depot .

 

TL;DR a central repository for "orphaned" extensions under the auspices of
TCA and maintained by the community. Details as per the README below.

 

(Brian, your TclX update for Tcl 9 could be a candidate.)

 

Current admins are Clif, Harald and myself. Note this is not under the
purview of the TCT.

 

The org has just been set up and is currently empty. Orphaned packages will
be added over time. Please raise a ticket for candidate packages that might
be added following the procedure in the README. Active contributors would be
most welcome.

 

README.md

 

This Github organization, owned by the Tcl Community Association, hosts
repositories for Tcl/Tk packages and applications, in particular those that
are no longer maintained by the original author(s). The intent is to avoid
proliferation of forks by providing a centralized location for users to
download as well as provide patches.

See Repositories
<https://github.com/orgs/tcltk-depot/repositories?q=visibility%3Apublic+arch
ived%3Afalse>  for a list of currently hosted packages.

Requesting an addition

To request addition of a package, please raise a ticket
<https://github.com/tcltk-depot/.github/issues>  with a public URL of the
repository to be added along with contact information of the original
owner/maintainer if available. Ideally, this source repository would have
merged any existing patches or forks.

Note that addition of a repository here does not change the license or
copyright of the package.

Contributing

The tcltk-depot administrators are not responsible for maintenance and
upkeep of the hosted packages. The intent is that this will be a community
effort. If willing to help in this regard,

*	for a one-time contribution to a specific package, create a pull
request (preferred) or create a ticket with an attached patch in that
package's repository
*	for ongoing contributions to one (or a few) repositories, raise a
ticket <https://github.com/tcltk-depot/.github/issues>  in the organization
(not package) to become a collaborator on those repositories
*	for contributing to multiple repositories, it would be easiest to
join tcltk-depot as a member, again by raising a ticket
<https://github.com/tcltk-depot/.github/issues>  in the organization.