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