Cursor conventions spec

Fredrik Höglund fredrik at kde.org
Thu Oct 23 02:48:23 EEST 2003


On Thursday 23 October 2003 00:45, Keith Packard wrote:
> A cursor theme may well want to use the same image for several standard
> cursors; either the defaulting mechanisms should fall back in a well
> defined behaviour to make this easy to do, or we should provide some other
> way for themes to do this mapping for themselves.

I'm not arguing against that, I think we can provide sensible fallbacks
for all the cursors, eventually ending up with just the default cursor.

What I'm suggesting is a fallback strategy for the resizing cursors, along
with a suggestion for which ones should be marked as required.

That a cursor is marked as required doesn't mean we don't provide a
fallback for it, I see it mainly serving as a way of discouraging theme
authors from creating themes that create usability problems for the
end user.

> > I'm not sure I follow you here... some bitmap cursors will have a one-to-
> > one correspondance with the new standard cursors. Are those the ones
> > you mean should be mapped to a standard name in a system-wide config
> > file, while the mapping information for other bitmap cursor will still be
> > stored in the cursor themes?
>
> uhh.  My idea was that these two reasons for aliasing appear to be
> independent of the theme and are hence system-wide.  This would mean that
> all aliases should live outside of the theme directories.  I'm not sure
> restricting things this way will be useful, but I think it might simplify
> the design in some ways.

Well I think there is a separation between the two, since in one case you'll
have a well defined name for the cursor, and in the other the name is
choosen by the theme author.

In the first case it's easy to share the aliases, but in the latter there's
a danger that we'll end up with conflicts if they're all installed in the
place. That artists don't choose the same names for the same bitmap
cursors is something I'm already seeing in existing themes.

Fredrik




More information about the xdg mailing list