[Top][All Lists]

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

Re: [Gnumed-devel] SOAP widget navigation - RT coments

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] SOAP widget navigation - RT coments
Date: Thu, 15 Jul 2004 06:05:19 +0200
User-agent: Mutt/

> - This SOAP editor is an attempt to emultate the appearance and 
> functionality of the edit-area(s), without the cumbersome nature of text 
> boxes, hence gaining much screen real-estate space for extra use. For 
> example the extra space can now be used for enhancements such as tool 
> pallettes for diagram drawing etc.
This is understood.

> - By modifying a text editor we are moving on from that control to 
> effectively create a new one with new properties
But we aren't going back to fields.

> - The features Ian describes of the function of the return/enter/tab 
> keys enhances functionality. Having done much 'on the ground' computer 
> tutition in doctors surgeries over the years, I've noted how many people 
> work.
If you say so I cannot argue against that.

> The enter key is a particulary intuitive way to move to the next 
> line, and in fact, if you think back to the early dos days it was 
> usually used as such. Having implemented in my editing areas both the 
> tab/enter key to move forward, I can tell you that for me (and I'd 
> suggest most people), the speed of use of the control will be doubled by 
> the simple use of default enter key presses.
I still need a way to tell the widget to start a new line now.
I am fine with Ctrl-Enter, too.

> - I would also again plug for the use of enter to not just signify end 
> of SOAP line etc, but to put a default separator character after the 
> current input,
Oh, you mean after *any* partial SOAP line ? Eg, also after
fragments of the Soap line ? That sounds right and I think I
overlooked that.

> If the enter key is pressed again after the last ; 
> is automatically added by the system, it signifies to the editor to move 
> to the next SOAP line (etc).

> Also, I don't think we need to wait for another version to add the 
> in-line popup secondary editors
I didn't mean to wait for "another version" but rather to
stabilize the basic version first. It is by no means trivial
to do that. We are not popping up phrase wheels, we are using
functionality that the control already offers. We just reuse
the matchers that allow for attaching to different match
sources and deliver different match locations depending on
fragment lenght. For one thing we don't have the delayed popup
yet (which could be implemented fairly easily though).

Also remember that those popup edit areas can be wildly country
dependant. This doesn't mean someone shouldn't go ahead and
attach one for AU but they'd rather think about how to design
that so i18n-aware ones can simply be attached instead.

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

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