Re: Adjusting the 2.4 schedule (cursors)

[Owen Taylor <otaylor redhat com>]

On Tue, 2003-06-24 at 19:45, Keith Packard wrote:
> 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.

Should accessible descriptions be part of the cursor theme? 
We have some prior art for how that would work with the icon theme
which allows for a localizable name for icons.

The main problem with making the descriptions part of the cursor theme
is that you dont' want to duplicate them in each cursor theme.
Perhaps you could have inheritance of the description from
the parent theme.

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

Well, we haven't settled how icon themes will work on windows yet,
but the likely way is simply that we'll just copy the way it works
on Unix rather than trying to integrate with the system. Since
the code to locate icons is in GTK+, and the icons are simply standard
image formats that gdk-pixbuf supports, all we have to do is 
change /usr/share/icons to some appropriate path on Windows.

But that doesn't work at all for cursors

 the code to locate icons is in libXcursor
 the code to load icons is in libXcursor
 for standard icons, we should use the standard Windows cursors
 
Perhaps we need to port libXcursor to Windows or at least part
of it. It's not pleasant, but then again, saying that to use
a custom cursor on Unix, you should install a Xcursor format
file in a theme directory, while on Windows, you should do 
something entirely different (say, put an .ico or .ani in
a resource file) isn't pleasant eithr.

(And while custom cursors should be avoided when possible, I am
quite certain that "never use custom cursors" is not something
which will fly with GTK+ develoeprs.)

This is sounding definitely like 2.6 material to me, though the
"cursor from pixbuf" stuff should be able to go in anyways.

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

My concern is more that people haven't gotten over the addition
of expat/render/Xrender/Xft/freetype for 2.2 (which will become required
dependencies for 2.4.) It's become prohibitively hard to build
GTK+ and every new dependency makes that a bit worse.

The libXrender dependency doesn't matter since we already have that for
Xft.

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

It strikes me as a bit of a problem if in some cursor themes all your
resize handles for a window show the same cursor... especially with 
some old window managers where the resize cursor provided essential
information as to what was going to happen.

Really, my experience is that theme designers don't have a problem 
churning out amazing types of artwork (the number of icons in an icon
theme is quit shocking ... hundreds and hundreds.) 

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

The conclusion I'd draw from that is that we should pick a reasonable
sized set of standard cursors, say that icon themes should support
all of them. Too much flexibility will reduce consistency.

Regards,
						Owen