Version: unspecified (using Devel) OS: All On http://websvn.kde.org/trunk/KDE/kdebase/workspace/kcontrol/input/xcursor/xcursortheme.cpp?revision=750619&view=markup lines 85-86, i suspect that the hashes should be switched, because all the themes I've seen link c7088f0f3e6c8088236ef8e1e3e70000 to bd_double_arrow and make that the NW-SE double arrow (⤡, i.e. "backward diagonal" as in the way the backslash is oriented), whereas in the Oxygen theme, which I expect to be correct, the same is called size_fdiag ("forward diagonal" as in "x and y coordinates both increasing or both decreasing", I suppose). And vice versa. Alternatively a lot of cursor themes are buggy. I've not been able to find an authoritative reference on the issue. Reproducible: Always Steps to Reproduce: 1. Install a cursor theme set such as DMZ, Chameleon (http://www.kde-look.org/content/show.php?content=38459), Comix (http://opendesktop.org/content/show.php?content=32627), or Crystal (http://www.kde-look.org/content/show.php?content=6240), which are available as Debian packages. 2. Set the core theme as system default (otherwise bug 213615 may interfere). 3. Select any theme from one of the aforementioned sets on the Cursor Theme tab. 4. Choose OK or Apply. 5. Point at a window corner. Actual Results: After step 3 above, a SW-NE double arrow is previewed. At step 5, the cursor is flipped. Expected Results: A NW-SE double arrow should be previewed, as is the case when an Oxygen theme is selected. Note that after logging out and logging back in, the resizing cursors are correct.
According to http://fedoraproject.org/wiki/Artwork/EchoCursors/NamingSpec the hashes are indeed swapped.
Note however, that there might be a confusion about what is "backward" and not. For example, http://doc.trolltech.com/4.6/qcursor.html shows "BDiag" the same as the NE-SW diagonal.
Another reference I found is http://ubuntuforums.org/showthread.php?t=1440110 where it says "c7088f0f3e6c8088236ef8e1e3e70000 --> top_left_corner". On the cursor theme I am using (flatcursor from kde-look.org), there is a link "c7088f0f3e6c8088236ef8e1e3e70000 -> bd_double_arrow". Confused.
See also bug 54359, which states the bug is in the theme. Adding Fredrik to ask for reference and clafification.
(In reply to comment #2) > Note however, that there might be a confusion about what is "backward" and not. > For example, http://doc.trolltech.com/4.6/qcursor.html shows "BDiag" the same > as the NE-SW diagonal. BDiag is definitely NE-SW, and FDiag is SE-NW, but at the same time everyone seems to be of the opinion that bd_double_arrow is SE-NW and that fd_double_arrow is NE-SW.
I have now located the bitmaps in QCursor and the hash algorithm in libXcursor (http://cgit.freedesktop.org/xorg/lib/libXcursor/tree/src/xlib.c) and verified that, indeed, size_fdiag hashes to c7088f0f3e6c8088236ef8e1e3e70000 and size_bdiag to fcf1c3c7cd4491d801f1e1c78f100000. The mapping in xcursortheme.cpp is therefore wrong. Put together and constant values substituted: #include <stdio.h> typedef unsigned char uchar; static const uchar cur_bdiag_bits[] = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x3f, 0x00, 0x3e, 0x00, 0x3c, 0x00, 0x3e, 0x00, 0x37, 0x88, 0x23, 0xd8, 0x01, 0xf8, 0x00, 0x78, 0x00, 0xf8, 0x00, 0xf8, 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 }; static const uchar cur_fdiag_bits[] = { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xf8, 0x01, 0xf8, 0x00, 0x78, 0x00, 0xf8, 0x00, 0xd8, 0x01, 0x88, 0x23, 0x00, 0x37, 0x00, 0x3e, 0x00, 0x3c, 0x00, 0x3e, 0x00, 0x3f, 0x00, 0x00, 0x00, 0x00 }; #define RotByte(t,i) (((t) << (i)) | ((t) >> (8 - (i)))) void print_hash(const uchar *data) { int i = 0; uchar t; uchar hash[16] = ""; for (int y = 0; y < 16; y++) { for (int x = 0; x < 16 / 8; x++) { t = data[2*y+x]; if (t) hash[(i++) & 0xf] ^= RotByte (t, y & 7); } } for (i = 0; i < 16; i++) { printf("%02x", hash[i]); } } int main () { printf("size_fdiag hash: "); print_hash(cur_fdiag_bits); printf("\n"); printf("size_bdiag hash: "); print_hash(cur_bdiag_bits); printf("\n"); }
The same as bug#325837, which contains a review request to fix this *** This bug has been marked as a duplicate of bug 325837 ***