Richard Terry wrote:
ok , I explained it like the babbling propeller-head that I am, on discoveringsyan,
I'm afraid I'm not literate enough to follow your instructions.
Any chance of expanding on them?
Richard
some new aspect .
I am now going to mouth off an explanation about something I have superficial knowledge about, just like any user on the postgres users list, or twiki users list. Glad to see Gnumed is making the grade with acquiring superficial users.
The problem seems to be:-
1.
- from HorstSpace (default) gui, the config editor can be used
to change the settings in default workspace DB:CURRENT_USER_CURRENT_WINDOW/main/window/ layout_style
from 'status_quo' to 'terry'. (this is Karstens/Ians/Hilmar's work)
2. Also go to DB:CURRENT_USER_CURRENT_WINDOW/terry_layout/plugins and replace the list of gmGP modules with the 2 lines:-
Gnumed.wxpython.gmDemographics.Demographics Gnumed.wxpython.gui.gmConfigRegistry.gmConfigEditorPanel
This explicitly puts demographics and config editor as modules to load.
3. when the client is shutdown and then re-executed, it should run in RichardSpace, except there may be an error with loading a default.png bitmap that is available on Ian's installation, but not mine. It isn't in the cvs under gnumed/gnumed/client/bitmaps either . If one is using an editor with search, search for "default.png" and change that to one of the png files in the bitmaps directory. RichardSpace should then be working with demographics.
4. In order to get RichardSpace to get the config editor to work as well, the constructor ( the
def __init__(self, parent, ....)
) function
in Gnumed/wxpython/gui/gmConfigRegistry.py , class gmConfigEditorPanel, line 373 ,
should have a default 2 parameter definition, so that in
class gmConfigEditorPanel(wxPanel, gmRegetMixin.cRegetOnPaintMixin):
def __init__(self, parent, aUser,aWorkplace, plugin = 1):
wxPanel.__init__(self, parent, -1)
gmRegetMixin.cRegetOnPaintMixin.__init__(self)aUser and aWorkplace needs default values , in order for
the RichardSpace module to load it : I think this is a good
idea, because there is enough Singleton global objects
such as gmCurrentPatient , and gmWhoAmI.cWhoAmI to not need parameters for gui modules : thus a plugin
is simplified to anything that can be constructed like a wxPanel
with minimum parameters (Ian's idea, as far as I gather).
The gui module then gets its connection to the business layer
via the global reference objects.
so the above example becomes ,
class gmConfigEditorPanel(wxPanel, gmRegetMixin.cRegetOnPaintMixin):
def __init__(self, parent, aUser =gmWhoAmI.cWhoAmI().get_db_account()
,aWorkplace=gmWhoAmI.cWhoAmI().get_workplace(), plugin = 1):
wxPanel.__init__(self, parent, -1)
gmRegetMixin.cRegetOnPaintMixin.__init__(self)...
gmWhoAmI is the module, cWhoAmI is the singleton class that when constructed
always returns the same object and get_db_account() gives the
postgres CURRENT_USER , and get_workplace() gets the correct current workplace.
If you look at the Plugin class at line 527, which is the older style way of defining plugins, the GetWidget() function basically uses a cWhoAmI() instance , and constructs the ConfigEditorPanel using the same functions.
to
_______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
