[Gnumed-devel] remote control GNUmed

[Sebastian Hilbert]

Hi all,

Jim mentioned it and we took the liberty of giving you the opportunity to see 
GNUmed being driven by an external program.

It is really easy. Set up a local database gnumed_v2 by using redo-v2.sh in 
bootstrap (latest CVS ). This has consistently worked for me during the last 
few months so I don't expect any problems.

change into the client directory and run gm-slave-test-from-cvs.sh
It will start a GNUmed in slave mode.

This instance of GNUmed can be controlled by 3rd party programs like python 
scripts.

In the same directory there is an example script named test-slave.py. Run it 
and watch the GNUmed gui being magically remote controlled.

It opens a patient and switches to the document viewer plugin.

Example session:
address@hidden:~/sources/gnumed> 
address@hidden:~/sources/gnumed/gnumed/client> python test-slave.py
=> setting up connection to GnuMed client on localhost:9999
=> showing macro processor version
cMacroPrimitives $Revision: 1.21 $
=> attaching to macro processor (should fail, missing cookie)
[0, 'attach to personality [None] rejected']
=> attaching to macro processor (should fail, wrong cookie)
[0, 'attach to personality [wrong cookie] rejected']
=> executing action in client (should fail since not attached)
0
=> attaching to macro processor (should work)
1 0.727081896298
=> trying to raise GnuMed client to top of desktop
cMacroPrimitives.raise_gnumed() not implemented
=> listing loaded plugins (should fail)
0
=> listing loaded plugins
['gmNotebookedProgressNoteInputPlugin', 'gmScanIdxMedDocsPlugin', 
'gmConfigRegistry', 'gmShowMedDocs', 'gmEMRBrowserPlugin', 'gmManual', 
'gmEMRJournalPlugin', 'gmNotebookedPatientEditionPlugin']
=> raising a plugin that doesn't need an active patient
1
=> trying to raise a plugin that needs an active patient
1
=> knew it, need to lock into a patient first ...
1 0.0209650316248
=> trying to raise plugin again
1
=> switching to document display plugin
1
=> cleaning up: unlocking patient
[0, 'patient unlock request rejected, wrong cookie provided']
=> unlocking again, correctly
[1, '']
=> detaching from macro processor (should fail)
0
=> oh well, but now for real
1

What good is this ? GNUmed 0.2 (librarian) will connect to the commercial 
software we are forced to use side by side with GNUmed.

This software is capable of calling external programs. GNUmed will be running 
in the backgroud all the time. Once you call a ditigal document ( GNUmed 
Archive aka librarian ) from this commercial software it will raise GNUmed, 
select the corresponding patient and display the digital document like a fax, 
referral letter , you name it. No user interaction whatsoever. It will feel 
like a part of the 3rd party software. 

What you see here is our concept of GNUmed. GNUmed will run side by side with 
traditional software. Users will make the transition automatically as more 
features will move from the commercial software into GNUmed. 

Like it or not. GNUmed (my understanding of it ) is not here to replace any 
commercial software here and now.

Wanna know why GNUmed perfoms way better than any package I have seen in 
commercial software ? Because files are stored and accessed through GNUmed. 
Simple rule. If you have access to GNUmed you have access to the digital 
documents. Anywhere. Anytime. Try to do this if you store the documents on a 
SAMBA share :-)
-- 
Sebastian Hilbert 
Leipzig / Germany
[www.openmed.org]  -> PGP welcome, HTML ->/dev/null
ICQ: 86 07 67 86   -> No files, no URL's
VoIP: callto://address@hidden
My OS: Suse Linux. Geek by Nature, Linux by Choice

test-slave.py
Description: application/python