gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] [FreeMedForms] Re: Free diams


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] [FreeMedForms] Re: Free diams
Date: Wed, 16 Oct 2013 10:30:37 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Sun, Jul 21, 2013 at 12:54:14PM +0200, Eric Maeker wrote:

> >>>>>> [...] currently partially broken [...] FreeDiams does not send
> >>>>>> back PDF files for prescriptions
> >>> 
> >>>>> [...] corrected in v0.8.4
> >>> 
> >>> Hi,
> >>> 
> >>> Did someone made some tests with FreeDiams 0.9.0~beta1 on Ubuntu?
> >>> 
> >>> Thanks
> >>> Eric
> >> Hello!
> >> 
> >> FMF 0.9.0 beta 1
> >> Ubuntu 13.04 64 bits
> >> 
> >> Printing is ok, i can previsualize and save the prescription in pdf.
> >> There seems to be no problem.
> > 
> > The problem was about FreeDiams auto-creating PDFs,
> > auto-saving them into some sort of archive directory and
> > putting the paths into the XML file passed back to external
> > applications.
> > 
> > Did you test that ?
> 
> Yes. Works perfectly now
> 0.9.0beta2 does not segfault at any time...
> I'll update the ppa as soon as possible to help you in your testings. I'm 
> starting to write some unit test for this part of the code (prescription XML 
> files)

Now that Debian/Unstable carries 0.9.0 I can report
more details on this aspect:

It is a good idea that FreeDiams uses a dedicated
subdirectory of /tmp/ for each instance of itself.

It is also a good idea that FreeDiams cleans up after
itself (eg deletes its tmp directory) upon closing.

However, when there's no explicit path configured for
automatic PDF copies of printed descriptions the two
ideas collide: FreeDiams dutifully keeps copies of
printed prescriptions as PDFs in

        /tmp/freediams_<HASH>/

and also keeps tab of them in the XML file passed
back to calling applications but FreeDiams also
duefully deletes /tmp/freediams_<HASH> when
FreeDiams is closed :-)

That means those PDFs won't serve any useful
purpose when the default path is used and, in
fact, the XML file does not represent the truth
in that case.

Of course, the workaround for now is to require
an explicit path to be configured (say, /tmp/) but
I do believe fixing the described behaviour would
help avoiding to violate the POLS

        https://en.wikipedia.org/wiki/Principle_of_least_astonishment

A fix might consist of

- *requiring* a path to be configured or
- defaulting to /tmp/ rather than /tmp/freediams_<HASH>/

Thanks,
Karsten
-- 
GPG key ID E4071346 @ gpg-keyserver.de
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346



reply via email to

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