Re: [Gnumed-devel] Conference Report

[ju0815nk]

> We agreed at the conference that gnumed development had proceeded a lot
> slower than we had hoped, and that
> it was important to expidite client development. We agreed lack of
> proper design and a clear development plan were
> largely responsible for this situation.
Yes. Plus a small number of active developers, which made things even worse.

> <AU> The point was also raised that the major competitor Medical
> Director is switching to windows SQL in the next year or so, a
> good time to enter the market.</AU>
Do we want to compete ?  I always thought that we just do that for fun and
to
have an independant medical software that meets our needs. I'm not sure if
we are
up for competitiion.

> Horst announced that he would commence work on a "quick" client, using
> Python/Tk, and monolithic postgres server as a
> private project to get something working, this takes the pressure of us
> a little, but it is universially agreed that the current gnumed client
> is
> the definitive client and work will continue on it.
Good.
 
> The current client was criticised on a number of points:
>     - lack of borderless widgets [as an aside, this is probably a
> limitation of the underlying GTK library, a switch to Qt is the only
> real solution here]
This is IMHO a problem that won't stop us get the functional parts working.
I didn'n have the feeling
that one cannot write a functionally attractive GUI with wxPython (at least
that's my experience with 
the Setup and Drug Browser plugin). But yes, Richard is the GUI coordinator
and he will no better than I.
>     - lack of good design tools
>     - hacky double plugin structure
>     - hacky UI modules [no offence Richard]
>     - lack of overall design consistency ("Richard space" and "Karsten
> space")
True.

> 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. 
> The Plan:
> 
> To construct a Python/Qt client as follows:
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 ?

> 1/ Richard will write plain English functional specs, using his client
> as a guide [1 month]
Very good.
> 1a/ Specs for clinical notes viewer are added
> 
> 2/ UML object design from said specs devised. A skills shortage is this
> area was identified,
> Tim Churches has indicated he knows some people who may be able to help
> [1 day workshop + further month]
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. I guess we will 
need a UML-modelller, too. Is there one available as open source ?
IN general, I like the idea of UML object design. Don't know much about it,
yet, but sounds like it could 
help us to sort out our design problems / inconsistencies.

> 3/ actual coding based on above object model [timeline unspecified]
> Need to pick clincial coding system at this point.
> 
> Barring some massive advance with drugref, it is agreed that MIMS is the
> drug database in AU.
> 
> It is agreed that work on the backend should continue as is.
Even if we decide to favour Qt for the client GUIi, please don't throw away
the current wxPython GUI.
Rewriting the client with Qt will take some time, getting it stable even
more. Meanwhile, work on the backend side
should continue. I guess we all agree that at least some sort of GUI is
desirable to test backend functionality/performance.
The current GUI is quite stable, easily extensible to test
backend/middleware without to much work.
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). 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. 

> 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,
IMHO. 2/ will be a big monster that makes us dependant from Qt and it's
licensing. We won't be able to connect that to other GUI's easily if we use Qt 
objects
for everything. 
/3 miight be doable, but we have to make sure that license problems won't
bring us in trouble. Plus we will need somebody who 
does the rewrite.
Well, I personally am fine with 1/ but I can see the benefits of having GUI
design tools and a better widget set available. However, I suggest not to
drop the current client until a stable alternative is ready.

Regards, Hilmar

-- 
COMPUTERBILD 15/03: Premium-e-mail-Dienste im Test
--------------------------------------------------
1. GMX TopMail - Platz 1 und Testsieger!
2. GMX ProMail - Platz 2 und Preis-Qualitätssieger!
3. Arcor - 4. web.de - 5. T-Online - 6. freenet.de - 7. daybyday - 8. e-Post