Very Small Issue with Cursor/Window Style Behavior.

Metallicow · December 31, 2013, 1:51am

OK, so since I’m helping fix up the demo(s) for Phoenix, in this journey
I have finally come time to do the Cursor.py demo.

Well, when it came to this subject I noticed the lack of custom cursor examples,
which is usually what is used in graphics apps and other custom functionality with other widgets.
So… I needed a decent test cursor. Lo and behold most all cursors found around the net are GPL,
which doesn’t fly for PyEmbeddedImages and Including with the demo.
So, I looked at KDE Crystal and Oxygen, only to find that the only the icons were LGPL, but not the cursors.
Strange, but true.
So I photoshoped up my own little similar fancy vector shape with style,
that will have a better embeddable license, free for anyone to do whatever with(including embed in their app). Funny that Microsofts Default Cursor still blows after all these years.
PaperAirPlane style. Made .ani, cur, .png, and PyEmbeddableImage. (.apng and .gif still to come yet, maybe if I can find a way to support them for cursors…)
Ones With transparency also, as to stop living in the gif(quality) age of animated cursors/images.

Anyhow, Every Decent Cursor App has a “Cursor Test Panel” with various widgets to test on,
so I made a decent one to replace the bland old single window one.

OK, so now it is showtime right, and It’s running fine, until I noticed a verrry small(1px size issue)
but blatant issue that needs addressed in some way.

What is this issue you may not notice…???
It has to do with the wx.BORDER_SIMPLE wx.Window style(s) bits.

If you look carefully when passing the cursor over the edge of the Window Border(this happens with the TextCtrl, SpinCtrl borders too),
that the cursor reverts back to the default cursor, when it should be the custom one.
This is more obvious with the wx.CURSOR_CROSS(Ex: as users are trying to precisely start or end a drag at a certain point; think GIMP/Photoshop rectangular marquee tool)

Or is there some way to override this behavior as it apparently seems that the window border style is a wx.Window of it’s own somehow…???

See Attachment. Preview Includes: New PaperAirPlane Cursors, New run.py and New Cursor.py
The Demo is cross compatible with Classic and Phoenix and runs with wx from 2.8 to 3.0
at least until I get to cleaning it up only for Phoenix. So no worries about running it(on windows anyway…)
haven’t tested on linux or mac yet.

@ Robin/Others: Any Ideas on a fix…?

Cursor_MCow.7z (18.4 KB)

Rob_McMullen · December 31, 2013, 10:52pm

Just FYI, on linux the animated cursors don’t appear to work. Never tried this before so maybe it’s a GTK limitation. It responds with:

14:43:44: Selecting the paperairplane_arrow_colorshift.ani cursor

14:43:44: Error: Image file is not of type 5.

whatever that means. Also, maybe this tiny patch will help? I don’t exactly see the border issues, but this fixed the bottom two controls.

Rob

widgets.patch (534 Bytes)

···

On Mon, Dec 30, 2013 at 5:51 PM, Metallicow metaliobovinus@gmail.com wrote:

OK, so since I’m helping fix up the demo(s) for Phoenix, in this journey
I have finally come time to do the Cursor.py demo.

Well, when it came to this subject I noticed the lack of custom cursor examples,
which is usually what is used in graphics apps and other custom functionality with other widgets.
So… I needed a decent test cursor. Lo and behold most all cursors found around the net are GPL,

which doesn’t fly for PyEmbeddedImages and Including with the demo.
So, I looked at KDE Crystal and Oxygen, only to find that the only the icons were LGPL, but not the cursors.
Strange, but true.
So I photoshoped up my own little similar fancy vector shape with style,

that will have a better embeddable license, free for anyone to do whatever with(including embed in their app). Funny that Microsofts Default Cursor still blows after all these years.
PaperAirPlane style. Made .ani, cur, .png, and PyEmbeddableImage. (.apng and .gif still to come yet, maybe if I can find a way to support them for cursors…)

Ones With transparency also, as to stop living in the gif(quality) age of animated cursors/images.

Anyhow, Every Decent Cursor App has a “Cursor Test Panel” with various widgets to test on,
so I made a decent one to replace the bland old single window one.

OK, so now it is showtime right, and It’s running fine, until I noticed a verrry small(1px size issue)
but blatant issue that needs addressed in some way.

What is this issue you may not notice…???

It has to do with the wx.BORDER_SIMPLE wx.Window style(s) bits.

If you look carefully when passing the cursor over the edge of the Window Border(this happens with the TextCtrl, SpinCtrl borders too),
that the cursor reverts back to the default cursor, when it should be the custom one.

This is more obvious with the wx.CURSOR_CROSS(Ex: as users are trying to precisely start or end a drag at a certain point; think GIMP/Photoshop rectangular marquee tool)

Or is there some way to override this behavior as it apparently seems that the window border style is a wx.Window of it’s own somehow…???

See Attachment. Preview Includes: New PaperAirPlane Cursors, New run.py and New Cursor.py
The Demo is cross compatible with Classic and Phoenix and runs with wx from 2.8 to 3.0
at least until I get to cleaning it up only for Phoenix. So no worries about running it(on windows anyway…)

haven’t tested on linux or mac yet.

@ Robin/Others: Any Ideas on a fix…?

–

You received this message because you are subscribed to the Google Groups “wxPython-users” group.

To unsubscribe from this group and stop receiving emails from it, send an email to wxpython-users+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

Metallicow · January 1, 2014, 4:22am

Opps yeah, I forgot to add those two to the list. Thanks for noticing.
I added them after noticing the border issue initially.
Adding didn’t fix the issue tho.
The pnl(Panel housing the 2 draw windows) has the wx.BORDER_SIMPLE style which has the 1px border issue. Also the tc(TextCtrl) and the sc(SpinCtrl) draws a border around the text portion or the control that has the 1 px issue also.

RE: Error: Image file is not of type 5
The ani files are Windows specific I believe. The first frame might work if using the BITMAP_STYLE_CUR bitmap style bit on a newer version.
Until I get around to testing on linux, I really won’t know how this and the border issue might react.
Depending on the distro and desktop environment, maybe it might not draw the border the same way…
I should probably put a platform check in for that one tho.

I don’t have access to a linux box ATM. Might be a few days…
Did all the .cur files show up correctly on GTK(those are the main unanimated cursor filetype)?
IIRC on GTK the standard cursors used are just pngs with a file that specifies the hotspot right…?

···

On Tuesday, December 31, 2013 4:52:42 PM UTC-6, Rob McMullen wrote:

Just FYI, on linux the animated cursors don’t appear to work. Never tried this before so maybe it’s a GTK limitation. It responds with:

14:43:44: Selecting the paperairplane_arrow_colorshift.ani cursor

14:43:44: Error: Image file is not of type 5.

whatever that means. Also, maybe this tiny patch will help? I don’t exactly see the border issues, but this fixed the bottom two controls.

Rob

Rob_McMullen · January 1, 2014, 5:24am

All the non-animated cursors worked correctly (including hotspots) AFAICT.

I tried with a bunch of cursors on the BORDER_SIMPLE issue around the two draw frames and the text/spin controls and I can’t see the effect you’re talking about. So maybe it doesn’t affect GTK? This is with 2.8.12.1 and gtk 2.24.22

Rob

···

On Tue, Dec 31, 2013 at 8:22 PM, Metallicow metaliobovinus@gmail.com wrote:

On Tuesday, December 31, 2013 4:52:42 PM UTC-6, Rob McMullen wrote:

Just FYI, on linux the animated cursors don’t appear to work. Never tried this before so maybe it’s a GTK limitation. It responds with:

14:43:44: Selecting the paperairplane_arrow_colorshift.ani cursor

14:43:44: Error: Image file is not of type 5.

whatever that means. Also, maybe this tiny patch will help? I don’t exactly see the border issues, but this fixed the bottom two controls.

Rob

Opps yeah, I forgot to add those two to the list. Thanks for noticing.
I added them after noticing the border issue initially.
Adding didn’t fix the issue tho.
The pnl(Panel housing the 2 draw windows) has the wx.BORDER_SIMPLE style which has the 1px border issue. Also the tc(TextCtrl) and the sc(SpinCtrl) draws a border around the text portion or the control that has the 1 px issue also.

RE: Error: Image file is not of type 5
The ani files are Windows specific I believe. The first frame might work if using the BITMAP_STYLE_CUR bitmap style bit on a newer version.
Until I get around to testing on linux, I really won’t know how this and the border issue might react.

Depending on the distro and desktop environment, maybe it might not draw the border the same way…
I should probably put a platform check in for that one tho.

I don’t have access to a linux box ATM. Might be a few days…

Did all the .cur files show up correctly on GTK(those are the main unanimated cursor filetype)?
IIRC on GTK the standard cursors used are just pngs with a file that specifies the hotspot right…?

–

You received this message because you are subscribed to the Google Groups “wxPython-users” group.

To unsubscribe from this group and stop receiving emails from it, send an email to wxpython-users+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

Metallicow · January 1, 2014, 6:06am

OK, so a platform “WXGTK” check on linux for the one .ani file should work fine, now just to get someone to test on mac…

Anyway, here is a pic displaying the issue. See Attachment.
The cursor in the top draw box is the one that should display on the borders where the old windows1980’s cursor is showing in 3 other spots. I circled the borders area with cursor with green.
This should help better visually explain the issue at hand for others.

···

On Tuesday, December 31, 2013 11:24:16 PM UTC-6, Rob McMullen wrote:

All the non-animated cursors worked correctly (including hotspots) AFAICT.

I tried with a bunch of cursors on the BORDER_SIMPLE issue around the two draw frames and the text/spin controls and I can’t see the effect you’re talking about. So maybe it doesn’t affect GTK? This is with 2.8.12.1 and gtk 2.24.22

Rob

Rob_McMullen · January 2, 2014, 11:52pm

I forgot that my (linux) machine had 2.9.4.1 in a virtualenv, so I tried that just now. I don’t see the border issue there either.

Rob

···

On Tue, Dec 31, 2013 at 10:06 PM, Metallicow metaliobovinus@gmail.com wrote:

On Tuesday, December 31, 2013 11:24:16 PM UTC-6, Rob McMullen wrote:

All the non-animated cursors worked correctly (including hotspots) AFAICT.

I tried with a bunch of cursors on the BORDER_SIMPLE issue around the two draw frames and the text/spin controls and I can’t see the effect you’re talking about. So maybe it doesn’t affect GTK? This is with 2.8.12.1 and gtk 2.24.22

Rob

OK, so a platform “WXGTK” check on linux for the one .ani file should work fine, now just to get someone to test on mac…

Anyway, here is a pic displaying the issue. See Attachment.

The cursor in the top draw box is the one that should display on the borders where the old windows1980’s cursor is showing in 3 other spots. I circled the borders area with cursor with green.
This should help better visually explain the issue at hand for others.

–

You received this message because you are subscribed to the Google Groups “wxPython-users” group.

To unsubscribe from this group and stop receiving emails from it, send an email to wxpython-users+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.