Bug 248599

Summary: Corner resizing cursors swapped when loading theme without size_fdiag and size_bdiag
Product: systemsettings Reporter: Magnus Holmgren <holmgren>
Component: kcm_mouseAssignee: Marie Loise Nolden <nolden>
Status: RESOLVED DUPLICATE    
Severity: normal CC: fredrik, wbauer
Priority: NOR    
Version: unspecified   
Target Milestone: ---   
Platform: Debian testing   
OS: All   
Latest Commit: Version Fixed In:

Description Magnus Holmgren 2010-08-21 15:26:48 UTC
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.
Comment 1 Christoph Feck 2010-08-21 16:38:10 UTC
According to http://fedoraproject.org/wiki/Artwork/EchoCursors/NamingSpec the hashes are indeed swapped.
Comment 2 Christoph Feck 2010-08-21 16:45:12 UTC
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.
Comment 3 Christoph Feck 2010-08-21 17:12:11 UTC
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.
Comment 4 Christoph Feck 2010-08-21 17:21:18 UTC
See also bug 54359, which states the bug is in the theme.

Adding Fredrik to ask for reference and clafification.
Comment 5 Magnus Holmgren 2010-08-21 17:42:46 UTC
(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.
Comment 6 Magnus Holmgren 2010-08-21 21:28:59 UTC
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");
}
Comment 7 Wolfgang Bauer 2013-10-10 10:16:45 UTC
The same as bug#325837, which contains a review request to fix this

*** This bug has been marked as a duplicate of bug 325837 ***