subject:"wxpython"



Change by admin :


___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue210668] Python1.6 and wxPython incompatibility (PR#366)



Change by admin :


___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue213145] config.h defines socklen_t, kills wxPython build



Change by admin :


--
github: None -> 33016

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue210668] Python1.6 and wxPython incompatibility (PR#366)



Change by admin :


--
github: None -> 32738

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42805] broken pygame integration into wxpython

2021-01-01 Thread monchy



monchy  added the comment:

The only thing I changed was the version of python I was using, which means
that whatever caused the problem was python itself
if something was changed in how the interpreter operates the environmental
variables or something then that might do it
PYTHON broke MY software, so this and this alone is the appropriate bug
tracker

On Fri, 1 Jan 2021 at 15:54, Serhiy Storchaka 
wrote:

>
> Serhiy Storchaka  added the comment:
>
> Pygame and wxpython are not parts of the stdlib. Please use an appropriate
> bug tracker.
>
> --
> nosy: +serhiy.storchaka
> resolution:  -> third party
> stage:  -> resolved
> status: open -> closed
>
> ___
> Python tracker 
> <https://bugs.python.org/issue42805>
> ___
>

--

___
Python tracker 
<https://bugs.python.org/issue42805>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42805] broken pygame integration into wxpython

2021-01-01 Thread Serhiy Storchaka



Serhiy Storchaka  added the comment:

Pygame and wxpython are not parts of the stdlib. Please use an appropriate bug 
tracker.

--
nosy: +serhiy.storchaka
resolution:  -> third party
stage:  -> resolved
status: open -> closed

___
Python tracker 
<https://bugs.python.org/issue42805>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue42805] broken pygame integration into wxpython

2021-01-01 Thread monchy



New submission from monchy :

in previous python verions a pygame window could be embedded into wxpython by 
assigning the SDL_WINDOWID to the current wx.Panel.GetHandle() and the 
SDL_VIDEODRIVER to 'windib' before importing python
the same code creates a separate pygame window in the newest python version
a basic implementation can be found here:
https://github.com/Monchytales/Puppet-Theatre/blob/main/pygame_panel.py

--
messages: 384203
nosy: MonchyTales
priority: normal
severity: normal
status: open
title: broken pygame integration into wxpython
type: behavior
versions: Python 3.9

___
Python tracker 
<https://bugs.python.org/issue42805>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

ANN: wxPython 4.1.1

2020-11-25 Thread Robin Dunn


Announcing wxPython 4.1.1
=

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

New and improved in this release:

* This should have been mentioned in the notes for the last release,
  but alas, it wandered away and got lost. wxWidgets is now validating
  the flags passed when adding items to a sizer, to ensure that they
  are the correct flags for the type of the sizer. If the given flags
  do not make sense, for example using horizontal alignment flags in a
  horizontal box sizer, then a wxAssertionError error is raised.

* Fixed missing binder for wxEVT_STC_AUTOCOMP_SELECTION_CHANGE. (#1613)

* DataViewModel.HasValue can be overridden and will inform the
  DataViewCtrl whether or not an item and column has data. If HasValue
  returns False, then GetValue for that item/col will not be called.
  This allows a distinction between a truly empty cell, and one that
  has a value even if it is an empty string. (#1600)

* Added flag that allows blocking of item dragging in the
  UltimateListControl class. (PR#1620)

* Add the column index to notification events in UltimateListControl
  (PR#1630)

* Added orientation parameter to UltimateListControl.GetScrollPos.
  (PR#1632)

* wx.lib.agw.aui.AuiNotebook RemovePage() now hides the removed page,
  so it needs to be shown again if it is reused in another place.
  (PR#1668)

* Fixed issue that could modify `bytes` objects under Python. (PR#1680)

* Added wx.lib.agw.aui.EVT_AUI_PANE_CLOSE event which is sent when a
  AUI (the agw version) Pane has been closed (after it has been
  closed, not when it is about to be closed, which is when
  EVT_AUI_PANE_CLOSE is sent.) (PR#1628)

* Exposed the wx.DC methods GetGraphicsContext and SetGraphicsContext.
  Depending on the platform and the type of the DC, there may be a
  wx.GraphicsContext used for the implementation of the DC. If so, the
  GetGraphicsContext method enables access to it. Be sure to check
  that the return value is not None before trying to use it.

* Simplified the implementation of the wx.App.InitLocale method. See the
  MigrationGuide for more information.

* Added wx.lib.agw.aui.AUI_DOCKART_HINT_WINDOW_BORDER_COLOUR constant
  so the hint window border color can be themed as well.

* The wx.lib.mixins.listCtrl.CheckListCtrlMixin is now obsolete
  because wx.ListCtrl has new functionality which does pretty much the
  same thing. In fact there is some overlap in method names which may
  trip up some use cases. It is advised to drop the use of
  CheckListCtrlMixin and just use the wx.ListBox functionality. You
  will need to call EnableCheckBoxes to turn it on, and you may need
  to change some event handlers or overloaded methods.

* wx.html2.WebView is now able to use Microsoft's Edge browser
  component as its backend renderer. This should improve the
  capabilities of the WebView widget on Windows, and be more
  consistent with the WebViews on the other platforms, compared to the
  original IE 11 backend. Using this backed requires that a new-ish
  version of the Edge browser is installed on the end user's computer.

* Added the wx.Image.ConvertToRegion method. This lets you create a
  wx.Region from an image and a specified color or the mask if the
  image has one. This was done to workaround a bug in wxMac, but it
  seems worthwhile enough to keep it around even after the bug was
  fixed.

* Added the missing context manager methods for wx.LogNull. (#1842)

* Refactored ScrolledThumbnail out of agw.ThumbnailCtrl so as to be
  usable outside of ThumbnailCtrl.




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

wxpython-OGL fails to render objects with Python-3

2020-09-17 Thread Frank Miles

I have a substantial wxpython-based application that I'm trying to port from 
python-2 to -3.  
Almost everything is working properly, except for a few small but important 
sections that use 
the OGL library.  That executes without any exceptions, but the objects created 
within the 
diagram/canvas/panel are invisible!  {sometimes they are visible for a small 
fraction of a 
second}.  This occurs on Windows-10 and on Linux(Debian) systems.  The colored 
background and
buttons render just fine, the buttons do what they should, but no objects 
appear on the
background (again, only with Py3, Py2 works properly).

I have cut the code to a pretty minimum set and will attempt to paste it to the 
bottom of 
this message in the hope that it will encourage one of you to see what the 
problem might be.
Alternatively if anyone knows of an example that works with Python-3 I'd be 
delighted to 
learn of it.

Thanks for any insights!!

# -
#   togl.py test 'OGL' shape system.

from __future__ import print_function

import  sys
if 2 == sys.version_info.major :
import wxversion
import  wx
import  random
import  wx.lib.ogl as ogllib

NOMSIZE=80
WINSIZE=400
N_ITEMS=7
shapeTypes= ( 'rect', 'circle', 'rndRect' )

class ShapeGraphicWindow(ogllib.ShapeCanvas):
def __init__(self, parent):
ogllib.ShapeCanvas.__init__(self, parent)
self.diagram= ogllib.Diagram()
self.SetDiagram(self.diagram)
self.diagram.SetCanvas(self)
self.SetBackgroundColour(wx.BLUE)
def addShape(self, shape_type, title) :
if 'rect' == shape_type : # rectangle
shape= ogllib.RectangleShape(50, 35)
brush= wx.Brush(wx.TheColourDatabase.Find("RED"), wx.SOLID)
elif 'circle' == shape_type : # circle
shape= ogllib.CircleShape(65)
brush= wx.Brush(wx.TheColourDatabase.Find("YELLOW"), wx.SOLID)
elif 'rndRect' == shape_type : # rounded-rectangle
shape= ogllib.RectangleShape(45, 30)
shape.SetCornerRadius(-0.3)
brush= wx.Brush(wx.TheColourDatabase.Find("GOLDENROD"), wx.SOLID)
else :
raise AssertionError("Unable to add shape: %s : 
%s",(shape_type,title))
shape.SetBrush( brush )
x= int(random.uniform(NOMSIZE,WINSIZE-NOMSIZE))
shape.SetX(x)
y= int(random.uniform(NOMSIZE,WINSIZE-NOMSIZE))
shape.SetY(y)
shape.AddText(title)
print("Draw",title,"at location ", (x,y), "on canvas of size", 
self.GetSize())
shape.SetCanvas(self)
self.AddShape(shape)
self.Refresh()
shape.Show(True)
return

class TestPanel(wx.Panel):
def __init__(self, frame) :
wx.Panel.__init__(self, parent=frame)
self.objcnts= (0,N_ITEMS)
sz= wx.BoxSizer(wx.VERTICAL)
hsz= wx.BoxSizer(wx.HORIZONTAL)
btnq= wx.Button(self, -1, "Quit")
btnq.Bind(wx.EVT_BUTTON, self.Quit)
hsz.Add(btnq, 0, wx.ALL, 3)
btnq= wx.Button(self, -1, "AutoTest")
btnq.Bind(wx.EVT_BUTTON, self.AutoTest)
hsz.Add(btnq, 0, wx.ALL, 3)
sz.Add(hsz, 0, wx.ALIGN_LEFT)
self.shp_graph_win= ShapeGraphicWindow(self)
sz.Add(self.shp_graph_win, 2, wx.EXPAND)
self.SetSizer(sz)
#self.Layout()
#self.Fit()
self.SetAutoLayout(True)
def mkTitle(self, index) :
return ''.join([ chr(index + ord('A')), ":", str(index) ])
def AutoTest(self, event=None) :
for j in range(*(self.objcnts)) :
self.shp_graph_win.addShape(shapeTypes[j % len(shapeTypes)], 
self.mkTitle(j))
self.objcnts= (self.objcnts[1], self.objcnts[1]+N_ITEMS)
def Quit(self, event) :
self.Destroy()
sys.exit(0)

class TestFrame(wx.Frame):
def __init__(self) :
wx.Frame.__init__(self, None, -1, "test basic OGL functionality",
size= wx.Size(WINSIZE,WINSIZE) )
TestPanel(self)
self.Show(True)

app = wx.App(False)
frame = TestFrame()
ogllib.OGLInitialize()
app.MainLoop()
sys.exit(0)
-- 
https://mail.python.org/mailman/listinfo/python-list

ANNOUNCE: wxPython 4.1.0

2020-04-24 Thread Robin Dunn


Announcing wxPython 4.1.0
=

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

Starting with this release wxPython has switched to tracking the
wxWidgets master branch (version 3.1.x) for the wxWidgets source code,
which wxPython is built upon, and which is included in the wxPython
source archives.

This will be the last release to include binaries for Python 2.7. The
code will likely still compile and be compatible with Python 2.7 for
some time, but no effort will be put into keeping it that way.


New and improved in this release:

* Add a sample for wx.Font.AddPrivateFont to the demo.

* Added wrappers for the OSXEnableAutomaticQuoteSubstitution,
  OSXEnableAutomaticDashSubstitution, and
  OSXDisableAllSmartSubstitutions methods in wx.TextCtrl. Also added
  OSXEnableAutomaticTabbing in wx.App.

* Added wx.ColourDialogEvent, wx.DCTextBgColourChanger,
  wx.DCTextBgModeChanger, wx.grid.GridCellDateRenderer,
  wx.grid.GridCellDateEditor, wx.SystemAppearance, etc.

* Many of the deprecated items in wxWidgets and wxPython are being or
  have been removed. Be sure to test your code in a recent 4.0.x
  release with warnings enabled so you can see which class, method or
  function calls you need to change.

* Bug fixes in wx.lib.calendar: key navigation across month boundaries
  is now possible; key navigation now sets the date and fires the
  EVT_CALENDAR event; setter APIs now set the date correctly (#1230).

* Switch to using a wx.Overlay in the Widget Inspection Tool to
  highlight widgets when running on a GTK3 port.

* Fixed issue in wx.lib.agw.customtreectrl where the label editor
  could remain stuck forever (#1235).

* Grafted on a EnableSystemTheme method to the classes which support
  it. This can be used to disable the default system theme on Windows
  for native widgets like wx.ListCtrl, wx.TreeCtrl and
  wx.dataview.DataViewCtrl. It has no effect on the other platforms.

* The wx.WS_EX_VALIDATE_RECURSIVELY extended style flag is obsolete,
  as it is now the default (and only) behavior. The style flag has
  been added back into wxPython for compatibility, but with a zero
  value. You can just stop using it in your code with no change in
  behavior. (#1278)

* Fix a sometimes crash when using a wx.Overlay by letting the
  wx.DCOverlay hold a reference to the DC, to ensure that the
  DCOverlay is destroyed first.  (PR#1301)

* Replaced the Vagrant VMs used for building wxPython for various
  Linux distros with Docker images.

* Add some missing methods in wx.adv.BitmapComboBox (#1307)

* Added the wx.svg package which contains code for parsing SVG
  (Scalable Vector Graphics) files, and also code for integrating with
  wxPython. It can rasterize the SVG to a wx.Bitmap of any size with
  no loss of quality, and it can also render the SVG directly to a
  wx.GraphicsContext using the GC's drawing primitives. (PR #1323)

* Ported the embedding sample from Classic, which shows how to use
  wxPython from a C++ wxWidgets application that embeds Python. (PR
  #1353)

* Fixed wx.GetApp() to use wxWidgets' global wxApp instance instead of
  maintaining its own pointer. This way, if the wxApp is created by
  C++ code wxPython will still be able to get access to it. (#1126)

* Added wrappers for the wx.ActivityIndicator class.

* Added wrappers for the wx.CollapsibleHeaderCtrl class.

* Fixed issues in PlotCanvas around displaying and using
  scrollbars. (#1428)

* Added wx.msw.CHMHelpController, and also a wx.HelpController factory
  function that creates an instance of the best Help Controller for
  the platform. (#1536)

* Added wx.adv.GenericAnimationCtrl so the generic version of the
  animation classes can be used even on the platforms that have a
  native version. Note that due to internal changes to support both
  types of animations, some API changes in how the Animation objects
  are created. See the AnimationCtrl.py sample in the demo for the
  various usage patterns (#1579)

* Added wrappers for the wx.grid.GridBlockCoords, wx.grid.GridBlocks,
  and wx.grid.GridBlockDiffResult classes, as well as associated new
  methods in the wx.grid.Grid class. These provide a new way to
  interact with blocks of selected cells, including an iterator
  interface in wx.grid.GridBlocks which should be a more efficient
  (time and memory) way to process large groups of selections.




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

wxPython 4.0.7 released

2019-10-26 Thread Robin Dunn


Announcing wxPython 4.0.7
=

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

This release is comprised mostly of fixes and minor features
which have been back-ported from the master branch. This release
is likely the last release of the 4.0.x release series, and is
certainly the last 4.0.x release that will support Python 2.7. It
may still continue to build for Python 2.7 for some time, but no
extra effort will be expended to keep it compatible.

Support for building for Python 3.8 has been added, as well as
3.8 binaries on PyPI for Windows and MacOS.

This release provides the following changes:

* Bug fixes in wx.lib.calendar: key navigation across month
  boundaries is now possible; key navigation now sets the date
  and fires the EVT_CALENDAR event; setter APIs now set the date
  correctly (#1230).

* Switch to using a wx.Overlay in the Widget Inspection Tool to
  highlight widgets when running on a GTK3 port.

* Fixed issue in wx.lib.agw.customtreectrl where label editor
  could remain stuck forever (#1235).

* Fix a sometimes crash when using a wx.Overlay by letting the
  wx.DCOverlay hold a reference to the DC, to ensure that the
  DCOverlay is destroyed first.  (PR#1301)

* Ported the embedding sample from Classic, which shows how to
  use wxPython from a C++ wxWidgets application that embeds
  Python. (PR #1353)

* Fixed wx.GetApp() to use wxWidgets' global wxApp instance
  instead of maintaining its own pointer. This way, if the wxApp
  is created by C++ code wxPython will still be able to get
  access to it. (#1126)

* Several other PRs have been backported from the master branch
  (which will become wxPython 4.1.0), the full list can be seen
  here: https://github.com/wxWidgets/Phoenix/pull/1357
--
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-le...@python.org
https://mail.python.org/mailman3/lists/python-announce-list.python.org/

   Support the Python Software Foundation:
   http://www.python.org/psf/donations/

ANNOUNCE wxPython 4.0.6

2019-05-24 Thread Robin Dunn



Announcing wxPython 4.0.6
=

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

This is a quick-fix release to take care of the following issues:

* Fixed a probably rare, but fatal bug on OSX when calling certain
  overloaded virtual methods with implementations in Python.

* Fixed char pointers in generated stub code to have a valid
  pointer value.

* Reverted the change that loads up install_requires from the
  contents of requirements.txt. Split the requirements.txt file
  into one for install and one for development.



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
--
https://mail.python.org/mailman/listinfo/python-announce-list

   Support the Python Software Foundation:
   http://www.python.org/psf/donations/

ANNOUNCE: wxPython 4.0.5

2019-05-24 Thread Robin Dunn




Announcing wxPython 4.0.5
=

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

Changes in this release include the following:


* Added missing HtmlWindow.ScrollToAnchor method, and also a couple
  methods in HtmlCell too. (#1141)

* Added missing setters for the wheel-related properties in
  wx.MouseEvent.  (#1140)

* Updated wxWidgets commit reference, bringing fixes for #1140, #1086
  and #1147.

* Fix the use of the output parameter in HtmlWindow.OnOpeningURL the
  same way it was fixed in
  HtmlWindowInterface.OnHTMLOpeningURL. (#1068)

* Fixed a crashing bug when using a member of a transient
  wx.VisualAttributes object. Also set the attributes to be read-only
  to simplify the fix. (#1198).

* Updated the sip being used in wxPython builds to version 4.19.16.

* Added helper functions to check results of wxWidgets configure
  during the build of wxPython. Currently used to determine if the wx
  webview, glcanvas, and media libraries should be added to the link
  command. (#1138)

* Fixed scrollbar issue with ListCtrlAutoWidthMixin (#1215)

* Fixed file access in the wx.py and wx.tools.pywxrc packages to be
  Python 2 and 3 compatible. (#1193, #1156)

* Fixes for building with Python 3.8 on Linux. (#1227)


Have fun!

--
Robin Dunn
Software Craftsman
http://wxPython.org
--
https://mail.python.org/mailman/listinfo/python-announce-list

   Support the Python Software Foundation:
   http://www.python.org/psf/donations/

Re: ANN: Creating GUI Applications with wxPython

2019-02-27 Thread Dietmar Schwertberger


On 27.02.2019 20:34, Dan Sommers wrote:

What is a "network widget" in this context?  Application
users don't usually interact with "the network" directly,
and networks are usually on the opposite end of applications
from the GUI.  What would your hypothetical network widget
do?  What cross-platform differences would it abstract/hide?
What do your applications do to/with/against "the network"?


Probably an integration of sockets with the main loop to allow for 
asynchroneous communication.
Qt has a socket class that will deliver events when data is received or 
transmitted. It's a long time that I had a look at this, but I think 
it's available from PyQt as well.
Alternatively, I have successfully used Quamash, which is an integration 
of the Qt event loop with asyncio.


For new projects, I would always recommend to use asyncio as this is 
available in the standard library.


For wxPython there is some code to integrate with asyncio, but I have 
never used this myself.


Alternatively, the communication can always be placed into a separate 
thread, posting events to the main application / frontend.


Regards,

Dietmar

--
https://mail.python.org/mailman/listinfo/python-list

Re: ANN: Creating GUI Applications with wxPython

2019-02-27 Thread Michael Torrie

On 02/27/2019 10:59 AM, Igor Korot wrote:
> Hopefully with the wxQt having more and more development we might have
> a wxQt/Android port getting attention.

I don't think Qt has any plans to support Android with the traditional
Qt framework.  They've instead focused on their next generation system,
which is QtQuick.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: ANN: Creating GUI Applications with wxPython

2019-02-27 Thread Dan Sommers


On 2/27/19 9:37 AM, Dave wrote:


I have two Python 3 (3.6) apps that will get the full GUI treatment very
soon.  I'm in the process of choosing a GUI, and that may be where
you/your book can help.  Seems this is not a trivial effort (wishing
that Python was like VB6 from the 90's).

Anyway, here is what I am looking for - hopefully it helps guide you.




   A network widget may also be good.


What is a "network widget" in this context?  Application
users don't usually interact with "the network" directly,
and networks are usually on the opposite end of applications
from the GUI.  What would your hypothetical network widget
do?  What cross-platform differences would it abstract/hide?
What do your applications do to/with/against "the network"?
--
https://mail.python.org/mailman/listinfo/python-list

Re: ANN: Creating GUI Applications with wxPython

2019-02-27 Thread Michael Torrie

On 02/27/2019 11:36 AM, Karsten Hilbert wrote:
> On Wed, Feb 27, 2019 at 10:38:25AM -0500, Dave wrote:
> 
>> * GUI relatively easy to understand and implement.  easyGUI is truly easy in
>> all areas, but fails some of my other requirements.  The QT/PyQT/PySide2
>> situation is a mess - which one to use, why, any implementation differences,
>> etc.
> 
> Python has been made a first-tier supported language in Qt
> just recently if I understood the news correctly. So, PySide2.

Except PySide2 doesn't yet support all of the core Qt class API, such as
QtSerialPort.  Of course there's PySerial in PyPi, but that's not
integrated with the Qt main loop.  So for me it's PyQt, but hoping
PySide2 will catch up eventually.  Other than missing bits, with a small
wrapper module I wrote, it's actually quite trivial to make code that
works without change on PyQt or PySide2.

So it's not the mess that Dave makes it out to be.  Back in PySide days,
I found a couple of occasions where references to C++ objects would be
dropped, causing segfaults.  This was due to an impedance mismatch
between Python and C++ in terms of references and object lifecycles.
Haven't encountered that in PySide2 though.

>> * Performance is very good.  Users hate to wait - for anything!
> 
> That's rarely a concern in chosing a GUI toolkit.

Agreed. Waiting isn't because the UI doesn't have good performance. It's
because you blocked the main loop.  Learn how to work with your UI
framework's event loop and you won't have this problem.
>> * Lots of widgets!  I'll need a spreadsheet-like widget, a form widget to
>> enter information on parts, activities, etc., splash screen that the code
>> can talk to while the app is loading, and the big one - a cross-platform
>> printer widget that works with Windows and Mac/Unix/CUPS.  A network widget
>> may also be good.
> 
> Usable built-in printer support (and "network widget would be
> good") takes wxPython out of the equation.

wxWidgets does seem to have a wide variety of third-party widgets for
doing all kinds of things like Dave wants, but how much of that is
exposed via Python wrappers?

> Karsten
> PS: Myself using wxPython, so no bashing there.

The future of Qt is QtQuick, and the advantage of it is that whatever
fancy visualization widgets come along, they will be exposed to all
language bindings without any special wrappers. The downside for me is
the heavy use of Javascript for UI logic and event handling.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: ANN: Creating GUI Applications with wxPython

2019-02-27 Thread Dietmar Schwertberger


On 27.02.2019 16:10, Dave wrote:
I have two Python 3 (3.6) apps that will get the full GUI treatment 
very soon.  I'm in the process of choosing a GUI, and that may be 
where you/your book can help.  Seems this is not a trivial effort 
(wishing that Python was like VB6 from the 90's).


IMHO what comes closest to VB6 is wxPython with wxGlade. The focus of 
wxGlade is on frames and dialogs with standard widgets, though. Graphics 
and printing is always a bit more effort.


Regards,

Dietmar

--
https://mail.python.org/mailman/listinfo/python-list

Re: ANN: Creating GUI Applications with wxPython

2019-02-27 Thread Karsten Hilbert

On Wed, Feb 27, 2019 at 10:38:25AM -0500, Dave wrote:

> * GUI relatively easy to understand and implement.  easyGUI is truly easy in
> all areas, but fails some of my other requirements.  The QT/PyQT/PySide2
> situation is a mess - which one to use, why, any implementation differences,
> etc.

Python has been made a first-tier supported language in Qt
just recently if I understood the news correctly. So, PySide2.

> * Performance is very good.  Users hate to wait - for anything!

That's rarely a concern in chosing a GUI toolkit.

> * Lots of widgets!  I'll need a spreadsheet-like widget, a form widget to
> enter information on parts, activities, etc., splash screen that the code
> can talk to while the app is loading, and the big one - a cross-platform
> printer widget that works with Windows and Mac/Unix/CUPS.  A network widget
> may also be good.

Usable built-in printer support (and "network widget would be
good") takes wxPython out of the equation.

Karsten
PS: Myself using wxPython, so no bashing there.
-- 
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: ANN: Creating GUI Applications with wxPython

2019-02-27 Thread Igor Korot

Hi,
On Wed, Feb 27, 2019 at 10:53 AM Dave  wrote:
>
> On 2/27/19 11:38 AM, Rhodri James wrote:
> > On 27/02/2019 15:37, Dave wrote:
> >> * GUI must support all desktops with a native look and feel.  Kivy
> >> fails this one.  Will have mobile apps later in the year, so it would
> >> be nice if one GUI fits all, but am ok with 2 gui's if needed.
> >
> > This requirement will cause you endless pain, particularly when mobiles
> > enter the picture.  I'm not convinced it's a completely good idea; a
> > sensible UI for a desktop probably won't be sensible for a phone and
> > vice versa
> >
>
> Agreed - that is why I'm open to two GUI kits.

It is not about the toolkit, but more about the design.
If something works properly on the desktop, there is no guarantee it will look
sensible and normal on the mobile device.
Besides UI guidelines for Android/iOS are very different than for the desktop
application.

Hopefully with the wxQt having more and more development we might have
a wxQt/Android port getting attention.

Thank you.

>
> Dave
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: ANN: Creating GUI Applications with wxPython


On 2/27/19 11:38 AM, Rhodri James wrote:

On 27/02/2019 15:37, Dave wrote:
* GUI must support all desktops with a native look and feel.  Kivy 
fails this one.  Will have mobile apps later in the year, so it would 
be nice if one GUI fits all, but am ok with 2 gui's if needed.


This requirement will cause you endless pain, particularly when mobiles 
enter the picture.  I'm not convinced it's a completely good idea; a 
sensible UI for a desktop probably won't be sensible for a phone and 
vice versa




Agreed - that is why I'm open to two GUI kits.

Dave
--
https://mail.python.org/mailman/listinfo/python-list

Re: ANN: Creating GUI Applications with wxPython

2019-02-27 Thread Rhodri James


On 27/02/2019 15:37, Dave wrote:
* GUI must support all desktops with a native look and feel.  Kivy fails 
this one.  Will have mobile apps later in the year, so it would be nice 
if one GUI fits all, but am ok with 2 gui's if needed.


This requirement will cause you endless pain, particularly when mobiles 
enter the picture.  I'm not convinced it's a completely good idea; a 
sensible UI for a desktop probably won't be sensible for a phone and 
vice versa


--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list

Re: ANN: Creating GUI Applications with wxPython

Sorry about the duplicate messages - bad hair day!

Dave,

On 2/27/19 10:38 AM, Dave wrote:

On 1/14/19 2:08 PM, Mike Driscoll wrote:

Hi,

I just thought I would let you all know that I am working on my 2nd
wxPython book, "Creating GUI Applications with wxPython". This one
will be about actually creating small runnable applications instead of
just recipes like my Cookbook did. I hope to have 8-10 working
applications included with the book.

You can read more about it here if you are interested:
https://www.blog.pythonlibrary.org/2019/01/14/creating-gui-applications-with-wxpython-kickstarter/

Feel free to ask me questions about it too.

Thanks,
Mike

Mike,

I have two Python 3 (3.6) apps that will get the full GUI treatment very
soon. I'm in the process of choosing a GUI, and that may be where
you/your book can help. Seems this is not a trivial effort (wishing
that Python was like VB6 from the 90's).

Anyway, here is what I am looking for - hopefully it helps guide you.

* GUI relatively easy to understand and implement. easyGUI is truly
easy in all areas, but fails some of my other requirements. The
QT/PyQT/PySide2 situation is a mess - which one to use, why, any
implementation differences, etc.

* Performance is very good. Users hate to wait - for anything!

* Lots of widgets! I'll need a spreadsheet-like widget, a form widget
to enter information on parts, activities, etc., splash screen that the
code can talk to while the app is loading, and the big one - a
cross-platform printer widget that works with Windows and Mac/Unix/CUPS.
A network widget may also be good.

* A GUI designer may be good. Currently there is Glade for GTK, and
QT-Designer for QT.

* GUI must support all desktops with a native look and feel. Kivy fails
this one. Will have mobile apps later in the year, so it would be nice
if one GUI fits all, but am ok with 2 gui's if needed.

* A great book taking me from beginner to expert.

Dave,

--
https://mail.python.org/mailman/listinfo/python-list

Re: ANN: Creating GUI Applications with wxPython

On 1/14/19 2:08 PM, Mike Driscoll wrote:

Hi,

I just thought I would let you all know that I am working on my 2nd wxPython book,
"Creating GUI Applications with wxPython". This one will be about actually
creating small runnable applications instead of just recipes like my Cookbook did. I hope
to have 8-10 working applications included with the book.

You can read more about it here if you are interested:
https://www.blog.pythonlibrary.org/2019/01/14/creating-gui-applications-with-wxpython-kickstarter/

Feel free to ask me questions about it too.

Thanks,
Mike

Mike,

Anyway, here is what I am looking for - hopefully it helps guide you.

* Performance is very good. Users hate to wait - for anything!

* A GUI designer may be good. Currently there is Glade for GTK, and
QT-Designer for QT.

* GUI must support all desktops with a native look and feel. Kivy fails
this one. Will have mobile apps later in the year, so it would be nice
if one GUI fits all, but am ok with 2 gui's if needed.

* A great book taking me from beginner to expert.

Dave,

--
https://mail.python.org/mailman/listinfo/python-list

Re: ANN: Creating GUI Applications with wxPython

On 1/14/19 2:08 PM, Mike Driscoll wrote:

Hi,

I just thought I would let you all know that I am working on my 2nd wxPython book,
"Creating GUI Applications with wxPython". This one will be about actually
creating small runnable applications instead of just recipes like my Cookbook did. I hope
to have 8-10 working applications included with the book.

You can read more about it here if you are interested:
https://www.blog.pythonlibrary.org/2019/01/14/creating-gui-applications-with-wxpython-kickstarter/

Feel free to ask me questions about it too.

Thanks,
Mike

Mike,

Anyway, here is what I am looking for - hopefully it helps guide you.

* Performance is very good. Users hate to wait - for anything!

* A GUI designer may be good. Currently there is Glade for GTK, and
QT-Designer for QT.

* GUI must support all desktops with a native look and feel. Kivy fails
this one. Will have mobile apps later in the year, so it would be nice
if one GUI fits all, but am ok with 2 gui's if needed.

* A great book taking me from beginner to expert.

Dave,

--
https://mail.python.org/mailman/listinfo/python-list

Re: ANN: Creating GUI Applications with wxPython

On 1/14/19 2:08 PM, Mike Driscoll wrote:

Hi,

I just thought I would let you all know that I am working on my 2nd wxPython book,
"Creating GUI Applications with wxPython". This one will be about actually
creating small runnable applications instead of just recipes like my Cookbook did. I hope
to have 8-10 working applications included with the book.

You can read more about it here if you are interested:
https://www.blog.pythonlibrary.org/2019/01/14/creating-gui-applications-with-wxpython-kickstarter/

Feel free to ask me questions about it too.

Thanks,
Mike

Mike,

Anyway, here is what I am looking for - hopefully it helps guide you.

* Performance is very good. Users hate to wait - for anything!

* GUI must support all desktops with a native look and feel. Kivy fails
this one. Will have mobile apps later in the year, so it would be nice
if one GUI fits all, but am ok with 2 gui's if needed.

* A great book taking me from beginner to expert.

Dave,

--
https://mail.python.org/mailman/listinfo/python-list

ANN: Creating GUI Applications with wxPython

2019-01-14 Thread Mike Driscoll

Hi,

I just thought I would let you all know that I am working on my 2nd wxPython 
book, "Creating GUI Applications with wxPython". This one will be about 
actually creating small runnable applications instead of just recipes like my 
Cookbook did. I hope to have 8-10 working applications included with the book.

You can read more about it here if you are interested: 
https://www.blog.pythonlibrary.org/2019/01/14/creating-gui-applications-with-wxpython-kickstarter/

Feel free to ask me questions about it too.

Thanks,
Mike
-- 
https://mail.python.org/mailman/listinfo/python-list

wxPython 4.0.4

2019-01-07 Thread Robin Dunn



Announcing wxPython 4.0.4
=

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

Changes in this release include the following:

* Fixed an issue where wx.lib.intctrl would erroneously attempt to use
  long on Python3. (#898)

* Include the MSVC runtime DLLs for Python 3.7 builds too.

* Clear LIBPATH_PYEXT and LIB_PYEXT for linux builds too. (#904)

* Added a dependency on the Pillow package since it's used in some
  wx.lib.agw modules. (PR #908)

* Add flag to hide page in wx.lib.agw.aui.notebook. (#895)

* Switch wx.lib.plot to issue deprecation warnings with
  PlotPendingDeprecation so it doesn't have to enable all warnings to
  get them to be shown by default.  (#902)

* Added a Python 3.7 builder on Fedora 28. (#925)

* Fix the object ownership transfer for wx.Menu.Insert() (#931)

* Added wx.Treebook.GetTreeCtrl, wx.Listbook.GetListView and
  wx.Choicebook.GetChoiceCtrl. (#918)

* Removed the wx.BookCtrlBase.RemovePage workaround as it was causing
  problems and doesn't seem to be necessary any more. The existing
  wxWidgets assertions are catching the out of range error just fine,
  however if wxWidgets was built without the debug helpers turned on
  then it could still cause a crash. (#888)

* Reverted the changes which removed the content of the wx.lib.pubsub
  package and encouraged users to switch to the real PyPubSub package
  instead. Removing it caused more issues than were expected so it has
  been restored and the code updated to PyPubSub v3.3.0. Version 4.0.0
  is available upstream, but it is not compatible with Python
  2.7. Now, wx.lib.pubsub is actually deprecated instead of just
  trying to pass control over to the upstream PyPubSub library. (#932)

* Improve calltip stability in pyshell. (#941)

* Fix TypeError in wx.lib.throbber. (#924)

* Fix missing parameter tool_id in
  wx.lib.agw.ribbon.toolbar.RibbonToolBar.AddToggleTool. (#947)

* Add a step to wx.Config.ReadInt to attempt converting from long to
  int under python2. (#384)

* Add virtual behavior for wx.RichTextCtrl and wx.TextCtrl's
  Copy/Cut/Paste methods and their Can* counterparts. (#954)

* Fix IO type in wx.lib.agw.thumbnailctrl (#959)

* Fix type error that would occur using pycolourchooser. (#957)

* Optimize line drawing in HyperTreeList. (#973)

* Add wrapper for wx.StaticBox.GetBordersForSizer and use it in the
  demo to do platform-specific layout of the items in the
  StaticBox. (#974)

* Update wx.Point, wx.RealPoint, and wx.Size to use floating point
  arithmetic when conducting scalar multiplication (#971)

* Fix load/save bugs in PySlices (PR#978)

* Replace deprecated PIL.Image.tostring (PR#1005)

* Fix rendering and mouse sensitivity in UltimateListCtrl when adding
  HyperText items. (#1010)

* Added a parameter to lib.agw.CustomTreeCtrl.SetItemWindow(), to
  allow positioning the Window (a small image) on the left of text in
  a CustomTreeItem. (#PR886).

* Declared DeleteAllPages in the notebook subclasses, so the proper
  C++ implementation will be called. (#972)

* Removed wx.lib.floatbar, which has been deprecated forever and
  probably hasn't been working in nearly as long. (#976)

* Updated SIP to version 4.19.13.

* Fix an issue in wx.lib.agw.aui.AuiManager where the orientation of
  an AuiToolBar would not be updated when calling
  LoadPerspective. (#917)

* Fixed a bug in wx.FileSystemHandler.OpenFile where the object
  ownership was not being transferred correctly, causing a crash after
  a premature object deletion. (#926)

* Fixed wx.ListCtrl.Append when wx.LC_SORT style is used, so appending
  items out of order does not lose the data for the remaining
  columns. (#906)

* Add wx.Accessible, it's Windows-only, will raise a
  NotImplementedError exception on the other platforms. (#958)

* Added the ability to generate stub classes for use when optional
  wxWidgets features are not part of the build. So far, stubs are
  available for wx.Accessible, wx.FileSystemWatcher, wx.glcanvas,
  wx.media and wx.html2.

* Moved the wxpy_api.h file into the wx package at wx/include/wxPython
  so it will be included in the wheel file. (#961)

* Fixed how string data is added to a virtual file-like object in
  wx.MemoryFSHandler. All strings are now added to the file as utf-8
  encoded data, in both Python2 and Python3, and will be read from the
  virtual file the same way. If you need to use some other encoding
  for some reason you can first convert the text to a bytesarray or
  other buffer protocol compatible object and then create the virtual
  file from that data. (#969)

* Performance update for wx.lib.agw.customtreectrl (#1049)

* Ensure that colours set in wx.lib.agw.customtreectrl.TreeItemAttr
  are instances of wx.Colour. (#1032)

* Fix drawing of ticks in wx.lib.agw.speedmeter when there are
  negative bounds values. (#1013)

* wxWidgets for Mac includes the wxJoystick class now

Re: Problems with wxPython _core_.pyd on windows98

2018-08-03 Thread Thomas Jollans


On 02/08/18 18:02, Wanderer wrote:

I have a laptop with windows 98 I use to connect to the OBD2 port on my car. 
I'm trying to install pyobd. I have a build for Python 2.7 for Windows98 that 
works but I'm having trouble with running wxPython. I get the following error.
I'm sure you have your reasons, but of course Windows 98 hasn't been 
supported, by Python, Microsoft, or anybody else, for many years. Are 
you sure it wouldn't be easier to use a newer laptop or install Linux?


Support for Windows 98 was dropped in Python 2.6.


C:\pyobd>python pyobd.py
Traceback (most recent call last):
   File "pyobd.py", line 28, in 
  import wx
   File "C:\Python27\lib\site-packages\wx-3.0-msw\wx\__init__.py", line 45, in 

   from wx_core import *
   File "C:\Python27\lib\site-packages\wx-3.0-msw\wx\_core.py", line4, in 

   import _core_
Import Error: DLL load failed: A device attached to the system is not 
functioning.


So what is going on?

Do these pyd files need to be compiled specifically for win98? If so how do I 
do that? Does python compile these dlls or do I need a C compiler?
If you want to compile extension modules, you need to C compiler Python 
was compiled with. I expect this is Visual C++ 6.0 for the last Win9x 
releases.


Is there an old version of wxPython that will work on windows 98?



--
https://mail.python.org/mailman/listinfo/python-list

Re: Problems with wxPython _core_.pyd on windows98

2018-08-02 Thread Wanderer

On Thursday, August 2, 2018 at 12:03:01 PM UTC-4, Wanderer wrote:
> I have a laptop with windows 98 I use to connect to the OBD2 port on my car. 
> I'm trying to install pyobd. I have a build for Python 2.7 for Windows98 that 
> works but I'm having trouble with running wxPython. I get the following error.
> 
> C:\pyobd>python pyobd.py
> Traceback (most recent call last):
>   File "pyobd.py", line 28, in 
>  import wx
>   File "C:\Python27\lib\site-packages\wx-3.0-msw\wx\__init__.py", line 45, in 
> 
>   from wx_core import *
>   File "C:\Python27\lib\site-packages\wx-3.0-msw\wx\_core.py", line4, in 
> 
>   import _core_
> Import Error: DLL load failed: A device attached to the system is not 
> functioning.
> 
> 
> So what is going on? 
> 
> Do these pyd files need to be compiled specifically for win98? If so how do I 
> do that? Does python compile these dlls or do I need a C compiler? 
> 
> Is there an old version of wxPython that will work on windows 98?
> 
> Thanks

I got it working with
Python 2.5.1
pywin32-207
pyserial 2.4
wxPython2.7

Though I'm still getting a warning
API version mismatch for module win32event. This Python has API version 1013, 
module win32event has version 1012
I don't know what it means.

pyobd.py has bug in it line 354

if "OS" in os.environ.keys() : running windows
 
"OS" is not in os.environ.keys() in windows 98, so I changed "OS" to "WINDIR" 
which is in os environ.keys in windows 98.
-- 
https://mail.python.org/mailman/listinfo/python-list

Problems with wxPython _core_.pyd on windows98

2018-08-02 Thread Wanderer

I have a laptop with windows 98 I use to connect to the OBD2 port on my car. 
I'm trying to install pyobd. I have a build for Python 2.7 for Windows98 that 
works but I'm having trouble with running wxPython. I get the following error.

C:\pyobd>python pyobd.py
Traceback (most recent call last):
  File "pyobd.py", line 28, in 
 import wx
  File "C:\Python27\lib\site-packages\wx-3.0-msw\wx\__init__.py", line 45, in 

  from wx_core import *
  File "C:\Python27\lib\site-packages\wx-3.0-msw\wx\_core.py", line4, in 

  import _core_
Import Error: DLL load failed: A device attached to the system is not 
functioning.


So what is going on? 

Do these pyd files need to be compiled specifically for win98? If so how do I 
do that? Does python compile these dlls or do I need a C compiler? 

Is there an old version of wxPython that will work on windows 98?

Thanks
-- 
https://mail.python.org/mailman/listinfo/python-list

wxPython 4.0.2

2018-06-18 Thread 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

wxPython 4.0.1

2018-02-02 Thread Robin Dunn

Announcing wxPython 4.0.1
=

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

This release is a quick hot-fix of some issues discovered in 4.0.0
just after the release, plus a bit of low-hanging fruit that was easy
to squeeze in too.  Changes in this release include the following:

* A fix for a segfault that happens upon startup on newer linux
  releases. (#648)

* Set LD_RUN_PATH for the wxWidgets part of the build so the wx libs
  that are loaded by other wx libs can be found successfully. (#723)

* Use wxApp::GetInstance to check if there is an existing wxApp
  object. (#720)





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
-- 
https://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations/

wxPython 4.0.0 final

2018-01-31 Thread Robin Dunn


Announcing wxPython 4.0.0
=

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

Changes in this release include the following:

* Fixes in wx.aui to properly transfer ownership of the menubar, and
  also some tweaks in the AUI_MDI sample in the demo. (#540)

* Added a wx.BUILD_TYPE value to distinguish between development,
  snapshot, and release builds. The value is also appended to
  wx.PlatformInfo. (Thanks Mesalu!)

* Fix crash when trying to fetch multiple items from a composite data
  object in wx.DropTarget.OnData. (#550) Also fixed the
  CustomDragAndDrop sample to not fail on Python 2.7.

* Add ability for wxArray wrappers to return a copy of the item in the
  ``__getitem__`` method. This solves problems where an array that is
  the return value of some method call is indexed immediately and a
  reference to the array is not held, which could result in garbage
  values for the indexed item. Currently this is turned on for just
  GridCellCoordsArray, but others can be switched in the future if
  needed. (#297)

* Add missing ``wx.GetLocale`` function. (#572)

* Add methods to wx.TextCtrl for output "file-like"
  compatibility. (#578)

* Fix object ownership issue for menus added to toolbar items. (#580)

* Updated SIP to version 4.19.5. One of the new features of this
  version is that integer overflows are no longer silently truncated
  and ignored. In other words, if a wrapped API has a parameter that
  is a C int type, and you pass a value that is larger than what will
  fit in that type of integer then an OverflowError exception will be
  raised.

* Fixed wx.richtext.RichTextBuffer.GetExtWildcard to return a tuple of
  2 values, as was done in Classic. (#594)

* Various fixes in UltimateListCtrl, HyperTreeList and
  CheckListCtrlMixin.  (#592, #349, #612)

* Fixes in TextEditMixin to ensure that the new value is passed in the
  event. (#605)

* Fix comparing DataViewItem and TreeListItem objects with
  None. (#595)

* Fix event type name in wx/lib/sheet.py (#613)

* The wx.MessageDialog methods which take ButtonLabel parameters are
  now able to accept either strings or stock IDs. (#607, #276)

* Fix wx.EvtHandler.Unbind to work correctly when specifying the
  handler and it is a bound method. (#624)

* Fix OGL's ShapeCanvas to draw properly when the window is scrolled,
  and to also adjust the mouse coordinates, etc. (#635)

* Set a default background color for the generic buttons. (#651)

* Fixed HtmlWindow's OnFoo virtual methods so calls to them are
  propagated to the Python class. (#642)

* Fixed wx.CallLater to explicitly hold a reference instead of
  depending on an uncollectable cycle to keep the instance
  around. Like before the cycle is broken and the saved reference is
  deleted after the timer expires and the callable has been
  called. (#457)

* Although it's more or less just an implementation detail, add
  wrappers for wx.aui.AuiTabCtrl so references to it will get the
  correct type. (#664)

* List-like wrapper classes generated for accessing wxLists and
  wxArrays now support reverse indexing. (#669) For example::

  child = panel.GetChildren()[-1]


* Ported some of the classes in Classic's gizmos module from C++ to
  Python, including LEDNumberCtrl, DynamicSashWindow, and
  TreeListCtrl. The classes are now located in the wx.lib.gizmos
  package, with a compatibility module at the old wx.gizmos
  location. Please note that this TreeListCtrl class is a very
  different implementation than wx.dataview.TreeListCtrl, although
  there is some overlap in purpose. In addition, the new TreeListCtrl
  class is not actually a port from the old gizmos.TreeListCtrl but
  rather just a thin layer around AGW's HyperTreeList. This means that
  if you are using a non- default style flag you'll need to pass it to
  the agwStyle parameter instead of the style parameter.

* Fix crash when deleting all wx.dataview.TreeListCtrl items with
  wxGTK3.  (#679, #704)

* Fix displaying '&' in the label of wx.RadioBox on GTK. (#39)

* Fix problems of the wrong C++ method being called in
  wx.ProgressDialog on MS Windows. (#701)

* Fixed how the scrollbar events are captured in DynamicSashWindow in
  order to fix regression in the sample. (#687)

* Allow extra CLI args to be passed to build.py by setting
  WXPYTHON_BUILD_ARGS in the environment.

* Added context manager methods to wx.DC that explicitly destroys the
  C++ part of the DC upon exit. Using DCs as context managers is not
  required, but can be handy in the rare cases where something holds
  on to a DC for too long, perhaps unintentionally. (#680)

* Fixed crash due to too aggressive management of wxModules when we
  load subordinate extensions that have their own wxModules (wx.html,
  wx.adv, etc.)  (#688)

* Fixed StyledTextCtrl.MarkerDefineRGBAImage and RegisterRGBAImage
  methods to be able to acc

Re: [wxPython-dev] wxPython 4.0.0 final

2018-01-31 Thread Eric Fahlgren

Excellent work, Robin (and other committers)!  Thanks for all your
continued efforts to keep wxPython alive and growing.

On Wed, Jan 31, 2018 at 5:37 PM, Robin Dunn <ro...@alldunn.com> wrote:

>
> Announcing wxPython 4.0.0
> =
>
> PyPI:   https://pypi.python.org/pypi/wxPython/4.0.0
> Extras: https://extras.wxPython.org/wxPython4/extras/
> Pip:``pip install wxPython==4.0.0``
>
> Changes in this release include the following:
>
> * Fixes in wx.aui to properly transfer ownership of the menubar, and
>   also some tweaks in the AUI_MDI sample in the demo. (#540)
>
> * Added a wx.BUILD_TYPE value to distinguish between development,
>   snapshot, and release builds. The value is also appended to
>   wx.PlatformInfo. (Thanks Mesalu!)
>
> * Fix crash when trying to fetch multiple items from a composite data
>   object in wx.DropTarget.OnData. (#550) Also fixed the
>   CustomDragAndDrop sample to not fail on Python 2.7.
>
> * Add ability for wxArray wrappers to return a copy of the item in the
>   ``__getitem__`` method. This solves problems where an array that is
>   the return value of some method call is indexed immediately and a
>   reference to the array is not held, which could result in garbage
>   values for the indexed item. Currently this is turned on for just
>   GridCellCoordsArray, but others can be switched in the future if
>   needed. (#297)
>
> * Add missing ``wx.GetLocale`` function. (#572)
>
> * Add methods to wx.TextCtrl for output "file-like"
>   compatibility. (#578)
>
> * Fix object ownership issue for menus added to toolbar items. (#580)
>
> * Updated SIP to version 4.19.5. One of the new features of this
>   version is that integer overflows are no longer silently truncated
>   and ignored. In other words, if a wrapped API has a parameter that
>   is a C int type, and you pass a value that is larger than what will
>   fit in that type of integer then an OverflowError exception will be
>   raised.
>
> * Fixed wx.richtext.RichTextBuffer.GetExtWildcard to return a tuple of
>   2 values, as was done in Classic. (#594)
>
> * Various fixes in UltimateListCtrl, HyperTreeList and
>   CheckListCtrlMixin.  (#592, #349, #612)
>
> * Fixes in TextEditMixin to ensure that the new value is passed in the
>   event. (#605)
>
> * Fix comparing DataViewItem and TreeListItem objects with
>   None. (#595)
>
> * Fix event type name in wx/lib/sheet.py (#613)
>
> * The wx.MessageDialog methods which take ButtonLabel parameters are
>   now able to accept either strings or stock IDs. (#607, #276)
>
> * Fix wx.EvtHandler.Unbind to work correctly when specifying the
>   handler and it is a bound method. (#624)
>
> * Fix OGL's ShapeCanvas to draw properly when the window is scrolled,
>   and to also adjust the mouse coordinates, etc. (#635)
>
> * Set a default background color for the generic buttons. (#651)
>
> * Fixed HtmlWindow's OnFoo virtual methods so calls to them are
>   propagated to the Python class. (#642)
>
> * Fixed wx.CallLater to explicitly hold a reference instead of
>   depending on an uncollectable cycle to keep the instance
>   around. Like before the cycle is broken and the saved reference is
>   deleted after the timer expires and the callable has been
>   called. (#457)
>
> * Although it's more or less just an implementation detail, add
>   wrappers for wx.aui.AuiTabCtrl so references to it will get the
>   correct type. (#664)
>
> * List-like wrapper classes generated for accessing wxLists and
>   wxArrays now support reverse indexing. (#669) For example::
>
>   child = panel.GetChildren()[-1]
>
>
> * Ported some of the classes in Classic's gizmos module from C++ to
>   Python, including LEDNumberCtrl, DynamicSashWindow, and
>   TreeListCtrl. The classes are now located in the wx.lib.gizmos
>   package, with a compatibility module at the old wx.gizmos
>   location. Please note that this TreeListCtrl class is a very
>   different implementation than wx.dataview.TreeListCtrl, although
>   there is some overlap in purpose. In addition, the new TreeListCtrl
>   class is not actually a port from the old gizmos.TreeListCtrl but
>   rather just a thin layer around AGW's HyperTreeList. This means that
>   if you are using a non- default style flag you'll need to pass it to
>   the agwStyle parameter instead of the style parameter.
>
> * Fix crash when deleting all wx.dataview.TreeListCtrl items with
>   wxGTK3.  (#679, #704)
>
> * Fix displaying '&' in the label of wx.RadioBox on GTK. (#39)
>
> * Fix problems of the wrong C++ method being called in
>   wx.ProgressDialog on MS Windows. (#701)
>
> * Fixed how the scrollbar events are cap

wxPython 4.0.0b2 release

2017-09-20 Thread Robin Dunn

Announcing wxPython 4.0.0b2
===

PyPI:   https://pypi.python.org/pypi/wxPython/4.0.0b2
Extras: https://extras.wxPython.org/wxPython4/extras/
Pip:``pip install wxPython==4.0.0b2``

Changes in this release include the following:

* Added a deprecated compatibility helper for wx.CustomDataFormat.

* Transfer ownership of the wx.EvtHandler object when pushing/popping
  them, and also for Set/RemoveEventHandler. (#443)

* Add missing wx.VScrolledWindow methods listed in the docs as
  deprecated but still present. (#441)

* Fixed copy/paste error in wx.BusyInfo.__exit__ (#449)

* Added new tool wxget, (a minimal wx implementation of wget)

* Added new tools wxdocs and wxdemos to launch the respective items,
  fetching and unpacking as required. (#437)

* Fixes to ensure that the locale message catalogs are included in the
  release files. (#464)

* Fix wx.ListCtrl.SetItemData to check that the data value is not out
  of the range of a C long. (#467)

* Changed the default port on *nix builds to be GTK3. The new
  ``--gtk2`` flag for build.py can be used to force a build for GTK2
  instead, and the ``--gtk3`` flag still exists, but defaults to True
  unless ``--gtk2`` is specified. Please note that there is currently
  no auto-detection of whether GTK3 is available or not, so if you
  know you need to build for GTK2 then you need to use the build flag,
  and there is currently no way to specify that flag for builds
  performed by pip. (#431)

* Fix parameter names in Toolbar.AddTool methods to be
  consistent. (#475)

* Remove inconsistent GetVirtualSize method in ScrolledWindow and let
  it be inherited from wx.Window instead. (#474)

* Fix crashing bug caused by importing a module that reinitializes the
  wxModule system after having imported wxpyTag. (#468)

* Fix missing methods in various DataObject classes. (They were
  actually accidentally marked "private" when they should have been
  public.) (#480)

* Add missing ListCtrl.DeleteAllColumns. (#486)

* Various fixes in the demo.

* Fixed improper initial scale factor in wx.lib.agw.speedmeter

* Fix for calls to wx.Notebook.HitTest calling the wrong instance
  (base class version) of the method. (#499)

* Add wx.Simplebook class.

* Fix exception in wx.lib.agw.customtreectrl when calling
  SortChildren. (#463, #500)

* Fix missing imports needed for drawing the legend in
  wx.lib.plot. (#503)

* Fix other instances of list.sort using old cmp-style ordering
  functions.  (#508)

* Update SizedControls to do a sanity check on the parent's sizer, as
  GetSizer can return None for SizedParent under certain
  circumstances, such as when AUI reparents the control during pane
  movement. (#523, #537)

* Added Vagrant configs for Fedora 23 and Fedora 26, and dropped
  Fedora 24.  Wheels built on F23 can also be used on F24 and F25, and
  F26 adds Python 3.6 support.

* Fix bitwise OR bug in wx.lib.agw.aui.framemanager. (#493)

* Fix bugs in wx.lib.plot when saving file. (#526)

* Fix integer division bug in ultimatelistctrl. (#528)

* Fix bug in wx.SearchCtrl.SetCancelBitmap (#532)

* Fixed property grid SetPropertyValue method to not truncate floating
  point values to integers, and a couple other possible incorrect
  conversions.  (#536)




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

wxPython 4.0.0b1

2017-07-26 Thread Robin Dunn

Announcing wxPython 4.0.0b1
===


PyPI:   https://pypi.python.org/pypi/wxPython/4.0.0b1
Extras: https://extras.wxPython.org/wxPython4/extras/

Changes in this release include the following:

* Various little tweaks and fixes in some of the demo samples.

* Fixes in wx.lib.imagebrowser so it looks and acts better on OSX.

* Fixed problem due to wxModules not being initialized when non-core
  extensions are imported.

* Fixed issue in wx.TreeItemId comparison methods affecting PyCrust and
  other tools.

* Restore the simplified names for the wxGridSelectionModes enum that
  were present in Classic.

* Add accessors for the internal widgets in the wx.EditableListBox.

* Fixes in wx.lib.eventwatcher to avoid deprecated methods and other
  Phoenix related changes.

* Correctly transfer ownership of the input stream in wx.FSFile.

* Ensure the license files are getting into the source tarball and the
  binary wheel files.

* Add wrappers for the classes derived from wxImageHandler.

* Fix wx.lib.plot.polyline to not attempt to draw the spline if there
  are less than 3 points.

* Transfer the ownership of the prop arg in
  wx.propgrid.PGProperty.AddChild and AddPrivateChild. Various other
  fixes in wx.propgrid classes for backwards compatibility and to fix
  problems caused by mismatches between customizations that were done
  for Classic and how Phoenix does things by default. Also solved some
  problems in the PropertyGrid sample in the demo.

* Add missing HtmlCell.FindCellByPos.

* Enhance the DLG_UNIT convenience function such that if something
  other than a wx.Point or wx.Size was passed in then the return value
  will be a tuple. This eliminates some surprises that are possible due
  to auto-conversion of tuples to points or sizes.





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 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/

Happy Hacking!

-- 
Robin Dunn
Software Craftsman
http://wxPython.org
-- 
https://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations/

wxPython 4.0.0a3

2017-06-05 Thread Robin Dunn

Announcing wxPython 4.0.0a3
===

https://pypi.python.org/pypi/wxPython/4.0.0a3

Changes
---

Fixed a few cases where the GIL was not acquired before building
tuples of values. The problems associated with this (hangs or crashes)
were sporadic and seemingly random, and did not appear until there was
a background thread that was very busy. Running under a debug build of
Python revealed the problem almost immediately. Yay Python!

Return an integer value from wx.DC.GetHandle instead of a wrapped
voidptr object, similar to how it is done for wx.Window.GetHandle.

Make wx.TreeItemID hashable, with meaningful hash value and equality
operators, so it can be used as a dictionary key in Py3.

Fixed crash in wx.grid.GridTable.GetAttr, and potentially other cases
of classes derived from wx.RefCounter.

Add ShowPage and IsRunning methods to wx.adv.Wizard.

Fixed various GTK specific bugs and other cleanup in wx.lib.agw.aui.

Updated to SIP 4.19.2

Restored builders for Python 3.4 to the buildbot.

Restore the wrappers for GetPaperSize and SetPaperSize to
wx.PrintData.

Fix crashing problem when a wx.TreeItemId was compared with None.

Fix for missing checkbox images in CheckListCtrlMixin on Linux and
OSX.

Fix another crashing problem in propgrid, and a few other propgrid
issues too.

The release version of the documentation can now be found at
https://docs.wxPython.org/ The documentation created during the
snapshot builds is still located at https://wxPython.org/Phoenix/docs/html



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 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
-- 
https://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations/

wxPython 4.0.0a2

2017-05-09 Thread Robin Dunn


Announcing wxPython 4.0.0a2
---

https://pypi.python.org/pypi/wxPython/4.0.0a2

This build of wxPython is based on the official wxWidgets 3.0.3
release.

This release is mostly various bug fixes and other tweaks, such as:

  * Allow numpy arrays to be auto-converted to simple sequence value
types like wx.Size, wx.Colour, etc.

  * A couple of fixes to lib/agw/aui to prevent segfaults under OSX
when AuiNotebook tabs are closed

  * Fix wx._core.wxAssertionError in wx.lib.agw.aui when dragging a
notebook tab

  * Fix the [G|S]etClientData methods in wx.CommandEvent to behave the
same way they are in wx.ClientDataContainer.

  * Fix the SetFonts methods in wx.html classes

  * Several fixes in wx.dataview related to overriding methods

  * Fixed some flickering in wx.lib.agw.aui.framemanager

  * Fixed problem with wrong implementation of
wxNotebook::DeleteAllPages being called on Windows

  * Added the missing wx.grid.GRID_AUTOSIZE flag

  * Fixed crash due to the object created in an XmlSubclassFactory
being destroyed too soon

  * Fixed crash in wx.lib.agw.toasterbox

  * Fixed crash when using wx.xrc.XmlSubclassFactory

  * Fixed wx.grid.GridTableBase.GetValue and related methods to work
more like they did in Classic, so non-string values can be used a
little more easily.

Added building and bundling of the PDB files for wxWidgets and the
wxPython extensions on Windows.  Until a better place is found they
will be downloadable from https://wxPython.org/Phoenix/release-extras,
along with archives for the documentation as well as the demo and
samples.



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 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://wxpython.org/Phoenix/docs/html/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://wxpython.org/Phoenix/docs/html/main.html

-- 
Robin Dunn
Software Craftsman
http://wxPython.org
-- 
https://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations/

wxPython 4.0.0a1

2017-04-18 Thread Robin Dunn


Announcing wxPython 4.0.0a1
---

https://pypi.python.org/pypi/wxPython/4.0.0a1

I'm pleased to announce that wxPython's Project Phoenix has made it's public
debut as wxPython 4.0.0a1, available from PyPI. Don't let the fact that
it is
marked as an "alpha" release scare you away. It is an alpha simply because
this is the **first** in several ways:

  * It's the first real release of Phoenix, which is built on a different
foundation than Classic wxPython was.

  * It's the first wxPython release intended to be fully available from
PyPI and
buildable/installable by pip on all of the supported platforms.

  * It's the first release for Python3 (binaries for 3.5 and 3.6 are
provided,
and building for 3.4 is still possible as well). In addition, Python 2.7
is also supported from the same codebase, with binaries available.

  * The wheel files are fully self-contained and relocatable on the
supported
platforms, so they are installable in virtual environments without
needing
to be able to find specific versions of the wxWidgets shared libraries
(or others) at fixed locations elsewhere in the file-system.

  * And as with most alphas, there are still a few things that are not
finished or polished yet.

But even with all that, many people have been using the pre-release
snapshots
of Phoenix for quite a while now, and it has been relatively stable and
solid
for them.



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 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://wxpython.org/Phoenix/docs/html/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://wxpython.org/Phoenix/docs/html/main.html

-- 
Robin Dunn
Software Craftsman
http://wxPython.org
-- 
https://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations/

RE: wxPython Cookbook

2016-08-26 Thread Gonzales, Dean

Very cool! Thanks for doing this. I can't wait to dig into your cookbook.

Regards,
Dean Gonzales

-Original Message-
From: Python-announce-list 
[mailto:python-announce-list-bounces+dean.gonzales=amd@python.org] On 
Behalf Of Mike Driscoll
Sent: Wednesday, August 24, 2016 12:57 PM
To: python-announce-l...@python.org
Subject: ANN: wxPython Cookbook

Hi,

Several years ago, the readers of my popular Python blog 
<http://www.blog.pythonlibrary.org/> asked me to take some of my articles and 
turn them into a cookbook on wxPython. I have finally decided to do just that. 
I am including over 50 recipes that I am currently editing to make them more 
consistent and updating them to be compatible with the latest versions of 
wxPython. I currently have nearly 300 pages of content!

If you'd like to check out the funding campaign for the book, you can find it 
here: https://www.kickstarter.com/projects/34257246/wxpython-cookbook/

Thanks,
Mike
--
https://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations/
-- 
https://mail.python.org/mailman/listinfo/python-list

ANN: wxPython Cookbook

2016-08-26 Thread Mike Driscoll

Hi,

Several years ago, the readers of my popular Python blog
<http://www.blog.pythonlibrary.org/> asked me to take some of my articles
and turn them into a cookbook on wxPython. I have finally decided to do
just that. I am including over 50 recipes that I am currently editing to
make them more consistent and updating them to be compatible with the
latest versions of wxPython. I currently have nearly 300 pages of content!

If you'd like to check out the funding campaign for the book, you can find
it here: https://www.kickstarter.com/projects/34257246/wxpython-cookbook/

Thanks,
Mike
-- 
https://mail.python.org/mailman/listinfo/python-announce-list

Support the Python Software Foundation:
http://www.python.org/psf/donations/

Re: A question about imports in wxpython

2016-02-08 Thread Ian Kelly

On Mon, Feb 8, 2016 at 8:44 AM,  <c...@isbd.net> wrote:
> I'm playing with some code that uses the wxpython grid.  *Every*
> example I have seen starts with the imports:-
>
> import wx
> import wx.grid as Gridlib
>
> As Gridlib is exactly the same number of characters as wx.grid I
> really don't see the point.  Am I missing something?

You're not missing anything. I've actually never seen that before (or
at least never noticed). The first hit when searching "import wx.grid"
is http://wxpython.org/Phoenix/docs/html/grid_overview.html which
doesn't use the "as" (but I see some hits farther down that do).

Probably the author of that code was just trying to save a dict lookup
every time "wx.grid" is referenced (which has to look up "wx" in the
globals and then "grid" as an attribute). Seems like an unnecessary
micro-optimization to me.
-- 
https://mail.python.org/mailman/listinfo/python-list

A question about imports in wxpython

2016-02-08 Thread cl

I'm playing with some code that uses the wxpython grid.  *Every*
example I have seen starts with the imports:-

import wx
import wx.grid as Gridlib

As Gridlib is exactly the same number of characters as wx.grid I
really don't see the point.  Am I missing something?

-- 
Chris Green
·
-- 
https://mail.python.org/mailman/listinfo/python-list

Confused by wxpython documentation

2016-02-08 Thread cl

I'm playing around with some existing code that uses wxpython.  I've
been trying to understand a basic bit about the import statement and
so went to the beginning of the wxPython on line documents.

Going from the top to the "Hello World Example" (can't give URL as the
URL is the same for all the docs, http://www.wxpython.org/onlinedocs.php)
the first thing I see is some C/C++ code.  What's this about? How have
I got to the underlying C/C++ implementation rather than the Python
documentation?

I realise the Python usage follows the underlying C/C++ very closely
but seeing the C/C++ doesn't really help me write my Python too much.

Looking more closely what I've actually been taken to is the wxWidgets
documentation which, not unreasonably, is in C/C++.

... but where do I find the Python documentation for this?

-- 
Chris Green
·
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Confused by wxpython documentation

2016-02-08 Thread Ian Kelly

On Mon, Feb 8, 2016 at 8:36 AM,  <c...@isbd.net> wrote:
> I'm playing around with some existing code that uses wxpython.  I've
> been trying to understand a basic bit about the import statement and
> so went to the beginning of the wxPython on line documents.
>
> Going from the top to the "Hello World Example" (can't give URL as the
> URL is the same for all the docs, http://www.wxpython.org/onlinedocs.php)
> the first thing I see is some C/C++ code.  What's this about? How have
> I got to the underlying C/C++ implementation rather than the Python
> documentation?
>
> I realise the Python usage follows the underlying C/C++ very closely
> but seeing the C/C++ doesn't really help me write my Python too much.
>
> Looking more closely what I've actually been taken to is the wxWidgets
> documentation which, not unreasonably, is in C/C++.
>
> ... but where do I find the Python documentation for this?

wiki.wxpython.org was the site I used when I was developing wxPython.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Confused by wxpython documentation

2016-02-08 Thread cl

Ian Kelly <ian.g.ke...@gmail.com> wrote:
> On Mon, Feb 8, 2016 at 8:36 AM,  <c...@isbd.net> wrote:
> > I'm playing around with some existing code that uses wxpython.  I've
> > been trying to understand a basic bit about the import statement and
> > so went to the beginning of the wxPython on line documents.
> >
> > Going from the top to the "Hello World Example" (can't give URL as the
> > URL is the same for all the docs, http://www.wxpython.org/onlinedocs.php)
> > the first thing I see is some C/C++ code.  What's this about? How have
> > I got to the underlying C/C++ implementation rather than the Python
> > documentation?
> >
> > I realise the Python usage follows the underlying C/C++ very closely
> > but seeing the C/C++ doesn't really help me write my Python too much.
> >
> > Looking more closely what I've actually been taken to is the wxWidgets
> > documentation which, not unreasonably, is in C/C++.
> >
> > ... but where do I find the Python documentation for this?
> 
> wiki.wxpython.org was the site I used when I was developing wxPython.

Thanks, a good place to start, and it tells me why I get to the C/C++
docs for wxWidgets.

-- 
Chris Green
·
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: wxpython strange behaviour

2016-01-16 Thread Michael Torrie

On 01/15/2016 05:58 PM, Shiva Upreti wrote:
> 
> What kind of further details do you want? Please tell me and i will try my 
> best to provide them.

As always, post a small but complete example test program (no more than
20 lines of code) that has the problem.  Paste it in such a way that one
can copy and paste it into an editor and get a validly-formatted
program.  Also post the traceback you get when you run the test program
you created.  Another person has to be able to replicate the problem to
advise you. Often in the process of doing this, people find their own bugs.

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: wxpython strange behaviour

2016-01-15 Thread Ian Kelly

On Fri, Jan 15, 2016 at 10:05 AM, Shiva Upreti <katewinslet...@gmail.com> wrote:
> https://gist.github.com/anonymous/4baa67aafd04555eb4e6
>
> I wrote the above code to display a toasterbox, and I didnt want it to 
> display any frames on the screen, just a toasterbox. The problem with this 
> code is that it runs fine when I run it the first time, but when I run it 
> next time it shows some error and the toasterbox doesnt disappear from the 
> screen itself(it should though).
> Error message I got:
> https://gist.github.com/anonymous/f0d4ec685d2432c80a1

The first gist is short enough that it easily could have been included
inline in your message. The second gist is a 404 (looks like it may be
short one hex digit).

I haven't used wxPython in a while and I've never used that ToasterBox
widget, but I'll see what I can answer.

If you don't want any frames then you should probably use parent=None,
not parent=wx.Frame(None), which creates a frame. Also, the purpose of
the panel is unclear since it's never used.

When you say that you run it the next time, do you mean that you're
running this script twice, as two separate processes, and getting
different results? That seems strange. Or do you mean that you're
invoking this code multiple times in the same Python process?
-- 
https://mail.python.org/mailman/listinfo/python-list

wxpython strange behaviour

https://gist.github.com/anonymous/4baa67aafd04555eb4e6

I wrote the above code to display a toasterbox, and I didnt want it to display 
any frames on the screen, just a toasterbox. The problem with this code is that 
it runs fine when I run it the first time, but when I run it next time it shows 
some error and the toasterbox doesnt disappear from the screen itself(it should 
though).
Error message I got:
https://gist.github.com/anonymous/f0d4ec685d2432c80a1

There is one more issue. I am using canopy as my environment, and when i run it 
using canopy it works fine at least for the first time but when I run it using 
command prompt in windows 10, nothing happens, I get no errors and still it 
does not work.

Please help me solve these issues.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: wxpython strange behaviour

2016-01-15 Thread Mark Lawrence


On 15/01/2016 17:05, Shiva Upreti wrote:

https://gist.github.com/anonymous/4baa67aafd04555eb4e6

I wrote the above code to display a toasterbox, and I didnt want it to display 
any frames on the screen, just a toasterbox. The problem with this code is that 
it runs fine when I run it the first time, but when I run it next time it shows 
some error and the toasterbox doesnt disappear from the screen itself(it should 
though).
Error message I got:
https://gist.github.com/anonymous/f0d4ec685d2432c80a1


I'm sorry that I can't help directly but you're more likely to get 
answers here gmane.comp.python.wxpython.




There is one more issue. I am using canopy as my environment, and when i run it 
using canopy it works fine at least for the first time but when I run it using 
command prompt in windows 10, nothing happens, I get no errors and still it 
does not work.



Two problems, one is that Canopy is *NOT* main stream Python, it is part 
of the Enthought distibution, second is that "still it does not work" 
amongst other things is about as much use as a wet fart in a 
thunderstorm.  Please give us data that we can work with.



Please help me solve these issues.



--
My fellow Pythonistas, ask not what our language can do for you, ask
what you can do for our language.

Mark Lawrence

--
https://mail.python.org/mailman/listinfo/python-list

Re: wxpython strange behaviour

On Friday, January 15, 2016 at 10:35:57 PM UTC+5:30, Shiva Upreti wrote:
> https://gist.github.com/anonymous/4baa67aafd04555eb4e6
> 
> I wrote the above code to display a toasterbox, and I didnt want it to 
> display any frames on the screen, just a toasterbox. The problem with this 
> code is that it runs fine when I run it the first time, but when I run it 
> next time it shows some error and the toasterbox doesnt disappear from the 
> screen itself(it should though).
> Error message I got:
> https://gist.github.com/anonymous/f0d4ec685d2432c80a1
> 
> There is one more issue. I am using canopy as my environment, and when i run 
> it using canopy it works fine at least for the first time but when I run it 
> using command prompt in windows 10, nothing happens, I get no errors and 
> still it does not work.
> 
> Please help me solve these issues.

New link to error message, old one is giving 404:
http://pasted.co/f398a1e4
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: wxpython strange behaviour

On Friday, January 15, 2016 at 10:55:59 PM UTC+5:30, Ian wrote:
> On Fri, Jan 15, 2016 at 10:05 AM, Shiva Upreti <katewinslet...@gmail.com> 
> wrote:
> > https://gist.github.com/anonymous/4baa67aafd04555eb4e6
> >
> > I wrote the above code to display a toasterbox, and I didnt want it to 
> > display any frames on the screen, just a toasterbox. The problem with this 
> > code is that it runs fine when I run it the first time, but when I run it 
> > next time it shows some error and the toasterbox doesnt disappear from the 
> > screen itself(it should though).
> > Error message I got:
> > https://gist.github.com/anonymous/f0d4ec685d2432c80a1
> 
> The first gist is short enough that it easily could have been included
> inline in your message. The second gist is a 404 (looks like it may be
> short one hex digit).
> 
> I haven't used wxPython in a while and I've never used that ToasterBox
> widget, but I'll see what I can answer.
> 
> If you don't want any frames then you should probably use parent=None,
> not parent=wx.Frame(None), which creates a frame. Also, the purpose of
> the panel is unclear since it's never used.
> 
> When you say that you run it the next time, do you mean that you're
> running this script twice, as two separate processes, and getting
> different results? That seems strange. Or do you mean that you're
> invoking this code multiple times in the same Python process?

parent=None doesnt work, it gives error:



AttributeErrorTraceback (most recent call last)
C:\Users\Mike\Desktop\zz.py in ()
  5 app = wx.App()
  6 panel=wx.Panel(parent=wx.Frame(None))
> 7 toaster = TB.ToasterBox(parent=None, tbstyle=TB.TB_COMPLEX, 
closingstyle=TB.TB_ONTIME)
  8 
  9 toaster.SetPopupPauseTime(3000)

C:\Users\Mike\AppData\Local\Enthought\Canopy\User\lib\site-packages\wx\lib\agw\toasterbox.pyc
 in __init__(self, parent, tbstyle, windowstyle, closingstyle, scrollType)
135 wx.GetDisplaySize().GetHeight())
136 
--> 137parent.Bind(wx.EVT_ICONIZE, lambda evt: [w.Hide() for w in 
winlist])
138 
139self._tb = ToasterBoxWindow(self._parent, self, self._tbstyle, 
self._windowstyle,

AttributeError: 'NoneType' object has no attribute 'Bind'


By running it the next time I meant that I am running this script twice as 
separate processes and I run it the second time only after first process has 
finished its execution.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: wxpython strange behaviour

On Friday, January 15, 2016 at 10:55:59 PM UTC+5:30, Ian wrote:
> On Fri, Jan 15, 2016 at 10:05 AM, Shiva Upreti <katewinslet...@gmail.com> 
> wrote:
> > https://gist.github.com/anonymous/4baa67aafd04555eb4e6
> >
> > I wrote the above code to display a toasterbox, and I didnt want it to 
> > display any frames on the screen, just a toasterbox. The problem with this 
> > code is that it runs fine when I run it the first time, but when I run it 
> > next time it shows some error and the toasterbox doesnt disappear from the 
> > screen itself(it should though).
> > Error message I got:
> > https://gist.github.com/anonymous/f0d4ec685d2432c80a1
> 
> The first gist is short enough that it easily could have been included
> inline in your message. The second gist is a 404 (looks like it may be
> short one hex digit).
> 
> I haven't used wxPython in a while and I've never used that ToasterBox
> widget, but I'll see what I can answer.
> 
> If you don't want any frames then you should probably use parent=None,
> not parent=wx.Frame(None), which creates a frame. Also, the purpose of
> the panel is unclear since it's never used.
> 
> When you say that you run it the next time, do you mean that you're
> running this script twice, as two separate processes, and getting
> different results? That seems strange. Or do you mean that you're
> invoking this code multiple times in the same Python process?

parent=None doesnt work, it gives error:

AttributeErrorTraceback (most recent call last)
C:\Users\Mike\Desktop\zz.py in ()
  5 app = wx.App()
  6 panel=wx.Panel(parent=wx.Frame(None))
> 7 toaster = TB.ToasterBox(parent=None, tbstyle=TB.TB_COMPLEX, 
closingstyle=TB.TB_ONTIME)
  8 
  9 toaster.SetPopupPauseTime(3000)

C:\Users\Mike\AppData\Local\Enthought\Canopy\User\lib\site-packages\wx\lib\agw\toasterbox.pyc
 in __init__(self, parent, tbstyle, windowstyle, closingstyle, scrollType)
135 wx.GetDisplaySize().GetHeight())
136 
--> 137parent.Bind(wx.EVT_ICONIZE, lambda evt: [w.Hide() for w in 
winlist])
138 
139self._tb = ToasterBoxWindow(self._parent, self, self._tbstyle, 
self._windowstyle,

AttributeError: 'NoneType' object has no attribute 'Bind'

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: wxpython strange behaviour

On Saturday, January 16, 2016 at 2:22:24 AM UTC+5:30, Mark Lawrence wrote:
> On 15/01/2016 17:05, Shiva Upreti wrote:
> > https://gist.github.com/anonymous/4baa67aafd04555eb4e6
> >
> > I wrote the above code to display a toasterbox, and I didnt want it to 
> > display any frames on the screen, just a toasterbox. The problem with this 
> > code is that it runs fine when I run it the first time, but when I run it 
> > next time it shows some error and the toasterbox doesnt disappear from the 
> > screen itself(it should though).
> > Error message I got:
> > https://gist.github.com/anonymous/f0d4ec685d2432c80a1
> 
> I'm sorry that I can't help directly but you're more likely to get 
> answers here gmane.comp.python.wxpython.
> 
> >
> > There is one more issue. I am using canopy as my environment, and when i 
> > run it using canopy it works fine at least for the first time but when I 
> > run it using command prompt in windows 10, nothing happens, I get no errors 
> > and still it does not work.
> >
> 
> Two problems, one is that Canopy is *NOT* main stream Python, it is part 
> of the Enthought distibution, second is that "still it does not work" 
> amongst other things is about as much use as a wet fart in a 
> thunderstorm.  Please give us data that we can work with.
> 
> > Please help me solve these issues.
> >
> 
> -- 
> My fellow Pythonistas, ask not what our language can do for you, ask
> what you can do for our language.
> 
> Mark Lawrence

What kind of further details do you want? Please tell me and i will try my best 
to provide them.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: wxpython strange behaviour