Re: Adjusting the 2.4 schedule (cursors)
- From: Owen Taylor <otaylor redhat com>
- To: Keith Packard <keithp keithp com>
- Cc: gtk-devel-list gnome org
- Subject: Re: Adjusting the 2.4 schedule (cursors)
- Date: 24 Jun 2003 14:32:43 -0400
On Tue, 2003-06-24 at 13:29, Keith Packard wrote:
> Around 11 o'clock on Jun 24, Owen Taylor wrote:
>
> > - X cursor support for GTK+
>
> I'd like to see at least a preliminary outline of a spec for a set of
> standard cursor names and how they map to the existing core cursor
> numbers. Without that, we're left with the current disaster where cursor
> themes require far too many cursors to implement reasonably. We'll need
> rough semantic descriptions for the HIG as well. Here's a short list,
> perhaps we can keep it brief and reduce the number of different cursors
> that appear on the screen for most application uses:
I think most likely the GTK+ API would have three things:
- Create cursor by name
- Create cursors from pixbuf
- Create animate cursor from pixbufs
http://bugzilla.gnome.org/show_bug.cgi?id=69436 has patches for the
latter two. The first is trivial to implement, though has some
interesting side questions:
- 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.)
- How does legacy handling work for named cursors? (I don't think
we want to require Xcursor for 2.4)
I think for most cases, we'd continue to encourage people to use
the GDK enumeration values, possibly augmented/with deprecations
marked rather than using named cursors where not needed. Named
cursors would, I think, be simply a way of creating custom cursor
with the possibility of themes theming them.
> Pointer. Default cursor. Indicates the interface is idle and prepared
> to accept commands from the user. Used to manipulate basic
> user interface elements like buttons and scrollbars.
>
> Text. Text input cursor. Indicates the cursor is in a region which
> can select text and possibly edit text.
>
> Busy. Busy cursor. Indicates the interface is not prepared to
> accept commands from the user and is blocked on some
> external resource.
>
> Pointer+Busy. Default cursor + busy cursor. Indicates a pending activity
> which may asycnhronously affect the interface but which
> is not blocking commands from the user.
>
> Grab. Manipulation cursor. Indicates the interface is engaged in
> direct manipulation of some visible representation of
> an object.
>
> Silly. Ridiculous cursor. Indicates that the interface is intent
> on provoking the user with arbitrary and capricious responses.
I think this list is likely a bit short ... for comparison, Havoc's list
of useful X cursors is at:
http://developer.gnome.org/doc/API/2.0/gdk/gdk-Cursors.html
and the standard set for WinForms is:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfSystemWindowsFormsCursorsMembersTopic.asp
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.
[...]
> A secondary list of 'optional' cursors could then be created to include
> things like paint tools and resize handles; I'd like to make sure that the
> use of these optional cursors was restricted somehow so that they didn't
> appear except where the additional information provided was justified.
I have some trouble seeing how one would draw this line.
Regards,
Owen
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]