Critique of wxWidgets

wxPython Users
1

Howdy,

This page;
http://leo.zwiki.org/WxWidgetsSummary

describes a developer's experience porting a TK app,
Leo, http://sourceforge.net/projects/leo/
to wxWidgets

I would be very interested in comments from this
community on the issues encountered.

I don't know wxPython well enough to evaluate, I do
know that many seem very happy with wxPython,
and wish Leo was among them.

Are the issues in the critique somehow related in
differences between TK and wx architecture?

Thanks,
Kent

2

Hi Kent,

Howdy,

This page;
http://leo.zwiki.org/WxWidgetsSummary

describes a developer's experience porting a TK app,
Leo, Leo: a programmer's editor & more download | SourceForge.net
to wxWidgets

I would be very interested in comments from this
community on the issues encountered.

I don't know wxPython well enough to evaluate, I do
know that many seem very happy with wxPython,
and wish Leo was among them.

Are the issues in the critique somehow related in
differences between TK and wx architecture?

Well, most of the comments are quite general, and there are no code samples to help us understand the issues, so it's impossible with just that info to know whether most of the author's points about specific bugs are valid or not. In fact, for the wx.Menu and wx.TreeCtrl 'bugs', I'm really not sure I understand what he means by things like 'inner' and 'outer' events, or needing to create a key binding to create a shortcut. Based solely on what he's written, I'd say that I've never run into either of these issues, but maybe I'm misunderstanding something. As for the STC problem, it might be the case that it eats key events, that one I'm not totally sure on.

Anyway, the best way to get to the bottom of this stuff is for us to see some sample code. (I downloaded the latest release but didn't find any wx code in the release to look at.) That way, we can know if the code itself is correct, and there's a bug, or if the code is going about doing something in a way that doesn't match how wx works.

Regards,

Kevin

···

On Mar 17, 2007, at 6:18 AM, Kent Tenney wrote:

Thanks,
Kent

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

3

Hi Kent,

Hi Kent,

> Howdy,
>
> This page;
> http://leo.zwiki.org/WxWidgetsSummary
>
> describes a developer's experience porting a TK app,
> Leo, Leo: a programmer's editor & more download | SourceForge.net
> to wxWidgets
>
> I would be very interested in comments from this
> community on the issues encountered.
>
> I don't know wxPython well enough to evaluate, I do
> know that many seem very happy with wxPython,
> and wish Leo was among them.
>
> Are the issues in the critique somehow related in
> differences between TK and wx architecture?

Well, most of the comments are quite general, and there are no code
samples to help us understand the issues, so it's impossible with
just that info to know whether most of the author's points about
specific bugs are valid or not. In fact, for the wx.Menu and
wx.TreeCtrl 'bugs', I'm really not sure I understand what he means by
things like 'inner' and 'outer' events, or needing to create a key
binding to create a shortcut. Based solely on what he's written, I'd
say that I've never run into either of these issues, but maybe I'm
misunderstanding something. As for the STC problem, it might be the
case that it eats key events, that one I'm not totally sure on.

Anyway, the best way to get to the bottom of this stuff is for us to
see some sample code. (I downloaded the latest release but didn't
find any wx code in the release to look at.)

The wx code lives in CVS at http://leo.tigris.org
http://murl.se/22663

I've also posted it on the Leo wiki, http://leo.zwiki.org/WxguiPy
with the Leo 'sentinels' removed (comments which Leo uses to manage structure)

Thanks!

I found the menu code that's being referred to. It looks to me like the goal is to "show" the accelerator key combo, but have wx not actually assign a key binding to it...? That being the case, I suspect that replacing the "\t" in the menu item label with " " or something should give the desired results. (IIRC the wx.MenuItem code looks for "\t" to determine if it has an key binding.) The code later on seems to use wx.AcceleratorEntry to create the said key binding anyway, so I'm not quite sure why it's a problem if it's done by wx.MenuItem instead, but anyway, hopefully the tab-to-spaces workaround would do the trick.

Regarding the TreeCtrl, I didn't see anything in the code that clarified what was meant by 'inner' and 'outer' events, but looking at the "redraw" code for the TreeCtrl, I suspect there may be some misunderstanding of how wx events work and what the purpose of each event is. Again, this is just from a glance at the code, but it doesn't look like the code is drawing anything inside the TreeCtrl's EVT_PAINT handler - partialRedraw and cleverRedraw look more like they're updating the TreeCtrl's state, which should never happen inside of EVT_PAINT. EVT_PAINT should only ever be used to actually draw to the screen using a DeviceContext (wx.DC and related classes). Of course, any attempt to update the TreeCtrl's state will fire events whenever applicable (possibly including more paint events), which is why the code has to 'lockout' events while handling a paint event. That may be where the 'inner' events comment comes from.

As for how it should work, if I had to take a wild guess, I'd say the code is trying to workaround issues where changes to the data do not get immediately reflected by the wx.TreeCtrl. (Since wx.EVT_PAINT fires fairly often, it would seem like the best way to make sure updates are quickly processed.) A good way to handle those kinds of situations is to have a callback function, like updateTreeCtrl, that gets fired whenever the data gets updated. There's also the option of using a timer, though I'd recommend using a callback if possible because timers will fire even when no updates are actually needed.

As for the rest, I didn't see anything in the code related to key events that seemed off, but no comments about any bugs either, so I guess that issue would just need someone testing things out. But IMHO issues like the TreeCtrl problems should be addressed before doing bug testing for other things.

Regards,

Kevin

···

On Mar 17, 2007, at 3:48 PM, Kent Tenney wrote:

On 3/17/07, Kevin Ollivier <kevino@theolliviers.com> wrote:

On Mar 17, 2007, at 6:18 AM, Kent Tenney wrote:

Thanks,
Kent

That way, we can know if

the code itself is correct, and there's a bug, or if the code is
going about doing something in a way that doesn't match how wx works.

Regards,

Kevin

> Thanks,
> Kent
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
> For additional commands, e-mail: wxPython-users-
> help@lists.wxwidgets.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org