[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/

> 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?)

> - other user control (Python programming or command-line interface, or 
> a text "settings" or "prefs" file)

> 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

> 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.

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

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