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

[Karsten Hilbert]

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

> (I can afterward post a digest/synthesis to the wiki)
Good.

> appgen
Once used by code from Syan in an attempt to generate
application code from some other structure.

> Archive
> - how do files get into here?
by checking them in

> - how is it to be used?
It once held the code for the document archive when that part
wasn't merged into GnuMed proper yet. It now serves as a
staging area for document archive code to be merged into the
main trunk much like test_area/

Legacy. To disappear at some distant day.

> - I note a folder "scan", why do I not also find this in server or client?
Because the stuff in there hasn't been merged yet.

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

> CVS
Working dirs of the CVS system. Don't touch.

> data
legacy, empty, disregard, -P it

> device-drivers
> 
> - presently this contains a single file, Clinitek50.py
a driver for the Bayer Clinitek 50 urinalysis device -
deployed at one site here in Leipzig (although not by me)

> - is this directory intended purely for where the gnumed application 
> is intended to directly access, or control, a device?
A staging area for device drivers. Once more device drivers
are developer a better pattern might emerge on where to place
and how to use them.

> - 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?
Thanks $DEITY, no. We interface SANE/TWAIN. And it works. And
has been deployed nearly 2 years ago.

> 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)
All that is old news and been working for ages.

> - if not the file Clinitek50.py, then other (future) drivers stored 
> here (or prospective users) might benefit from accompanying usage 
> notes, tips etc.
On my machine there also is a driver for the MicroLab 3500
spirometer sitting in that directory ?

> 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.
We shall see.

> This could let people see what other people 
> (apparently) are already using successfully (unless the readme warns 
> of problems).
Sounds reasonable.

> 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?
No. CVS isn't for storing, say, *.debs but rather for storing
control files for *building* debs and such. This is what this
directory is for. "dists" refers to GnuMed-dists, not Linux
distributions.

> 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
True enough. Still, eventually deb control files would live
here. If Andreas wanted they would be here today. Until then a
README pointer is IMO useful.

> - 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"?
No. Rather does this directory contain files that make it
possible to package the XDT browser as a standalone
application distribution.

> 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?
IMO no.

> Is Ian's epydoc output listing a gui plugin gmXdtViewer pertinent to 
> progress with xdt?
Yes. The plugin wxpython/gui/gmXdtViewer.py still contains the
business logic for displaying XDT files in a list box instead
of just wrapping a wxpython/gmXdtWidgets.py class. That class
is also used in the standalone XDT viewer that is packaged for
distribution by dists/XdtViewer/

> - the "Windows" directory... is there some function/use to what is in here?
Why of course. It's our (current attempts at a) Windows
installer.

> drafts
Kill.

> 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?)
There is still unique content in them no one has bothered yet
to move to either the Wiki or to gnumed/client/doc/*

> server
> - main trunk code to be located +- run on the server?
a) run to setup the schema
b) run on the server to check foreign keys across databases
c) tools to dump missing translations from the schema

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

> windows
> - empty; what purpose is it meant to serve?
-P

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346