gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: ju0815nk
Subject: Re: [Gnumed-devel] Move to Qt (was: Conference)
Date: Wed, 13 Aug 2003 17:39:09 +0200 (MEST)

Hi,
> > 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?
I refer to the core GUI structure like plugin management, login, main window
and associated functions like the patient selector in the top bar. These are
needed in order to write and test plugins and should be running and stable 
before we do the switch to an Qt/whatever GUI-client.


> > 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?
Well, nobody - or anybody who likes. If Qt is up and running there will be
no 
need to maintain another client. But until then it should remain.

> > Rewriting the client with Qt will take some time, getting it stable
> > even more.
> I disagree. Remember the current client has basically zero
> functionality,
It has at least a core functionality (see above). 
> 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.
If the work progresses at the same speed as right now, it might take half a
year :(. Even if we speed up 
it will take at least 1-2 month (prove me wrong).
But if you are right  - why doesn't somebody start to write the core GUI
functionality while Richard is paper designing the GUI ? Let's fork the tree.
Someone writes the Qt client, the rest continues on the wxPython tree as long
as the Qt client is not ready.

> Despite preaching the importance of design, IMHO, there can coding tasks
> that can be done while we are waiting:
In order to avoid duplication of work, please refer to the roadmap document
in the CVS written by Karsten. There are already some names assigned to tasks
(I guess that the list you presented is the same plus some new tasks).

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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]