CL trunk mouse cursor stuck as arrow

[petah]

Hi Eran,

I just built CL trunk with wx trunk on Debian x64 and the mouse cursor is stuck as an arrow - it never changes when editing text. I built it with:

Code: Select all

CXX=/usr/bin/g++-4.8 PATH="$DEVELOPMENT/git/wxTrunk/build_REL:$PATH" cmake -G "Unix Makefiles" -DENABLE_SFTP=0 -DGTK_USE_AUIBOOK=0 -DCMAKE_BUILD_TYPE=Release -DCOPY_WX_LIBS=1 -DPREFIX="$DEVELOPMENT/codelite60" ..

Btw I love the new unified project settings, one nitpick would be the boolean fields using "True/False" instead of C++'s "true/false"

thx & cheers,

-- p

[eranif]

I saw that once also, it was fixed by performing a rebuild of codelite (did not see this for couple of weeks now...)

Eran

[petah]

I retried on 2 machines, with gcc 4.7 and 4.8, with and without -DGTK_USE_AUIBOOK=1 and the bug is still there.

It seems to be related to wx's recent changes to accomodate GTK3; I have GTK2. There's no bug when using wx from 2014-01-06, but the bug appears in wx from 2014-02-10, so it must be between those dates.

Do you think you could try wx trunk on Gtk to confirm the bug's there?

thx & cheers,

-- p

[eranif]

I am trying to keep my Linux boxes clean from any custom builds as they are using for packaging codelite + wxcrafter
Maybe DavidGH is able to assist here

Eran

[petah]

ok, it's just to confirm it's actually a wx bug and not related to my config, so anybody could do it really.

cheers,

-- p

[DavidGH]

Hi,

Do you mean http://trac.wxwidgets.org/ticket/15801#comment:8? If so, it's now fixed .

Regards,

David

[petah]

that's probably the right ticket but the bug must have been reintroduced because I'm using wx trunk. Check the git log, there are related changes @ 2014-02-09 which is after the last Trac entry.

cheers,

-- p

[DavidGH]

Ah, looking at a wx3.0 CL build, I see what you mean. I was so glad to lose the double-headed cursor that I hadn't noticed that it used to be a single-head arrow.

This is likely to be a wxSTC/wxDVC-inside-aui thing. It happens for editors, and for most of the outputview panes; but not for 'Trace', which is a plain wxTextCtrl.
As before, I can't reproduce it in any of the samples, though...

[petah]

yeah it happens in the main edit view and some fields in prefs but not others. I also couldn't reproduce it on the stc sample... which I know is what Vadim will ask for.

If you look closely, on the main edit view the cursor does change to the right shape for ~100ms, then back into the arrow.

-- p

[petah]

I narrowed down the bug between:

Code: Select all

commit 0dfeb74e78ca65401961ca250e9099498d928686
Author: Paul Cornett <paulcor@bullseye.com>
Date:   Thu Feb 6 04:43:46 2014 +0000

    Different fix for cursor inheritance and busy cursor/global cursor.
    Previous work was not compatible with GTK < 2.18 and did not properly handle some cases
    see #15801

which works, and:

Code: Select all

commit 9d0d2b7e98c729a57e7b048af2dc0f329a19e611
Author: Paul Cornett <paulcor@bullseye.com>
Date:   Thu Feb 6 08:54:17 2014 +0000

    Fix wxSetCursorEvent handling
    For compatibility with wxMSW, send event up the parent chain.
    Properly handle setting the cursor for a wxSetCursorEvent, and don't overwrite the window cursor.
    see #15801

which doesn't.

The diff is complex enough that I doubt it can be fixed without having gtk3 to retest. I'm guessing it's related to the cursor being reset.

cheers,

-- p

edit : I see the double-headed cursor now, so the game is "pick your least-annoying bug"?