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 > [email protected] > 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://[EMAIL PROTECTED] My OS: Suse Linux. Geek by Nature, Linux by Choice _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
