[Mono-list] [MonoDevelop] ANNOUNCE: Mono.Addins 0.1

["Andrés G. Aragoneses [ knocte ]]

Lluis Sanchez escribió:
>>> However, as Matthijs pointed out in his reply, app-domains don't play
>>> well with GUI toolkits, and GTK# is not an exception.
>> Mmmmm, why? I didn't have any information about this. Could you 
>> ellaborate? It sounds very strange to me because I already have a 
>> mini-framework which supports this and uses WinForms.
> 
> I can't tell for WinForms, but it won't work with gtk#. One problem is
> that the GType types that gtk# creates for every managed subclass of a
> widget are per-process, not per-assembly, and you'll get errors when
> trying to use the same classes from different app-domains. Another
> problem is that gtk# does not support having two managed objects to
> represent the same GTK object. What would happen if you override the
> OnKeyPress event on both objects? which one would be called? And even if
> you application had an strict control on the objects and avoided
> creating two managed objects for the same GTK object, the application
> has no control on the main GTK thread, so for example the GTK thread
> might receive an event for an object from domain A, while running in
> domain B.

Very interesting Lluis. However, I think that these problems shouldn't 
arise for this feature because it wouldn't imply using objects across 
appDomains. As I understand it (and as I have coded my mini-framework), 
the only usage of AppDomain boundaries crossing would be at the 
application launch, where the launcher would "launch" the core of the 
addin manager (and subsequently the addins...) in a second appdomain 
configured with ShadowCopy==true. Since that launch, no other 
inter-AppDomain calls would be launched. The main program flow would 
live and die in the second appdomain as if it were the main appdomain.


> GTK# can probably be improved to support multiple domains (even with
> some limitations), but it would require an important redesign of the
> internals (e.g. reference tracking), and IMO the effort needed is not
> worth it.

Well, perhaps in a far future we could have a completeley managed GTK# 
library. That would solve the problem too I guess :)

Regards,

	Andrés	[ knocte ]

--