[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Gnumed-devel] forms handling / NetEpi
From: |
Karsten Hilbert |
Subject: |
[Gnumed-devel] forms handling / NetEpi |
Date: |
Tue, 19 Jun 2007 17:11:58 +0200 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
On Tue, Jun 19, 2007 at 08:28:18AM +0200, Philipp Walderdorff wrote:
> > First step might be to simply use OpenOffice with a template
> > and a background image.
>
> Open office stars verry slowly.
We don't need to *start* OOo for each form. We simply talk
to a running OOo. We already have the code for that.
> If the print-function is needed often per day
Yes.
> this is time-consuming.
It would be, yes.
Advantages of using OpenOffice would be:
- cross-platform
- acceptably easy beginner-level form generation
- scan image
- load as background image
- add textboxes and/or placeholders onto image within OOo
- tell GNUmed to use the new form
> That is wy I am usin vi for writing Attest and letters for patients, which is
> not userfriendly, but verry quick.
So, the user interface for filling in the form is vi ? Or
any other fast text editor, for that matter.
> For that task I will have to know python, some time is necessary for that :-(
Yes, but it's not that hard to learn. wxPython may be
slightly harder to get a grip on.
BTW, the process I imagine here would be the same for pretty
much any document, letter or pre-designed form:
Letters would be templates without a background image while
forms may or may not have one. If they do have one the would
be suited for on-screen in-OOo "WYSIWYG"-style editing of
the form while those w/o a background image would simply be
processed by GNUmed *via* OOo - the user would never need to
bother looking at the thing inside OOo.
The only one thing I am not yet conceptually clear about is this:
How do we handle form filling from within GNUmed for those
forms which are not to be edited inside OOo ? For that one
would want a GUI generator which creates a UI mask from a
definition of fields.
Tim, how is this (conceptually) done in NetEpi ?
Karsten
--
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346