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
