[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] installing and using gnumed

From: David Grant
Subject: Re: [Gnumed-devel] installing and using gnumed
Date: Thu, 19 Feb 2004 03:05:15 -0500
User-agent: Mozilla Thunderbird 0.5 (Windows/20040207)

Just my 2 cents:

Richard Terry wrote:

At the risk of starting a flame war, and please when reading this all remember I am in no way putting anyone down!

James , I agree wholeheartedly with your comments! I've installed it many times on number of distro's and always got stuck at some point.

The roadmap-sequence-plan is a constant thorn, and characteristic of open source. The problem I think with this project is that we have never reached a common agreement of the path forward, and I hope that doesn't mean that gnumed will eventually fail.

For example I spent many months doing the gui-prototype, and documentation (its tucked away somewhere, Karsten will know the URL), based on my excellent vb client (see (with capital I in Index) in case you've missed the philosophy and gui's of the vb client. The program was demonstrated live at the sydney gnumed conference and usually blows away people because of its breathtaking simplicity and power and speed (runs as quick on a pentium 266 as it does on modern machines!). Though I wrote the guts in 1995 (script) and the rest in 1997 it is still light years ahead of anything I've ever seen.
If you're comparing it to Java or Python, I'm not surprised that it is very fast... :-)

Its success in practice was a combination of the gui with a functional philosophy and automatation. The code was crap as I'm not a programmer.

Despite this, I've not been able to pursuade the code writers to stick to its features, as, I suspect, because they have not used it in clinical practice, they have not experienced how it flows, and often think some features are not necessary or should be done differently, whereas since I've developed and used it, I usually went through the iterations they now are putting in place and found they just didn't function optimally, so I advanced the design.

This illustrates, I guess, a lack of structure where one person gets the ultimate say on functionality and features, and others code it. What happens is that the main coders (Karsten and Ian) change the gui to suit what they think would be better - please no flame wars - I'm not a coder at all and don't profess to be). Personally I still think wxPython sucks as a gui interface compared to QT which was my personal preference, where the vb client could have been reproduced in its entireity and hence in all its funcitonality.
I'm not clear on why Qt is so much better than wxPython in its ability to reproduce faithfully the vb client. What functionality in the vb client is missing in wxPython? I think using qt/PyQt would be less portable because isn't Qt non-free under Windows? I'm not to clear on the licensing issues there... but I've never seen a qt app for windows yet.

I think we lack a co-ordinator who can visualise the grand plan and allocate coding of each section to whovever and overview and have a final say on the result. I'm aware those of you with computer degrees/commercial experience think I'm wrong in this as we have had the conversation already.
Maybe you are right and wrong. I would think that the developers (in the absence of any supreme ruler) should have a roadmap, and the roadmap can act as the "co-ordinator" as you call it, to guide the progress. I might have sent some people this before,, but there's a good simple roadmap. All that's missing is an assignee for the task, but I'm not even sure if that's needed.


I've seen many people who obviously wanted to help come and go over the last couple of years, (eg people really interested in HL7, pathology downloading etc) and I don't blame them because there was no structure for them to become involved, but it is a sad loss of talent.

I would probably be the best beta-alpha tester because I know how the gui is meant to function, as I use it every single day and have years and years of data and experience using it, yet I've not been involved with this. When I do try out the latest interaction and post comments as a result I don't get far so I give up. There isn't any mechanism in place to incrementally improve after I comment.
I think the main problem is that gnumed always seems so unusable whenever I try it, that it's hard to test. Getting a first release out should help. We need to come up with the feature set required for a release, even if it is minimal. Then get a release out, something that can be called 0.1. It should have an easy installation/build using distutils which will make it easily installable on all variants of Linux or Windows. I think it should also be very cleanly split between server and client. (I'm not really sure why there is a gnumed-common package in debian, last time I checked).

reply via email to

[Prev in Thread] Current Thread [Next in Thread]