ANN: PyAUI 0.9.2

Gavana_Andrea · April 21, 2006, 1:36pm

Hello NG,

A new release of wxAUI has come out in these days, so I am keeping PyAUI synchronized with it. There are not particular enhancements with respect to PyAUI 0.9.1, only some minor maquillage and better event handling, plus some small bug fixes. The folks at Kirix has added the so-called "wxMac-support" for wxAUI, but as far as I know Chris Mellon has already provided me (some months ago) with everything needed to run PyAUI on Mac. They have just added some whistles and bells to improve (?) appearance on Mac, but I won't go into their implementation because I don'y have a Mac to test the results. Probably Chris could help me in implementing this fancy stuff for Mac, but I don't think it is vital to PyAUI.

BTW, PyAUI 0.9.2 implements the following features/fixes:

Fix to pass more unused events through
Fix to allow floating windows to receive idle events
Fix for minimizing/maximizing problem with transparent hint pane
Fix to not paint empty hint rectangles
Some maquillage/speed improvements

For the moment, I have uploaded the source and the demo here:

http://xoomer.virgilio.it/infinity77/eng/freeware.html#pyaui

Or, if you prefer in italian :

http://xoomer.virgilio.it/infinity77/ita/freeware.html#pyaui

I still don’t have internte access + ftp access, so I can’t upload the source in the web space that Peter Damoc has kindly provided to me. If anyone experiences some problems in downloading from xoomer.virgilio.it, please let me know. In 1 week I should be internet-up and running

Enjoy!

Andrea.

···

Andrea Gavana
(gavana@kpo.kz)

Reservoir Engineer

KPDL

4, Millbank

SW1P 3JA London

Direct Tel: +44 (0) 20 717 08936

Mobile Tel: +44 (0) 77 487 70534

Fax: +44 (0) 20 717 08900

Web:
http://xoomer.virgilio.it/infinity77

¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

David_Pratt · April 21, 2006, 3:24pm

Hi Andrea. The new release is not behaving well on Mac pulling the menubars out of the dock and putting them back or closing panes. It seems to be having some trouble with mouse events. Sizing of the menus bar is also a bit strange. When pulling out the menubar in some cases it will lose its padding. A good thing, however, is that when the menus are pulled from the dock they are no longer chrome as they used to be which is a bit more natural for appearance.

Because wxPython and PyAUI is designed to provide cross platform functionality, could I suggest that you revert this to a beta until there is feedback and fixes for the other platforms (at least Mac since this is the other primary target for the interface tool).

Andrea and Robin. Is there a way that projects like this can go under source control in wxPython's cvs or that a svn be set up as a wxPython projects collective (that are not included in the source distribution) This would at the very least bring the sources together under version control (which would be better for everyone). I am grateful for the contributions that Andrea and others are making but feel it could only be a benefit for maintaining projects that make use of it since it is difficult at best to identify where code changes are being made. Many thanks.

Regards,
David

Gavana, Andrea wrote:

···

Hello NG,
A new release of wxAUI has come out in these days, so I am keeping PyAUI synchronized with it. There are not particular enhancements with respect to PyAUI 0.9.1, only some minor maquillage and better event handling, plus some small bug fixes. The folks at Kirix has added the so-called "wxMac-support" for wxAUI, but as far as I know Chris Mellon has already provided me (some months ago) with everything needed to run PyAUI on Mac. They have just added some whistles and bells to improve (?) appearance on Mac, but I won't go into their implementation because I don'y have a Mac to test the results. Probably Chris could help me in implementing this fancy stuff for Mac, but I don't think it is vital to PyAUI.
BTW, PyAUI 0.9.2 implements the following features/fixes:
* Fix to pass more unused events through
* Fix to allow floating windows to receive idle events
* Fix for minimizing/maximizing problem with transparent hint pane
* Fix to not paint empty hint rectangles
* Some maquillage/speed improvements
For the moment, I have uploaded the source and the demo here:
http://xoomer.virgilio.it/infinity77/eng/freeware.html#pyaui
Or, if you prefer in italian :
http://xoomer.virgilio.it/infinity77/ita/freeware.html#pyaui
I still don't have internte access + ftp access, so I can't upload the source in the web space that Peter Damoc has kindly provided to me. If anyone experiences some problems in downloading from xoomer.virgilio.it, please let me know. In 1 week I should be internet-up and running
Enjoy!
Andrea.

_________________________________________

*Andrea Gavana* (gavana@kpo.kz <mailto:gavana@kpo.kz>)

/Reservoir Engineer/

KPDL

4, Millbank

SW1P 3JA London

Direct Tel: +44 (0) 20 717 08936

Mobile Tel: +44 (0) 77 487 70534

Fax: +44 (0) 20 717 08900

Web: http://xoomer.virgilio.it/infinity77

¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

Robin · April 21, 2006, 6:07pm

David Pratt wrote:

Andrea and Robin. Is there a way that projects like this can go under source control in wxPython's cvs or that a svn be set up as a wxPython projects collective (that are not included in the source distribution) This would at the very least bring the sources together under version control (which would be better for everyone). I am grateful for the contributions that Andrea and others are making but feel it could only be a benefit for maintaining projects that make use of it since it is difficult at best to identify where code changes are being made. Many thanks.

I've got it on my ToDo list to pull some of Andrea's contribs into the wxPython distribution, but this is a good idea too. Kind of a staging area that acts as a central collection point of potential contribs, and where they can get some wider testing and refinement and etc. before becoming "official." I'll give it some more thought.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

David_Pratt · April 21, 2006, 6:34pm

Hi Robin! Thanks for your reply. Yes, and the other benefit would be broader exposure to the projects in general since - they would be together. I believe this could lead to broader interest and collaborative development, possibly faster development cycles, and good quality code (since there would more eyes on it). There are many good folks in this community and I think it would be great if we were growing and incubating ideas together as well as collaborating on some excellent components for everyone's benefit.

Regards,
David

Robin Dunn wrote:

···

David Pratt wrote:

Andrea and Robin. Is there a way that projects like this can go under source control in wxPython's cvs or that a svn be set up as a wxPython projects collective (that are not included in the source distribution) This would at the very least bring the sources together under version control (which would be better for everyone). I am grateful for the contributions that Andrea and others are making but feel it could only be a benefit for maintaining projects that make use of it since it is difficult at best to identify where code changes are being made. Many thanks.

I've got it on my ToDo list to pull some of Andrea's contribs into the wxPython distribution, but this is a good idea too. Kind of a staging area that acts as a central collection point of potential contribs, and where they can get some wider testing and refinement and etc. before becoming "official." I'll give it some more thought.

Chris_Barker1 · April 21, 2006, 6:58pm

a svn be set up as a wxPython projects collective (that are not included in the source distribution) This would at the very least bring the sources together under version control (which would be better for everyone).

I like this idea. Maybe a wxPython-Extras Sourceforge project? If someone creates it, I'll put FloatCanvas in it. I've considered setting up a Sourceforge project for just FloatCanvas, but it seems like overkill. Grouping it with other projects does make sense.

By the way, FloatCanvas is in the wxPython lib, but I upgrade and change it on a faster (and plain different) schedule than wxPython itself, and I don't have write permission to the wx projects anyway, so it makes sense to have it elsewhere.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

Kevin_Ollivier4 · April 21, 2006, 7:17pm

Hi David,

Hi Andrea. The new release is not behaving well on Mac pulling the menubars out of the dock and putting them back or closing panes. It seems to be having some trouble with mouse events. Sizing of the menus bar is also a bit strange. When pulling out the menubar in some cases it will lose its padding. A good thing, however, is that when the menus are pulled from the dock they are no longer chrome as they used to be which is a bit more natural for appearance.

Because wxPython and PyAUI is designed to provide cross platform functionality, could I suggest that you revert this to a beta until there is feedback and fixes for the other platforms (at least Mac since this is the other primary target for the interface tool).

Andrea and Robin. Is there a way that projects like this can go under source control in wxPython's cvs or that a svn be set up as a wxPython projects collective (that are not included in the source distribution)

I think the idea of a repository is a good one, though I think it should be separate from the official wxPython sources. There is wxCode (http://wxcode.sf.net), BTW, which is one possible option; or a separate SF project could be created for this.

I also think wxPython should have a way of picking up add-ons from certain directories so they can be referenced with syntax such as "import wx.addons.pyaui", or perhaps "import wx.ext.pyaui". The benefit of this is that wxPython extensions don't need to be kept in local source trees and copied over for each new project, nor do developers need to clutter their site-packages with a bunch of wxPython extensions at the root of site-packages. They can all go into one local and/or system extensions dir, which will be picked up by the wxPython installation. Furthermore, we could have the demo auto-load any modules which have a "demo" submodule and put that demo into an "add-ons" section in the wxPython demo. To make this simple for people, we could offer extension developers a template setup.py and setup.cfg that installs the extensions to the right places.

Extensions that prove to be highly reliable, work well on all major platforms, and get at least some degree of maintenance, could be periodically merged into the official wxPython sources. Although, at the same time, I think that if we have a way of managing extensions and integrate the ability to find and install extensions into wxPython (e.g. have links to the online repository right in the wxPython demo or even having an 'extensions browser' where you can click 'install this extension' if you want it), then the process of finding and installing add-ons would be so simple that calls to put things into the core distribution might decrease considerably. If you look at highly successful IDEs like XCode and MSVC, they have thriving add-on communities even though very little of those add-ons actually become part of the core, and it seems to work pretty well for them.

Just some thoughts.

Thanks,

Kevin

···

On Apr 21, 2006, at 8:24 AM, David Pratt wrote:

This would at the very least bring the sources together under version control (which would be better for everyone). I am grateful for the contributions that Andrea and others are making but feel it could only be a benefit for maintaining projects that make use of it since it is difficult at best to identify where code changes are being made. Many thanks.

Regards,
David

Gavana, Andrea wrote:

Hello NG,
A new release of wxAUI has come out in these days, so I am keeping PyAUI synchronized with it. There are not particular enhancements with respect to PyAUI 0.9.1, only some minor maquillage and better event handling, plus some small bug fixes. The folks at Kirix has added the so-called "wxMac-support" for wxAUI, but as far as I know Chris Mellon has already provided me (some months ago) with everything needed to run PyAUI on Mac. They have just added some whistles and bells to improve (?) appearance on Mac, but I won't go into their implementation because I don'y have a Mac to test the results. Probably Chris could help me in implementing this fancy stuff for Mac, but I don't think it is vital to PyAUI.
BTW, PyAUI 0.9.2 implements the following features/fixes:
* Fix to pass more unused events through
* Fix to allow floating windows to receive idle events
* Fix for minimizing/maximizing problem with transparent hint pane
* Fix to not paint empty hint rectangles
* Some maquillage/speed improvements
For the moment, I have uploaded the source and the demo here:
http://xoomer.virgilio.it/infinity77/eng/freeware.html#pyaui
Or, if you prefer in italian :
http://xoomer.virgilio.it/infinity77/ita/freeware.html#pyaui
I still don't have internte access + ftp access, so I can't upload the source in the web space that Peter Damoc has kindly provided to me. If anyone experiences some problems in downloading from xoomer.virgilio.it, please let me know. In 1 week I should be internet-up and running
Enjoy!
Andrea.
_________________________________________
*Andrea Gavana* (gavana@kpo.kz <mailto:gavana@kpo.kz>)
/Reservoir Engineer/
KPDL
4, Millbank
SW1P 3JA London
Direct Tel: +44 (0) 20 717 08936
Mobile Tel: +44 (0) 77 487 70534
Fax: +44 (0) 20 717 08900
Web: http://xoomer.virgilio.it/infinity77
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

David_Pratt · April 21, 2006, 8:04pm

Hi Chris. I was thinking of something on SourceForge too but Robin should have time to think about the organization of it since the main stream code that is ready for prime-time will likely find itself in the distribution. I could be broader than incubating projects for wxPython distribution because some projects are frameworks in their own right but rely on wxPython. Wax and Dabo come to mind here.

Another benefit is release cycles for sure. There is no need to wait for a new wxPython releases to tag releases of your project and for others to work with it on this basis. At the same time, project releases ought to be something that could be incorporated into a wxPython distribution. So it should be considered alpha or beta code until the project admin has been determined it is release quality.

How about calling it the wxPython Collective since I see this a place for collaborative development? Any number of admins can be assigned to the collective. A project admin is someone responsible for the integrity of a project. Any project admin can create another admin or project. Everyone has read only access to cvs or svn sources all the way along but only the project admin for a project determines who gets write access to their project. This sort of thing. Anyway - I'm rambling.

I just read Kevin's post and these are really great ideas and a way to bring extension components into wxPython in a very nice way. Great post, Kevin! I was not aware of wxCode. This is the idea for sure but something I would really like to see this for wxPython folks so the focus stays on python and enhancing wxPython. I think wxPython has grown up and is big enough for this type of effort.

Regards,
David

Christopher Barker wrote:

···

a svn be set up as a wxPython projects collective (that are not included in the source distribution) This would at the very least bring the sources together under version control (which would be better for everyone).

I like this idea. Maybe a wxPython-Extras Sourceforge project? If someone creates it, I'll put FloatCanvas in it. I've considered setting up a Sourceforge project for just FloatCanvas, but it seems like overkill. Grouping it with other projects does make sense.

By the way, FloatCanvas is in the wxPython lib, but I upgrade and change it on a faster (and plain different) schedule than wxPython itself, and I don't have write permission to the wx projects anyway, so it makes sense to have it elsewhere.

-Chris

SPE_Stani_s_Python_E · April 21, 2006, 9:20pm

I was thinking the same for a while and thought of opening a wxPython
repository on stani.be I would use for this the Plone software center
as you can see in action here:
http://plone.org/products

It gives the possiblility for any developper to register and to submit
its software with a screenshot. Visitors can leave comments. I was
actually waiting to upgrade till the rating system is integrated as
well. Like that high quality extensions will bubble up.

This is just an offer

Stani

···

On 4/21/06, Kevin Ollivier <kevino@tulane.edu> wrote:

On Apr 21, 2006, at 8:24 AM, David Pratt wrote:
I think the idea of a repository is a good one, though I think it
should be separate from the official wxPython sources.

--

http://pythonide.stani.be/screenshots
http://pythonide.stani.be/manual/html/manual.html

Kevin_Ollivier4 · April 21, 2006, 9:48pm

Hi Stani,

I think the idea of a repository is a good one, though I think it
should be separate from the official wxPython sources.

I was thinking the same for a while and thought of opening a wxPython
repository on stani.be I would use for this the Plone software center
as you can see in action here:
http://plone.org/products

It gives the possiblility for any developper to register and to submit
its software with a screenshot. Visitors can leave comments. I was
actually waiting to upgrade till the rating system is integrated as
well. Like that high quality extensions will bubble up.

This is just an offer

Actually, that's pretty much the philosophy behind the wxCommunity download center:

http://wxcommunity.com/modules.php?op=modload&name=Downloads&file=index

I don't have the screenshot ability yet (though I think it's a really good idea and hopefully can add it at some point soon), but the rest of the functionality you describe is there. You can also rate the software, and the user can see which software is frequently downloaded, etc. and sort by that. Users can also write thorough reviews and put them in the reviews section of the site. Of course, you need to register an account to edit, add entries, etc. wxCommunity is also linked in several prominent places in the new wxWidgets.org site (http://wxwidgets.org/newsite) which is about to go live, maybe this weekend or next. (I need to do some tweaks to randomly load screenshots onto the front page.) In fact, once the new site goes live, it will effectively be the 'official' site for finding wxWidgets components and applications.

Unfortunately, very little (wx)Python-related stuff is on wxCommunity right now. ;-/ But that's easy to change...

Thanks,

Kevin

···

On Apr 21, 2006, at 2:20 PM, SPE Stani's Python Editor wrote:

On 4/21/06, Kevin Ollivier <kevino@tulane.edu> wrote:

On Apr 21, 2006, at 8:24 AM, David Pratt wrote:

Stani
--
http://pythonide.stani.be
http://pythonide.stani.be/screenshots
http://pythonide.stani.be/manual/html/manual.html

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

Kevin_Ollivier4 · April 22, 2006, 7:55am

Hi David,

Hi Chris. I was thinking of something on SourceForge too but Robin should have time to think about the organization of it since the main stream code that is ready for prime-time will likely find itself in the distribution. I could be broader than incubating projects for wxPython distribution because some projects are frameworks in their own right but rely on wxPython. Wax and Dabo come to mind here.

Another benefit is release cycles for sure. There is no need to wait for a new wxPython releases to tag releases of your project and for others to work with it on this basis. At the same time, project releases ought to be something that could be incorporated into a wxPython distribution. So it should be considered alpha or beta code until the project admin has been determined it is release quality.

How about calling it the wxPython Collective since I see this a place for collaborative development? Any number of admins can be assigned to the collective. A project admin is someone responsible for the integrity of a project. Any project admin can create another admin or project. Everyone has read only access to cvs or svn sources all the way along but only the project admin for a project determines who gets write access to their project. This sort of thing. Anyway - I'm rambling.

I just read Kevin's post and these are really great ideas and a way to bring extension components into wxPython in a very nice way. Great post, Kevin! I was not aware of wxCode. This is the idea for sure but something I would really like to see this for wxPython folks so the focus stays on python and enhancing wxPython. I think wxPython has grown up and is big enough for this type of effort.

If we go this route, we'll effectively have to rebuild the functionality of their site, or at least duplicate it. I think for open source projects, it makes more sense to pool resources together because the less amount of work that needs to be done, the more likely it is that it will get done. I also think that there's an advantage in numbers, because the more projects on the wxCode site, the "bigger" the wx community looks, and thus the more perspective new users feel comfortable with it. In that sense, I think it's better for wxCode to have 200 projects, for example, than to have two sites each with 100 projects in them. Even if you can't use all those contributions, the number of contributions gives you an idea of how active the community, and thus the project, on the whole is.

What about having the wxCode interface be customizable, so that if you select wxPython as your language (or you click on a link like wxCode - wxWidgets components download | SourceForge.net), only wxPython related items are shown? Everything not Python-related disappears unless you select "langauge = all" from a drop down box or whatever. I don't know if this would be a lot of work for them, but since everything's in a database, it may not be too difficult to do. Of course, this is assuming the wxCode folks are willing to help us out on this, or someone here is willing to help the wxCode folks.

Regards,

Kevin

···

On Apr 21, 2006, at 1:04 PM, David Pratt wrote:

Regards,
David

Christopher Barker wrote:

a svn be set up as a wxPython projects collective (that are not included in the source distribution) This would at the very least bring the sources together under version control (which would be better for everyone).

I like this idea. Maybe a wxPython-Extras Sourceforge project? If someone creates it, I'll put FloatCanvas in it. I've considered setting up a Sourceforge project for just FloatCanvas, but it seems like overkill. Grouping it with other projects does make sense.
By the way, FloatCanvas is in the wxPython lib, but I upgrade and change it on a faster (and plain different) schedule than wxPython itself, and I don't have write permission to the wx projects anyway, so it makes sense to have it elsewhere.
-Chris

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

David_Pratt · April 22, 2006, 2:24pm

Hi Kevin. I think the idea of pooling with wxCode with a language parameter to select python related material is a good solution. It is practical and will be less to maintain since ultimately it comes down to people putting effort in to get something out. I am sure we don't need to duplicate the resource to get what we all seem to want.

Yesterday I was looking a bit at the beginnings of the zope foundation (zf) and their upcoming effort to certify software that will provided through a common repository. I have to say the ideas are very appealing and the grading system will have developers competing to ensure their packages meet the gold standard (of bronze, silver, gold). All code will be released as ZPL (a liberal license for commercial work) as a requirement. There is also some talk that it may go to a python license Much of the emphasis of zope2 to zope3 was to create a natural python approach that does not impose any restriction on how you use zope packages with other packages. I have to say it was very encouraging and perhaps there are interesting ideas here.

The point in discussing the zope foundation work is that they have a site in the repository that is designed to work with this in mind. It has the necessary peices as well and this work itself is under the ZPL so could be used potentially.

I have to say the read of the zf also got me thinking whether wxpython could not be move to a python license. I realize that it is derived from wxWidgets source but are we not talking binaries to create a wxpython distribution. That said, it could be released as any license. Everything else is simply python. I find one thing that is obviously different about wxPython is developing a commercial product. With wxWidgets, compile and your worries are over and you can release in any licensing configuration you want. But with packaging like py2app for example, sources are together with byte compiled files. If your sources are available then they become GPL which is an undesirable side effect (if you are concerned about your sources in a commercial context or have embedded some company's logic). In any case these are some thoughts worth some consideration and it would be great if Robin and others could comment on this. I think the trend toward more open and liberal python expands its potential.

I am happy for the discussion this has stimulated about possible approaches. I guess ultimately the direction ought to be decided somehow collectively by the community with Robin's input since he has a stake in how any new code will be integrated in a distribution.

Regards,
David

Kevin Ollivier wrote:

···

Hi David,

On Apr 21, 2006, at 1:04 PM, David Pratt wrote:

Hi Chris. I was thinking of something on SourceForge too but Robin should have time to think about the organization of it since the main stream code that is ready for prime-time will likely find itself in the distribution. I could be broader than incubating projects for wxPython distribution because some projects are frameworks in their own right but rely on wxPython. Wax and Dabo come to mind here.

Another benefit is release cycles for sure. There is no need to wait for a new wxPython releases to tag releases of your project and for others to work with it on this basis. At the same time, project releases ought to be something that could be incorporated into a wxPython distribution. So it should be considered alpha or beta code until the project admin has been determined it is release quality.

How about calling it the wxPython Collective since I see this a place for collaborative development? Any number of admins can be assigned to the collective. A project admin is someone responsible for the integrity of a project. Any project admin can create another admin or project. Everyone has read only access to cvs or svn sources all the way along but only the project admin for a project determines who gets write access to their project. This sort of thing. Anyway - I'm rambling.

I just read Kevin's post and these are really great ideas and a way to bring extension components into wxPython in a very nice way. Great post, Kevin! I was not aware of wxCode. This is the idea for sure but something I would really like to see this for wxPython folks so the focus stays on python and enhancing wxPython. I think wxPython has grown up and is big enough for this type of effort.

If we go this route, we'll effectively have to rebuild the functionality of their site, or at least duplicate it. I think for open source projects, it makes more sense to pool resources together because the less amount of work that needs to be done, the more likely it is that it will get done. I also think that there's an advantage in numbers, because the more projects on the wxCode site, the "bigger" the wx community looks, and thus the more perspective new users feel comfortable with it. In that sense, I think it's better for wxCode to have 200 projects, for example, than to have two sites each with 100 projects in them. Even if you can't use all those contributions, the number of contributions gives you an idea of how active the community, and thus the project, on the whole is.

What about having the wxCode interface be customizable, so that if you select wxPython as your language (or you click on a link like wxCode - wxWidgets components download | SourceForge.net), only wxPython related items are shown? Everything not Python-related disappears unless you select "langauge = all" from a drop down box or whatever. I don't know if this would be a lot of work for them, but since everything's in a database, it may not be too difficult to do. Of course, this is assuming the wxCode folks are willing to help us out on this, or someone here is willing to help the wxCode folks.

Regards,

Kevin

Regards,
David

Christopher Barker wrote:

a svn be set up as a wxPython projects collective (that are not included in the source distribution) This would at the very least bring the sources together under version control (which would be better for everyone).

I like this idea. Maybe a wxPython-Extras Sourceforge project? If someone creates it, I'll put FloatCanvas in it. I've considered setting up a Sourceforge project for just FloatCanvas, but it seems like overkill. Grouping it with other projects does make sense.
By the way, FloatCanvas is in the wxPython lib, but I upgrade and change it on a faster (and plain different) schedule than wxPython itself, and I don't have write permission to the wx projects anyway, so it makes sense to have it elsewhere.
-Chris

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

Robin · April 23, 2006, 8:40am

Kevin Ollivier wrote:

I just read Kevin's post and these are really great ideas and a way to bring extension components into wxPython in a very nice way. Great post, Kevin! I was not aware of wxCode. This is the idea for sure but something I would really like to see this for wxPython folks so the focus stays on python and enhancing wxPython. I think wxPython has grown up and is big enough for this type of effort.

If we go this route, we'll effectively have to rebuild the functionality of their site, or at least duplicate it. I think for open source projects, it makes more sense to pool resources together because the less amount of work that needs to be done, the more likely it is that it will get done. I also think that there's an advantage in numbers, because the more projects on the wxCode site, the "bigger" the wx community looks, and thus the more perspective new users feel comfortable with it. In that sense, I think it's better for wxCode to have 200 projects, for example, than to have two sites each with 100 projects in them. Even if you can't use all those contributions, the number of contributions gives you an idea of how active the community, and thus the project, on the whole is.

I really hate to say something like this but I would rather not do this as part of wxCode in order to not have to deal with Otto and his attitude.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

Robin · April 23, 2006, 8:42am

David Pratt wrote:

I have to say the read of the zf also got me thinking whether wxpython could not be move to a python license. I realize that it is derived from wxWidgets source but are we not talking binaries to create a wxpython distribution. That said, it could be released as any license. Everything else is simply python. I find one thing that is obviously different about wxPython is developing a commercial product. With wxWidgets, compile and your worries are over and you can release in any licensing configuration you want. But with packaging like py2app for example, sources are together with byte compiled files. If your sources are available then they become GPL which is an undesirable side effect (if you are concerned about your sources in a commercial context or have embedded some company's logic). In any case these are some thoughts worth some consideration and it would be great if Robin and others could comment on this. I think the trend toward more open and liberal python expands its potential.

Kevin and I talked about this a bit off-list today and I have to admit that I am now a little less sure about details than before, but here is how I see the intent of, or the spirit of the license as it applies to wxPython:

* You can distribute your programs that *use* wxPython in whatever form you wish, under whatever license you wish.

Kevin brought up some questions regarding the wxWidgets license and the LGPL and how it all applies to distributing Python apps. Here's my take:

* While .pyc files are not object code, they can be considered non-source binaries, and in my mind are equivalent to object code as far as the license is concerned.

* Py2exe (and the other similar tools I've looked at) bundle together the .pyc files needed for the app so there is no source code being distributed when building an executable this way. So even if distributing source automatically converted it to LGPL, (maybe I'm blind but I don't see that in the license) it wouldn't apply in this case. Also, since we are considering that .pyc files are equivalent to binary object code, then the wxWidgets license exception applies and you are free to distribute yours however you wish.

* Eventhough the py2exe type of tools bundle together your proprietary .pyc files and the wx-licensed or lgpl-licensed .pyc files, they are not permanently (static-)linked together. They can easily be separated into individual modules by anyone with an unzip tool, so I think that this satisfies the requirements of the LGPL and would not require that your code become LGPL.

* I am not a lawyer.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

David_Pratt · April 23, 2006, 1:25pm

Hi Robin. Many thanks for your comments. I guess my thoughts were not so much on the merit of the existing license because as Kevin has pointed out it perhaps leaves things less clear cut. Your absolutely right, we are not lawyers - this is the point. We should not need to be lawyers to understand what we are working with. More than this, I believe most python programmers want transparency in licensing. When you program with the python distribution, you do not have to think about using any part of the python distribution when it comes to licensing.

My thought was that because wxPython is distributed as binaries of modified wxWidgets sources, there exists the possibility to change the licensing of wxPython from wxWidgets license to the Python license. This removes all grey area. There is nothing preventing wxPython project from using a different form of licensing that brings it in line with the python language. It is in the same realm as something like pyLucene since you are dealing with compiled objects. wxPython apps only participate with binary objects in wxPython distribution, not the c code directly from wxWidgets. That said, I do not see a need to inherit wxWidgets license - but an opportunity for wxPython community to explore a different possibility, licensing for the python programmer that is as transparent as using the Python license. What could be better?

Regards,
David

Robin Dunn wrote:

···

David Pratt wrote:

I have to say the read of the zf also got me thinking whether wxpython could not be move to a python license. I realize that it is derived from wxWidgets source but are we not talking binaries to create a wxpython distribution. That said, it could be released as any license. Everything else is simply python. I find one thing that is obviously different about wxPython is developing a commercial product. With wxWidgets, compile and your worries are over and you can release in any licensing configuration you want. But with packaging like py2app for example, sources are together with byte compiled files. If your sources are available then they become GPL which is an undesirable side effect (if you are concerned about your sources in a commercial context or have embedded some company's logic). In any case these are some thoughts worth some consideration and it would be great if Robin and others could comment on this. I think the trend toward more open and liberal python expands its potential.

Kevin and I talked about this a bit off-list today and I have to admit that I am now a little less sure about details than before, but here is how I see the intent of, or the spirit of the license as it applies to wxPython:

* You can distribute your programs that *use* wxPython in whatever form you wish, under whatever license you wish.

Kevin brought up some questions regarding the wxWidgets license and the LGPL and how it all applies to distributing Python apps. Here's my take:

* While .pyc files are not object code, they can be considered non-source binaries, and in my mind are equivalent to object code as far as the license is concerned.

* Py2exe (and the other similar tools I've looked at) bundle together the .pyc files needed for the app so there is no source code being distributed when building an executable this way. So even if distributing source automatically converted it to LGPL, (maybe I'm blind but I don't see that in the license) it wouldn't apply in this case. Also, since we are considering that .pyc files are equivalent to binary object code, then the wxWidgets license exception applies and you are free to distribute yours however you wish.

* Eventhough the py2exe type of tools bundle together your proprietary .pyc files and the wx-licensed or lgpl-licensed .pyc files, they are not permanently (static-)linked together. They can easily be separated into individual modules by anyone with an unzip tool, so I think that this satisfies the requirements of the LGPL and would not require that your code become LGPL.

* I am not a lawyer.

SPE_Stani_s_Python_E · April 23, 2006, 4:40pm

Hi Stani,

>> I think the idea of a repository is a good one, though I think it
>> should be separate from the official wxPython sources.
>
> I was thinking the same for a while and thought of opening a wxPython
> repository on stani.be I would use for this the Plone software center
> as you can see in action here:
> http://plone.org/products
>
> It gives the possiblility for any developper to register and to submit
> its software with a screenshot. Visitors can leave comments. I was
> actually waiting to upgrade till the rating system is integrated as
> well. Like that high quality extensions will bubble up.
>
> This is just an offer

Actually, that's pretty much the philosophy behind the wxCommunity
download center:

NameBright - Coming Soon

Hi Kevin,

this is great! I was not aware of it.

I don't have the screenshot ability yet (though I think it's a really
good idea and hopefully can add it at some point soon),

Screenshots are crucial for a gui repository. At least provide a
screenshot url. For the rest it looks perfect already.

As others have mentioned, for me it is crucial that there is a
difference between wxPython and wxWidgets code. It's ok if it is a
setting, but it should be also be available as an url. (eg adding
?section=wxpython)

I would propose the following sections:
- wxWidgets
- wxPython
- xrc (*.xrc)
- wxGlade (*.wxg)

I've started working with xrc more and more. XRCed is very stable and
offers wonderful possibilities. You could argue that offering xrc
without code doesn't make sense, but I think it does. Designing and
building nice or complex guis takes time. It would be fun if C++ or
wxPython programs could share the same ui files. It stimulates
separating the gui from the code logic. Same is true for wxGlade, but
as it is quite unstable, I'm now more leaning to XRCed.

Stani

···

On 4/21/06, Kevin Ollivier <kevino@tulane.edu> wrote:

On Apr 21, 2006, at 2:20 PM, SPE Stani's Python Editor wrote:
> > On 4/21/06, Kevin Ollivier <kevino@tulane.edu> wrote:
>> On Apr 21, 2006, at 8:24 AM, David Pratt wrote:

--

http://pythonide.stani.be/screenshots
http://pythonide.stani.be/manual/html/manual.html

Kevin_Ollivier4 · April 23, 2006, 8:22pm

Hi Robin,

Kevin Ollivier wrote:

I just read Kevin's post and these are really great ideas and a way to bring extension components into wxPython in a very nice way. Great post, Kevin! I was not aware of wxCode. This is the idea for sure but something I would really like to see this for wxPython folks so the focus stays on python and enhancing wxPython. I think wxPython has grown up and is big enough for this type of effort.

If we go this route, we'll effectively have to rebuild the functionality of their site, or at least duplicate it. I think for open source projects, it makes more sense to pool resources together because the less amount of work that needs to be done, the more likely it is that it will get done. I also think that there's an advantage in numbers, because the more projects on the wxCode site, the "bigger" the wx community looks, and thus the more perspective new users feel comfortable with it. In that sense, I think it's better for wxCode to have 200 projects, for example, than to have two sites each with 100 projects in them. Even if you can't use all those contributions, the number of contributions gives you an idea of how active the community, and thus the project, on the whole is.

I really hate to say something like this but I would rather not do this as part of wxCode in order to not have to deal with Otto and his attitude.

Actually, sorry I made you have to say something like that. In all honesty, my dealings with wxCode usually involve Francesco so I had actually totally forgotten this was Otto's project. ;-/

What I suggest we do for the short term then is plan a strategy that first allows for add-ons that works with or without a repository. Until we have such a repository, contributors would have to host their contributions somewhere, of course, but I think if we have an add-ons strategy working, it will build momentum towards a repository and it will solve some significant issues as well.

So, here's what I suggest we do for the add-ons:

1) Create a wxAddons (name?) module that gets installed with wxPython, but at the top level of site-packages. It will contain an __init__.py file containing methods to load all the files/submodules inside it when it is imported, and also methods to get the list of modules, etc. We should also have plugins define a function canLoad() that checks the version of wxPython and returns true or false. If an addon requires a certain version of wxPython, it should check for that version and bomb out with an error without having the module imported, but in such a way that other modules can continue loading. This will allow us not to have to make a wxAddons-2.6, etc.

2) Provide a setup.py template that can be used to install a module into wxAddons, or even just show what modifications would need to be made to an existing one to do so.

3) Create an Add-ons tree item whose root page loads "wxCommunity > Downloads > wxPython > Add-ons" and load the demos for whatever wxAddons that have them as child items of the Add-ons section of the tree.

Thoughts? This should be fairly simple and straightforward as some first steps, and from there we could move on to more sophisticated things.

Kevin

···

On Apr 23, 2006, at 1:40 AM, Robin Dunn wrote:

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-users-help@lists.wxwidgets.org

Chris_Barker1 · April 24, 2006, 10:05pm

Kevin Ollivier wrote:

Actually, that's pretty much the philosophy behind the wxCommunity download center:

NameBright - Coming Soon

Cool!

I did notice that under:

Category: Add-on Components

There are a number of applications:
Display Doctor 7
PhotoPerfect

Also, I think there is a need to for a development site for wxPython add on, one that support svn, etc. This looks like it provides mostly links to projects that have their own site.

I'd like to have a place for projects that might not be large enough to really need their own sourceforge project. The Add-ons idea is good, but I guess what I'm thinking is that there is stuff (like my FloatCanvas) that needs a site, but is also part of wx.lib, but, like Andrea, I kind of want to be reviewing it before updates go into wx.lib.

Does wxCode provide for this kind of use?

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

Robin · April 24, 2006, 11:00pm

Christopher Barker wrote:

Also, I think there is a need to for a development site for wxPython add on, one that support svn, etc. This looks like it provides mostly links to projects that have their own site.

I'd like to have a place for projects that might not be large enough to really need their own sourceforge project. The Add-ons idea is good, but I guess what I'm thinking is that there is stuff (like my FloatCanvas) that needs a site, but is also part of wx.lib, but, like Andrea, I kind of want to be reviewing it before updates go into wx.lib.

I've applied for a new SF project for this and we can put a subversion repository there. I think that whether or not we also use it for a website or just automate some integration with the wxCommunity site can be decided later.

···

--
Robin Dunn
Software Craftsman
http://wxPython.org Java give you jitters? Relax with wxPython!

Chris_Barker1 · April 24, 2006, 11:24pm

Robin Dunn wrote:

I've applied for a new SF project for this and we can put a subversion repository there. I think that whether or not we also use it for a website or just automate some integration with the wxCommunity site can be decided later.

Sounds great! Let us know the details when you have them.

-Chris

···

--
Christopher Barker, Ph.D.
Oceanographer

NOAA/OR&R/HAZMAT (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception

Chris.Barker@noaa.gov

David_Pratt · April 24, 2006, 11:26pm

Hi Robin. Thanks for this effort!

Regards
David

Robin Dunn wrote:

···

Christopher Barker wrote:

Also, I think there is a need to for a development site for wxPython add on, one that support svn, etc. This looks like it provides mostly links to projects that have their own site.

I'd like to have a place for projects that might not be large enough to really need their own sourceforge project. The Add-ons idea is good, but I guess what I'm thinking is that there is stuff (like my FloatCanvas) that needs a site, but is also part of wx.lib, but, like Andrea, I kind of want to be reviewing it before updates go into wx.lib.

I've applied for a new SF project for this and we can put a subversion repository there. I think that whether or not we also use it for a website or just automate some integration with the wxCommunity site can be decided later.