Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

Patch 0131_all_4.2.99.3-Imake-make-icondir-configable-v3.patch applied on Xorg
6.8.2 makes Xorg to search mouse cursor themes from wrong paths. Xcursor, by
default, somewhat adheres to fd.o base directory specification, which makes
things quite convenient for application developers to create gui's for cursor
theme configuration.

The patch however, makes the cursor search paths depend on the X Window system
vendor, which makes things quite difficult. Plus, it changes the paths in a
manner that renders the Xcursor man page incorrect. While compile time
configuration of cursor paths, provided by the patch, is okay, the cursor
search paths applied by it should be changed to those mentioned on Xcursor man
page.

Nothing like this patch appears to exist in our 7.0 builds. 6.8.2 is currently
in security mode, so it won't be receiving any more non-critical fixes. Please
give 7.0 a try to see whether it works there. Take a look at
http://www.gentoo.org/proj/en/desktop/x/x11/modular-x-howto.xml for some tips.

I looked into 7.0 a bit more, and the reason the patch no longer exists is
because upstream incorporated it.

You'll have to do something like this to get the cursor location:

$ pkg-config xcursor --variable icondir
/usr/share/cursors/xorg-x11

Installed Xorg 7 to see this for myself.

"the reason the patch no longer exists is because upstream incorporated it"

Excuse the stupid question, but unless I'm completely mistaken, this would
suggest that the Xorg upstream has incorporated the patch? But I couldn't find
it in their cvs[1]. And the source of the icon path seems to be the ebuild this
time.

While using pkg-config makes things somewhat easier, the paths in Gentoo are
still broken in regard to XDG compliancy (to which Xcursor seems to try to
adhere to by default). I don't understand the rationale behind this.

[1]: http://cvs.freedesktop.org/xorg/lib/Xcursor/

(In reply to comment #3)
> Installed Xorg 7 to see this for myself.
> 
> "the reason the patch no longer exists is because upstream incorporated it"
> 
> Excuse the stupid question, but unless I'm completely mistaken, this would
> suggest that the Xorg upstream has incorporated the patch? But I couldn't find
> it in their cvs[1]. And the source of the icon path seems to be the ebuild this
> time.

I mean the options to change it were incorporated.

> While using pkg-config makes things somewhat easier, the paths in Gentoo are
> still broken in regard to XDG compliancy (to which Xcursor seems to try to
> adhere to by default). I don't understand the rationale behind this.
> 
> [1]: http://cvs.freedesktop.org/xorg/lib/Xcursor/

I don't have a problem also adding those locations to the default search path.
But we're not interested in breaking people's already working setups that rely
on /usr/share/cursors and /usr/local/share/cursors. Also, those locations make
more sense for cursors, regardless of what XDG says.

(In reply to comment #4)
> 
> But we're not interested in breaking people's already working setups that rely
> on /usr/share/cursors and /usr/local/share/cursors. Also, those locations make
> more sense for cursors, regardless of what XDG says.
> 

Well no, of course not. I would've suggested deprecating /usr/share/cursors
etc. and installing the cursors by default to standard locations, and at some
later stage drop the path.

It perhaps is true, that /usr/share/cursors makes more sense for cursors, but I
would guess application developers, that usually depend on xdg, are quite
reluctant of writing code paths just for Gentoo.

(In reply to comment #5)
> (In reply to comment #4)
> > 
> > But we're not interested in breaking people's already working setups that rely
> > on /usr/share/cursors and /usr/local/share/cursors. Also, those locations make
> > more sense for cursors, regardless of what XDG says.
> > 
> 
> Well no, of course not. I would've suggested deprecating /usr/share/cursors
> etc. and installing the cursors by default to standard locations, and at some
> later stage drop the path.

OK, still looking for a good reason besides "it's a standard." More below ...

> It perhaps is true, that /usr/share/cursors makes more sense for cursors, but I
> would guess application developers, that usually depend on xdg, are quite
> reluctant of writing code paths just for Gentoo.

Shouldn't be necessary, they can just use pkg-config in 7.0 onwards.
Incidentally, we originally got the patch from Fedora. However, it appears
they've moved to /usr/share/icons in 7.0.

You've said that pkg-config will work for the purpose of application
developers. So what problem remains that is not solved by use of pkg-config?

Gentoo doesn't blindly adhere to standards for the sake of standards, as you'll
see if you look into our FHS compliance. We do what makes sense, whether or not
it fits into some standard.

(In reply to comment #6)
>
> You've said that pkg-config will work for the purpose of application
> developers. So what problem remains that is not solved by use of pkg-config?
> 

pkg-config --variable=icondir combined with dirs from fd.o icon theme spec[1]
will do it indeed. I'd rather not use pkg-config except for checking the
existence of Xcursor, but prefer to just rely on the spec in theme lookup. This
unfortunately has some problems, as Xcursor isn't 100% xdg compliant.

The only "problem" that remains is that Gentoo breaks dawning standards
compliancy of one package on purpose, and makes things different from other
distributions. I fail to see the reason behind this, as "it makes sense"
doesn't quite buy. Plus, it's somewhat annoying to see Gentoo users advice
people to put their cursor themes in /usr/share/cursors/xorg-x11 even though it
won't work for them. But it's somewhat irrelevant, and this definitely should
not become a silly dispute. I have what I need, and am looking to get this
fixed elsewhere.

Thanks

[1]:
http://standards.freedesktop.org/icon-theme-spec/icon-theme-spec-latest.html#directory_layout

(In reply to comment #7)
> The only "problem" that remains is that Gentoo breaks dawning standards
> compliancy of one package on purpose, and makes things different from other
> distributions. ... But it's somewhat irrelevant, and this definitely should
> not become a silly dispute. I have what I need, and am looking to get this
> fixed elsewhere.

I agree. At some point we (Gentoo) should probably bring this up on the xdg
list. From my POV, icons are icons (e.g., application icons in menus et al),
and cursors are cursors. Putting cursors into a directory called icons doesn't
make sense from the end user's perspective, even though they may technically be
a set of "icons."

We'll leave this bug open until we ensure that all xdg icon paths are searched,
in addition to any custom paths.

Could you make sure I didn't miss anything?

--- libXcursor-1.1.5.2.ebuild   2006-01-31 00:00:03.000000000 -0800
+++ libXcursor-1.1.5.2-r1.ebuild        2006-01-31 00:02:16.000000000 -0800
@@ -16,4 +16,4 @@
 DEPEND="${RDEPEND}"

 CONFIGURE_OPTIONS="--with-icondir=/usr/share/cursors/xorg-x11
-      
--with-cursorpath=~/.cursors:~/.icons:/usr/local/share/cursors/xorg-x11:/usr/share/cursors/xorg-x11:/usr/share/pixmaps/xorg-x11"
+      
--with-cursorpath=~/.cursors:~/.icons:/usr/local/share/cursors/xorg-x11:/usr/share/cursors/xorg-x11:/usr/share/pixmaps/xorg-x11:/usr/share/icons:/usr/share/pixmaps"

(In reply to comment #9)
> Could you make sure I didn't miss anything?

/usr/local/share/icons seems to be missing. Otherwise seems fine.

(In reply to comment #10)
> (In reply to comment #9)
> > Could you make sure I didn't miss anything?
> 
> /usr/local/share/icons seems to be missing. Otherwise seems fine.

The spec requests the /usr/local variant for icons/ but not pixmaps/ ? That
seems odd.

(In reply to comment #11)
> 
> The spec requests the /usr/local variant for icons/ but not pixmaps/ ? That
> seems odd.
> 

Yes, that seems to be the case. And now, on a second look, I realize
~/.local/share/icons should probably be on the list too.

(In reply to comment #12)
> (In reply to comment #11)
> > 
> > The spec requests the /usr/local variant for icons/ but not pixmaps/ ? That
> > seems odd.
> > 
> 
> Yes, that seems to be the case. And now, on a second look, I realize
> ~/.local/share/icons should probably be on the list too.

I've added both the /usr/local things, because it just makes sense. That
~/.local thing is just plain weird.

Committed -r1 with additional paths, marking fixed.