Closed Bug 609889 Opened 9 years ago Closed 8 years ago

cursor themes are not completely supported

Categories

(Core :: General, defect)

All
Linux
defect
Not set

Tracking

()

RESOLVED DUPLICATE of bug 310924

People

(Reporter: flying-sheep, Unassigned)

Details

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.12) Gecko/20101027 Ubuntu/10.10 (maverick) Firefox/3.6.12
Build Identifier: 

https://developer.mozilla.org/en/CSS/cursor

most of the cursors on linux are ugly, black, aliased standard cursors instead of the ones thetheme provides. it is completely confusing, because sometimes, they are called differently and it works, while it doesn’t work sometimes when css property and cursor file name are identical.

also, in the freedesktop cursor themes, there is no real standard, what should be called how (or nobody follows it). here a page where some people collect aliases: http://fedoraproject.org/wiki/Artwork/EchoCursors/NamingSpec

i have here a manually created (=not perfect) list which shows which cursors are taken from the theme (☑), which not (☐), and what files are in the theme (comma-separated list of filenames):

Firefox      │ Oxy-white
═════════════╪═══════════════════════════════════════
default      │ ☑ left_ptr
context-menu │ ☐
help         │ ☑ help, whats_this
pointer      │ ☑ pointer
progress     │ ☑ progress, left_ptr_wait, half_busy
wait         │ ☑ wait
cell         │ ☑ plus
crosshair    │ ☐ cross
text         │ ☑ text, ibeam, xterm
vertical-text│ ☐ 
alias        │ ☐ alias, link, dnd-link
copy         │ ☐ copy, dnd-copy
move         │ ☑ fleur, size_all, all-scroll
no-drop      │ ☐ not-allowed, forbidden, dnd-no-drop
not-allowed  │ ☐ crossed_circle, circle
all-scroll   │ ☑ fleur, size_all, all-scroll
col-resize   │ ☐ col-resize, split_h*
row-resize   │ ☐ row-resize, split_v*
n-resize     │ ☐ n-resize
e-resize     │ ☐ e-resize
s-resize     │ ☐ s-resize
w-resize     │ ☐ w-resize
ne-resize    │ ☐
nw-resize    │ ☐
se-resize    │ ☐
sw-resize    │ ☐
ew-resize    │ ☑ h_double_arrow, size_hor
ns-resize    │ ☑ v_double_arrow, size_ver
nesw-resize  │ ☐ size_bdiag
nwse-resize  │ ☐ size_fdiag
-moz-grab    │ ☐ openhand
-moz-grabbing│ ☐ closedhand
-moz-zoom-in │ ☐
-moz-zoom-out│ ☐

*instead, horizontal/vertical resize is shown

With GNOMEs standard cursor theme, dmz-white, there are some differences: The one-directional resizers work (e.g. n-resize). but they have aliases named like “bottom_right_corner” or “top_side”, too. crosshair and i-don’t-know-how-it’s-called-but-it-appears-when-you-drag’n’drop-text, work, too.

i don’t know where i should file this bug, gtk+, kde or firefox, but i suppose, here is a good starting point, since firefox is the application “requesting” the cursors. we need the path the cursors take. i think it’s roughly like this:

css-property → gtk-curser-enum → cursor-filename

can somebody help me track this down?

Reproducible: Always
So the CSS property values are converted to nsCursor values in nsEventStateManager::SetCursor.  Then nsWindow::SetCursor is called (in widget/src/gtk2/nsWindow.cpp in your case), which calls get_gtk_cursor; that function takes an nsCursor enum value, maps it to a corresponding GDK cursor enum, calls gdk_cursor_new on that, and returns the resulting GdkCursor*.

get_gtk_cursor definitely supports n-resize, say (maps it to GDK_TOP_SIDE).  But for a bunch of things on your list, we end up in the |newType| case and use a bitmap.

It sounds like the mapping from GDK_* constant to filename is handled by GDK and/or the theme.  Note that we can't meaningfully pass "n-resize" to gdk_cursor_new; the set of values that function takes is listed at http://www.gtk.org/api/2.6/gdk/gdk-Cursors.html.

Does that help?
ok, i’m lost.

on the fedora aliases list, which i posted, are all the cursors a linux system should support. is there anything we can do to ensure that every css cursor which has an equivalent on the aliases list actually maps to it?
I'm not familiar with how gdk_cursor_new maps the enum it gets to theme files.  Is that something under the control of the theme?  Seems like at least for the theme you reported in comment 0 this is the point where mapping GDK_TOP_SIDE to your theme's n-resize fails....
In any case, from our end it looks like gdk_cursor_new and the constants it takes is the API we're supposed to use.  Is that correct?  If not, is there some other GTK/GDK API we're supposed to be using?

If we're using the right API, then the issue would presumably be in GDK or the themes or their interaction....
ok. i also found the freedesktop.org specs: http://www.freedesktop.org/wiki/Specifications/cursor-spec

i’ll keep looking where any improvement can be done. maybe it would be best to close this bug now, if you think, mozilla does everything right, and reopen it if i find out that this was not exactly true :)

and, srsly: gdk-Cursors is veeery outdated. it’s about time somebody writes a freedesktop-compatible cursor api.
ok, don’t close it now. we are in fact using the library wrongly:

look at this neat function, it should be all we need!
http://library.gnome.org/devel/gdk/stable/gdk-Cursors.html#gdk-cursor-new-from-name
It should if the cursor names are sane.  But you said there's no standard for the names (unlike the enum, which is pretty clear as far as I can tell)...

ccing mwu, who might know what the right thing to here is (especially in terms of being compatible with all themes, as much as possible).
I looked at supporting more cursors at one point but that didn't get very far. Don't think I can help much without diving into the code. (see also, bug 310924 and bug 314224)
I was more asking about specifically gdk-cursor-new-from-name vs gdk_cursor_new.  But bug 310924 answers that question, I think (and this bug should be a duplicate of it, looks like).  The 2.8 dep is not an issue anymore, right?
(In reply to comment #7)
> It should if the cursor names are sane.  But you said there's no standard for
> the names (unlike the enum, which is pretty clear as far as I can tell)...
i was misleaded, there is a standard: http://www.freedesktop.org/wiki/Specifications/cursor-spec
additionally, the gnome developers recommended using this method.
if you want to be completely sure, check if the returned cursor is NULL and use an alias from the fedora aliases list. that’s really the best thing we can do, because it *will* use the cursor gdk_cursor_new uses, if all else fails.* but even if you don’t use the aliases, it would work better than the current way, because most cursor themes support most aliases themselves (by symlinking all aliases to the main name)



so currently we have this function: http://hg.mozilla.org/mozilla-central/file/2b612890113b/widget/src/gtk2/nsWindow.cpp#l1517, which calls this: http://hg.mozilla.org/mozilla-central/file/2b612890113b/widget/src/gtk2/nsWindow.cpp#l5316

we need to do the following changes: when we create a new cursor, use gdk_cursor_new_from_name() for each alias, until it doesn’t give back NULL anymore. we need to store the name-string of the current cursor to have something to compare to when we create a new one. (so that we don’t change the cursor if the new one is the same as the old one). done.

*yeah really, we lose only some nanoseconds for each cursor change, nothing else.
sorry for spamming, but i just saw that it’s even easier, since mozilla uses it’s own integers. so we have this switch. and in it we do sth. like this (i can’t code c++, so this is a fantasy language. if somebody translates it to proper c++ and replaces the enum with it, we should be done.

  case eCursor_nesw_resize:
    //this array contains all names, including the one gdk_cursor_new yields!
    string[3] aliases = {"nesw-resize", "bd_double_arrow", "size_bdiag"};
    for each (string name in aliases) {
      gdkcursor = gdk_cursor_new_from_name(name);
      if (gdkcursor != NULL)
        break;
    }
    //if none of the aliases is present (=**** theme), we can still use inbuilt cursors
    if (gdkcursor == NULL)
      newType = MOZ_CURSOR_NESW_RESIZE;
    break;
Status: UNCONFIRMED → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 310924
You need to log in before you can comment on or make changes to this bug.