Cursor conventions spec
keithp at keithp.com
Fri Oct 17 01:10:00 EEST 2003
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
> 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
> 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
More information about the xdg