Re: [Gnumed-devel] layout managers

[Karsten Hilbert]

> > I have factored out the Horst space simple notebook design
> > into it's own layout manager panel child class (still living in
> > gmGuiMain.py). Please have a look if you have any objections
> > or maybe want to do the Richard space manager like that. I
> > have taken care not to remove any of the Richard space code
> > but I am fairly sure it won't work out of the box. Later on we
> > can move the layout managers into their own files
> > (gmTerryGuiParts.py comes to mind).
> Looks good.
> AFAIK cHorstSpaceLayoutMgr would work as a wxNotebook descendant.
It already is a wxPanel holding nothing but a wxNotebook
currently. However, you never know what else it may need at
some point in time... :-)   It may also be advantageous to
"know" that layout managers are wxPanels at their topmost
level. That much conformity I think we are entitled to
enforce *evil grin*

> > I haven't yet gone down the path of changing the plugin load
> > API. I have, however, an EVT_PAINT based data refresh in the
> > works.
Note that this is a) confined to Horst space at the moment and
b) is even doable for single Horst space plugins at a time (as
is the case now).

> 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"
b) The EVT_PAINT mechanism hasn't got anything to do with
   vetoing being uncovered ! All it does is that on receiving
   an EVT_PAINT the widget code checks whether the backend
   data has
   - changed: in which case the widget fetches the data
              immediately and redisplays itself
   - not changed: in which case the widget does nothing

   Now, how does the widget know that the data has changed ?
   Well, it listens to appropriate gmDispatcher signals being
   emitted by business objects (gmClinicalRecord, mostly). The
   business objects in turn learn of data changes via the
   async notify-listen thread. The widget checks whether it is
   - visible: in which case it immediately fetches the data
              and redisplays itself
   - not visible: in which case it just schedules a data fetch

   Also, it doesn't really matter which way the data is
   fetched. It may be async or in sync. Doesn't make a
   difference to the above scheme except for better usability
   in the async case at the cost of a bit more involved code.

>       - no "unpaint" event, so the exposed widget when a patient changes 
> doesn't know this. 
This is the main problem of the above scheme. Layout managers
would need to call a method you_are_not_visible_anymore() upon
switching to another widget. Which is IMO an acceptable thing.
Even if they *don't* call that method the widget will just
always think it is visible and always immediately fetch the
changed data. This will result in slowdown but not any loss of
functionality. And even that slowdown will simply go away once
fetching data is done async.

> This isn't a factor if we move to the behaviour of Richard's client (where 
> the demographics
> screen comes to the fore automatically to display patient search results, 
> instead of a popup result window) 
This doesn't at all solve the issue at hand as far as I can
see. How does it react to backend data changes related to the
patient currently being displayed ? I mean, one could popup a
window saying
*---------------------------------------------*
 The data for the current patient has changed.

  Reload now ?
*---------------------------------------------*

but how cool is that ?  :-))
(never thought I'd use that sort of argument, hehe)

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