Discussion:
wxWidgets 2.5.4
Rob Gayvert
2006-07-19 15:18:00 UTC
Permalink
wxWidgets 2.5.4 has been released: please click on the Download
link on the wxWidgets site at http://www.wxwidgets.org.
This is a development snapshot and will quickly be followed
up by 2.5.5 and 2.6 in March. Please report problems to
the Bug Tracker at SourceForge, or this list (or wx-dev
if you are subscribed): this will help us iron out any
issues before the stable release.
Note that 2.5.X are considered "unstable" development releases, and 2.6
is the next official stable release.

My current plan is to release wxSqueak 0.4 using wxWidgets 2.5.3,
followed shortly by a 0.4.1 release based on wxWidgets 2.5.4. The 0.5
release will be based on wxWidgets 2.6. The 0.4.1 release will probably
be modularized and packaged with Monticello in some form once we figure
it out.

I don't anticipate any major API changes for these new wxWidgets
releases. There are a couple of new controls and assorted changes, but
nothing significant from a wxSqueak perspective.
Cees de Groot
2006-07-19 15:18:00 UTC
Permalink
Post by Rob Gayvert
My current plan is to release wxSqueak 0.4 using wxWidgets 2.5.3,
followed shortly by a 0.4.1 release based on wxWidgets 2.5.4. The 0.5
release will be based on wxWidgets 2.6. The 0.4.1 release will probably
be modularized and packaged with Monticello in some form once we figure
it out.
FWIW, sounds like a good plan :)

We moved our development to 0.4, no big surprises so far. I think the grid
code can still do with some range checking, I'd need to check the exact
spot but I had a VM crash when still using 0-based offsets, I think when I
set column labels. The right-click problem seems to be solved, although I
had problems in the tree with spurious events - tree events coming in with
event items containing pointers that didn't match any of the items in my
tree (I keep a list of items around).

Hopefully the wx guys get the busy cursor over grids etcetera back into
shape, as far as I can tell that's currently the only 'out of our control'
issue in our application.

(I'll start work on translation in a couple of weeks, so you guys can take
an informed look ;))
Rob Gayvert
2006-07-19 15:18:00 UTC
Permalink
Post by Cees de Groot
We moved our development to 0.4, no big surprises so far. I think the
grid code can still do with some range checking, I'd need to check
the exact spot but I had a VM crash when still using 0-based offsets,
I think when I set column labels. The right-click problem seems to be
solved, although I had problems in the tree with spurious events -
tree events coming in with event items containing pointers that
didn't match any of the items in my tree (I keep a list of items
around).
The range checking actually has a long way to go -- I've probably only
done about 10% of what needs to be done. The problem is that it's a
tedious job. In most cases, I have to check both the wxWidgets
documentation and the source code to see how the boundary values are
handled. Sometimes an index of -1 will be invalid, while other times it
has special meaning. Once I get the API spec into a sqlite database it
will be easier to add these checks.

As for tree events, I know there are some oddities. On OS X I had to
disable the tree control demo because it kept crashing for some reason.
But this line in the release notes for 2.5.4 gives us some hope:
- Various changes to how wxListCtrl and wxTreeCtrl react to
right
mouse clicks and left mouse click for starting a drag
operation.
Post by Cees de Groot
Hopefully the wx guys get the busy cursor over grids etcetera back
into shape, as far as I can tell that's currently the only 'out of
our control' issue in our application.
Well, a quick mod to the grid sample reveals that the problem is still
there in 2.5.4. I'll have to check with the wx mailing list about this.
Cees de Groot
2006-07-19 15:18:00 UTC
Permalink
Post by Rob Gayvert
The range checking actually has a long way to go -- I've probably only
done about 10% of what needs to be done. The problem is that it's a
tedious job.
And it's not the most important thing - so far, most range errors have
been caught nicely by the debugging VM and so far, they've all pointed out
programming mistakes :).

Loading...