Cursor conventions spec

[Keith Packard]

Around 23 o'clock on Oct 17, Fredrik =?iso-8859-1?q?H=F6glund?= wrote:

> 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?

Hmm.  I think it's significant that the cursor avoids occluding the menu 
entries when pointing at the left hand side of them.  In an RTL 
environment, I can easily imagine wanting to use a left arrow for this 
task, and as a left-handed mouse user, it seems like I should use a right 
arrow for the default cursor (and a right arrow for the menu selection 
cursor as I predominantly use a left-to-right language).

So perhaps this is a 'menu selection' cursor?  A cursor used to traverse 
menu entries?

> 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.

I think we'll need to get some feedback from application authors on that 
point; I'd like to be able to import cursor themes from other environments 
and have them do sensible things though.  I suspect the most problematic 
cursors are all of the resize arrows; it may be that we need to map all of 
those to a single resize cursor for defaulting purposes.

> 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.

I guess we should try and figure out what the aliases are good for.  They 
have two separate roles right now:

	1)	map cursor hash values to pretty themed cursors
	2)	map unavailable cursors to available ones.

If we have built-in defaulting rules for unavailable standard cursors, 
then I don't think 2) has a lot of utility.  And 1) is entirely for legacy 
applications; I suggest that we map these to two names -- a specific name 
that can map to a custom cursor and a standard name.

In this latter case, the mapping is entirely independent of the theme and 
can be placed in a system-wide configuration files; perhaps a set of 
directories containing mapping files.

> 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?

I suggest 'both' -- names presented to Xcursor should map naturally to 
filenames.  Using a separate namespace seems like just a lot of work for 
no gain.

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

Again, I suggest a specific/standard name pair for each cursor; themes 
could provide specific cursors as desired.  They're just legacy aliases in 
any caes.

-keith