What is the current situation with Phoenix from a users point of view?
What is your experience:
- Happy user of Phoenix
- Never used, as it seems to be too beta
- My platform (e.g. Python 3.5) is not supported
- Tried, but did not work
- Tried, but features were missing
- other...
I'm asking because the lack of "official" wxPython for Python 3.x was holding me back from Python 3 for several years.
But when I tried this month, I found that almost everything is working and it's very stable as well, once you get the differences. At some points Phoenix is less tolerant.
The missing parts that I needed (MetafileDC or Internet Explorer in an Active X window) were not impossible to implement.
Also, I had a look at Python 3.5 support for 32 and 64 bit and this also does basically work with some patches (on Windows).
So, my feeling is that it's time to get some momentum again...
On Thu, Nov 19, 2015 at 11:08:39PM +0100, Dietmar Schwertberger wrote:
What is the current situation with Phoenix from a users point of view?
What is your experience:
- Happy user of Phoenix
- Never used, as it seems to be too beta
- My platform (e.g. Python 3.5) is not supported
- Tried, but did not work
- Tried, but features were missing
- other...
What is the current situation with Phoenix from a users point of view?
What is your experience:
- Happy user of Phoenix
- Never used, as it seems to be too beta
- My platform (e.g. Python 3.5) is not supported
- Tried, but did not work
- Tried, but features were missing
- other...
Lack of a package for Debian.
Last time I checked, it didn't support wxMediaCtrl, which is a must-have for me.
Like you I have been waiting for years too. I’d like to use wxPython-Phoenix to upgrade Dabo to python3. My fear it’s not going to happen. I’m sure Robin needs help and I wish I could help - but I have little understanding of the underlying code to be much help! I believe at one time someone suggested a kickerstarter or crowdfunding to pay someone to move it forward but I guess that went nowhere.
What is the current situation with Phoenix from a users point of view?
What is your experience:
Happy user of Phoenix
Never used, as it seems to be too beta
My platform (e.g. Python 3.5) is not supported
Tried, but did not work
Tried, but features were missing
other…
I’m asking because the lack of “official” wxPython for Python 3.x was holding me back from Python 3 for several years.
But when I tried this month, I found that almost everything is working and it’s very stable as well, once you get the differences. At some points Phoenix is less tolerant.
The missing parts that I needed (MetafileDC or Internet Explorer in an Active X window) were not impossible to implement.
Also, I had a look at Python 3.5 support for 32 and 64 bit and this also does basically work with some patches (on Windows).
So, my feeling is that it’s time to get some momentum again…
Regards,
Dietmar
–
You received this message because you are subscribed to the Google Groups “wxPython-users” group.
Of course we have. I haven’t tested in the last few months but I still believe the grid is a major issue (but has there been an updated release). We actually have a git branch with code that supports python3 and Phoenix but of course only parts of it work. Believe me if Phoenix ever gets released it won’t take long for Dabo to convert to python 3. We currently have wxPython 3.x working and working well I might add. Dabo2 (that’s what I call it) runs faster and better with wxPython 3.x than with wxPython 2.8.x
Like you I have been waiting for years too. I’d like to use wxPython-Phoenix to upgrade Dabo to python3. My fear it’s not going to happen.
Am 19.11.2015 um 23:27 schrieb John Fabiani:
Did you actually try whether Dabo runs with Phoenix?
Regards,
Dietmar
–
You received this message because you are subscribed to the Google Groups “wxPython-users” group.
What is the problem with the grid? For me it's working fine after some small changes in my code.
Is there e.g. something which is working in the demo, but not in your code?
E.g. with Phoenix you need to keep a reference to your GridCellAttr and also you need to return the correct data type in GetValue.
Regards,
Dietmar
···
Am 20.11.2015 um 00:10 schrieb John Fabiani:
Of course we have. I haven't tested in the last few months but I still believe the grid is a major issue (but has there been an updated release). We actually have a git branch with code that supports python3 and Phoenix but of course only parts of it work. Believe me if Phoenix ever gets released it won't take long for Dabo to convert to python 3. We currently have wxPython 3.x working and working well I might add. Dabo2 (that's what I call it) runs faster and better with wxPython 3.x than with wxPython 2.8.x
Last time I tried Phoenix I hit major problems with little to no help on this
list.
I have 2 projects that I want to port, pysvn WorkBench and Barry's Emacs.
I was seeing crashes and visual glitches. The code changes did not take that
long and where mostly obvious.
At the moment I cannot even use classic 3.0.2 as it has broken clipboard paste
on OS X. (Assumes that clipboard has UTF-8 text when in fact its UTF-16).
And no one has even acknowledged the bug yet.
Barry
···
On Thursday 19 November 2015 23:08:39 Dietmar Schwertberger wrote:
What is the current situation with Phoenix from a users point of view?
What is your experience:
- Happy user of Phoenix
- Never used, as it seems to be too beta
- My platform (e.g. Python 3.5) is not supported
- Tried, but did not work
- Tried, but features were missing
- other...
I'm asking because the lack of "official" wxPython for Python 3.x was
holding me back from Python 3 for several years.
But when I tried this month, I found that almost everything is working
and it's very stable as well, once you get the differences. At some
points Phoenix is less tolerant.
The missing parts that I needed (MetafileDC or Internet Explorer in an
Active X window) were not impossible to implement.
Also, I had a look at Python 3.5 support for 32 and 64 bit and this also
does basically work with some patches (on Windows).
So, my feeling is that it's time to get some momentum again...
Hi,i´m a newie with wxWidgets from Python. Past week i was unable to install Phoenix from github python script builder, (Windows 8) all the succesive build.py steps did run OK,but, probably because not getting Python 3.4 to see the libraries when doing “import wx” after command install of build py (it complained about that, i think the compilation with VC 2010 was ok) - I´m learning now the python-c extending stuff so was not able to understand why… and is probably my fault.
After that fail, the setup using pip on 3.4 and the precompiled whell for x64 worked like charm.
Some examples of demo.py (a minority of them) did not work for me. But the mayority worked for me. I did get in love with Phoenix instantly.
What I missed most was that in Windows, the embedding of a Browser embeded IE6 in my setup, and I was not able to tell Phoenix to embed either Chromium or Gecko engines. That suposed for me the lack of an HTML5 canvas, or the ability of providing a diferent from the Microsoft one in Windows.
That was not practical for me, because the excelent implementations of Python over Javascript that are overthere such as http://brython.info/ did not work with the outdated non HTML5 canvas.
It is a pitty, because that i´m considering either trying to link with wxGTK from wxPython in Windows instead of using the native Windows one, either avoiding Phoenix and using C++ for de Web Toolkit container.
Anyway Phoenix looked to me as production ready if you cand stand the limitations or extend it in any way.
···
El jueves, 19 de noviembre de 2015, 23:08:50 (UTC+1), Dietmar Schwertberger escribió:
What is the current situation with Phoenix from a users point of view?
What is your experience:
Happy user of Phoenix
Never used, as it seems to be too beta
My platform (e.g. Python 3.5) is not supported
Tried, but did not work
Tried, but features were missing
other…
I’m asking because the lack of “official” wxPython for Python 3.x was
holding me back from Python 3 for several years.
But when I tried this month, I found that almost everything is working
and it’s very stable as well, once you get the differences. At some
points Phoenix is less tolerant.
The missing parts that I needed (MetafileDC or Internet Explorer in an
Active X window) were not impossible to implement.
Also, I had a look at Python 3.5 support for 32 and 64 bit and this also
does basically work with some patches (on Windows).
So, my feeling is that it’s time to get some momentum again…
Hi,i´m a newie with wxWidgets from Python. Past week i was unable to install Phoenix from github python script builder, (Windows 8) all the succesive build.py steps did run OK,but, probably because not getting Python 3.4 to see the libraries when doing "import wx" after command install of build py (it complained about that, i think the compilation with VC 2010 was ok) - I´m learning now the python-c extending stuff so was not able to understand why.. and is probably my fault.
For me the build and install commands both seem to work.
When the build itself is successful, you should see a message like that:
------------ BUILD FINISHED ------------
To use wxPython from the build folder (without installing):
- Set your PYTHONPATH variable to D:\Python\Sources34\Phoenix.
What I missed most was that in Windows, the embedding of a Browser embeded IE6 in my setup, and I was not able to tell Phoenix to embed either Chromium or Gecko engines. That suposed for me the lack of an HTML5 canvas, or the ability of providing a diferent from the Microsoft one in Windows.
OK, Werner answered that the grid issues were reported on -dev.
I had a quick look at the sources and the demo.
In wxWidgets, for different data types different methods are called:
GetValue for strings, GetValueAsLong for integers and so on.
In the demo there's a comment about this:
# Get/Set values in the table. The Python version of these
# methods can handle any data-type, (as long as the Editor and
# Renderer understands the type too,) not just strings as in the
# C++ version.
This comment is 100% correct. The standard renderer will not cope with an integer returned by GetValue.
But e.g. the demo GridStdEdRend.py with Python renderers will do.
If I add e.g. a GetValueAs Long method to the demo code with the standard renderer (GridCustTable.py), things work as expected for the integer types in Phonix:
def GetValue(self, row, col):
try:
return self.data[row][col]
except IndexError:
return ''
def GetValueAsLong(self, row, col):
try:
return self.data[row][col]
except IndexError:
return 0
In the sources of classic, you can find e.g. the implementation for GetValueAsLong calling Python GetValue and converting it to Long:
(in src/grid.i)
// Map the Get/Set methods for the standard non-string types to
// the GetValue and SetValue python methods.
long GetValueAsLong( int row, int col ) {
long rval = 0;
wxPyBlock_t blocked = wxPyBeginBlockThreads();
if (wxPyCBH_findCallback(m_myInst, "GetValue")) {
PyObject* ro;
PyObject* num;
ro = wxPyCBH_callCallbackObj(m_myInst, Py_BuildValue("(ii)", row, col));
if (ro && PyNumber_Check(ro)) {
num = PyNumber_Int(ro);
if (num) {
rval = PyInt_AsLong(num);
Py_DECREF(num);
}
Py_DECREF(ro);
}
}
wxPyEndBlockThreads(blocked);
return rval;
I'm not sure which is the better way: stay compatible with Classic or use the "standard" way of multiple methods.
The Classic way is probabyl more pythonic.
Regards,
Dietmar
···
Am 20.11.2015 um 00:10 schrieb John Fabiani:
Of course we have. I haven't tested in the last few months but I still believe the grid is a major issue (but has there been an updated release). We actually have a git branch with code that supports python3 and Phoenix but of course only parts of it work. Believe me if Phoenix ever gets released it won't take long for Dabo to convert to python 3. We currently have wxPython 3.x working and working well I might add. Dabo2 (that's what I call it) runs faster and better with wxPython 3.x than with wxPython 2.8.x
Hi,i´m a newie with wxWidgets from Python. Past week i was unable to install Phoenix from github python script builder, (Windows 8) all the succesive build.py steps did run OK,but, probably because not getting Python 3.4 to see the libraries when doing “import wx” after command install of build py (it complained about that, i think the compilation with VC 2010 was ok) - I´m learning now the python-c extending stuff so was not able to understand why… and is probably my fault.
After that fail, the setup using pip on 3.4 and the precompiled whell for x64 worked like charm.
Some examples of demo.py (a minority of them) did not work for me. But the mayority worked for me. I did get in love with Phoenix instantly.
What I missed most was that in Windows, the embedding of a Browser embeded IE6 in my setup, and I was not able to tell Phoenix to embed either Chromium or Gecko engines. That suposed for me the lack of an HTML5 canvas, or the ability of providing a diferent from the Microsoft one in Windows.
That was not practical for me, because the excelent implementations of Python over Javascript that are overthere such as http://brython.info/ did not work with the outdated non HTML5 canvas.
It is a pitty, because that i´m considering either trying to link with wxGTK from wxPython in Windows instead of using the native Windows one, either avoiding Phoenix and using C++ for de Web Toolkit container.
Anyway Phoenix looked to me as production ready if you cand stand the limitations or extend it in any way.
El jueves, 19 de noviembre de 2015, 23:08:50 (UTC+1), Dietmar Schwertberger escribió:
What is the current situation with Phoenix from a users point of view?
What is your experience:
Happy user of Phoenix
Never used, as it seems to be too beta
My platform (e.g. Python 3.5) is not supported
Tried, but did not work
Tried, but features were missing
other…
I’m asking because the lack of “official” wxPython for Python 3.x was
holding me back from Python 3 for several years.
But when I tried this month, I found that almost everything is working
and it’s very stable as well, once you get the differences. At some
points Phoenix is less tolerant.
The missing parts that I needed (MetafileDC or Internet Explorer in an
Active X window) were not impossible to implement.
Also, I had a look at Python 3.5 support for 32 and 64 bit and this also
does basically work with some patches (on Windows).
So, my feeling is that it’s time to get some momentum again…
If I understand this correctly, Dabo has the option of using the individual methods, then it will work now. Or wait for Robin to do some magic to handle this as I think he did in Classic or come up with the magic and do a PR for it.
As I won't get to this for a long time I'll copy the Dabo list, maybe someone wants to take this on.
Werner
···
On 11/23/2015 22:17, Dietmar Schwertberger wrote:
Am 20.11.2015 um 00:10 schrieb John Fabiani:
Of course we have. I haven't tested in the last few months but I still believe the grid is a major issue (but has there been an updated release). We actually have a git branch with code that supports python3 and Phoenix but of course only parts of it work. Believe me if Phoenix ever gets released it won't take long for Dabo to convert to python 3. We currently have wxPython 3.x working and working well I might add. Dabo2 (that's what I call it) runs faster and better with wxPython 3.x than with wxPython 2.8.x
OK, Werner answered that the grid issues were reported on -dev.
I had a quick look at the sources and the demo.
In wxWidgets, for different data types different methods are called:
GetValue for strings, GetValueAsLong for integers and so on.
In the demo there's a comment about this:
# Get/Set values in the table. The Python version of these
# methods can handle any data-type, (as long as the Editor and
# Renderer understands the type too,) not just strings as in the
# C++ version.
This comment is 100% correct. The standard renderer will not cope with an integer returned by GetValue.
But e.g. the demo GridStdEdRend.py with Python renderers will do.
If I add e.g. a GetValueAs Long method to the demo code with the standard renderer (GridCustTable.py), things work as expected for the integer types in Phonix:
def GetValue(self, row, col):
try:
return self.data[row][col]
except IndexError:
return ''
def GetValueAsLong(self, row, col):
try:
return self.data[row][col]
except IndexError:
return 0
In the sources of classic, you can find e.g. the implementation for GetValueAsLong calling Python GetValue and converting it to Long:
(in src/grid.i)
// Map the Get/Set methods for the standard non-string types to
// the GetValue and SetValue python methods.
long GetValueAsLong( int row, int col ) {
long rval = 0;
wxPyBlock_t blocked = wxPyBeginBlockThreads();
if (wxPyCBH_findCallback(m_myInst, "GetValue")) {
PyObject* ro;
PyObject* num;
ro = wxPyCBH_callCallbackObj(m_myInst, Py_BuildValue("(ii)", row, col));
if (ro && PyNumber_Check(ro)) {
num = PyNumber_Int(ro);
if (num) {
rval = PyInt_AsLong(num);
Py_DECREF(num);
}
Py_DECREF(ro);
}
}
wxPyEndBlockThreads(blocked);
return rval;
I'm not sure which is the better way: stay compatible with Classic or use the "standard" way of multiple methods.
The Classic way is probabyl more pythonic.
If I understand this correctly, Dabo has the option of using the individual methods, then it will work now. Or wait for Robin to do some magic to handle this as I think he did in Classic or come up with the magic and do a PR for it.
Right. If there are no other bugs.
For int, float etc. you may as well do the string conversion on the Python side. I'm doing it this way, which explains why I did not run into this problem...
But finally I understand why wx uses the GetName and then the GetValue. For Python that would have not been necessary.
As I won't get to this for a long time I'll copy the Dabo list, maybe someone wants to take this on.
With some basic c++ knowledge this should not be too hard, but still takes some time to get familiar with the build system.
Robin did a great job. I could build Phoenix with MediaCtrl without having to dive deeply into C++...
What I don't understand though, is the selection and availability of the backends.
With my build and also with the wxPython 2.8 demo the automatic selection (empty string for backend) does not work.
What's working in both cases is the MEDABACKEND_WMP10.
Are you using Windows? Which backends are working and how do you select?
Can you use the Quicktime backend?
Regards,
Dietmar
···
Am 19.11.2015 um 23:21 schrieb David Woods:
Last time I checked, it didn't support wxMediaCtrl, which is a must-have for me.
I admit, it's been a while since I tried Phoenix. My recollection is that NOTHING worked as far as wxMediaCtrl is concerned the last time I tried it.
I have created a program for the qualitative analysis of data and need to support as many formats as I can. I need both the WMP10 and QuickTime backends to work on Windows, as the different back ends support different formats that my customers are used to using.
After my next release, I'll take a look at the latest Phoenix release. I'm encouraged you've been able to get it to work.
David
···
On 11/24/2015 04:06 PM, Dietmar Schwertberger wrote:
Am 19.11.2015 um 23:21 schrieb David Woods:
Last time I checked, it didn't support wxMediaCtrl, which is a must-have for me.
Robin did a great job. I could build Phoenix with MediaCtrl without having to dive deeply into C++...
What I don't understand though, is the selection and availability of the backends.
With my build and also with the wxPython 2.8 demo the automatic selection (empty string for backend) does not work.
What's working in both cases is the MEDABACKEND_WMP10.
Are you using Windows? Which backends are working and how do you select?
Can you use the Quicktime backend?
I admit, it's been a while since I tried Phoenix. My recollection is that NOTHING worked as far as wxMediaCtrl is concerned the last time I tried it.
As of now, in the release there is no MediaCtrl, so it's no surprise that nothing works....
I have created a program for the qualitative analysis of data and need to support as many formats as I can. I need both the WMP10 and QuickTime backends to work on Windows, as the different back ends support different formats that my customers are used to using.
If you can provide some code examples, I can test.
It would be good to have three examples that work under older wxPython versions:
- one that selects the backend automatically
- one that works with / requires WMP10
- one that works with / requires Quicktime
(preferably with some video/audio files that are available publically)
Currently I'm reading about Git. Once I understand the workflows around submodules, I think I can upload the changes to Github for testing.
As far as I have done most all the porting work on the wxPython demo… It is alright for a user not wanting some of the custom widgets like DynamicSash or external libs for example MediaCtrl that are not ported yet…
But besides the libs and some other stuff that Robin hasn’t gotten to yet, for the most part, it works for general use already.
At the moment look out for problems with FlatMenu. It imports but hard crashes on Popup.
As
far as AGW/AUI I personally have “almost completely bugfree” working code and fixes, but a few things remain to be looked over.
SourceCoder works completely xwx(Classic/Phoenix Py2/Py3) besides the unported modules and small stuff, so yea…
I’m satisfied.
BTW… Still primarily running Py2.7.# and wxPy3.0.1.1+ preferably wxPy3.0.2