Problems with 2.5.4.1

I'm testing my pysvn WorkBench GUI against 2.5.4.1 which I've previously supported under 2.5.3.1.
I use python 2.3.

Win32:

Ugly red lines between panels in a SplitterWindow. Also get the red lines in with the demo.

Mac:

ListCtrl column labels blank out if the listctrl width is not 100% shown by the panel.

Linux GTK2:

I start a drag from a listctrl and drop on a tree control and lose mouse input for the whole desktop.
The mouse is left with the inverted L shaped cursor. The same code works fine on win32 and mac.
Only if I allow the doc outline to catch up with the mouse can I get a drop to not lose the mouse.
Exiting from the app returns the mouse control to the desktop.

This was broken in 2.5.3.1 as well, I think its a bit better in 2.5.4.1.

Barry

Barry Scott wrote:

I'm testing my pysvn WorkBench GUI against 2.5.4.1 which I've previously supported under 2.5.3.1.
I use python 2.3.

Win32:

Ugly red lines between panels in a SplitterWindow. Also get the red lines in with the demo.

I've never seen this. Can you grab a screenshot?

Mac:

ListCtrl column labels blank out if the listctrl width is not 100% shown by the panel.

I don't see this either, but I do see that the separators between the column headers are not drawn in the right place when the listctrl is scrolled horizontally. Please enter a bug report about this.

Linux GTK2:

I start a drag from a listctrl and drop on a tree control and lose mouse input for the whole desktop.

There was a bug like this mentioned on wx-dev last week. I think that it ends up with the mouse still being captured after the DnD. You might try adding something like this after your DoDragDrop:

  if self.HasCapture():
    self.ReleaseMouse()

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

I've been having this problem too (see attached screenshot). The OS is XP Service Pack 2, ATI Radeon 9600 series video card, 32-bit color.

Regards,
Nate

splitter.png

···

On Mar 21, 2005, at 9:55 AM, Robin Dunn wrote:

Barry Scott wrote:

I'm testing my pysvn WorkBench GUI against 2.5.4.1 which I've previously supported under 2.5.3.1.
I use python 2.3.
Win32:
Ugly red lines between panels in a SplitterWindow. Also get the red lines in with the demo.

I've never seen this. Can you grab a screenshot?

Nate Silva wrote:

Barry Scott wrote:

I'm testing my pysvn WorkBench GUI against 2.5.4.1 which I've previously supported under 2.5.3.1.
I use python 2.3.
Win32:
Ugly red lines between panels in a SplitterWindow. Also get the red lines in with the demo.

I've never seen this. Can you grab a screenshot?

I've been having this problem too (see attached screenshot). The OS is XP Service Pack 2, ATI Radeon 9600 series video card, 32-bit color.

I expect that this is a bug in the XP Sliver theme. The correct colour is used by the default blue and olive green themes. The wxSplitterWindow uses this code for drawing the sash:

             wxUxThemeEngine::Get()->DrawThemeBackground
                                     (
                                         (WXHTHEME)hTheme,
                                         dc.GetHDC(),
                                         29, // WP_DIALOG: dlg background
                                         0, // no particular state
                                         &rect,
                                         NULL
                                     );

···

On Mar 21, 2005, at 9:55 AM, Robin Dunn wrote:

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

I can confirm that it only occurs on the silver theme.

Is there any chance of a workaround? As XP has only three themes, I would expect a lot of my customers are using the silver one.

Regards,
Nate

···

On Mar 21, 2005, at 10:53 AM, Robin Dunn wrote:

I expect that this is a bug in the XP Sliver theme. The correct colour is used by the default blue and olive green themes. The wxSplitterWindow uses this code for drawing the sash:

Nate Silva wrote:

I expect that this is a bug in the XP Sliver theme. The correct colour is used by the default blue and olive green themes. The wxSplitterWindow uses this code for drawing the sash:

I can confirm that it only occurs on the silver theme.

Is there any chance of a workaround? As XP has only three themes, I would expect a lot of my customers are using the silver one.

You could try the wx.SP_NO_XP_THEME style, but I expect that would look even uglier.

···

On Mar 21, 2005, at 10:53 AM, Robin Dunn wrote:

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

Thank you, this works. It actually looks exactly the same to me (except the "pink" lines are gone).

Regards,
Nate

···

On Mar 21, 2005, at 12:30 PM, Robin Dunn wrote:

Nate Silva wrote:

On Mar 21, 2005, at 10:53 AM, Robin Dunn wrote:

I expect that this is a bug in the XP Sliver theme. The correct colour is used by the default blue and olive green themes. The wxSplitterWindow uses this code for drawing the sash:

I can confirm that it only occurs on the silver theme.
Is there any chance of a workaround? As XP has only three themes, I would expect a lot of my customers are using the silver one.

You could try the wx.SP_NO_XP_THEME style, but I expect that would look even uglier.

Mac:
ListCtrl column labels blank out if the listctrl width is not 100% shown by the panel.

I don't see this either, but I do see that the separators between the column headers are not drawn in the right place when the listctrl is scrolled horizontally. Please enter a bug report about this.

I cannot break this in a small test case, but its 100% reproducible in the pysvn workbench code.
You may recall that you had the same bug in the gtk2 version a little while ago if that hints at a possible
I'll log a bug report for you.

Linux GTK2:
I start a drag from a listctrl and drop on a tree control and lose mouse input for the whole desktop.

There was a bug like this mentioned on wx-dev last week. I think that it ends up with the mouse still being captured after the DnD. You might try adding something like this after your DoDragDrop:

  if self.HasCapture():
    self.ReleaseMouse()

I take it you don't need a bug report for this one as you'll be fixing in due course?

Barry

···

On Mar 21, 2005, at 17:55, Robin Dunn wrote:

This is only partly helpful.

case 1. drag from list control and release over same control - mouse released with above code
case 2. drag from list control to tree control - mouse lost.

Barry

···

On Mar 21, 2005, at 17:55, Robin Dunn wrote:

There was a bug like this mentioned on wx-dev last week. I think that it ends up with the mouse still being captured after the DnD. You might try adding something like this after your DoDragDrop:

  if self.HasCapture():
    self.ReleaseMouse()

Barry Scott wrote:

Linux GTK2:
I start a drag from a listctrl and drop on a tree control and lose mouse input for the whole desktop.

There was a bug like this mentioned on wx-dev last week. I think that it ends up with the mouse still being captured after the DnD. You might try adding something like this after your DoDragDrop:

    if self.HasCapture():
        self.ReleaseMouse()

I take it you don't need a bug report for this one as you'll be fixing in due course?

It probably won't be me fixing it so a bug report would be good so it doesn't risk to be forgotten.

···

On Mar 21, 2005, at 17:55, Robin Dunn wrote:

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!