<!DOCTYPE html> <html> <head> <meta http-equiv="content-type" content="text/html; charset=UTF-8"> </head> <body> I've been following some of the discussions around new cursor theme specs and wanted to throw an idea out there to get some feedback on it. The following is a modified section of the XCursor man page to illustrate my thoughts <pre> CURSOR FILES Xcursor defines a new format for cursors on disk. Each file holds one or more cursor images. Each cursor image is tagged with a nominal size so that the best size can be selected automatically. Multiple cursors of the same nominal size can be loaded together; applications are expected to use them as an animated sequence. + Originally XCursor only specified uncompressed images and comments as + chunks. In addition to uncompressed images, icon files may now reference + external files such as vector images to provide scalable and/or higher + quality images than can be contained in a traditional image chunk. When + multiple file sections of the same subtype are loaded, they are + considered an animated sequence. + If Vector chunks are included and the client supports them, raster and + classic image chunks should be ignored and the vector chunks used instead. + If the client does not support vector chunks or none are provided then + XCursor will read the raster and image chunks together. Animation frames + for a given size must all be of the same chunk type. For example an icon + may consist of three Image chunks of the same size and three Raster chunks + of a different size, but it may not consist of an Image section and a + Raster which have the same size. Cursor files are stored as a header containing a table of contents followed by a sequence of chunks. The table of contents indicates the type, subtype and position in the file of each chunk. The file header looks like: magic: CARD32 "Xcur" (0x58, 0x63, 0x75, 0x72) header: CARD32 bytes in this header version: CARD32 file version number ntoc: CARD32 number of toc entries toc: LISTofTOC table of contents Each table of contents entry looks like: type: CARD32 entry type subtype: CARD32 type-specific label - size for images position: CARD32 absolute byte position of table in file Each chunk in the file has set of common header fields followed by additional type-specific fields: header: CARD32 bytes in chunk header (including type-specific fields) type: CARD32 must match type in TOC for this chunk subtype: CARD32 must match subtype in TOC for this chunk version: CARD32 version number for this chunk type ~ There are currently three chunk types defined for cursor files; comments, ~ classic images, rasters, and vectors. Comments look like: header: 20 Comment headers are 20 bytes type: 0xfffe0001 Comment type is 0xfffe0001 subtype: { 1 (COPYRIGHT), 2 (LICENSE), 3 (OTHER) } version: 1 length: CARD32 byte length of UTF-8 string string: LISTofCARD8 UTF-8 string Images look like: header: 36 Image headers are 36 bytes type: 0xfffd0002 Image type is 0xfffd0002 subtype: CARD32 Image subtype is the nominal size version: 1 width: CARD32 Must be less than or equal to 0x7fff height: CARD32 Must be less than or equal to 0x7fff xhot: CARD32 Must be less than or equal to width yhot: CARD32 Must be less than or equal to height delay: CARD32 Delay between animation frames in milliseconds pixels: LISTofCARD32 Packed ARGB format pixels + Rasters look like: + + header: 40 Comment headers are 32 bytes + type: 0xfffe0003 File type is 0xfffe0003 + subtype: { 1 (PNG) } + version: 1 + size CARD32 Nominal size + width: CARD32 Must be less than or equal to 0x7fff, must be 0 for SVGs + height: CARD32 Must be less than or equal to 0x7fff, must be 0 for SVGs + xhot: CARD32 Must be less than or equal to width + yhot: CARD32 Must be less than or equal to height + delay: CARD32 Delay between animation frames in milliseconds + length: CARD32 byte length of UTF-8 path + path: LISTofCARD8 Slash separated UTF-8 encoded relative path + within the "content" directory + + Vectors look like: + + header: 32 Comment headers are 32 bytes + type: 0xfffe0003 File type is 0xfffe0003 + subtype: { 1 (SVG) } + version: 1 + xhot: CARD32 Must be less than or equal to width + yhot: CARD32 Must be less than or equal to height + delay: CARD32 Delay between animation frames in milliseconds + length: CARD32 byte length of UTF-8 path + path: LISTofCARD8 Slash separated UTF-8 encoded relative path + within the "content" directory THEMES Xcursor (mostly) follows the freedesktop.org spec for theming icons. The default search path it uses is ~/.local/share/icons, ~/.icons, /usr/share/icons, /usr/share/pixmaps Within each of these directories, it searches for a directory using the theme name: o Within the theme directory, it looks for cursor files in the "cursors" subdirectory. Xcursor looks for a specific file, which must be one of the cursor shape names, e.g., as used in XcursorLibraryLoadImage or XcursorLibraryShape. + o Within the theme directory, it looks for paths referenced by a "File" + chunk in the "content" subdirectory. Such paths must not resolve to + any file not within the "content" directory + + Such SVG files must not contain animation directives and must be + self contained (i.e. they may not reference other images). o If it finds no matching cursor file in the "cursors" subdirectory, Xcursor next looks for an "index.theme" file in each theme directory to look for inherited themes. Those are lines in this format: Inherits = theme-name Xcursor uses the first inherited theme-name, ignoring others which may exist in a given "index.theme" file. If it finds an inherited theme, Xcursor searches along the path to use that as well. Xcursor ignores other keys in the "index.theme" file, including "Name" (i.e., the name which a graphical application may use as the presentation name). More than one theme-name may be listed on the Inherits= line. The freedesktop.org spec states that list items are separated by commas. Xcursor also accepts semicolon, but translates both to colon when searching the path. Xcursor expects only one Inherits= line; the freedesktop.org spec is unclear whether multiple keys are allowed. If no theme is set, or if no cursor is found for the specified theme anywhere along the path, Xcursor checks the "default" theme. When Xcursor finds a cursor file, it stops searching. It always uses the first cursor file found while searching along the path. </pre> <pre></pre> This is broadly an effort to match the capabilities of Hyprcursors within the confines of existing XCursor infrastructure. From what I have read of the XCursor codebase, older programs would still be able understand a cursor which includes these extra chunks. However, any updated themes or applications would have access to PNG and SVG cursors without needing to overhaul their cursor handling. For backwards compatibility themes would need to keep classic image chunks in the cursor files, but could cut back on how many they ship and would no longer be quite as constrained by file size. Any thoughts? My background is in application side more than desktop infrastructure so it's possible I'm missing some major blocker here, but I'd love to hear any feedback </body> </html>