[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] roadmap and what a 0.1 release will "look like"
From: |
Karsten Hilbert |
Subject: |
Re: [Gnumed-devel] roadmap and what a 0.1 release will "look like" |
Date: |
Sat, 27 Mar 2004 09:43:05 +0100 |
User-agent: |
Mutt/1.3.22.1i |
> Can everything that is written to run "under" or "inside" wxPython be
> considered part of the GNUMed user interface?
No. It is part of the GnuMed client collection but not
necessarily part of *the* GnuMed user interface. But OTOH,
well, yes.
> Can the wxPython GUI (and any embedded non-GUI functions) be understood
> as a collection of widgets, presumably
> - under the coordination of, and...
> - accessible through, and...
> - optionally independently of...
> the user's first widget after the login backend connection, a widget I
> gather may be the "main notebook"?
Yes, except that the business classes can be (and are) used
also from separate clients (say, the importers/exporters).
> Presumably some of the "standalone" clients, which might be cronned,
> can also be controlled from (or at least activated by) one of the other
> GUI widgets
It is certainly possible to write a controlling plugin for the
wxPython client but that doesn't necessarily make sense: Path
results will end up in some directory on the server to be
picked up by the importers. The wxPython client will usually
run on the client machines ...
> Can I infer that the "standalone" clients could involve any combination
> of
> - their own wxPython GUI widget (document archive browser, ASCII
> patient exporter?)
Yep.
> - other user control (Python programming or command-line interface, or
> a text "settings" or "prefs" file)
Yep.
> A "standalone" client, even when it has a wxPython GUI, is considered
> not to be part of the "main" "wxPython client"?
Yes or no. Any way we want it. To tell the truth, the main
wxPython notebook client is a specialized application GUI
framework and hence suited to any widget that deals with a
patient.
> How then to easily express the state of development, or readiness, of
> parts?
Well, express the state of development of *functionality*, not
physical parts. Implementations may change over time.
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346