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...>