Re: [Gnumed-devel] Re: [Fwd: Re: Attn Ian: re LIstbook in gnuMed 'terry']

[catmat]

Karsten Hilbert wrote:

> On Wed, Mar 16, 2005 at 12:34:54PM +0100, Hilmar Berger wrote:
>
>  
>
> > PS: I modified the DrugBrowser to work again ( at least with AMIS), but as
> > this is probably post-0.1 stuff I won't check it in right now.
> >    
> Please do. It'll simply not be included with the release.
> Unless it changes *core* stuff - in which case it's
> fundamentally broken ;-)
>
> Karsten
>  
well since you're not in the mood to offer the counter arguments, I try 
my best.
The dispatcher.send() shouldn't be wrapped in a try: catch block as a hacky
sacrifice to impatient module writers , because release modules should not
be throwing uncaught exceptions. However, for individuals wanting to do some
debugging/coding, there's nothing wrong with adding try: catch blocks 
here and
there, like print statements, for debugging,  as long as they don't get 
committed
and break the styling quality of committed code.
 As for the paint event, it's designed to delay time-consuming updates when
the model changes, until the time a module tab is displayed, so like the 
previous
thread about how to solve document scanning affecting network performance
of a emr, it's a matter of good  resource use design. 
There isn't enough time for 0.1 release to redesign model-view 
interaction to using
threads , which would be a much more complicated way of  managing  gui 
responsiveness,
and prone to non-deterministic bugs,
and at least trying to manage gui responsiveness using the paint event  
is much
better than leaving an overly simplistic dispatcher push update which causes
the gui to block  until  all modules are updated, whenever a dispatcher 
notification occurs.

I apologize for being a bit too open about code critiques, and I hope 
the list doesn't
feel I am trying to undermine anything, and therefore have to resort to 
trying
to make me look more amatuer about getting things to work e.g. I used sql to
update the cfg_string between status_quo and terry , because I didn't 
initially
find it when I looked in the config editor, and without the config 
editor being
loadable in the terryspace client  until recently, I had to use it to change
back to status_quo. Really, I should remember there isn't a 
gnumed-general list,
and therefore non-coders reading this list might misconstrue my 
sometimes naive
questions as problems with code design. That really isn't the case : the 
core
developers Karsten, Ian, Hilmar , Carlos are committed and excellent coders,
and  the fundamentals of good emr design is possibly the best of all the 
open
source emrs available ; the gap between gnumed and say CPRS is much less
then any of the other open source emrs recently crossposted as 
comparisons to this list.
It is not hard to see that most of the functional requirements in CPRS are
in gnumed, and I as an outsider examining the code for some time now, 
see there
is nothing insurmountable for gnumed to also implementing the few remaining
functional points in CPRS it doesn't already do.