Re: [Gnumed-devel] plugin framework

[Ian Haywood]

On Sat, 19 Jun 2004 19:36:26 +0200
Karsten Hilbert <address@hidden> wrote:


> 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.  
I agree.

> 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).
This was the original plan. For a long time I was confused by clinical widgets
popping up in notebook tabs, such as the docs viewer and now the path stuff. 
I apprecipate now that you could suppress the loading of these tabs and
then import the same widgets as plugins under wxpython/patient.

However I now believe this is a nonstarter, as I have said. My vision of the 
perfect GUI woud have some 
integration of "clinical" and "nonclinical" items.
For example the lists notebook on the top left hand side would have "Inbox" and 
a "Waiting List" lists
(as well as "Results" "Medications" etc) which you can refer to
without leaving the "clinical" screen, as the reality of workflow is that you 
will often be moving 
from one to the other. 

There is also the "Alerts" box on the bottom left column for showing drug 
interactions, overdue
vaccinations etc. This must be visible at all times to be useful, the aim is to 
substitute for popup
dialogs except in exceptional circumstances. (an often-requested feature of 
users of other systems) 

If something is really so separate,  it should be a standalone program, as you 
have said previously.
>  or
> 
> Either notebook tabs OR gmClinicalWindowManager.
I really think we need to offer this choice, with both layouts in one client 
it's just a mess.
If no-one has any objections (and if you do, you really need for argue *for* 
the status quo)
I will start work on this.

Ian

-- 
PGP public key E750652E at wwwkeys.pgp.net
9BF0 67B7 F84F F7EE 0C42  C063 28FC BC52 E750 652E

pgphskJv630Cm.pgp
Description: PGP signature