Changes between Version 19 and Version 20 of MonoLoader

Timestamp:

May 26, 2007, 6:45:34 PM (17 years ago)

Author:

ecoffey

Comment:

--

MonoLoader

@@ -8 +8 @@
   * Completely wrap libpurple API in .NET bindings.
   * ~~Fix the Mysterious Seg Fault On Exit (tm).~~
-  * Re-examing and possibly re-implement signal-glue and API -glue code.
-  * Give .NET Purple objects the ability to actually update their C counterpart (or create one).
-    Possible solution:  Every api Object thats mapped to a purple object would inherit from Object.  Object would have a !IntPtr pointing to the C structure (or null if this is a "new" object). A potential constructor could look like:
-    {{{
-    public class Object {
-        private IntPtr _c_structure = null;
-        Object(IntPtr struct) {
-           _c_structure = struct;
-           _updateFromStruct();
-        }
-    }
-    }}}
-    And derived classes could be responsible for implementing _updateFromStruct().  Derived classes would also have to handle creation of their specific C struct:
-    {{{
-    public class Buddy : Object {
-       Buddy(IntPtr struct)
-          : base(struct)
-       {
-       }
-
-       Buddy()
-       {
-          _c_structure = purple_buddy_new_glue();
-       }
-    }
-    }}}
-  * Right now delegates are invoked and just given an array of their data.  Would be nice if we could explicitly state what they expect, e.g. {{{ OnBuddyStatusChanged(Buddy b, Status s) }}}
-  * Possibly utilize an object cache mainly in the signal-glue code, so we're not constantly (re)building objects.
+  * ~~Re-examing and possibly re-implement signal-glue and API -glue code.~~  The glue code is now gone.  The use of !DllImport has made it all pretty much obsolete.
+  * ~~Give .NET Purple objects the ability to actually update their C counterpart (or create one).~~
+  * Would be nice if we could explicitly state what Delegates expect, e.g. {{{ OnBuddyStatusChanged(Buddy b, Status s) }}}  This could probably be solved with the Manager idea discussed below.
+  * Possibly utilize an object cache in the api, and to manage the mappings between .net objects and their c struct counterparts so we're not constantly (re)building objects.
   * [http://reaperworld.com/htdocs/monoloader.html grim provided gameplan]
 
@@ -42 +18 @@
  * Fix the build system so that make can be run successfully with multiple jobs.
 
-=== Loader Internals: ===
-  * There must be a better way for having the loader handle signals on behalf of .net plugins (will document the current implementation here).
-  
+== Loader Internals ==
+   The api objects now directly tap into libpurple using !DllImport.  This is true for purple_signal_connect also, which gives us a cleaner way to tie up signals in .Net.  Going to need to explore an Object Manager so that plugins don't have to worry about !IntPtrs and what not.