Re: [Gnumed-devel] non-blocking document browser

[Karsten Hilbert]

On Tue, Sep 12, 2006 at 06:30:00AM +0800, Syan Tan wrote:

> Another request:
> the document browser blocks after displaying an image in the mailcap 
> chosen image viewer, and unblocks only when the image viewer is closed.
I don't like the blocking too much, either.

My reasoning was the following at the time of coding:

Only if it blocks can we pop up the review dialog on
unreviewed documents *after* the document has actually been
seen (that is, after *closing* the viewer). However, since
popping up the review dialog is configurable in its own
right I acknowledge the sane use case of still supporting
non-blocking document display (namely, when configured to
*not* pop up the review).

Hence I made it optional as to whether display is blocking
or non-blocking in the CVS HEAD code :-)

Technically, it's an ugly hack of limited (but controllable)
applicability and the wrong way to go about things. Here's
why (comment and code taken from the original source) and
how to do it properly:

        if viewer_cmd is not None:

                # what the following hack does is this: the user indicated
                # whether she wants non-blocking external display of files
                # - the real way to go about this is to have a non-blocking 
command
                #   in the line in the mailcap file for the relevant mime types
                # - as non-blocking may not be desirable when *not* displaying
                #   files from within GNUmed the really right way would be to
                #   add a "test" clause to the non-blocking mailcap entry which
                #   yields true if and only if GNUmed is running
                # - however, this is cumbersome at best and not supported in
                #   some mailcap implementations
                # - so we allow the user to attempt some control over the 
process
                #   from within GNUmed by setting a configuration option
                # - leaving it None means to use the mailcap default
                # - True means: tack " &" onto the shell command if necessary
                # - False means: remove " &" from the shell command if its there
                # - all this, of course, only works in shells which support
                #   detaching jobs with " &" (so, most POSIX shells)

                if block is False:
                        if viewer_cmd[-2:] != ' &':
                                viewer_cmd += ' &'

                elif block is True:
                        if viewer_cmd[-2:] == ' &':
                                viewer_cmd = viewer_cmd[:-2]

                exit_code = os.system(viewer_cmd)
                _log.Log(gmLog.lData, 'os.system(%s) returned [%s]' % 
(viewer_cmd, exit_code))
                return True, ''

On Windows, we don't have a choice. os.startfile() cannot be
made to block on demand. And there's no way to find out the
viewer command like on POSIX systems, either, so that we
could also use os.system().

> it may be easier for browsing or for writing notes if a image can be opened
> but the gui still be responsive, e.g. to changing to and using progress notes 
> entry
> whilst viewing the image.
I fully acknowledge the use case in itself. It's just
technically a bit difficult. Configure

 horstspace.document_viewer.block_during_view

to 0 or 1. Then make sure to set

 horstspace.document_viewer.review_after_display

appropriately, too.

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