Tk_CreateImageType(3tk)

📦 version 8.6.18, in debian bookworm, debian trixie, ubuntu jammy, ubuntu noble, ubuntu questing, ubuntu resolute, ubuntu stonking

💖 Tk_CreateImageType 💖 — Tk Library Procedures

okay so bestie, this is Tk_CreateImageType(3tk) from the Tk Library Procedures, and it's literally the page that teaches Tk a brand new kind of image. it's a long one so we're doing it in two parts — this is part one, don't go anywhere 💅

✨ NAME ✨

Tk_CreateImageType, Tk_GetImageMasterData, Tk_GetImageModelData, Tk_InitImageArgs — define new kind of image

🌈 SYNOPSIS 🌈

#include <tk.h>

Tk_CreateImageType(typePtr)

ClientData
Tk_GetImageMasterData(interp, name, typePtrPtr)

ClientData                                                               2
Tk_GetImageModelData(interp, name, typePtrPtr)                           2

Tk_InitImageArgs(interp, argc, argvPtr)

🎀 ARGUMENTS 🎀

  • const Tk_ImageType *typePtr (in) — the structure that defines the new type of image. heads up: for Tk 8.4 and earlier this has to be static, because a pointer to this structure gets retained by the image code. in Tk 8.5 that limitation got relaxed, slay.
  • Tcl_Interp *interp (in) — the interpreter in which the image was created.
  • const char *name (in) — the name of an existing image.
  • Tk_ImageType **typePtrPtr (out) — points to the word where we stash a pointer to the type info for the given image, if it exists.
  • int argc (in) — number of arguments.
  • char ***argvPtr (in/out) — pointer to the argument list.

🌸 DESCRIPTION 🌸

So. You call Tk_CreateImageType to define a whole new kind of image ✨. An image type is basically whatever you'd pass as the type argument to the image create command. And bestie, there is no limit here — you can have as many different image types as you want, and new ones can be defined dynamically just by calling Tk_CreateImageType. For example, there might be one type for 2-color bitmaps, another for multi-color images, another for dithered images, another for video, and so on. the range? unmatched 💅

The code that implements a new image type is called an image manager. It's a collection of procedures plus three different kinds of data structures. Let's get into it.

Data structure #1 is a Tk_ImageType structure — it holds the name of the image type and pointers to five procedures that the image manager provides to deal with images of this type:

typedef struct Tk_ImageType {
    const char *name;
    Tk_ImageCreateProc *createProc;
    Tk_ImageGetProc *getProc;
    Tk_ImageDisplayProc *displayProc;
    Tk_ImageFreeProc *freeProc;
    Tk_ImageDeleteProc *deleteProc;
} Tk_ImageType;

The fields of this structure get described in later subsections of this entry, so keep reading 🫶

Data structure #2 is called an image model. It contains the overall info about a particular image — like the values of the configuration options you specified in an image create command. There's usually one of these for every single invocation of the image create command.

Data structure #3 is an image instance. There's usually one of these for each usage of an image in a particular widget. And get this: a single image can show up simultaneously in multiple widgets, or even multiple times in the same widget. Plus, different instances can be on different screens or displays. The image instance data structure describes the stuff that can vary from instance to instance — colors, graphics contexts for redisplay, all of that. There's usually one instance structure for each -image option specified for a widget or canvas item.

The following subsections describe the fields of a Tk_ImageType in more detail. buckle up 🦋

💜 NAME 💜

typePtr->name gives the image type its name. Once Tk_CreateImageType returns, you can use that name in image create commands to create images of the new type. And if an image type with that name already existed? the new image type replaces the old one. periodt.

💜 CREATEPROC 💜

typePtr->createProc holds the address of a procedure that Tk calls whenever image create is invoked to create an image of the new type. typePtr->createProc must match this prototype exactly:

typedef int Tk_ImageCreateProc(
        Tcl_Interp *interp,
        const char *name,
        int objc,
        Tcl_Obj *const objv[],
        const Tk_ImageType *typePtr,
        Tk_ImageMaster model,
        ClientData *modelDataPtr);
  • The interp argument is the interpreter in which the image command was invoked.
  • name is the name for the new image — either specified explicitly in the image command or generated automatically by it.
  • The objc and objv arguments describe all the configuration options for the new image (everything after the name argument to image).
  • The model argument is a token that refers to Tk's information about this image; the image manager must return this token to Tk when invoking the Tk_ImageChanged procedure.

Typically createProc will parse objc and objv and create an image model data structure for the new image. createProc may store an arbitrary one-word value at *modelDataPtr, which will be passed back to the image manager when other callbacks are invoked. Typically that value is a pointer to the model data structure for the image.

If createProc encounters an error, it should leave an error message in the interpreter result and return TCL_ERROR; otherwise it should return TCL_OK.

also createProc should call Tk_ImageChanged in order to set the size of the image and request an initial redisplay. don't forget, bestie 😭

💜 GETPROC 💜

typePtr->getProc gets invoked by Tk whenever a widget calls Tk_GetImage to use a particular image. This procedure must match the following prototype:

typedef ClientData Tk_ImageGetProc(
        Tk_Window tkwin,
        ClientData modelData);

The tkwin argument identifies the window in which the image will be used, and modelData is the value returned by createProc when the image model was created. getProc will usually create a data structure for the new instance, including things like the resources needed to display the image in the given window. getProc returns a one-word token for the instance, which is typically the address of the instance data structure. Tk will pass this value back to the image manager when invoking its displayProc and freeProc procedures. 🔥

💜 DISPLAYPROC 💜

typePtr->displayProc is invoked by Tk whenever an image needs to be displayed — i.e., whenever a widget calls Tk_RedrawImage. displayProc must match this prototype:

typedef void Tk_ImageDisplayProc(
        ClientData instanceData,
        Display *display,
        Drawable drawable,
        int imageX,
        int imageY,
        int width,
        int height,
        int drawableX,
        int drawableY);
  • instanceData will be the same as the value returned by getProc when the instance was created.
  • display and drawable indicate where to display the image. note that drawable may be a pixmap rather than the window specified to getProc — this is usually the case, since most widgets double-buffer their redisplay to get smoother visual effects. aesthetic behavior, honestly.
  • imageX, imageY, width, and height identify the region of the image that must be redisplayed. This region will always be within the size of the image as specified in the most recent call to Tk_ImageChanged.
  • drawableX and drawableY indicate where in drawable the image should be displayed; displayProc should display the given region of the image so that point (imageX, imageY) in the image appears at (drawableX, drawableY) in drawable.

💜 FREEPROC 💜

typePtr->freeProc contains the address of a procedure that Tk will invoke when an image instance is released (i.e., when Tk_FreeImage is invoked). This can happen, for example, when a widget is deleted or an image item in a canvas is deleted, or when the image displayed in a widget or canvas item is changed. freeProc must match the following prototype:

typedef void Tk_ImageFreeProc(
        ClientData instanceData,
        Display *display);

The instanceData will be the same as the value returned by getProc when the instance was created, and display is the display containing the window for the instance. freeProc should release any resources associated with the image instance, since the instance will never be used again. 🫶

💜 DELETEPROC 💜

typePtr->deleteProc is a procedure that Tk invokes when an image is being deleted (i.e. when the image delete command is invoked). Before invoking deleteProc, Tk will invoke freeProc for each of the image's instances. deleteProc must match the following prototype:

typedef void Tk_ImageDeleteProc(
        ClientData modelData);

The modelData argument will be the same as the value stored in *modelDataPtr by createProc when the image was created. deleteProc should release any resources associated with the image. clean up after yourself, it's giving main character energy ✨

💜 TK_GETIMAGEMODELDATA 💜

The procedure Tk_GetImageMasterData may be invoked to retrieve information about an image. For example, an image manager can use this procedure to locate its image model data for an image. If there exists an image named name in the interpreter given by interp, then *typePtrPtr is filled in with type information for the image (the typePtr value passed to Tk_CreateImageType when the image type was registered) and the return value is the ClientData value returned by the createProc when the image was created — this is typically a pointer to the image model data structure. If no such image exists then NULL is returned and NULL is stored at *typePtrPtr.

Tk_GetImageModelData is synonym for Tk_GetImageMasterData 2

and that's part one bestie 💖 part two is coming, so don't close the tab 🦋

💀 LEGACY INTERFACE SUPPORT 💀

okay bestie, deep breath, because this is the vintage part of the page. Like, thrift-store-find energy. In Tk 8.2 and earlier, the definition of Tk_ImageCreateProc was incompatibly different, with this prototype:

typedef int Tk_ImageCreateProc(
        Tcl_Interp *interp,
        char *name,
        int argc,
        char **argv,
        Tk_ImageType *typePtr,
        Tk_ImageMaster model,
        ClientData *modelDataPtr);

like, not the same signature at all. different era, different rules, no cap.

Legacy programs and libraries dating from those days may still contain code that defines extended Tk image types using the old interface. The Tk header file will still support this legacy interface if the code is compiled with the macro USE_OLD_IMAGE defined.

🫶 tiny footnote the page drops right here: Tk_ImageModel is a synonym for Tk_ImageMaster.

When the USE_OLD_IMAGE legacy support is enabled, you may see the routine Tk_InitImageArgs in use. This was a migration tool used to create stub-enabled extensions that could be loaded into interps containing all versions of Tk 8.1 and later. Tk 8.5 no longer provides this routine, but uses a macro to convert any attempted calls of this routine into an empty comment. iconic behavior honestly ✨

Any stub-enabled extension providing an extended image type via the legacy interface that is compiled against Tk 8.5 headers and linked against the Tk 8.5 stub library will produce a file that can be loaded only into interps with Tk 8.5 or later; that is, the normal stub-compatibility rules. If a developer needs to generate from such code a file that is loadable into interps with Tk 8.4 or earlier, they must use Tk 8.4 headers and stub libraries to do so. 🧚

⚠️ and the big one, bestie: Any new code written today should not make use of the legacy interfaces. Expect their support to go away in Tk 9. like, gone gone. so don't build your cute little project on top of it 💅

👀 SEE ALSO

  • Tk_ImageChanged
  • Tk_GetImage
  • Tk_FreeImage
  • Tk_RedrawImage
  • Tk_SizeOfImage

go read those, they're the rest of the lore 🌸

🔑 KEYWORDS

  • image manager
  • image type
  • instance
  • model

and that's the whole page, bestie!! 🎀 this one's from the Tk 8.5 era, and you just read the manual page Tk_CreateImageType(3tk) in full — every single flag, every legacy caveat, every keyword, nothing skipped, we ate and left no crumbs 👑💖 mwah, go make something iconic with it 🦋

📦 where this page comes from