Cursor conventions spec

[Fredrik Höglund]

On Friday 17 October 2003 00:10, Keith Packard wrote:
> > 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.

The side/corner cursors can easily be mapped to the twin-headed arrow
cursors, e.g. e-resize and w-resize -> ew-resize. Then you end up with
four cursors instead of eight. I think those should be quite easy to
design, since you only have to draw one and then rotate it. E17 also
has a cursor that looks like fleur rotated 45 degrees, which it uses for
all corners. If we add that cursor we could get it down to three.

I don't think we can get it down to one though, since then you wouldn't
be able to tell when you're holding the cursor close enough to a window
corner to be able to resize it diagonally, which would be annoying. On
the other hand I understand that OSX doesn't use resizing cursors at
all, so it would be interesting to know how they solve that.

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

Right, the additional Wiki page would only be for 1) of course, and only
for those hash values that can be mapped to a standard cursor.

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

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?

Regards,
Fredrik