[Gtk-sharp-list] Re: Gtk# hacking

[Bob Smith]

Ok. Its on the list now.

Ok. Say you have 2 objects of the same type, Button. You put a callback to
"clicked" and "destroyed" in both instances. With the method we were
using, clicked and destroyed would each be pined for the first instance,
and they would either be pinned again for the second, or the instance
itself would be pinned. The documentation on .NET is rather unclear about
which would really be the case. So, you would either have two instances
and two delegates pinned, or 4 delegates pinned for just 2 objects.

The proposed solution is to make a static delegate type for each type of
signal callback, keep a perminantly pinned instance of it laying around,
and have it registered when needed. So, assuming both "clicked" and
"destroyed" in the previous example are the same function type, the total
number of delegates is reduced to 1. You can have 50 buttons each with a
clicked method, and only one delegate gets pinned. This is MUCH easier on
the garbage collector and memory in general. All other delegates remain
managed, so nothing else needs pining.

As to how the delegate gets access to what wrapper object it needs, there
is a static Object function that gets the associated wrapper of a GObject.
The wrapper is stored in a static hash table, the hash key is an int
converted to an IntPtr and stored as data in the GObject. The delegate
uses this function to get the wrapper, then calls the appropriate event on
the wrapper.

As to the question about why I think delegates just passed to a function
will go rogue after the first callback, I was reading through the jungle
that is MSDN and saw that referenced. I'm not sure where it was, but I can
try to find it again if you really want to know badly enough. Pinning the
static method will ensure it wont go anywhere though, and is easy enough
to do.

I have all this already coded over here, and I can dump it into cvs if
you'd like. It may require a few min to make sure everything compiles, but
it should be pritty close.


On Thu, 20 Sep 2001 mkestner@speakeasy.net wrote:

> On Thu, 20 Sep 2001 14:45:09 -0400 (EDT), Bob Smith <bob@thestuff.net> wrote:
>
> > I can compile and test the GObject stuff using the remote compilation
> > service and thats what I did last night. It atleast parsed.
>
> Yes, the glib stuff parsed cleanly.  The errors were in Gtk.Object.
>
> > The core stuff
> > remaining to get ironed out before things are stabalized are signals. To
> > be frank, the way signals were implemented sucks. It wont work. Memory's
> > going to have more pins in it then a pin coushin. Its going to slow things
> > down alot, and it will fail the second+ time the signal gets called. It
> > must be fixed.
>
> I'm intrigued to see what kind of solution you have in mind that doesn't involve delegates via PInvoke.  I don't see the issue, and with Delegates being the recommended method of implementing PInvoked callbacks, I can't believe that the second invocation of a delegate would fail.  How in hell could they have wrapped the Win32 API if that were the case?   What makes you think this will happen?  I'd like to see some documentation on this if your concern derives from published material.
>
> As far as having more pins than a pincushion, that's part of the game, I think, with a thin wrapper around a native library.  And I think this discussion boils down to optimization of a potential issue that hasn't even been pegged on a profiler yet.
>
> That said, I'm not opposed to a better way if it's substantially and demonstrably better, completely hidden within GObject, and maintainable.
>
> > If you dont mind, I'll finish up the signal system I have
> > psudo coded, commit it, then the core is all yours. I'll stick to child
> > widgets. That way, what I do wont effect you or anyone else.
>
> Can you run the pseudocode version past me on the mailing list?  I'd like to read a description of the issue that you're concerned with and how what you are proposing is better. That kind of discussion will be good to archive on the list.
>
> > Until the
> > signal system is useable, I cant work on child widgets and neither can
> > anyone else wanting to help.
>
> The signal system is usable, until you prove otherwise to me. Statements like this with no substantiation piss me off.  So, feel free to stop casting stones and toss a few facts around at any time. And conjecture about "more pins than a pincushion" don't count.
>
> It may not scale, belongs below Gtk.Object, and should probably be switched to a closure based approach eventually, but at this point in the project there is nothing out there taxing the signal system enough to even evaluate its effectiveness and putting it where it is was the simplest approach. What exactly about Gtk.Button.Clicked is going to come crashing down to earth because of the current approach?
>
> > Is this acceptable?
>
> Demonstrate the need and describe the proposed signaling concept to me, and I'll let ya know.  I am heading out of town for the weekend, and I don't think the wife will let me take a laptop with me, so my availability and production is limited from Friday afternoon until Sunday Evening.
>
> As far as working on Child classes, if we can keep them out of the build by commentary or moving away from the \recurse:*.cs build approach, that may work out okay. We'll have to play it by ear.
>
> I gotta tell you I'm still very uncomfortable about having uncompiled code in HEAD, though, whether it's in the build or not. But maybe I can get over that, given enough time.  :-)
>
> Mike
>