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

[Ian Haywood]

> > Solving any of these implies a UI code rewrite, even if we stick
with
> > wxPython.
> Sure, we will have to replace parts of the current UI if we stick to
> wxPython and all of it otherwise.
Which parts would be preserved?

> Is there an agreement that we really want to leave wxPython for the
sake of
> Qt ? Do we want to
> leave it completely and right now ?
There is agreement between Richard, Horst and myself. We apprepricate
that you [Hilmar]
and Karsten ideally should have attended the conference!


> Well, we don't know if these people will be willing and have enough
spare
> time. Plus
> there is a lerning curve for everybody who want's to take part in that

> process.
True. However I believe it is an important proces.

> Is there one available as open-source
www.umbrello.org

> Even if we decide to favour Qt for the client GUIi, please don't throw

away
> the current wxPython GUI.
If we use business objects, then of course the wxPython client can stay.

As I said, how (rather: who) will it be maintained?

> Rewriting the client with Qt will take some time, getting it stable
even
> more.

I disagree. Remember the current client has basically zero
functionality,
despite Richard's widgets being in situ for around a full year. With the

plugin framework promised by Horst and the designs using QtDesigner
by Richard, we are pretty much back to where we currently are with
wxPython: not
that difficult.
In terms of debugging, the current client hasn't undergone much, not
much
functionality *to* debug of course!

> I suggest that (in the case of a GUI switch) we should fork the
current
c> lient tree (or at least the GUI part of it). Then everybody can work
on
> whatever
> tree he likes best. Once the new tree is stable and tested, missing
widgets
> can be ported from one tree to the other.
Agreed, we already have a client fork in the form of Syan's Java client
of course.


> Architectural concerns: [IMHO, this is where much if the problem lies,

> it  is difficult to do much work without firm foundations]
>
> Choices discussed:
> 1/ Status quo: wxPython client, pluggable with 2 plugin systems,
> 2/ Qt using Qt's own database objects and data-aware widgets
> 3/ Qt using Karsten's business objects,
> 4/ 3/ with communication via XML-RPC

> Looks like 2/ and 4/ will mean that we will start almost from scratch.

Which
> will throw us back some a considerable amount of time. Not a good
idea,
[...snip....].
> Well, I personally am fine with 1/ but I can see the benefits of
having GUI
> design tools and a better widget se

I think there is consensus that direct Qt database objects are too
restrictive, and XML-RPC,
although nice,. is (as has been said before) a post-1.0 matter, leaving
3/ and 1/: business objects
bound to Qt (and wxPython if ppl are willing to work on it)

My $.02 on licensing: it is difficult to accede to demands from users of

closed operating systems
that we use a free GUI library on that system, nor to see what advantage

is so offered to said users.
(they *can* still develop, as the source remains GPL, Python is an
interpreted language so it
doesn't matter if the library is binary-only. Of course they need to
switch to Linux if they want to run
QtDesigner. Nice to see the boot on the other foot for once.)
Qt is GPL on Linux, so purists can be GPL right down to the BIOS if they

want.

Coding jobs:
Despite preaching the importance of design, IMHO, there can coding tasks

that can be done while we
are waiting:

1/ demographics business object: the backend schema is well established,

should be easy to write w/o controversy.
2/ drugs business object (partially done, untested)
3/ XML forms backend (is actually GUI dependent of course, )
4/ referral letter-writer
5/ path importer (whoever has access to specs, ??Horst??)
6/ Single plugin framework for Qt
7/ Generalisation of clinical history API from the Allergies functions
to avoid separate functions for allergies, immunisations, etc:
viz. a thinner layer around updateable views.  Exact arrangement of
these views depends on outcome of design process.
8/ Any more?

Horst has 6. I am happy to take 2, possibly 1, volunteers for others?.

Ian