>> I am interested in possibly reviving the integrated Python >> scripting in Mahogany.
> Me too, eventually. Currently, I can do without Python scripting. But the > availability of Python scripting as advertised on the website was one of > the reasons I checked out M. AFAIR it doesn't work so well, currently?! VZ indicated that it wasn't working at all (?) and would be very hard to support again (?) ... so I also suggested it come down off the website. > Using SWIG. Ugh. I didn't understand one bit of SWIG when I browsed the > wxPython sources a while ago. >> the Boost Python Library > This is my favourite, too. >% I have no idea about the respective merits/drawbacks of Boost and SWIG. >% If you would prefer to use one instead of the other, I guess this should >% not really be a problem, as currently none is really used. Agreed on SWIG. Boost intentionally makes minimal or zero modifications to original C++ code while hooking it into Python. There is no need for complex IDL-like files. Boost is very, very nice to C++ code; almost effortless C++ interfacing. SWIG is not so easy. That's one reason I chose Boost for my earlier project over SWIG, CXX, raw C extensions, and some other toolkits. The rest of the Python world is catching on, but I was an alpha Boost Python tester because I saw the merit. Another thing about Boost Python is the author. He sits (or once sat) on the C++ standards committee. He is a deep, deep C++ guru very familiar with the intricacies of this complicated language. SWIG has a more general goal than Boost, covering many scripting languages. Boost Python is just for Python, so it's better tuned. I get the impression that the headache of Python scripting support in Mahogany involves SWIG. Maybe Boost could lighten that load. >> What about a wxPython port of Mahogany? > Writing a MUA in wxPython is an idea I had myself for a while. > Unfortunately, there are several unfinished Python MUAs out there. The idea is not to write another MUA. The idea is to rewrite wxWindows classes as wxPython classes in Mahogany. The MUA would not change but would become more strongly Python based. >% You would also have to rewrite/integrate c-client, the C library (75.000 >% lines) that M depends on for all the mail related functions. No, the rest of Mahogany's C/C++ would stay as C/C++, including c-client. Only the GUI would convert to wxPython, and possibly some file i/o. Basically whatever makes sense to become Python, could. Meanwhile Boost or SWIG could expose any non-Python objects to Python. This type of strategy would maximize accessibility from Python. The gain here would be scriptability of the whole GUI and more rapid development cycles on future GUI improvements. That is gravy on top of the Boost/SWIG-based scriptability functions for C++ internals. > Normally, I'm all for Python instead of C++, as it is much more productive > to code in Python. Exactly...which is one reason to use wxPython...well, maybe I had better stop talking, and put up or shut up... Best regards, Mark ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Mahogany-Developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mahogany-developers
