Re: [Gnumed-devel] installing and using gnumed

[David Grant]

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 www.gnumed.net/rterry/Index.htm (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, 
http://kmymoney2.sourceforge.net/release-plan.html, 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.

Dave

> 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).