[Top][All Lists]

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

Re: [Gnumed-devel] PropertySupport

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] PropertySupport
Date: Mon, 26 May 2003 03:14:26 +0200
User-agent: Mutt/

> Another problem is most (actually, virtually all) of gnumed UI code is 
> contained 
> as plugins. Plugins are meant to be self-contained items of code, ideally one 
> file, 
> to do a specific job. Users can load and unload modules at anytime. A 
> separate file  
> to hold handlers complicates things, as it has to be loaded/unloaded in 
> unison with
> its 'original' plugin file (but certainly doable).
IMHO, this is achievable by importing a plugin-specific handler file
in the plugin code and del()ing it upon deregister()ing.

> In addition, the current plugin system is poorly designed, as has been 
> commented on before,
Exactly what in it is so poorly designed ?

> All our "hand-rolled" screen widgets, such as gmEditArea, inherit from 
> gmWidget, so that they all
> update their values into the common dictionary (which is a member of the 
> plugin object)
IMHO no. A GUI plugin is a GUI plugin. It should have nothing
to do with a business object except talking to its API.

> [can this end the need to scan files and add handlers in a separate file? 
> Each widget could handle all of its
> own events. Or am I missing something?]
I guess yes it can. Teaching our widgets how to talk
generally to business objects is a good idea and can well be
done via a common ancester - or rather mixin in this case.

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]