[Gnumed-devel] Why is it I still can't reliably run gnuMed

[Richard Terry]

As you will have noticed, I've been absent from the list for a long time, 
though I have been reading the traffic. Having read the accounts of the german 
conference I'm keen to try and get the program running again.

Part of the problem, apart from my philosophical differences, is that I can't 
get gnuMed to run properly still, after all these years!.

Before anyone says get again RTFM, I've intermittently tried to RTFM and still 
can't get it to work. I think it must be around both the fact that I run 
wxPython2.6 and the unicode problem.

As I previously mentioned I'm more than happy to help point out where the 2.4 
code is out of sync with 2.6 and help adjust this, but I can't get to first 
base again now because of error messages. When I did get it running I 
couldn't enter patients through the add patient interface because of date 
format problems so I gave up.

I wonder if anyone is prepared to spend the time to help with this?

Also, in answer to some specific questions aimed at me on the list in recent 
times I include the following:
============================================
snip:
> There are screenshots that describe Richards
> "unified entry area" concept which seems to be deprecated or
> at least has almost no relation to what is functional right
> now. (?was this from hilmer - whover it was I agree with the preception)
============================================
?Karstens reply:

Actually, the past history item input widget is generated
using the very same code that can generate edit areas. A
vaccination edit area is functional but did not make it into
0.1.

I must admit that I misunderstood the distinguishing feature
of the edit area concept for a long time. Maybe I still am.
Maybe Richard can correct me on the following:

The advantage of the edit area not so much lies in the
widget itself but rather in it's consistent *placement*
within Richard's general design and it's *fairly*
consistent line-by-line layout. Over and above that it's
just a strict application of principles such as input
validation, coloring and phrasewheel use.

My comments:
========
The above is partly true. The editing area is in reality no more than half a 
dozen or more lines sitting on top of each other like lines on a page - ie 
the physical design is not the feature. The actual placement of the wigit 
within an overall design per se is not the feature, although having a 
consistent data input design would be unique amongst medical problems.

The distinguishing feature in reality of the editing area  is (and this has 
not been implemented in gnuMEd) its functionality across all sections of 
medical data input, as well described at www.gnumed.net/rterry/Index.htm. When 
combined with the phrase wheel and it's learning abilities it adds up to an 
easy to learn and quick to use system.

Unfortunately this has not been implemented in gnuMed. As I have previously 
commented on ad-nauseum - to the point of getting list members quite angry 
with me - the gnuMEd core members have made all the classic mistakes of 
program design - having no management structure, and not designing 
functionality first, and back-end second. What bits of the editing area and 
latterly the SOAP editor (which Ian designed at my behest) have been 
implemented, their functionality is much much worse than a couple of simple 
free-text text boxes - ie good design has been degraded by a poor 
implementation of a concept.

From a programmatic point of view, because the editing area concept is generic 
across all areas of data-input, if the underlying database has been designed 
in concordance with this concept, then all the subroutines to call/display 
data should also be the same - ie this should have led to a lightening fast 
development of quite a complete gui.

I've watched a  dozen or so medical software packages evolve in Australia over 
the last 20 years - all have gone down the path that gnuMed could have 
avoided, but chose not to. Ie, they have had no overall functional design, 
but have had one person's concept of what should be 'bolted' onto a basic 
design screen. The end result of this process always will be problematic.

Awaiting the flak.

Regards

Richard