[Gnumed-devel] app init

[sjtan]

I don't understand why plugin init cannot be done in one of
the following places and why an app init signal should be
needed:

a) at plugin load time (in GetWidget() and/or rather in the
   __init__ of the widget that's returned by GetWidget())
b) in a thread kicked off by a) if doing things right away
   would be too time-consuming
b) in a_plugin.ReceiveFocus() as already done in gmShowMedDocs
   and gmManual if we want to delay loading of data files
   until first use of the widget which reduces startup time
   and may reduce overall RAM usage

Why would we need gmSignals.app_init() ?

Karsten

How does one reply to just a part of a letter?

It just seems more clearly separated to me. the app init signal
occurs after ALL the widgets are loaded , then the next phase
all the handlers are loaded by seeing if a widget instance is
in the GuiBroker that matches each handler name.

Putting it in the plugin means the plugin has some idea there is
a handler, so a dependency exists . 
 
You can change the way you are implementing controllers , by removing
app init or any of the handlers implementations individually in
handler_loader  , without affecting the
plugins.


The app init signal shouldn't be causing the current system to
fail, except maybe there is a bug in the handler_loader somewhere on
that occurs on your setup that isn't present on mine.

you could rename the signal  more specifically, e.g
signal_post_plugins_loaded()

I might give the thread idea a go, 
but is the handler collaboration
going to coexist with other methods of implementing controllers?

It can, just don't load the handler for a widget with a custom
controller, and you can map the field granularity sql updates to
whatever sql wrapper we are going to use, 
 or map to sql directly by 
e.g.
making a custom dictionary class that calls or triggers sql update
when a certain number of calls to dict __getobject__ get called,
and substitute the raw dictionary types for these sql aware or
sql-wrapper aware dictionaries

Or re-write the default handlers to call a update method when a
component loses focus.