On Mon, 3 Nov 2003 02:10:53 +0100 (Romance Standard Time) Vadim Zeitlin <[EMAIL PROTECTED]> wrote:
VZ> On Sun, 02 Nov 2003 15:28:56 +1000 Mark Livingstone <[EMAIL PROTECTED]> wrote: VZ> VZ> ML> Step 2: VZ> ML> VZ> ML> Edit InitPython.cpp and comment out the entire module initialisations VZ> ML> block (lines 32 - 42 or so) and (lines 137-143 or so). VZ> VZ> Why is this needed? If you do not, it tries to compile in the *.i swig stuff which is broken. I probably was not clear enough originally. My hack so far gives you the ability to get the Python preferences page up and to get the scripts option in files menu. Beyond that, nothing more is currently possible. I tried to run a HelloWorld.py and it even errored out on that. It is useful for me because at least I don't have to constantly be making a Python version to hack then a non-Python version to be able to email! VZ> VZ> ML> ISTM that the Windows guys, if they fix their make / project file VZ> ML> should end up with a similar situation but since I have not tried, I'm VZ> ML> not sure. VZ> VZ> Ok, I'll try to do it but it's probably not very urgent... Agreed. Until we work out the stuff below, Windows support is a moot point. I suspect (although I'd be delighted to be proven wrong) that the average *nix user will be far more likely to make him/herself a Python enabled version than Windows users VZ> VZ> ML> I will now be working on each of the above .i files but with the VZ> ML> changes in M in the past 4-5 yrs since Python was current, how much VZ> ML> workk this will be remains to be seen. In theory, SWIG can be made to VZ> ML> do most of the work just by reading .h files but we have so many of VZ> ML> them that working out which of the multiplicity of .h files is needed VZ> ML> for each of the 6 or 7 Python modules may be quite a daunting task. VZ> VZ> It would be much easier to maintain however... VZ> VZ> ML> As Karsten designed things, we have the following Python modules: VZ> ML> VZ> ML> MAppBase - non gui app stuff VZ> ML> MailFolder - interface to mail folders VZ> ML> Message - handle single messages VZ> ML> MObject - base class for ref counted objects VZ> ML> MProfile - config options per class VZ> ML> MString - string class interface VZ> ML> SendMessageCC - holds msg during composition VZ> VZ> I think it is important to understand what kind of API we want to expose VZ> to Python instead of just fixing the existing code. I believe it should be VZ> possible to do at least the following: VZ> VZ> 1. send message VZ> 2. read message in given folder VZ> 3. be informed when new message arrives or ... VZ> VZ> This means wrapping the following classes: VZ> VZ> 1. SendMessage VZ> 2. MailFolder and Message VZ> 3. making the hooks work Isn't synchronicity a wonderful thing LOL. I was sitting watching TV last night and thinking the same sort of thing. Maybe now is the time to go back over the wishlist and see what it was that people were asking for and seeing how much needs to be exposed to achieve it. I've tried on a number of occasions to find that wishlist where someone asked for M to be exposed as a big API but I think that particular wisher will be disappointed for a long time yet ;-) VZ> VZ> ML> MString appears to be the simplest (Famous last words? :-) ) so I'll VZ> ML> try that first since it is required by MObject. After that, everything VZ> ML> turns to a bowl of spaghetti. VZ> VZ> Right, MObject is surely needed for anything to work (although I wonder if VZ> there is no smart way to make Python objects "dtor" to call DecRef() on our VZ> pointer without exposing MObject directly... maybe you should ask about VZ> this on swig ML, surelywe're not the first ones to want to do this). And we VZ> do need MString although its interface should be as minimal as possible. VZ> Again, it could be a good idea to ask on swig ML (or search in its VZ> archives) how people usually expose C++ std::string using SWIG, I'm quite VZ> sure it must be a common problem. VZ> VZ> But except for those 2 I'd really like to get rid of .i files. E.g. for VZ> the task (1), feeding SendMessage.h (note: *not* SendMessageCC.h) should be VZ> enough. Isn't it? >From what I understand, you will need to have a very minimal .i file with the name of the .h file and the module name you wish to associate with it. Having said that, I have also seen somewhere (I'll have another look) that this info can actually be embedded in the .h files themselves (between #def's maybe?) although I'm not sure how it will work when you want a module to span multiple .h files. For that you might need to have a .i file? I just downloaded (18MB!!) the SWIG mailing list archive which they are thoughtful enough to download in .mbox format so I'll see what they say about std::string. VZ> Thanks a lot, Mark, for looking into this! You're welcome Vadim. Dr. QA ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ _______________________________________________ Mahogany-Developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mahogany-developers
