Skip to content

Decide on an SVG cursor format

EDIT: Changed the title to reflect the end result instead of the original plan (was: Extend the XCursor theme format to support SVG cursors). The old title might mislead those who clicked through the link in Nate's blog mentioning this issue.

What's actually merged: !475 (merged) kwin!6187 (merged)

==========

After !453 (merged), we shall package those SVG cursors along with metadata (hotspot, animation sequence and frame time) and ship to the end user. This issue is to decide on the format.

IMHO, there are a few requirements:

  1. It should extend the current XCursor theme format, not being a completely new format. So the Cursor KCM and the like can remain largely intact. The current index.html file and cursors/ directory layout should be kept intact if possible.
  2. It should still ship pixmaps as in the original XCursor, alongside with SVGs. So old executables can still use a new-format theme without linking with a new version of libxcursor.
  3. It should be easy for the end user to tell that this is a new-format theme. E.g. by having a cursor-content directory side-by-side with cursors. So despite we can embed an SVG in a chunk of the XCursor file, and not adding any new files in the new format, we shouldn't do that.

And some points up for debate:

  1. How does an app use SVG cursors, via the old pixmap-based API (which renders the SVG into a pixmap), or some new API (which probably just return the SVG as a string, then the app should render it)?

I think it should be the latter.

a) For the former, what would be the list of available sizes for SVG? It should be "any size you want", but that would probably create problems in apps. But if you return the sizes of pixmaps, then it makes no sense as those pixmaps were pre-rendered from the SVG, so you can just return them instead.

b) It would require libxcursor to link with an SVG renderer, which might not be desirable.

So I think the old API should only access pixmaps. The app should call a new API to get the SVG cursor as a string, and render the cursor by itself. This might seem inconvenient, but probably only Wayland compositors need to do that, and apps should use the Wayland cursor shape protocol instead of making this change.

  1. Should we support PNG? I think not. As in point 2, we have to ship pixmaps (for compatibility) anyway, so PNG doesn't save space. (Unless some of your cursors aren't SVG-based, e.g. it's from a photo, then you might want to ship a huge PNG (or JPEG really?))

@vladz @jthoward

Edited by Jin Liu