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

[Sebastian Hilbert]

Hi !

If you are prepaired to sort this out step by step go I am willing to look at 
the problems. I must say that I don't understand 5% of the concepts behind 
GNUmed and therefore cannot judge what the problem is. Maybe you can help to 
get a little insight.

1st. which OS do you run exactly
2nd which source do you use ? CVS, tarball, tgz from savannah ?
3rd what is the name of the script you use to start it and where does it live
4th do you use a unicode version of wxpython
5th start GNUmed with the '--debug' option
6th look at the output of the start script and locate the log file

enough for now.
Sebastian

On Monday 29 August 2005 01:31, Richard Terry wrote:
> 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
>
>
>
>
>
> _______________________________________________
> Gnumed-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/gnumed-devel

-- 
Sebastian Hilbert 
Leipzig / Germany
[www.openmed.org]  -> PGP welcome, HTML ->/dev/null
ICQ: 86 07 67 86   -> No files, no URL's
VoIP: callto://address@hidden
My OS: Suse Linux. Geek by Nature, Linux by Choice