Couldn't all this be avoided by reverting to all the 2.4 calling
methods, and when you want to call with tuples you have an
additional variation of the function name... (I'm sure this idea is
nothing new.)
window.____(x, y, ...)
and when you want to use tuples as parameters, use a function
called window.____Tuple((x,y), ....)?
for instance:
sizer = wx.BoxSizer(wx.VERTICAL)
sizer.Add((20, 20), 0, 0, 0)
changes to:
sizer = wx.BoxSizer(wx.VERTICAL)
sizer.AddTuple((20, 20), 0, 0, 0)
My only other idea is to change the import name of wxwidgets,
instead of:
import wx
we would have
import wx2522 as wx
I realize that I can avoid all this in the code that I write
by using wxSize objects, but my problem is running other
people's code.
I'm afraid that this issue is going to hurt
the popularity of wxPython.
-Jim
···
-----Original Message-----
From: David Fraser [mailto:davidf@sjsoft.com]
Robin Dunn wrote:
> Chris Barker wrote:
>> Robin Dunn wrote:
>>> James Carroll wrote:
>>
>>>> Is there any way that I can have both 2.5 and 2.4 installed so
>>>> that if a program fails with one, I can try it with the other?
>>>>
>>> Yes, there has been lots of discussion of this over the past few
>>> months. Check the archives.
>>
>>
>>
>> Speaking of which, is there any chance that a built-in way
to specify
>> the wxPython version will be implemented for this release? I think
>> it's really clear that this is needed:
>
>
> There are still some issues to work out for the various
platforms and
> installers. For example there can not be any overlapping
files between
> any two releases or you'll get conflicts and the RPMs (for example)
> will not install any but the first without being forced. We
currently
> have the various scripts that get installed to {prefix}/bin
and with
> the new scheme we will have the version selector and bootstrapping
> modules that will get installed in site-packages that will
conflict,
> so I need to figure out a way that works for all platforms, package
> managers and installers that these files won't conflict.The version selector and bootstrapping modules could
initially be made
separate to the main release.
The path files could then be set up so that if you have multiple
versions installed one will be selected (at random) but that
shouldn't
be common... anyone at present who wants to use multiple
versions could
do that by installing the multiversion packageThe binary files are more difficult. Long term it seems like the best
solution would be for each binary to be a script that launches the
appropriate binary using the version selector. In fact, since
all of the
binaries other than wxrc are python scripts, they could be
moved into a
wxpython subpackage and called from the main script. The
trouble here is
how you handle these being present in multiple builds...> Additionally, the names of the packages will probably need
to change,
> as you can't normally have multiple copies of the same
named package
> installed on Linux or OSX. I havn't thought through all the
> implications of this yet.At least on RPM-based systems this is possible, it just requires
installing instead of upgrading. The advantage of keeping the
name the
same is that upgrades will work automatically (which is the normal
case), it just requires a little extra work from those
wanting to keep
multiple versions.>
> Anyway, to answer your question, it won't be there for this release
> but I do agree that it is important and I want to be able to start
> doing it for some 2.5.x release.I wonder if the best way to proceed is for to have a separate
'multi-versionable' build of 2.5.2.2 that those that are
wanting to do
multi-version builds can install. This would then get testing from
interested parties, and would be a step to finding out
platform-specific
problems. We could also do back-releases of multi-versionable
builds of
previous versions.David
---------------------------------------------------------------------
To unsubscribe, e-mail: wxPython-users-unsubscribe@lists.wxwidgets.org
For additional commands, e-mail:
wxPython-users-help@lists.wxwidgets.org