I remember we spoke some time ago about FlatMenu, LabelBook and
the other goodies for a possible inclusion in wx.lib (?), but in the
end we didn't get to a definitive answer, What should I do? Is it
better to wait? Or is it better for those widgets to stay where they
are right now?
I remember we spoke some time ago about FlatMenu, LabelBook and
the other goodies for a possible inclusion in wx.lib (?), but in the
end we didn't get to a definitive answer, What should I do? Is it
better to wait? Or is it better for those widgets to stay where they
are right now?
If you have time in the next few days then go for it. Otherwise it will probably need to wait for the next release.
There is also the question of where to put them, and it might be a good idea to get feedback from the others in this group about it. First a little background for everybody else: I've recently opened up a new place in the SVN for 3rd Party things to make it a little easier for people to maintain their own contributions, see https://svn.wxwidgets.org/svn/wx/wxPython/3rdParty/. So far we have XRCed and Editra there. Each developer gets a folder at that location and then I'll use svn:externals to map that folder into the main wxPython trees for each active branch of development. This allows the contributing developers to only need to maintain their code in one place instead of needing to make their changes in more than one wxPython branch. All they have to do is make their changes in the one place and make sure their code is compatible with the active wxPython branches. (Just 2.8 at the moment, but I'll be shifting focus to 2.9 soon.)
I've been thinking about moving Andrea's modules to the 3rdParty spot so he can get the same benefits, but because of a limitation of svn:externals it only works with folders, not individual files. So that means that his modules would need to be moved to a Python sub-package instead of being located directly in the wx.lib package. It wouldn't be hard to migrate to that structure, it would simply need some stub modules in wx.lib that import from the package, but I have no idea what to name that sub-package. I would prefer to have the name be something about the functional grouping of modules instead of just something like wx.lib.andrea or wx.lib.ag, but nothing comes to mind. Anybody have any better ideas?
P.S. Chris B., this would also be a good way to manage getting updates of FloatCanvas into wxPython releases! Once it is set up it would require almost zero effort on your part. (hint! hint!)
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
P.S. Chris B., this would also be a good way to manage getting updates of FloatCanvas into wxPython releases! Once it is set up it would require almost zero effort on your part. (hint! hint!)
I was just about to ask you about that...
Now that I've got FloatCanvas in SVN -- maybe you could just svn:external the existing SVN.
The other option, of course, is to make your new place the canonical one. Who would have write privileges to that?
-Chris
···
--
Christopher Barker, Ph.D.
Oceanographer
Emergency Response Division
NOAA/NOS/OR&R (206) 526-6959 voice
7600 Sand Point Way NE (206) 526-6329 fax
Seattle, WA 98115 (206) 526-6317 main reception
P.S. Chris B., this would also be a good way to manage getting updates of FloatCanvas into wxPython releases! Once it is set up it would require almost zero effort on your part. (hint! hint!)
I was just about to ask you about that...
Now that I've got FloatCanvas in SVN -- maybe you could just svn:external the existing SVN.
Yep, although in that case I would probably only pull specific revisions with the svn:external instead of letting it always get the latest, just to avoid release synchronization issues. So that would take a tiny bit more work to maintain which revision number is pulled.
The other option, of course, is to make your new place the canonical one. Who would have write privileges to that?
We don't use ACLs so it would be you plus everybody in the top half of this page: http://svn.wxwidgets.org/users.cgi. But we tend to operate with a high level of trust and people very seldom mess about in code they are not responsible for, or have a high level of familiarity with, so it works out well.
···
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
I remember we spoke some time ago about FlatMenu, LabelBook and
the other goodies for a possible inclusion in wx.lib (?), but in the
end we didn't get to a definitive answer, What should I do? Is it
better to wait? Or is it better for those widgets to stay where they
are right now?
The only one I have a concern about is FlatMenu, because that contribution will be really out of place on OS X. IMHO, if it's not the case already, we really ought to either disable it or simply use wx.Menu classes for it on Mac. Even though some devs might use it thinking "I don't intend to run this on Mac", I'm concerned that sooner or later some user will find code that does this and try it and possibly come to the conclusion that wx is about emulating Windows apps on Mac.
Thanks,
Kevin
···
On Nov 13, 2007, at 12:08 PM, Andrea Gavana wrote:
---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-dev-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-dev-help@lists.wxwidgets.org
Hi Robin & All,
I remember we spoke some time ago about FlatMenu, LabelBook and
the other goodies for a possible inclusion in wx.lib (?), but in the
end we didn't get to a definitive answer, What should I do? Is it
better to wait? Or is it better for those widgets to stay where they
are right now?
If you have time in the next few days then go for it. Otherwise it will probably need to wait for the next release.
There is also the question of where to put them, and it might be a good idea to get feedback from the others in this group about it. First a little background for everybody else: I've recently opened up a new place in the SVN for 3rd Party things to make it a little easier for people to maintain their own contributions, see https://svn.wxwidgets.org/svn/wx/wxPython/3rdParty/. So far we have XRCed and Editra there. Each developer gets a folder at that location and then I'll use svn:externals to map that folder into the main wxPython trees for each active branch of development. This allows the contributing developers to only need to maintain their code in one place instead of needing to make their changes in more than one wxPython branch. All they have to do is make their changes in the one place and make sure their code is compatible with the active wxPython branches. (Just 2.8 at the moment, but I'll be shifting focus to 2.9 soon.)
I've been thinking about moving Andrea's modules to the 3rdParty spot so he can get the same benefits, but because of a limitation of svn:externals it only works with folders, not individual files. So that means that his modules would need to be moved to a Python sub-package instead of being located directly in the wx.lib package. It wouldn't be hard to migrate to that structure, it would simply need some stub modules in wx.lib that import from the package, but I have no idea what to name that sub-package. I would prefer to have the name be something about the functional grouping of modules instead of just something like wx.lib.andrea or wx.lib.ag, but nothing comes to mind. Anybody have any better ideas?
What about mapping things? i.e. wx.lib might do "from wx.thirdparty.ag import FlatNotebook", etc. This way internally we can group the modules by developer without exposing that structure to the user (which I agree is less than ideal).
Thanks,
Kevin
···
On Nov 13, 2007, at 4:21 PM, Robin Dunn wrote:
P.S. Chris B., this would also be a good way to manage getting updates of FloatCanvas into wxPython releases! Once it is set up it would require almost zero effort on your part. (hint! hint!)
--
Robin Dunn
Software Craftsman http://wxPython.org Java give you jitters? Relax with wxPython!
---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-dev-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail: wxPython-dev-help@lists.wxwidgets.org