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

[Karsten Hilbert]

> > Even if we decide to favour Qt for the client GUIi, please don't throw
> > away the current wxPython GUI.
They can't. It's GPL :-))

> If we use business objects, then of course the wxPython client can stay.
*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.

> As I said, how (rather: who) will it be maintained?
Hoping to not sound hypocritical: By those who do so now.

> I disagree. Remember the current client has basically zero
> functionality,
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.

> 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