[Gnumed-devel] code location framework (was Gui-Designers was the id_name debate)

[J Busser]

At 11:45 AM +0200 9/11/04, Karsten Hilbert wrote:
> The purpose of test_area/ is to serve as a staging area for
> various ideas that may or may not be directly or conceptually
> merged into the trunk code.

Questions about existing directories in the CVS. The existing readme 
mentions only a few in passing. Is there anywhere already written 
notes about the intended or preferred functions of the following 
directories and files already placed within? (I can afterward post a 
digest/synthesis to the wiki)

==========================
appgen
- what is this for?


==========================
Archive

- how do files get into here?

- how is it to be used? "stuff we tried but rejected", "older 
versions of stuff we still use" and "other stuff people might like to 
use" and if for more than one of these is it less confusing if these 
are separated?

- I note a folder "scan", why do I not also find this in server or client?


==========================
client

- main trunk code to be located & run on the client?


==========================
CVS

- presumably reference or tracking files maintained by the cvs 
software and not directly interacted with by the developers?


==========================
data
- as with "CVS"?


==========================
device-drivers

- presently this contains a single file, Clinitek50.py

- is this directory intended purely for where the gnumed application 
is intended to directly access, or control, a device?

- for the purpose of operating a scanner (or digital camera or 
videocam) to capture directly into a patient record, would gnumed 
need a custom .py driver written for every device? If true is it more 
practical to let some other software capture and save the image file 
to a directory and maybe gnumed can smartly offer in order of most 
recent) the files that have been added to the reference directory 
(and maybe also renaming the file if that is desirable)

- if not the file Clinitek50.py, then other (future) drivers stored 
here (or prospective users) might benefit from accompanying usage 
notes, tips etc. Perhaps as this directory grows, each device 
(preferably with an accompanying readme) might be better be placed in 
its own subdirectory and as several devices accumulate, group them by 
category of device. This could let people see what other people 
(apparently) are already using successfully (unless the readme warns 
of problems).


==========================
dists

- the readme says: "Subdirectories in here hold files relevant to 
packaging GnuMed or parts thereof for various purposes.

- should we redefine the purpose of these directory contents to the 
hosting of EXECUTABLE CODE specific to a distro? I am thinking that 
for files whose function is to simply offer information (such as for 
Debian,  the readme pointing to Andreas' packages) we now do support 
this on the wiki

- the "XdtViewer" was placed here by Karsten (info at 
http://lists.gnu.org/archive/html/gnumed-devel/2003-02/msg00190.html)

Am I gathering correctly it is not distro-specific but is a more 
generic "package"?

If it is meant for the clients to use, should it move to clients and 
if germany-specific moved inside clients, say to a "/de" directory?

Is Ian's epydoc output listing a gui plugin gmXdtViewer pertinent to 
progress with xdt?
http://gnumed.net/~ihaywood/epydoc/public/Gnumed-module.html

- the "Windows" directory... is there some function/use to what is in here?


==========================
drafts
- there is nothing in here but given that we have test-area for code 
and the wiki for documents/text information do we no longer need 
drafts so should we deprecate it?


==========================
html

- while the readme file says "this is deprecated, please go read 
gnumed/client/doc/* (and I know cvs does not permit to remove 
directories) should we not delete the individual files, that way 
there is less chance of someone working on their local file copies to 
access the wrong one (and is this a general strategy we should try to 
follow when deprecating?)


==========================
server

- main trunk code to be located +- run on the server?


==========================
test-area

- per Karsten "serves as a staging area for various ideas that may or 
may not be directly or conceptually merged into the trunk code"

- applies to ideas and code intended for both client and server


==========================
windows

- empty; what purpose is it meant to serve?