Bug 248599

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

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 ***