Re: [Gnumed-devel] installing and using gnumed

[Karsten Hilbert]

Richard,

> The roadmap-sequence-plan is a constant thorn, and characteristic of open 
> source.
Well, there is one, however, if ever so sketchy:

http://mail.gnu.org/archive/html/gnumed-devel/2003-06/msg00045.html

> The problem I think with this project is that we have never reached a 
> common agreement of the path forward,
I think because we have differing needs.

> and I hope that doesn't mean that gnumed will eventually fail.
It can't, it is in production already. I just may not get
as far as some people would like it to go.

> 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 
And these still are THE agreed-to GUI-design specs.

> 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
Certainly not but rather because it's too much work right now
to remodel every of its details. For a 0.1 release we need
to do a few things simple and "complete enough" but still
technically CLEAN.

> or should be done differently,
Now, that may well be due to differences in working habits as
Horst pointed out.

Eg. you haven't explained to me *why* you think we *must* use
target schedules/diseases instead of indications indirectly
selected by way of specifying the vaccine used. There may well
be a reason that I have overlooked. Now, I don't blame you for
not enlightening me (or us), I merely point out that I am
still groping in the dark as for the reasons. I do have *my*
reasons why I think it should be done via vaccine->indication
(which I presented on the list). Would I *not* have reasons I
would have followed your opinion even without knowing your
reasons.

> 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.
This is entirely possible with wxPython as well, GTK2 or not.

> I think we lack a co-ordinator who can visualise the grand plan
True.

> and allocate coding of each section to whovever
1) Wrong. That's not the way it works.
2) There's no one to assign coding tasks *to*.
3) Assigning coding tasks won't make coding more attractive to
   potential developers.
4) I have on at least three occasions offered small,
   well-defined, finite coding tasks on the list. There was
   about zero interest to pick them up. (James, maybe search
   the archives and post them on the web site ?)

> 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. 
A mechanism like what ? What should we do to improve that ?

> it will immediately be apparent that every single 
> section of the program is the same in its design and functionality. My vb 
> coding reflected this, and the same subroutines handled 
> loading/displaying/manipulating the data, no matter whether you were in 
> vaccinations/scripts/pathology requests etc. I'm not sure why this can't be 
> done in python, but perhaps it is an I'm not aware of it.
It is to quite some degree. Syans code does that even more.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346