wxPython 4.0.2

classic Classic list List threaded Threaded
29 messages Options
12
Reply | Threaded
Open this post in threaded view
|

wxPython 4.0.2

Robin Dunn
Announcing wxPython 4.0.2
=========================

PyPI:   https://pypi.org/project/wxPython/4.0.2
Extras: https://extras.wxPython.org/wxPython4/extras/
Pip:    ``pip install wxPython==4.0.2``

Changes in this release include the following:

* Fixed wx.html2.EVT_WEBVIEW_NAVIGATING event not being sent on some
   versions of Linux. (#741)

* wx.Sizers can now be used as an iterator to iterate over the items
   within the sizer. (#738)

* Fix Python3 division in ThumbnailCtrl. (#746)

* Fix leaking image list in CheckListCtrlMixin (#752)

* All items marked as deprecated in the wxWidgets interface
   (documentation) files will now throw a DeprecationWarning when used
   from wxPython. Many of these items are disappearing in 4.1 so it's
   important to ensure they are deprecated at runtime too instead of
   just in the docs. (#749)

* Ensure that the attribute list given to the GLCanvas constructor is
   zero-terminated like it was in Classic. (#770)

* Updated to the wxWidgets 3.0.4 release version.

* Added the wxWidgets version number to the tail end of the string
   returned by wx.version().

* Bind EVT_WINDOW_DESTROY event only to the tree windows in
   CustomTreeCtrl, since otherwise it would be caught when child
   windows are destroyed too, which causes problems in this
   case. (#778)

* Fixed a problem where wx.TreeCtrl.OnCompareItems was not being
   called in derived classes on Windows. This was due to an
   optimization that wasn't compatible with how the classes are
   wrapped. (#774)

* Added wrappers for wx.ClassInfo and exposed
   wx.Object.GetClassInfo. This class is part of wxWidgets' internal
   type information system and although it is not very useful for
   Python applications it is useful for debugging some internal
   wxPython issues.

* Removed the wx.lib.pubsub package, and replaced it with code that
   imports the standalone PyPubSub in order remain compatible with
   older code that still uses wx.lib.pubsub. (#782, #792)

* Fixed bug in wx.lib.intctrl (#790)

* Fixed subclassing of wx.TextCompleter and wx.TextCompleterSimple
   (#827)

* Fixes for Python3 compatibility in PyCrust. (#823)

* Fix wxGet to be able to use pip v10. (#817)

* Change winid parameter in wx.ScrolledWindow to id, for
   consistency. (#816)

* Ensure that the page exists in book controls GetPage and RemovePage
   methods.  At least one of the wx ports do not do this. (#830)

* Added missing wx.NumberEntryDialog

* Change wx.TextCompleterSimple.GetCompletions to send the list of
   strings as a return value, rather than a parameter that gets
   filled. (#836)

* Enabled the wx.GraphicsContext.Create(metaFileDC) wrapper (#811)

* Metafile support is also available on OSX, so wx.msw.Metafile and
   wx.msw.MetafileDC have been moved to the core wx module. So they can
   now be accessed as wx.Metafile and wx.MetafileDC.

* Updated the waf tool used by the build to version 2.0.7. This fixes
   problems with building for Python 3.7.

* Fixed alignment in buttons on MSW which have had foreground or
   background colors set. (#815)

* Fix for unexpected assertion inside wx.aui.AuiMDIChildFrame.Close.

* Fix a bug in setting AuiDockingGuide size. (#727)

* Remove unnecessary AUI notebook updating, and use wx.BufferedDC in
   Repaint() to mitigate flicker. (wx.lib.agw.aui). (#851, #686)

* Fixed crashing bug when using client data with items in
   wx.dataview.DataViewTreeCtrl. (#856)

* Detach wx.Control in AuiToolbar from current sizer before attach to
   a new one. (#843)

* Fixed a problem in wx.lib.mixins.listctrl.TextEditMixin where the
   height of the editor widget could be set to zero. (See discussion in
   #849)

* Fix a bug in calculating whether a tool fits into the
   AuiToolBar. (#863)

* Override SetForegroundColour and SetBackgroundColour in
   MaskedEditMixin (#808)

* Add an explicit wx.GraphicsContext.Create overload for
   wx.AutoBufferedPaintDC. (#783)

* Return original AGW window style in
   AuiToolBar.GetAGWWindowStyleFlag. (#870)

* Fix a bug in group management on wx.lib.masked.numctrl; the previous
   code used truediv ('/') to calculate _groupSpace, but in python 3.x
   this leads to a float result, instead of an integer as was
   expected. Using floordiv ('//') instead to solve the problem. (#865)

* Hide the window when the tool does not fit into AuiToolBar. (#872)

* Fixed the virtual dispatch code for the PGEditor.GetValueFromControl
   method to properly pass the parameters to the Python implementation,
   and also fixed how the return value is handled. (#742)

* Fixed all implementations of the PGProperty.StringToValue and
   IntToValue methods to treat the value parameter as a return
   value. (#742)

* Add missing wx.adv.EVT_CALENDAR_WEEK_CLICKED (#875)

* Fixed the stock labels to conform to Windows design
   guidelines. (#787)

* Always reset floating size and style when floating a toolbar in
   agw.aui. (#880)





What is wxPython?
-----------------

wxPython is a cross-platform GUI toolkit for the Python programming
language.  It allows Python programmers to create programs with a
robust, highly functional graphical user interface, simply and
easily. It is implemented as a set of Python extension modules that
wrap the GUI components of the popular wxWidgets cross platform
library, which is written in C++. Supported platforms are Microsoft
Windows, Mac OS X and macOS, and Linux or other unix-like systems with
GTK2 or GTK3 libraries. In most cases the native widgets are used on
each platform to provide a 100% native look and feel for the
application.


What is wxPython Phoenix?
-------------------------

wxPython's Project Phoenix is a new from-the-ground-up implementation
of wxPython, created with the intent of making wxPython “better,
stronger, faster than he was before.” In other words, this new
implementation is focused on improving speed, maintainability and
extensibility of wxPython, as well as removing most of the cruft that
had accumulated over the long life of Classic wxPython.

The project has been in development off and on, mostly behind the
scenes, for many years. For the past few years automated snapshot
builds have been available for those adventurous enough to try it, and
many people eventually started using the snapshots in their projects,
even for production releases.  While there are still some things on
the periphery that need to be completed, the core of the new wxPython
extension modules which wrap the wxWidgets code has been stable for a
long time now.

Due to some things being cleaned up, reorganized, simplified and
dehackified wxPython Phoenix is not completely backwards compatible
with wxPython Classic.  This is intended. In general, however, the API
differences tend to be minor and some applications can use Phoenix
with slight, or even with no modifications.  In some other cases the
correct way to do things was also available in Classic and it's only
the wrong way that has been removed from Phoenix.  For more
information there is a Migration Guide document available at:
https://docs.wxpython.org/MigrationGuide.html

The new wxPython API reference documentation, including all
Python-specific additions and customizations, and docs for the wx.lib
package, is located at: https://docs.wxpython.org/



--
Robin Dunn
Software Craftsman
http://wxPython.org

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: wxPython 4.0.2

Marco Prosperi


Great work! I've just installed and looking around: I get a lot of deprecation warning about NewId. Which is the recommended way of managing ids? Passing wx.ANY in the constructor of objects and then object.GetId() to get the id?

Marco


On Monday, June 18, 2018 at 6:49:36 AM UTC+2, Robin Dunn wrote:
Announcing wxPython 4.0.2
=========================

PyPI:   <a href="https://pypi.org/project/wxPython/4.0.2" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fpypi.org%2Fproject%2FwxPython%2F4.0.2\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHM1pDYHooNNznWSZUnhIm_1BLhWg&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fpypi.org%2Fproject%2FwxPython%2F4.0.2\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHM1pDYHooNNznWSZUnhIm_1BLhWg&#39;;return true;">https://pypi.org/project/wxPython/4.0.2
Extras: <a href="https://extras.wxPython.org/wxPython4/extras/" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fextras.wxPython.org%2FwxPython4%2Fextras%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGcsw_Iobkg1aebNWhYuIi6uQR-vA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fextras.wxPython.org%2FwxPython4%2Fextras%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGcsw_Iobkg1aebNWhYuIi6uQR-vA&#39;;return true;">https://extras.wxPython.org/wxPython4/extras/
Pip:    ``pip install wxPython==4.0.2``

Changes in this release include the following:

* Fixed wx.html2.EVT_WEBVIEW_NAVIGATING event not being sent on some
   versions of Linux. (#741)

* wx.Sizers can now be used as an iterator to iterate over the items
   within the sizer. (#738)

* Fix Python3 division in ThumbnailCtrl. (#746)

* Fix leaking image list in CheckListCtrlMixin (#752)

* All items marked as deprecated in the wxWidgets interface
   (documentation) files will now throw a DeprecationWarning when used
   from wxPython. Many of these items are disappearing in 4.1 so it's
   important to ensure they are deprecated at runtime too instead of
   just in the docs. (#749)

* Ensure that the attribute list given to the GLCanvas constructor is
   zero-terminated like it was in Classic. (#770)

* Updated to the wxWidgets 3.0.4 release version.

* Added the wxWidgets version number to the tail end of the string
   returned by wx.version().

* Bind EVT_WINDOW_DESTROY event only to the tree windows in
   CustomTreeCtrl, since otherwise it would be caught when child
   windows are destroyed too, which causes problems in this
   case. (#778)

* Fixed a problem where wx.TreeCtrl.OnCompareItems was not being
   called in derived classes on Windows. This was due to an
   optimization that wasn't compatible with how the classes are
   wrapped. (#774)

* Added wrappers for wx.ClassInfo and exposed
   wx.Object.GetClassInfo. This class is part of wxWidgets' internal
   type information system and although it is not very useful for
   Python applications it is useful for debugging some internal
   wxPython issues.

* Removed the wx.lib.pubsub package, and replaced it with code that
   imports the standalone PyPubSub in order remain compatible with
   older code that still uses wx.lib.pubsub. (#782, #792)

* Fixed bug in wx.lib.intctrl (#790)

* Fixed subclassing of wx.TextCompleter and wx.TextCompleterSimple
   (#827)

* Fixes for Python3 compatibility in PyCrust. (#823)

* Fix wxGet to be able to use pip v10. (#817)

* Change winid parameter in wx.ScrolledWindow to id, for
   consistency. (#816)

* Ensure that the page exists in book controls GetPage and RemovePage
   methods.  At least one of the wx ports do not do this. (#830)

* Added missing wx.NumberEntryDialog

* Change wx.TextCompleterSimple.GetCompletions to send the list of
   strings as a return value, rather than a parameter that gets
   filled. (#836)

* Enabled the wx.GraphicsContext.Create(metaFileDC) wrapper (#811)

* Metafile support is also available on OSX, so wx.msw.Metafile and
   wx.msw.MetafileDC have been moved to the core wx module. So they can
   now be accessed as wx.Metafile and wx.MetafileDC.

* Updated the waf tool used by the build to version 2.0.7. This fixes
   problems with building for Python 3.7.

* Fixed alignment in buttons on MSW which have had foreground or
   background colors set. (#815)

* Fix for unexpected assertion inside wx.aui.AuiMDIChildFrame.Close.

* Fix a bug in setting AuiDockingGuide size. (#727)

* Remove unnecessary AUI notebook updating, and use wx.BufferedDC in
   Repaint() to mitigate flicker. (wx.lib.agw.aui). (#851, #686)

* Fixed crashing bug when using client data with items in
   wx.dataview.DataViewTreeCtrl. (#856)

* Detach wx.Control in AuiToolbar from current sizer before attach to
   a new one. (#843)

* Fixed a problem in wx.lib.mixins.listctrl.TextEditMixin where the
   height of the editor widget could be set to zero. (See discussion in
   #849)

* Fix a bug in calculating whether a tool fits into the
   AuiToolBar. (#863)

* Override SetForegroundColour and SetBackgroundColour in
   MaskedEditMixin (#808)

* Add an explicit wx.GraphicsContext.Create overload for
   wx.AutoBufferedPaintDC. (#783)

* Return original AGW window style in
   AuiToolBar.GetAGWWindowStyleFlag. (#870)

* Fix a bug in group management on wx.lib.masked.numctrl; the previous
   code used truediv ('/') to calculate _groupSpace, but in python 3.x
   this leads to a float result, instead of an integer as was
   expected. Using floordiv ('//') instead to solve the problem. (#865)

* Hide the window when the tool does not fit into AuiToolBar. (#872)

* Fixed the virtual dispatch code for the PGEditor.GetValueFromControl
   method to properly pass the parameters to the Python implementation,
   and also fixed how the return value is handled. (#742)

* Fixed all implementations of the PGProperty.StringToValue and
   IntToValue methods to treat the value parameter as a return
   value. (#742)

* Add missing wx.adv.EVT_CALENDAR_WEEK_CLICKED (#875)

* Fixed the stock labels to conform to Windows design
   guidelines. (#787)

* Always reset floating size and style when floating a toolbar in
   agw.aui. (#880)





What is wxPython?
-----------------

wxPython is a cross-platform GUI toolkit for the Python programming
language.  It allows Python programmers to create programs with a
robust, highly functional graphical user interface, simply and
easily. It is implemented as a set of Python extension modules that
wrap the GUI components of the popular wxWidgets cross platform
library, which is written in C++. Supported platforms are Microsoft
Windows, Mac OS X and macOS, and Linux or other unix-like systems with
GTK2 or GTK3 libraries. In most cases the native widgets are used on
each platform to provide a 100% native look and feel for the
application.


What is wxPython Phoenix?
-------------------------

wxPython's Project Phoenix is a new from-the-ground-up implementation
of wxPython, created with the intent of making wxPython “better,
stronger, faster than he was before.” In other words, this new
implementation is focused on improving speed, maintainability and
extensibility of wxPython, as well as removing most of the cruft that
had accumulated over the long life of Classic wxPython.

The project has been in development off and on, mostly behind the
scenes, for many years. For the past few years automated snapshot
builds have been available for those adventurous enough to try it, and
many people eventually started using the snapshots in their projects,
even for production releases.  While there are still some things on
the periphery that need to be completed, the core of the new wxPython
extension modules which wrap the wxWidgets code has been stable for a
long time now.

Due to some things being cleaned up, reorganized, simplified and
dehackified wxPython Phoenix is not completely backwards compatible
with wxPython Classic.  This is intended. In general, however, the API
differences tend to be minor and some applications can use Phoenix
with slight, or even with no modifications.  In some other cases the
correct way to do things was also available in Classic and it's only
the wrong way that has been removed from Phoenix.  For more
information there is a Migration Guide document available at:
<a href="https://docs.wxpython.org/MigrationGuide.html" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdocs.wxpython.org%2FMigrationGuide.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGBCH3yFfpruWww3JEH4LUNwkzXgg&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdocs.wxpython.org%2FMigrationGuide.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGBCH3yFfpruWww3JEH4LUNwkzXgg&#39;;return true;">https://docs.wxpython.org/MigrationGuide.html

The new wxPython API reference documentation, including all
Python-specific additions and customizations, and docs for the wx.lib
package, is located at: <a href="https://docs.wxpython.org/" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdocs.wxpython.org%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFrQ5-jIoeQgPyQhbPnSMpDDxMORw&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fdocs.wxpython.org%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFrQ5-jIoeQgPyQhbPnSMpDDxMORw&#39;;return true;">https://docs.wxpython.org/



--
Robin Dunn
Software Craftsman
<a href="http://wxPython.org" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2FwxPython.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHG9kM-NEpJfIvl_lWJvA23SuLjOA&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2FwxPython.org\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNHG9kM-NEpJfIvl_lWJvA23SuLjOA&#39;;return true;">http://wxPython.org

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: wxPython 4.0.2

Anders Munch
In reply to this post by Robin Dunn
Marco Prosperi:
> I get a lot of deprecation warning about NewId.

Just tried it. Some of the warnings are in the wx library itself, e.g. in wx.py.frame.

I googled to find http://docs.wxwidgets.org/3.1/overview_windowids.html.
It looks like wx.Window.NewControlId is the replacement. Although that one returns negative numbers, whereas NewId returns positive numbers, but I think that only makes a difference if you use hardwired literal constant ID's, which you shouldn't do anyway.

Robin, please keep wx.NewId and remove the deprecation, adding a forwarding implementation when it becomes necessary.
NewId calls are ubiquitous. You don't remove something like that, unless there's a hard technical need, or it's some sort of really badly named bug magnet, and wx.NewId is neither.

regards, Anders

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: [wxPython-dev] wxPython 4.0.2

efahl
In reply to this post by Robin Dunn
On Sun, Jun 17, 2018 at 9:49 PM Robin Dunn <[hidden email]> wrote:
Announcing wxPython 4.0.2
=========================

Thanks once more, Robin!  Good work.

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: wxPython 4.0.2

Robin Dunn
In reply to this post by Anders Munch
On Monday, June 18, 2018 at 5:06:56 AM UTC-7, Anders Munch wrote:
Marco Prosperi:
> I get a lot of deprecation warning about NewId.

Just tried it. Some of the warnings are in the wx library itself, e.g. in wx.py.frame.

I googled to find <a href="http://docs.wxwidgets.org/3.1/overview_windowids.html" target="_blank" rel="nofollow" onmousedown="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fdocs.wxwidgets.org%2F3.1%2Foverview_windowids.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF3DBfCOcYNwo-ZJ3bWeIlq8wGdQQ&#39;;return true;" onclick="this.href=&#39;http://www.google.com/url?q\x3dhttp%3A%2F%2Fdocs.wxwidgets.org%2F3.1%2Foverview_windowids.html\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNF3DBfCOcYNwo-ZJ3bWeIlq8wGdQQ&#39;;return true;">http://docs.wxwidgets.org/3.1/overview_windowids.html.
It looks like wx.Window.NewControlId is the replacement. Although that one returns negative numbers, whereas NewId returns positive numbers, but I think that only makes a difference if you use hardwired literal constant ID's, which you shouldn't do anyway.

Robin, please keep wx.NewId and remove the deprecation, adding a forwarding implementation when it becomes necessary.
NewId calls are ubiquitous. You don't remove something like that, unless there's a hard technical need, or it's some sort of really badly named bug magnet, and wx.NewId is neither.


https://docs.wxpython.org/wx.functions.html#wx.NewId

One of the changes in this release is that anything that is marked as deprecated in the wxWidgets interface is now automatically marked as deprecated for wxPython as well. The initial reason for this is that most of them are being permanently removed in 4.1, but there are other good reasons as well. It will make runtime behavior match the documentation, ("Why does it say deprecated in the documentation but doesn't raise a deprecation warning?") and also to conform to one of Phoenix's design goals of reducing the divergence between wxWidgets and wxPython.
 
If the change really rubs you the wrong way then you can always monkey-patch in a new implementation of NewId into wx in your applications.

--
Robin



--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: wxPython 4.0.2

Anders Munch
In reply to this post by Robin Dunn
Robin Dunn:
> If the change really rubs you the wrong way

It really does.  The author of the deprecation notice seems to live in a world where people hardwire constant ID numbers in their application. Who does that?  If library authors do that, then the numbers are bound to collide sooner or later.

The deprecation notice says:
> Deprecated: Ids generated by it can conflict with the Ids defined by the user code

But wx.NewId is the *solution* to that problem, not the cause of it.  The solution to the problem of hardwired constant ID numbers is to stop hardwiring constant ID numbers.

Monkeypatching wx is no good, because to avoid collisions everyone must use the same mechanism to allocate numbers, and if I make my own allocation function for my own private use, then that is not the case.

Before I go on a mass editing spree to replace wx.NewId, can you confirm that wx.Window.NewControlId is the proper replacement?

regards, Anders

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: wxPython 4.0.2

Robin Dunn


On Tuesday, June 19, 2018 at 3:14:59 AM UTC-7, Anders Munch wrote:
Robin Dunn:
> If the change really rubs you the wrong way

It really does.  The author of the deprecation notice seems to live in a world where people hardwire constant ID numbers in their application. Who does that?  If library authors do that, then the numbers are bound to collide sooner or later.

Until recently the usual way to bind events in C++ wxWidgets is to use the static event table, which means static IDs are needed. (Dynamically binding handers is becoming more popular now, thanks in part to wxPython's example with our Bind()). Duplicate IDs only really becomes a problem when the widgets with that ID are in the same containment hierarchy, and the events for those widgets are being caught in a common ancestor instead of within the widget itself or its immediate parent. That means that even with static IDs it is not a problem in something like 95% or better of the cases.
 


The deprecation notice says:
> Deprecated: Ids generated by it can conflict with the Ids defined by the user code

But wx.NewId is the *solution* to that problem, not the cause of it.  The solution to the problem of hardwired constant ID numbers is to stop hardwiring constant ID numbers.

Monkeypatching wx is no good, because to avoid collisions everyone must use the same mechanism to allocate numbers, and if I make my own allocation function for my own private use, then that is not the case.

But there are also potential conflicts with wxNewId because anything that uses wx.ID_ANY to allow wx to allocate the ID will be using NewControlId instead of wxNewId

 

Before I go on a mass editing spree to replace wx.NewId, can you confirm that wx.Window.NewControlId is the proper replacement?

It is. It uses an internal management class to reserve IDs when used and release them when the widget is destroyed, so even if the internal counter wraps around those IDs that are still active will not be reused.

--
Robin

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: wxPython 4.0.2

Marco Prosperi

hello, in the process of managing NewId deprecation warnings, replacing them with other code, I would like to silent these warnings in production code. In another thread a couple of days ago, before wxpython 4.0.2, I ended up with this solution:

if main_is_frozen():
    with warnings.catch_warnings():
        warnings.simplefilter('ignore')
        #warnings.filterwarnings('ignore')
        run()
else:
    run()

Unfortunately NewId deprecation warning by pass this filters. What could be used instead?

thank in advance

Marco


On Tuesday, June 19, 2018 at 6:47:10 PM UTC+2, Robin Dunn wrote:


On Tuesday, June 19, 2018 at 3:14:59 AM UTC-7, Anders Munch wrote:
Robin Dunn:
> If the change really rubs you the wrong way

It really does.  The author of the deprecation notice seems to live in a world where people hardwire constant ID numbers in their application. Who does that?  If library authors do that, then the numbers are bound to collide sooner or later.

Until recently the usual way to bind events in C++ wxWidgets is to use the static event table, which means static IDs are needed. (Dynamically binding handers is becoming more popular now, thanks in part to wxPython's example with our Bind()). Duplicate IDs only really becomes a problem when the widgets with that ID are in the same containment hierarchy, and the events for those widgets are being caught in a common ancestor instead of within the widget itself or its immediate parent. That means that even with static IDs it is not a problem in something like 95% or better of the cases.
 


The deprecation notice says:
> Deprecated: Ids generated by it can conflict with the Ids defined by the user code

But wx.NewId is the *solution* to that problem, not the cause of it.  The solution to the problem of hardwired constant ID numbers is to stop hardwiring constant ID numbers.

Monkeypatching wx is no good, because to avoid collisions everyone must use the same mechanism to allocate numbers, and if I make my own allocation function for my own private use, then that is not the case.

But there are also potential conflicts with wxNewId because anything that uses wx.ID_ANY to allow wx to allocate the ID will be using NewControlId instead of wxNewId

 

Before I go on a mass editing spree to replace wx.NewId, can you confirm that wx.Window.NewControlId is the proper replacement?

It is. It uses an internal management class to reserve IDs when used and release them when the widget is destroyed, so even if the internal counter wraps around those IDs that are still active will not be reused.

--
Robin

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: wxPython 4.0.2

Robin Dunn
On Tuesday, June 19, 2018 at 11:59:10 AM UTC-7, Marco Prosperi wrote:

hello, in the process of managing NewId deprecation warnings, replacing them with other code, I would like to silent these warnings in production code. In another thread a couple of days ago, before wxpython 4.0.2, I ended up with this solution:

if main_is_frozen():
    with warnings.catch_warnings():
        warnings.simplefilter('ignore')
        #warnings.filterwarnings('ignore')
        run()
else:
    run()

Unfortunately NewId deprecation warning by pass this filters. What could be used instead?


Is that code before or after the import of wx? There is `warnings.simplefilter('default', wxPyDeprecationWarning)` happening in the wx module which could be overriding your 'ignore'.

--
Robin


--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: wxPython 4.0.2

Anders Munch
In reply to this post by Robin Dunn
Robin Dunn:
> That means that even with static IDs it is not a problem in something like 95% or better of the cases.

95% is not really an impressive number in this context.

> But there are also potential conflicts with wxNewId because anything that uses wx.ID_ANY to allow wx to allocate the ID will be using NewControlId instead of wxNewId

I would call that an implementation bug in wx.NewId.  It had one job: To return a unique value.  Or, seeing as NewId was there first, maybe the bug is in NewControlId.
May I suggest an alternate implementation of wx.NewId, just one single line in core.py that goes:

NewId = Window.NewControlId

regards, Anders

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: wxPython 4.0.2

Marco Prosperi
In reply to this post by Robin Dunn



Is that code before or after the import of wx? There is `warnings.simplefilter('default', wxPyDeprecationWarning)` happening in the wx module which could be overriding your 'ignore'.


In run() I create the main Frame and create main loop. NewId warnings show up if import wx at the top of the script, outside of everything, but also if I import it in run function. I've tried to reduce everything to a simple app (attached) to understand better. In this case NewId warnings are never shown, even if I don't filter them! Can't understand
python 3.5,win10,wxpython 4.0.2
 
--
Robin


--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.

wxsample.py (438 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: wxPython 4.0.2

Robin Dunn
In reply to this post by Anders Munch


On Wednesday, June 20, 2018 at 6:43:35 AM UTC-7, Anders Munch wrote:
Robin Dunn:
> That means that even with static IDs it is not a problem in something like 95% or better of the cases.

95% is not really an impressive number in this context.

I was being very conservative. I expect that it's much higher than that.

--
Robin


--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: wxPython 4.0.2

efahl
In reply to this post by Robin Dunn

On Tuesday, June 19, 2018 at 9:47:10 AM UTC-7, Robin Dunn wrote:
Before I go on a mass editing spree to replace wx.NewId, can you confirm that wx.Window.NewControlId is the proper replacement?

It is. It uses an internal management class to reserve IDs when used and release them when the widget is destroyed, so even if the internal counter wraps around those IDs that are still active will not be reused.

NewControlId values being deallocated automatically when the widget is destroyed gives rise to a new problem.  In my context menus, I have some fixed entries ("Expand all" on a tree, for instance).  I keep a data structure, including the id, around and use that when creating the popup menu.  Works great the first time the context menu is built, but the second time I get the error below.  Seems I need some static ids outside the range controlled by the IdManager.  How do I generate those without collisions?

   lm/gui/contextMenu.py 865 in addToMenu:
      0865              item = wx.MenuItem(menu, self.id, self.text, kind=kind)
wxAssertionError: C++ assertion "gs_autoIdsRefCount[winid] != ID_FREE" failed at ..\..\src\common\windowid.cpp(146) in `anonymous-namespace'::DecIdRefCount(): id count already 0
 

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: wxPython 4.0.2

Robin Dunn
On Wednesday, June 20, 2018 at 5:23:47 PM UTC-7, efahl wrote:

On Tuesday, June 19, 2018 at 9:47:10 AM UTC-7, Robin Dunn wrote:
Before I go on a mass editing spree to replace wx.NewId, can you confirm that wx.Window.NewControlId is the proper replacement?

It is. It uses an internal management class to reserve IDs when used and release them when the widget is destroyed, so even if the internal counter wraps around those IDs that are still active will not be reused.

NewControlId values being deallocated automatically when the widget is destroyed gives rise to a new problem.  In my context menus, I have some fixed entries ("Expand all" on a tree, for instance).  I keep a data structure, including the id, around and use that when creating the popup menu.  Works great the first time the context menu is built, but the second time I get the error below.  Seems I need some static ids outside the range controlled by the IdManager.  How do I generate those without collisions?


I guess I need to wrap wxIdManager.

--
Robin

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: wxPython 4.0.2

efahl


On Wednesday, June 20, 2018 at 6:46:58 PM UTC-7, Robin Dunn wrote:
On Wednesday, June 20, 2018 at 5:23:47 PM UTC-7, efahl wrote:
NewControlId values being deallocated automatically when the widget is destroyed gives rise to a new problem.  In my context menus, I have some fixed entries ("Expand all" on a tree, for instance).  I keep a data structure, including the id, around and use that when creating the popup menu.  Works great the first time the context menu is built, but the second time I get the error below.  Seems I need some static ids outside the range controlled by the IdManager.  How do I generate those without collisions?

I guess I need to wrap wxIdManager.
 
But looking at the wxIdManager's interface, it doesn't appear to offer that functionality?  It would need something like a StaticControlId() method to produced values that are not put into the ref counted pool.  Or will your envisioned wrapper add a "don't deallocate" option and re-increment the ref count or something like that?

My current solution is to replace only those problematic NewControlId calls with this...  (I only have a couple dozen, so I don't think I'll run out of space.)

@staticvariable(next=wx.ID_HIGHEST)
def StaticId():
    StaticId.next += 1
    return StaticId.next 

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: wxPython 4.0.2

Anders Munch
In reply to this post by Robin Dunn
Robin Dunn:
>>> That means that even with static IDs it is not a problem in something like 95% or better of the cases.
>>95% is not really an impressive number in this context.
>I was being very conservative. I expect that it's much higher than that.

I would have said the same thing about 99.99%. The higher the number, the more obscure and hard to track down the bug will be when it finally does hit you.

Thank you for having championed a better way.

regards, Anders

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: wxPython 4.0.2

Anders Munch
In reply to this post by Robin Dunn
Robin Dunn:
> efahl:
>> NewControlId values being deallocated automatically when the widget is destroyed gives rise to a new problem. 

Wait, how does that work? NewControlId is a staticmethod, so how can any widget being destroyed deallocate it?

regards, Anders

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: wxPython 4.0.2

Robin Dunn
On Thursday, June 21, 2018 at 12:14:14 AM UTC-7, Anders Munch wrote:
Robin Dunn:
> efahl:
>> NewControlId values being deallocated automatically when the widget is destroyed gives rise to a new problem. 

Wait, how does that work? NewControlId is a staticmethod, so how can any widget being destroyed deallocate it?


It uses wxIdManager, which has methods for reserving and unreserving IDs. When the widget is destroyed it calls the unreserve method and the manager determines if it is one that it has allocated and makes it available again.

--
Robin
 

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: wxPython 4.0.2

Robin Dunn
In reply to this post by efahl
On Wednesday, June 20, 2018 at 7:30:42 PM UTC-7, efahl wrote:


On Wednesday, June 20, 2018 at 6:46:58 PM UTC-7, Robin Dunn wrote:
On Wednesday, June 20, 2018 at 5:23:47 PM UTC-7, efahl wrote:
NewControlId values being deallocated automatically when the widget is destroyed gives rise to a new problem.  In my context menus, I have some fixed entries ("Expand all" on a tree, for instance).  I keep a data structure, including the id, around and use that when creating the popup menu.  Works great the first time the context menu is built, but the second time I get the error below.  Seems I need some static ids outside the range controlled by the IdManager.  How do I generate those without collisions?

I guess I need to wrap wxIdManager.
 
But looking at the wxIdManager's interface, it doesn't appear to offer that functionality?  It would need something like a StaticControlId() method to produced values that are not put into the ref counted pool.  Or will your envisioned wrapper add a "don't deallocate" option and re-increment the ref count or something like that?


There is another class that is not documented which is used by the widgets to auto unreserve the IDs. I may have to do something with that. We'll see how it goes.

 --
Robin

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: wxPython 4.0.2

efahl
In reply to this post by Anders Munch
On Thursday, June 21, 2018 at 12:14:14 AM UTC-7, Anders Munch wrote:
Robin Dunn:
> efahl:
>> NewControlId values being deallocated automatically when the widget is destroyed gives rise to a new problem. 

Wait, how does that work? NewControlId is a staticmethod, so how can any widget being destroyed deallocate it?

What Robin said.  Here's a concrete example (off the top of my head, so bugs++, but you should get the idea).

id = wx.Window.NewControlId() 
item = wx.MenuItem(..., id=id, ...)
menu.Append(item)
window.PopupMenu(menu)
# 'item' is destroyed when the popup is torn down, and 'id' is automagically passed to wx.IdManager.UnreserveId at that time

--
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 [hidden email].
For more options, visit https://groups.google.com/d/optout.
12