Hi,

to start with my reply:
Python on OSX:
Snow Leopard (10.6.x) comes standard with 2.5 and 2.6. 2.6 being the default
active version.
Leopard (10.5.x) comes standard with 2.5.1.
Tiger (10.4.x) comes with 2.4.
As far as I can tell the new Lion (10.7.x) comes with 2.7.2 installed.

I'm on Snow Leopard and currently 70% of the users are.

>From the python.org site I already installed the python 2.7.2 installer and
the 3.2.1 installer. Both work and with some symlink modifications and
environment settings both work fine. According to python.org both installers
will run from 10.3 to 10.6 (no data on OSX Lion yet I assume).
I also installed python 2.7 from macports which works also with the proper
symlinks and env settings (getting a bit of a mess now).

Please note that despite my concerns I'm not against python and it's the
second priority for me on OSX (that is: second to to getting PTBatcherGui
run properly from Hugin).


2011/8/11 kfj <_...@yahoo.com>

>
> I wonder if there isn't a way to migrate the existing wxWidgets code
> to wxPython. On my (Kubuntu) system the two can coexist peacefully.
>

On OSX as well. Did some tests with other (sample) applications.


> Maybe one can wrap the wxWidgets code so that it can be called from
> wxPython, so we'd still have the old GUI but could start putting logic
> into python. I know nothing of the design concepts and implementation
> strategy behind hugin's GUI, but maybe someone from that end can
> comment? Like point me to a technical outline?
>
> > > By now the python
> > > integration is certainly a help for new functionality but it's not user
> > > friendly.
>
> I disagree. From the code side the python interface is a self-
> contained module which is included into hugin's code by means of a
> single function declaration. It doesn't get simpler than that.
> Extremely user-friendly. From the GUI side, when you get a plugin you
> see a new menu entry show up which you can click on. Something
> happens. What can be more user-friendly? I think you may not even have
> seen it in action, because you haven't managed to get it to run on Mac
> OS. The user-unfriendly thing here is your OS of choice which put's
> spanners in your works when you're trying to port free software to it.
> And comes up with a new spanner every so often and even charges you
> for it.
>
>
Point taken.


>
> as far as I know, hsi/hpi runs just fine on Windows, using either
> python 2.X or 3.X, thanks to Thomas' work on the code. Where's the
> issue? On MacOS, the issue is that we have noone who has a sound
> understanding of how it needs to be linked and integrated into the
> system - you've demonstrated it compiles there with a bit of
> modification, but the rest never worked. That's an issue. Whatever
> python code I wrote was written on a python 2.6 system, so it's sure
> compatible. If Thomas got it to run on Windows, it should really be no
> problem on MacOS which is even a UNIX system in disguise.
>
>
I mentioned in our conversations 2 months ago that I couldn't get a decent
hsi/hpi compiled using direct gcc and cmake.
Just before my holidays I mentioned I did manage to build a decent hsi/hpi
 from XCode. Somehow the direct gcc/cmake version misses some
compilation/link parameters which I still haven't found.
Creating a bundle from XCode with this python hsi/hpi did work too, so I got
a menu with scripts.
Clicking a script made Hugin crash.

We (I) do lack the knowledge to properly debug this.



> > On what basis do you say that Python should be fully backward compatible
> to at
> > least 2.6?  why not 2.4?  or 3.2?
>
> I wonder that myself. But it's probably because on MacOS, python is
> already part of the system. So it's easiest to go with what there is,
> rather than installing a different python version in parallel to work
> with hsi/hpi. Anyway, I don't see the problem.
>
> See my remarks in the top of this mail.

Maybe I'm too over concerned. I've read the remarks and arguments from both
you and Yuv. I agree on most of them, but not all. I don't want to go into
it, as only the future will tell.
If we can pull this off (cleaner, smaller code base and better integration
with (wx)Python), I'm the last to try to stop it.


Harry

-- 
You received this message because you are subscribed to the Google Groups 
"Hugin and other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

Reply via email to