On Sun, 02 Nov 2003 15:28:56 +1000 Mark Livingstone <[EMAIL PROTECTED]> wrote:

ML> Step 2:
ML> 
ML> Edit InitPython.cpp and comment out the entire module initialisations 
ML> block (lines 32 - 42 or so) and (lines 137-143 or so).

 Why is this needed?

ML> ISTM that the Windows guys, if they fix their make / project file 
ML> should end up with a similar situation but since I have not tried, I'm 
ML> not sure.

 Ok, I'll try to do it but it's probably not very urgent...

ML> I will now be working on each of the above .i files but with the 
ML> changes in M in the past 4-5 yrs since Python was current, how much 
ML> workk this will be remains to be seen. In theory, SWIG can be made to 
ML> do most of the work just by reading .h files but we have so many of 
ML> them that working out which of the multiplicity of .h files is needed 
ML> for each of the 6 or 7 Python modules may be quite a daunting task.

 It would be much easier to maintain however...

ML> As Karsten designed things, we have the following Python modules:
ML> 
ML> MAppBase - non gui app stuff
ML> MailFolder - interface to mail folders
ML> Message - handle single messages
ML> MObject - base class for ref counted objects
ML> MProfile - config options per class
ML> MString - string class interface
ML> SendMessageCC - holds msg during composition

 I think it is important to understand what kind of API we want to expose
to Python instead of just fixing the existing code. I believe it should be
possible to do at least the following:

1. send message
2. read message in given folder
3. be informed when new message arrives or ...

This means wrapping the following classes:

1. SendMessage
2. MailFolder and Message
3. making the hooks work

ML> MString appears to be the simplest (Famous last words? :-) ) so I'll 
ML> try that first since it is required by MObject. After that, everything 
ML> turns to a bowl of spaghetti.

 Right, MObject is surely needed for anything to work (although I wonder if
there is no smart way to make Python objects "dtor" to call DecRef() on our
pointer without exposing MObject directly... maybe you should ask about
this on swig ML, surelywe're not the first ones to want to do this). And we
do need MString although its interface should be as minimal as possible.
Again, it could be a good idea to ask on swig ML (or search in its
archives) how people usually expose C++ std::string using SWIG, I'm quite
sure it must be a common problem.

 But except for those 2 I'd really like to get rid of .i files. E.g. for
the task (1), feeding SendMessage.h (note: *not* SendMessageCC.h) should be
enough. Isn't it?

 Thanks a lot, Mark, for looking into this!
VZ



-------------------------------------------------------
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

Reply via email to