Re: [Gnumed-devel] Move to Qt (was: Conference)

[Ian Haywood]

On Fri, 15 Aug 2003 23:17:52 +0200
Karsten Hilbert <address@hidden> wrote:

> *Can* stay ?!?  What the heck do you mean ? First, we always
> had the notion of having multiple clients. Second, it will
> stay all by itself and does not need our approval for doing
> so.
Of course, a poor choice of words on my part.

> Uhm, ah, I wonder what part of that zero functionality my
> parents are using daily in their practice. I seem them using
> it, anyways. Must be that they have too much time on their
> hands and just diddle around with empty controls.
[embarrassed silence]

Point taken, sorry for ignoring this.

I am assuming you mean the object viewer. 
(is their anything else I have missed?) 

"Zero functionality" refers to Richard's GUI code, which remains
empty, this goes back to the problem of a split design philosophy, in
that functionality has been developed completely in parallel.

In this case, forking the client is really recognising 
a situation that has existed from the start.
A separate client over which Richard has overall design control will
allow him to develop a lot faster, then, once functional,
ideas/code/etc. can be merged as appropriate.

Ian 




 
> > In terms of debugging, the current client hasn't undergone much,
> Is that so ? For fair-play I will assume you are talking "code audit".
> 
> > > I suggest that (in the case of a GUI switch) we should fork the
> > > current client tree (or at least the GUI part of it).
> No. We just write another client. No *fork* needed. Fully in
> line with our erstwhile intentions IMHO.
> 
> > Agreed, we already have a client fork in the form of Syan's Java
> > client of course.
> No. We already have *two* clients (or rather four, if you
> want to count the drugref.org PHP frontend as one and the
> GnuMed/Archive standalone frontend as another one).
> 
> BTW: Initially I had some administrative problems with how
> Syan went into the code full force. Now, however, I am quite
> delighted by his commits (not that I run/develop/comment on/
> endorse the Java stuff but the way it is handled now works
> well).
> 
> > > 1/ Status quo: wxPython client, pluggable with 2 plugin systems,
> Fine by me.
> 
> > > 2/ Qt using Qt's own database objects and data-aware widgets
> I don't like 2/ at all.
> 
> > > 3/ Qt using Karsten's business objects,
> make that <any-client> using them business objects (but then
> they need to be accessible by something like ...
> 
> > > 4/ 3/ with communication via XML-RPC
> ... this which has been declared post-1.0 stuff and rightfully
> so.
> 
> > 1/ demographics business object: the backend schema is well
> > established, should be easy to write w/o controversy.
> IMHO the most sorely needed part.
> 
> Karsten
> -- 
> GPG key ID E4071346 @ wwwkeys.pgp.net
> E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346
> 
> 
> _______________________________________________
> Gnumed-devel mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/gnumed-devel


PGP public key E750652E at wwwkeys.pgp.net
9BF0 67B7 F84F F7EE 0C42  C063 28FC BC52 E750 652E

pgpdtz4W8lGEb.pgp
Description: PGP signature