[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] Re: [Fwd: Re: Attn Ian: re LIstbook in gnuMed 'terry'
From: |
catmat |
Subject: |
Re: [Gnumed-devel] Re: [Fwd: Re: Attn Ian: re LIstbook in gnuMed 'terry'] |
Date: |
Fri, 18 Mar 2005 00:16:32 +1100 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20041231 |
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.