Re: [Gnumed-devel] layout managers

[Karsten Hilbert]

> > > EVT_PAINT has two shortcomings compared to the current code.
> > >   - widgets can't veto being uncovered. (Personally I don't see this as a 
> > > problem, I can cope
> > > with seeing blank fields if no patient is loaded.)
> > a) the problem isn't the user coping with blank fields but
> >    rather the widget code continually having to check for
> >    patient existence unless we adopt the hard-and-fast rule
> >    "if I am visible I DO have a patient"
> As far as I understood, this was what Horst was talking about -- 
> when EVT_PAINT is received, the widget reconciles business layer reality with 
> its
> display, whether that's no patient, new patient or new data from the backend.
Well, the widgets have to everywhere (not continually, bad
choice of words) check whether there is a patient like so:

if not pat.is_connected():
    display_empty_boxes()
else:
    display_data(pat.get_data())

We could take the design decision that when a widget receives
an EVT_PAINT it DOES HAVE a patient available. Any "user" (as
in caller) of that widget needs to make sure this holds true.
In most cases this is the layout manager. Which is why many
Horst space notebook tabs can't be activated when there's no
patient. So, upon

EVT_PAINT:

1) assume there is and get patient
2) check for stale data
   2a) fetch new data if needed
3) repaint

new_patient/new_data:

1) assume there is and get patient
2) check for visibility
   2a) if visible reconcile data from business layer
       and redisplay
   2b) if not visible mark data stale
       

> > > This isn't a factor if we move to the behaviour of Richard's client 
> > > (where the demographics
> It relates to the new_patient event only in that all other notebook widgets 
> become hidden when this happens,
> so they don't have to worry if they're visible (because they're not).
I see. That'd work for all widgets with always-known
visibility states.

> these backend data changes relating to the current patient are another kettle 
> of fish.
> To be honest, I've never truly understood this.
> For instance, when the backend listener generates an event, the business 
> layer must
> respond first (if the GUI responds first, it will upload from old data in 
> business layer cache)
> How is this enforced? Presumably with two events: one listener -> backend, 
> one backend -> GUI,
> but I can't see this in the code anywhere. Can you explain?
The simple secret is that it is two events carrying the same
message:

- INSERT into table
- table trigger sends NOTIFY with patient ID attached
  - no one emits NOTIFIES
- threaded backend listener catches NOTIFY
  - if patient ID matches
  - no one else listens for NOTIFIES
- backend listener signals business layer via gmDispatcher
  - signal name is reused
- business layer catches gmDispatcher signal
  - if patient ID matches
  - no one else listens for this signal
- business layer evicts cache
  - eventually, async refetch should be initiated also
- business layer signals frontend via gmDispatcher
  - signal name is different (but same meaning)
- frontend widgets catch gmDispatcher signal
  - multiple receivers possible
- frontend receiver gets data from business layer
  - currently this is slowdown due to synced data transfer
- business layer picks up data
  - either directly from backend
  - or from async fetcher

Note that when the business layer does async refetches it
should signal changed data to the frontend only after the data
has arrived from the backend. In that case the widget need not
care about visibility anymore but can rather always go ahead
and request the data from the backend immediately.

> More importantly, this all sounds like a very large amount of work for very 
> little gain.
The entire chain is working already except for the
visible/not-visible behaviour by the widgets. There's two
solutions to that: have layout managers call
widget.you_disappear_now() so the widget can delay subsequent
data refetches until the next EVT_PAINT. Or implement async
data refetches in which case the visibility doesn't matter
anymore.

> At the end of the day, a patient can only be at one place at
> one time, and only one thing can happen to them at once.
> (except in resus, I suppose, but then there is still only one person doing 
> documentation) What am I missing?
Think incoming lab results, XR notes. Also think forgotten
workplaces, eg. the user not cleaning up program state when
leaving a workplace. I admit it might be "fairly rare".

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