Re: Adjusting the 2.4 schedule (cursors)

[Keith Packard <keithp keithp com>]

Around 14 o'clock on Jun 24, Owen Taylor wrote:

>  - Create cursor by name

An important part of that name is the semantics associated with it.  
Making sure the name and semantics are visible outside of the cursor 
loading mechanism will help improve a14y for people with limited vision.

>  - Create cursors from pixbuf

An issue here is how to ensure that the application semantics are exposed 
to the underlying a14y framework so that suitable feedback can be provided.

>  - Create animate cursor from pixbufs

Always our favorite.

>  - How does portability to windows work? If you created a custom
>    cursor that you installed into the default theme in Unix,
>    what would you do in Windows. (Windows has: standard system
>    cursor, from resource file, from data stream.)

Whatever mechanism is used for icons will work for cursors -- presumably 
there is a place applications can install custom icons.

>  - How does legacy handling work for named cursors? (I don't think
>    we want to require Xcursor for 2.4)

In case it matters, Xcursor is not dependent on any features in X.  Without
Render support, Xcursor falls back to using the legacy monochrome cursor
support.  Getting Xcursor to build without using the Xrender library would
take a bit of work, but would not expose any changes in the ABI or API.

> I think this list is likely a bit short ... for comparison, Havoc's list
> of useful X cursors is at:

It was intentionally short; I'd like to justify each additional standard 
cursor name before adding it to the 'required' list.

> There are also some cursors that really should be in cursor themes that
> aren't in either list ... DND cursors come to mind. I don't think making
> a cursor theme creator do 20-30 cursors is excessive, as long as they
> aren't spending all their time drawing sailboats and space shuttles.

I think it would be OK to *allow* themes to provide 20-30 cursors and have
them visually distinct.  I think it would also be nice to unify the
semantic notions somewhat - e.g., it would be nice if all of the 'resize'
cursors are related and could map to a single cursor for less agressive
theme designers.  

Perhaps some kind of relationship between the cursors so that the 'nearest'
cursor could be substituted from the theme instead of falling back to a
default cursor.  It's visually jarring to have cursors blink between
different themes as you wave the pointer over the screen.

> I have some trouble seeing how one would draw this line.

I guess what I'd like is some way to 'fall-back' to themed cursors when a 
standard but unimplemented name is presented to the API.

-keith