Re: [Gnumed-devel] plugin framework

[Karsten Hilbert]

> Karsten Hilbert <address@hidden> wrote:
> > That would be good. But the question was why there is
> > *plugin* code in *wxpython/gmDemographics.py* ?
> Because wxpython/gmDemographics.py is a fork of the original 
> wxpython/patient/gmDemographics.py
> yes this code can be deleted AFAIK
Ah, the fog rises :-)   Will tend to it RSN !

> > Eg, can we break it ? Also, I'd like to break the ugly direct
> > connection between the top panel and "the demographic plugin".
> Please do. I can't remember why I did it like that.
Will do my best.

> > Here it shows why the above widget/plugin code separation seems
> > useful: Horst might simply load the "vaccination panel"
> > complete with lists, editarea and phrasewheels into a main
> > notebook tab while Richard might instantiate it into the
> > left-hand of his two/three column layout.
> Exactly. But this means creating plugins under wxpython/gui for
> vaccinations/allergies etc. so they can be accessed in notebook tabs.
No. The *plugin* file in wxpython/gui/ need not (and should
not) contain any of the *business GUI* widgets. It simply
provides a wxPlugin derived class which loads the widgets
from, say, wxpython/gmLabWidgets.py.  Now, if someone else
decides do write UI unrelated with the notebook plugins they
simply load the needed business widgets from
wxpython/gmLabWidgets.py into another wrapper class. Eg.
Richard-space would instantiate the same classes as
Horst-space does but in Richard-space the parent wxWindow
would be part of cClinicalWindowManager while in Horst-space
it would be a sizer that's eventually plugged into the
notebook as a new page. No need for code from
wxpython/gui/*.py to mess at all with the notebook. Am I
making myself understood ?

> Also, for this to work the two/three column layout has to "take over" the 
> client window
> As one notebook tab among many it's worse than pointless.
I see. OK, now *thats* an option. Let the user decide whether
they want a notebook OR the 2/3 col layout. I think I am
getting what you are after. This might be doable after all.

> And if all plugins you need are  in gmClinicalWindowManager.py, the user
> is entitled to ask, why have a bottom tab line at all? This is the concept of
> a pluggable layout manager.
Because a whole bunch of plugins may not have to do with
clinical things at all, eg. managing the contacts data. Those
widgets wouldn't be integrated with cClinicalWindowManager.
But it might make sense to either say:

All clinical functionality must be within
gmClinicalWindowManager (then we can have notebook tabs, too).

 or

Either notebook tabs OR gmClinicalWindowManager.

> How else can it work? We have two competing layouts. Personally I would 
> prefer either to the status quo, but no agreement is possible.
> The current situation is the most complex and worst solution
In it's current incarnation, yes, I agree.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346