gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] SOAP widget


From: Karsten Hilbert
Subject: Re: [Gnumed-devel] SOAP widget
Date: Wed, 14 Jul 2004 10:47:34 +0200
User-agent: Mutt/1.3.22.1i

> This prevents parsing the text into SOAP, if this happens my thinking would 
> be to 
> assume it is deliberate, and chuck the whole entry into an uncoded
> clin_narrative entry. 
No clin_narrative entry can be uncoded but it makes sense to
just write it to a soap_cat=s row.

> > It would be a shame to accidentally bugger up one's SOAP note with no 
> > option but to have to cancel it, lose it all, and start over. 
> IMHO a guding principle should be anythng the user types should be preserved
> in the medical record,
Agree.

> it just won't be tagged and organised as well if the user goes out
> of their way to prevent this.
Using Shift-movement to select text isn't "going out of their
way" but rather everyday best-practice. Using "markers" on the
"margin" will allow this.

> Is already implemented in the widget ;-) Try Ctrl-Z
Praise be to Scintilla :-)

> > ENTER does the same for me, until I reach Plan, after which each press 
> > of ENTER does create a new paragraph ("line").
> This is intentional.
Makes sense for Plan (or the last header, for that matter).

However, the perception of the widget is a simple text editor
with some paragraph headings "prewritten". Hence we'd need to
support the standard text-editing commands.

I would suggest to:

- let ENTER create new lines with one exception: If the last
line of the current section is empty do not create a new line
but rather move to the next section.

- let Tab insert a tab character into the document

- let Ctrl-Tab/Shift-Ctrl-Tab jump forwards/backwards among
the sections

> I quite like Richard's idea that editareas pop up dynamically when
> certain keywords are typed.
IMO this is a new *quality* of enhancement to the basic SOAP
widget and should be done in the next iteration.

> I agree the editareas should still be accessible by other means. In 
> my-not-so-humble-opinion,
> this should be as toplevel notebook widgets,
I am fine with that and in fact this is why factoring out
edit-area code and gui/* and patient/* code into
wxpython/gm*Widgets.py files is on my TODO list.

> Navigating the notebook by keyboard is a must-have.
Yes.

> A nice touch would be
> to map the function keys (what else are we using them for?) to the matching
> tab, so F1 to the leftmost, F2 to the next and so on.
I like !

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




reply via email to

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