Re: [Gtk-osx-devs] [python] Multiple python instances of gtk_osxapplication



On Jul 28, 2010, at 9:09 PM, Richard Procter wrote:

> Hi there,
> 
> I'm using the python bindings to gtk_osxapplication.
> 
> A couple of days ago I tried instantiating two  
> gtk_osxapplication.OSXApplication()s, which the source seems to  
> suggest is ok (at least under C) as the underlying object is a  
> singleton. This was to avoid coupling the highest level of my program  
> with one of the lowest, which needs access to the bundle paths.
> 
> Unfortunately it didn't work (I'm afraid I don't remember the  
> details; if anyone is interested I can try to reproduce it).
> 
> However it led me to think that it would be an improvement to make  
> the functions for querying the bundle info module functions.
> 
>   +ve Easier to use as the question of whether or not it is safe to  
> instantiate multiple instances of gtk_osxapplication does not arise.
>   +ve Less coupling as bundle_id(), bundle_info(), resource_path()  
> etc do not actually use their self parameter
>   -ve Presumably self is passed to make the python bindings easier;  
> probably more work to implement, possibly more work to maintain.
> 
> It would be used thus:
> 
>   bp = gtk_osxapplication.get_bundle_path()
> 
> etc.
> 
> Comments appreciated,

Might you have created the two instances in separate threads? I didn't write it to be thread safe (which was perhaps naughty of me, but multi-threading event loop operations is risky and best avoided). 

There's no real reason for anything but the event-loop code (menus and accelerators) to be part of GtkOSXApplication other than as a convenient place to bundle them; but they could keep their names and just drop the GtkOSXApplication* parameter. That would improve the coupling issue but not really do anything about the multiple instantiation issue. In a complex application where there are many files talking to the GtkUIManager, one will need to get the GtkOSXApplication* in each one to be able to switch or sync the menubar.

Please do see if you can reproduce the problem. It does need to be fixed.

Regards,
John Ralls





[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]