I can dismiss a wx.PopupTransientWindow by (left) clicking somewhere outside the popup, but the click gets swallowed. For example, I can't close the window by clicking on the close control whilst the popup is displayed.
Complete example app attached (this is very similar to the demo). Clicking on the "transient" button creates a popup. It should be possible to toggle the state of the "Toggle" button whilst the popup is visible, but you can't do it. If the popup is visible and you click on the "Toggle" button, the popup goes away, but the "Toggle" button doesn't change state.
Looking at the C++ code, it looks like this is not intended.
I tried to work round this by implementing a similar class in Python, but you can't set the position of a (wx.Mouse...) event.
I can dismiss a wx.PopupTransientWindow by (left) clicking somewhere outside the popup, but the click gets swallowed. For example, I can't close the window by clicking on the close control whilst the popup is displayed.
Complete example app attached (this is very similar to the demo). Clicking on the "transient" button creates a popup. It should be possible to toggle the state of the "Toggle" button whilst the popup is visible, but you can't do it. If the popup is visible and you click on the "Toggle" button, the popup goes away, but the "Toggle" button doesn't change state.
Looking at the C++ code, it looks like this is not intended.
These problems are known and have recently been fixed in the 2.5 series.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
wxPython 2.4.2.4
Python 2.3
Windows XP
I can dismiss a wx.PopupTransientWindow by (left) clicking somewhere outside the popup, but the click gets swallowed. For example, I can't close the window by clicking on the close control whilst the popup is displayed.
Complete example app attached (this is very similar to the demo). Clicking on the "transient" button creates a popup. It should be possible to toggle the state of the "Toggle" button whilst the popup is visible, but you can't do it. If the popup is visible and you click on the "Toggle" button, the popup goes away, but the "Toggle" button doesn't change state.
Looking at the C++ code, it looks like this is not intended.
These problems are known and have recently been fixed in the 2.5 series.
wxPython 2.4.2.4
Python 2.3
Windows XP
I can dismiss a wx.PopupTransientWindow by (left) clicking somewhere outside the popup, but the click gets swallowed. For example, I can't close the window by clicking on the close control whilst the popup is displayed.
Complete example app attached (this is very similar to the demo). Clicking on the "transient" button creates a popup. It should be possible to toggle the state of the "Toggle" button whilst the popup is visible, but you can't do it. If the popup is visible and you click on the "Toggle" button, the popup goes away, but the "Toggle" button doesn't change state.
Looking at the C++ code, it looks like this is not intended.
These problems are known and have recently been fixed in the 2.5 series.
ok, good. What about the 2.4 series?
With 2.6 happening real soon now nobody is paying much attention to 2.4. I expect that even if somebody was still working on it that this change wouldn't be able to applied because of the need to maintain binary compatibility.
···
On Apr 08, 2005, at 00:15, Robin Dunn wrote:
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
I had previously rejected using 2.5.x as it was "unstable", that is, the interface might change. With an unstable interface there is a risk that I have to make large changes to my code in order to use a new 2.5 release, which I might want to do in order to get bug fixes. I had regarded the risk of making expensive changes as too high.
I had therefore selected 2.4.x as the series to use (and use it an way which is mostly 2.5 compatible, and in particular avoids any features deprecated in 2.5 - in so far as that is possible). But now you're telling me that there are unlikely to be any bug fixes for 2.4.
What version do you recommend that I should use for time-bounded projects for paying customers?
David Jones
···
On Apr 08, 2005, at 19:27, Robin Dunn wrote:
David Jones wrote:
On Apr 08, 2005, at 00:15, Robin Dunn wrote:
These problems are known and have recently been fixed in the 2.5 series.
ok, good. What about the 2.4 series?
With 2.6 happening real soon now nobody is paying much attention to 2.4. I expect that even if somebody was still working on it that this change wouldn't be able to applied because of the need to maintain binary compatibility.
I had previously rejected using 2.5.x as it was "unstable", that is,
the interface might change. With an unstable interface there is a risk
that I have to make large changes to my code in order to use a new 2.5
release, which I might want to do in order to get bug fixes. I had
regarded the risk of making expensive changes as too high.
I don't think you had to worry a lot about "unstable" releases versus "stable"
releases. Robin is doing an excellent work in order to keep the greatest
compatibility between the stable and unstable wxPython versions. I started
developing big (BIG) applications in wxPython 2.4.2.4, and I always upgraded
to the prereleases (when they were available) or to the ANNounced new intermediate
releases.
The small problems/incompatibilities I found, I could have been able to
correct them just by reading more carefully the "Recent Changes" instructions
(e.g. the TaskBarIcon problem I had). Other problems/headaches I had did
not come from wxPython, but from other site-packages batteries.
Moreover, every time I got problems/weird behaviors, I always got useful
answer from this nice NG.
I think you should ask for a refund! If you've been paying these guys to maintain 2.4, you're not getting your monies worth.
I switched to 2.5.2.8 from 2.4 because there were a couple of bugs that 2.5 resolved. The release after 2.5.3.1 had a few bugs that caused a couple of problems, but the last two releases have run faster (based on subjective performance analysis), and even fewer bugs.
Kudos Robin, Well Done!
If you decide to bite the bullet and upgrade, be sure you translate event macros to bind statements. I found a few quirks with old code that went away after translating to the new style.
With Py2exe and Inno its a snap to bring your clients up-to-date. Since updates to opensource are more frequent than commercial counterparts, the time spent incorporating these tools in the distribution chain are well worth the effort.
-Joe
David Jones wrote:
···
On Apr 08, 2005, at 19:27, Robin Dunn wrote:
David Jones wrote:
On Apr 08, 2005, at 00:15, Robin Dunn wrote:
These problems are known and have recently been fixed in the 2.5 series.
ok, good. What about the 2.4 series?
With 2.6 happening real soon now nobody is paying much attention to 2.4. I expect that even if somebody was still working on it that this change wouldn't be able to applied because of the need to maintain binary compatibility.
I had previously rejected using 2.5.x as it was "unstable", that is, the interface might change. With an unstable interface there is a risk that I have to make large changes to my code in order to use a new 2.5 release, which I might want to do in order to get bug fixes. I had regarded the risk of making expensive changes as too high.
I had therefore selected 2.4.x as the series to use (and use it an way which is mostly 2.5 compatible, and in particular avoids any features deprecated in 2.5 - in so far as that is possible). But now you're telling me that there are unlikely to be any bug fixes for 2.4.
What version do you recommend that I should use for time-bounded projects for paying customers?
David Jones
---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org
I think you should ask for a refund! If you've been paying these guys to maintain 2.4, you're not getting your monies worth.
Ummm. No, they are paying me.
Actually I'm being paid to write a tool, my customer doesn't really care what I write it in. I need to be sure that I can get the tool written for the price that I quoted. So I need to control risk. The issue is, should I be using wxPython 2.4 or 2.5.
I am already using py2exe (and some other installer) precisely so that I can exactly (or more exactly) control which versions of what end up in the finished product.
But as you point out, _I'm_ not paying anyone to maintain 2.4 for me. So that's why I'm asking, am I better off using 2.4 or 2.5? And the thing I'm most concerned about is having to make expensive changes.
I switched to 2.5.2.8 from 2.4 because there were a couple of bugs that 2.5 resolved. The release after 2.5.3.1 had a few bugs that caused a couple of problems, but the last two releases have run faster (based on subjective performance analysis), and even fewer bugs.
Kudos Robin, Well Done!
If you decide to bite the bullet and upgrade, be sure you translate event macros to bind statements. I found a few quirks with old code that went away after translating to the new style.
That's exactly the kind of thing I wish to avoid, but these war stories are quite useful.
I say go with 2.5!
2.6 is around the corner and guess what, there hasn't been a 2.4 release in some time. all the fixes happen in 2.5 PLUS you code faster with 2.5 (at least I do).
Anyway... even if you plan to use 2.4, use the wx namespace not the old
from wxPython.wx import *
it will make the transition to 2.5 easier.
Peter.
···
On Mon, 11 Apr 2005 19:19:26 +0300, David Jones <drj@ravenbrook.com> wrote:
On Apr 11, 2005, at 15:55, Joe Brown wrote:
I think you should ask for a refund! If you've been paying these guys to maintain 2.4, you're not getting your monies worth.
Ummm. No, they are paying me.
Actually I'm being paid to write a tool, my customer doesn't really care what I write it in. I need to be sure that I can get the tool written for the price that I quoted. So I need to control risk. The issue is, should I be using wxPython 2.4 or 2.5.
I am already using py2exe (and some other installer) precisely so that I can exactly (or more exactly) control which versions of what end up in the finished product.
But as you point out, _I'm_ not paying anyone to maintain 2.4 for me. So that's why I'm asking, am I better off using 2.4 or 2.5? And the thing I'm most concerned about is having to make expensive changes.
Well, I'm already using 2.4, but a switch to 2.5 is not out of the question. And I did look at 2.5 just enough to tell me that I should be using the wx namespace, and so on. Basically I'm using 2.4 but trying to maintain compatibility with 2.5 so that a switch, if it's necessary, is not too painful.
So far, apart from a couple of minor bug fixes, there's nothing that draws me hugely towards 2.5. And a very very brief experiment tells me that wx.lib.pubsub has changed.
Of course, had I been doing this in a few month's time it would have been an easy decision to go with 2.6.
This is a very useful discussion. The enthusiasm with which people recommend 2.5 gives 2.5 a quite different character from that suggested by the ReleaseSeries wiki page: http://wiki.wxpython.org/index.cgi/ReleaseSeries
David Jones
···
On Apr 11, 2005, at 17:42, Peter Damoc wrote:
On Mon, 11 Apr 2005 19:19:26 +0300, David Jones <drj@ravenbrook.com> > wrote:
But as you point out, _I'm_ not paying anyone to maintain 2.4 for me. So that's why I'm asking, am I better off using 2.4 or 2.5? And the thing I'm most concerned about is having to make expensive changes.
I say go with 2.5!
2.6 is around the corner and guess what, there hasn't been a 2.4 release in some time. all the fixes happen in 2.5 PLUS you code faster with 2.5 (at least I do).
Anyway... even if you plan to use 2.4, use the wx namespace not the old
from wxPython.wx import *
it will make the transition to 2.5 easier.
Oh, I ment to state, 2.5.5.1 seems most solid. Furthermore, Robin hasn't mentioned any drastic changes planned for the near future. Its worth while to invest the time to bring the work up-todate, IMO.
There probably could be a script that converts the wx.EVT macros, or even an editor macro could do the rough work. I searched for EVT and it was a snap to do it by hand. Usually doesn't hurt to revisit all old code, for nostalgia purposes.
-Joe
David Jones wrote:
···
On Apr 11, 2005, at 15:55, Joe Brown wrote:
If you decide to bite the bullet and upgrade, be sure you translate event macros to bind statements. I found a few quirks with old code that went away after translating to the new style.
That's exactly the kind of thing I wish to avoid, but these war stories are quite useful.
David Jones
---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org
Oh, I ment to state, 2.5.5.1 seems most solid. Furthermore, Robin hasn't mentioned any drastic changes planned for the near future. Its worth while to invest the time to bring the work up-todate, IMO.
There probably could be a script that converts the wx.EVT macros, or even an editor macro could do the rough work. I searched for EVT and it was a snap to do it by hand. Usually doesn't hurt to revisit all old code, for nostalgia purposes.
There is one in Boa 0.4.x, it was intended for Boa 0.3.1 code but does an o.k. job for others - BUT does NOT deal well with 2.4 code using the new namespace!
If you decide to bite the bullet and upgrade, be sure you translate event macros to bind statements. I found a few quirks with old code that went away after translating to the new style.
That's exactly the kind of thing I wish to avoid, but these war stories are quite useful.
David Jones
---------------------------------------------------------------------
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
I had previously rejected using 2.5.x as it was "unstable", that is, the interface might change. With an unstable interface there is a risk that I have to make large changes to my code in order to use a new 2.5 release, which I might want to do in order to get bug fixes. I had regarded the risk of making expensive changes as too high.
I had therefore selected 2.4.x as the series to use (and use it an way which is mostly 2.5 compatible, and in particular avoids any features deprecated in 2.5 - in so far as that is possible). But now you're telling me that there are unlikely to be any bug fixes for 2.4.
There is too much code and too few active developers to keep things moving for very long on more than one development branch. Plus the binary compatibility requirement for the stable branches makes things difficult as it won't be very long before the binary compatibility is broken in the unstable release and so back-porting any but the most trivial fixes from the unstable to the prior stable branch soon becomes impossible.
What version do you recommend that I should use for time-bounded projects for paying customers?
There should be no API changes bewteen 2.5.5 and 2.6.0, so jump on 2.5 now and you'll be ready for 2.6 when it comes out in a couple weeks
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
Actually from what I've seen and heard it *IS* different.
2.5 is unstable branch of wxwidgets but that instability gets caught when the wrapping to python occurs.
I've had very few surprises using the 2.5 branch and I use almost all releases (pre and RC)
Generaly speaking the 2.5 releases that hit the front page are just as stable as 2.4
Peter
···
On Mon, 11 Apr 2005 19:52:30 +0300, David Jones <drj@ravenbrook.com> wrote:
This is a very useful discussion. The enthusiasm with which people recommend 2.5 gives 2.5 a quite different character from that suggested by the ReleaseSeries wiki page: http://wiki.wxpython.org/index.cgi/ReleaseSeries
I had previously rejected using 2.5.x as it was "unstable", that is, the interface might change. With an unstable interface there is a risk that I have to make large changes to my code in order to use a new 2.5 release, which I might want to do in order to get bug fixes. I had regarded the risk of making expensive changes as too high.
I had therefore selected 2.4.x as the series to use (and use it an way which is mostly 2.5 compatible, and in particular avoids any features deprecated in 2.5 - in so far as that is possible). But now you're telling me that there are unlikely to be any bug fixes for 2.4.
There is too much code and too few active developers to keep things moving for very long on more than one development branch. Plus the binary compatibility requirement for the stable branches makes things difficult as it won't be very long before the binary compatibility is broken in the unstable release and so back-porting any but the most trivial fixes from the unstable to the prior stable branch soon becomes impossible.
OK. So to put it bluntly a branch is either bug-fixed or stable. That's fine as a policy, but it could perhaps be clearer.
We must have a discussion about binary compatibility sometime, as it's not something I understand much, but not now.
What version do you recommend that I should use for time-bounded projects for paying customers?
There should be no API changes bewteen 2.5.5 and 2.6.0, so jump on 2.5 now and you'll be ready for 2.6 when it comes out in a couple weeks
Aha, so 2.5.5 has already met the requirements of the policy of 2.6, namely, no API changes. So why not just rename 2.5.5 as 2.6 now?