Cursor conventions spec

[Fredrik Höglund]

On Wednesday 15 October 2003 01:48, Keith Packard wrote:
> I don't have any idea whether the included cursors are necessary and
> sufficient, but I do have other comments...
>
> X-cursor:	let's get rid of this one; it's just confusing.  I can
> 		make the X server start up with a different image by
> 		default -- having the X server use the Xcursor library to
> 		load the 'default' cursor from the default theme is one
> 		simple idea.

Yeah, I think that's a good idea. I'll go ahead and remove it from the list.

> right-arrow:	given the defintion (inverted version of default), it seems
> 		like the name could be 'inverted-default' or some such.

Another thing about this cursor is the description... right now it's just
an observation of how Motif uses it, but doesn't make a recommendation
either way. Do toolkit developers have an opinion about this?

> The others seem fine to me.  I suggest that we also define 'fall-back'
> rules for each of the default cursors so that a theme may present fewer
> cursors and yet still get each standard cursor represented by the theme.

I've already done that with the no-drop cursor, but I think whenever an
app asks for a cursor other than default it wants to convey a message to
the user, and care needs to be taken so that message doesn't get lost.
I'm open to suggestions of which cursors should be required, and which
should be optional.

> Then I'd like to get an idea of how more general cursor aliasing should
> work; the current 'symlink' method is horribly broken.  While we could
> place this information in the index.theme file, I was wondering if we
> shouldn't create special alias cursor files instead; separate files are
> generally easier for software installation scripts to deal with.

I think we should also create an additional Wiki page for cursor aliases,
where application/toolkit authors can easily add the aliases they need.
Those could then be extracted and shipped as a part of Xcursor.

If we have a good collection of aliases for the standard cursors, and
they can be shared by all themes, I'm not sure to what extent it will
be necessary for applications to install additional aliases themselves.
The aliases is after all really a backwards compatability mechanism.

It might be good enough to put all the aliases in a text file similar to
the rgb database. If artists decide they want to theme additional
cursors in apps that don't support Xcursor directly, they could put
the aliases for those cursors in their index.theme files.

Having the aliases in text files has the advantage that Xcursor can
keep them in memory, rather than having to search in the themes
for them, which may require walking the inheritance tree.

Finally, we also need to decide what the names in the cursor list
represent; Are they filenames, or are they the names apps/toolkits
specify when they make calls to Xcursor?

Either way we need to decide how the old fontcursor names should
be mapped to the new names.

Regards,
Fredrik