gnumed-devel
[Top][All Lists]
Advanced

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

[Gnumed-devel] plugin framework


From: Karsten Hilbert
Subject: [Gnumed-devel] plugin framework
Date: Fri, 18 Jun 2004 14:21:24 +0200
User-agent: Mutt/1.3.22.1i

> > Ian, I notice you are actively working on
> > wxpython/gmDemographics.py. I can't remember why that file
> > contains plugin code and why it references the "clinical
> > window manager" (self.mwm) ? Can you help me out here ? Are
> > those just remnants and can be removed ?
> The plugin wxpython/gui/gmDemographicsEditor.py actually imports most of its 
> functionality
> from this file.
That would be good. But the question was why there is
*plugin* code in *wxpython/gmDemographics.py* ?

> IMHO it should be moved back and wxpython/gmDemographics.py should be retired.
IMHO, no. Most of the time IMO it makes sense to split
plugins like this:

wxpython/gmLabWidgets.py
 - contains useful lab related panels that can be used anywhere

wxpython/gui/gmLabJournal.py
 - contains just the plugin child class plus the code to
   populate that from ../gmLabWidgets.py as needed

>  (the original intention was that plugins be fairly self-contained)
They would still be, in a way. The self-containedness need not be
physically but semantically, eg. loading gmLabJournal.py
shouldn't require any other plugin to be loaded.

> It references the clinical window manager as our [Richard's and my] intention 
> was that all
> patient-related stuff (including demographics) went into this super-plugin.
Aha but is there any *use* of the connection right now ?

> ClinicalWindowManager was intended to showcase the 3 salient features of 
> Richard's VB client
>       1- phrasewheels (which of course can be anywhere)
>       2- two-column screen layout
>       3- using small icons as tab markers (to accomodate a large number of 
> plugins)
4 - edit areas

And it does.

> IMHO we should dump gmClinicalWindowManager entirely and have single plugin 
> layer.
I wonder why people keep insisting that having a single plugin
layer means *dumping* gmClinicalWindowManager ?!? It simply
means disentangling the gmClinicalWindowManager "plugins" from
gmPlugin and friends !! They need not even be "plugins" at all,
they can just be loaded in by hardcoded statements attaching to
an internal gmClinicalWindowManager API.

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.

> 2 and 3 can be implemented in gmGuiMain as optional features via gmCfg, that 
> way everone is happy:
I think it'll make things more rather than less complex to
allow the user to select that with an option.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]