[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnumed-devel] code location framework (was Gui-Designers was the id
Re: [Gnumed-devel] code location framework (was Gui-Designers was the id_name debate)
Sun, 12 Sep 2004 18:22:29 +0200
> 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)
Once used by code from Syan in an attempt to generate
application code from some other structure.
> - 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.
> - main trunk code to be located & run on the client?
Working dirs of the CVS system. Don't touch.
legacy, empty, disregard, -P it
> - 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).
> - 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
> 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
> 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
> 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?
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
> - 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/*
> - 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
> - 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
> - empty; what purpose is it meant to serve?
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346
Re: [Gnumed-devel] Gui-Designers was the id_name debate, J Busser, 2004/09/16
Re: [Gnumed-devel] Gui-Designers was the id_name debate, Horst Herb, 2004/09/16
Re: [Gnumed-devel] Gui-Designers was the id_name debate, Karsten Hilbert, 2004/09/16
Re: [Gnumed-devel] Gui-Designers was the id_name debate, J Busser, 2004/09/17
Re: [Gnumed-devel] Gui-Designers was the id_name debate, Karsten Hilbert, 2004/09/20
- Re: [Gnumed-devel] Gui-Designers was the id_name debate, E Dodd, 2004/09/16
- Re: [Gnumed-devel] Gui-Designers was the id_name debate, Karsten Hilbert, 2004/09/16
- Re: [Gnumed-devel] Gui-Designers was the id_name debate, J Busser, 2004/09/16
- Re: [Gnumed-devel] Gui-Designers was the id_name debate, E Dodd, 2004/09/17
- Re: [Gnumed-devel] Gui-Designers was the id_name debate, Karsten Hilbert, 2004/09/19