Re: [Gnumed-devel] soap2

[Karsten Hilbert]

> >What is the rationale behind the seemingly complicated
> >__userlist/instance/callable/complete callbacks. It seems
> >complex.
> The idea is, a cMatchProvider may return in response to a match, 
> *either* a cResizingWindow instance (which answers your first question:
> that returned window becomes the popup.),
> or a callable, which is then called (in case you want to do something 
> else) or an inert, opaque data object (i.e. our existing match 
> providers) which is recorded,
Ah, I see. In our current match provider concept we were going
by the basic assumption that we'd be looking for a list of
string matches for a given string fragment. You are
conceptually extending that assumption such that the
"fragment" could also be a "keyword" upon occurrence of which
we would want to invoke some action or other.

I would propose to slightly more separate those things
conceptually:

- upon STC_MODIFIED lookup current fragment in "keyword" dict
    - if found:
        - modally do the attached action
        - use return value as embedded string
        - use return value as key in extra_values dict

    - if not found
        - if inactivity tineout passed
            - hand it to the match provider for string matching
              as in cPhraseWheel
            - simply embed selected string

This seems conceptually clean, quite simply (I like simple
where possible) and also capable enough to handle all
situations we might want to cover. Any faults in my reasoning?
What do you think ?

> An alternative, if you don't like this approach, is to extend the 
> dictionary the match providers are allowed to return, so they can return
> a 'popup_window' key, etc.as well/instead of the 'data' key.
Again, I would handle the dichotomy of whether to popup a
simple select list or to popup some complex widget right
inside ResizingSTC. That way no "double-rebound" callbacking
is involved.

> >Also the handling of picklist.alive in several classes seems
> >confusing.
> A picklist may die one of two ways: either itself when the user clicks
> on an item, or by the parent when the user tries to do something else 
> with the parent.
I don't remember having that problem with the phrase wheel. We
may want to look there how I did it. I understand the desire
to work around unexpected wxPython behaviour but I don't think we
should put that into the main trunk unless it can clearly be
demonstrated to be a real bug by a simple test program.

I have a feeling we just have the close semantics off by a
few inches which I would rather see fixed than work around it.

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