On Tuesday 13 September 2005 20:58, J Busser wrote: > Performance from Canada connecting to Salaam (Spain) > - Start > Programs > GNUmed to log-in screen ~ 5 seconds > - log-in screen to progress thermometer of plug-ins loading ~ 15-20 seconds > - plug-in loading to display of main GNUmed screen "no patient selected" > ~ 5-10 seconds > - search "kirk" to display of "Capt. James Tiberius Kirk" ~ 20 seconds > - click Patient Details tab --> display of details in ~ 2 seconds > - click "EMR tree" tab --> display in ~ 83 seconds (coffee time) > - click "Progress Notes" tab --> display in ~ 35 seconds > - click "EMR Journal" tab --> display in ~ 3 seconds > - click "Setup" tab --> display in ~ 4 seconds > > I noticed in the log that it "retrieved the EMR" in 15 seconds yet it > took 83 seconds to display. Is that because of the amount of work > done by the code to post-process the information before it can be > displayed in the desired form? Is this something Jonas could help > with? No way. There are two reason for this.
1st. We have a big problem with WIndows regarding display updating. This needs to be fixed. We all know this. Noone seems to have the time and/or skills to do it. Certainly not me before my finals. 2nd) Depends on you physical location and/or internet speed. When I use salaam I get connections which are roughly 5-10 times slower than with a local database but at least 10 times as fast as yours so it seems. > > Upon login the "manual" tab is blank of contents. Is that because it > depends on being "clicked" before it will refresh? It does so after I > load a patient and then click back on manual. Is there a way to > trigger GNUmed to 'auto-click" whatever is the first plug-in which I > assume will always be the tab that is "open" upon loading GNUmed? I know this behavior. Needs fixing. Haven't looked into it. > > Sorry I forgot an answer (if there was one) but upon logging in I > cannot click any other tab (not even Setup) until a patient is > loaded. Do plug-ins by default require a patient to be loaded, and > shall we have a way to "unbind" those plug-ins that may not require > any patient to be loaded? In another post I described that Windows version has some quirks. Some of them cannot be fixed easily and need bad workarounds. Starts with non-English interface, display updating, plugin locking ... > Note that Karsten and I are developing this on Linux. Maybe it was a mistake to supply a Windows version now. Because I cannot support it. I don't hate Windows or anything but I have to focus. I did my best to get it running Windows but I cannot cater for every OS. I don't have regular access to a Windows machine. > Immediately when I clicked "EMR tree" I could do nothing else. Maybe > that is by design, is it intended that I not be allowed to click to > Patient Details or any other Patient-related tabs while the fetching > and rendering of EMR tree data is occurring? > > re my earlier complaint about the left side of the EMR tree showing > "nothing". This happened again, not every time, but sometimes, and it > happened after I had already activated Kirk and had already brought up > (after 83 seconds) the EMR tree displayed below. What I noticed a couple > of times was that after clicking Progress Notes, and then coming back to > EMR tree, there was no content in the left pane i.e. "Capt James > Tiberius Kirk EMR" down through "ttt" were entirely missing and there > was nothign there but white space, while the right pane continued to > show "Summary ======= Allergy: Penicillin, developed urticaria... > During one such occasion, the left half did refresh unprompted after > more than a minute. On another occasion it didn't though I can't recall > if that time the right pane (Summary) info was missing as well. That log > is contained at bottom. > Try resizing the GNUmed windows. Most of the time it will refresh. Or simply use Linux. It simply works and is not !! hard to install. It's a lie. Just use Sarge and you will be running in no time. I get the feeling that most of you have neen testing this on Windows. I know that I suck because I still don't get that I should focus on Windows instead of Linux. BUt since there seem to be millions of Windows users with far better Windows and programming skills than I have it shouldn't be too hard to find a competent hacker to fix this problem. Should be easier than to find a Linux hacker. Windows verison of GNUmed has not been tested as much as Linux. May things change for future releases. I am here for questions. Some will call me ignorant again but I mostly scratch my itches before I devote time to other operating system (which I don't have and which I lack the skills for) Thanks for your feedback. Please resend this message again after October 17th. I might have the time to take a look. But hopefully bugs will be fixed by someone else before that time. > > > C:\Program Files\GNUmed-client\bitmaps>set PYTHONPATH=..\; > > C:\Program Files\GNUmed-client\bitmaps>set > PATH=C:\WINDOWS\system32;C:\WINDOWS;C > > :\WINDOWS\System32\Wbem;C:\PROGRA~1\COMMON~1\Odbc\FILEMA~1;c:\\Python23 > > C:\Program Files\GNUmed-client\bitmaps>REM set LANG=de_DE > > C:\Program Files\GNUmed-client\bitmaps>cd c:\ > > C:\>cd PROGRA~1 > > C:\PROGRA~1>cd GNUmed-client > > C:\PROGRA~1\GNUmed-client>python ./bin/gnumed.py > --conf-file=C:\PROGRA~1\GNUmed- > client\gm-0_1.conf --debug > log file is [C:\Documents and Settings\Admin\.gnumed\gnumed.log] ######### here ########## is the real log file ####################### > GNUmed startup: Activating verbose log level for debugging. > GNUmed startup: Determining GNUmed base directory ... > - environment variable GNUMED_DIR not set > (only necessary if nothing else works, though) > - standard path [/usr/share/gnumed/] not accessible > - seems like we are running from an arbitrary > directory (like a CVS tree or on Windows), namely: > [./bin/gnumed.py] -> [C:\PROGRA~1\GNUmed-client] > GNUmed startup: Determining GNUmed resource directory ... > - standard resource path [\usr\share\gnumed\] not accessible > - seems like we are running from an arbitrary > directory (like a CVS tree or on Windows) > gmManual: class cNotebookPluginOld used, please convert > [ERROR] > (c:\Python23\lib\site-packages\Gnumed\pycommon\gmCfg.py:__get_conf_name@ > 862): cannot find config file in any of the standard paths > [ERROR] > (c:\Python23\lib\site-packages\Gnumed\pycommon\gmCfg.py:__get_conf_name@ > 862): cannot find config file in any of the standard paths > [ERROR] > (c:\Python23\lib\site-packages\Gnumed\pycommon\gmCfg.py:__get_conf_name@ > 862): cannot find config file in any of the standard paths > [ERROR] > (c:\Python23\lib\site-packages\Gnumed\pycommon\gmCfg.py:__get_conf_name@ > 862): cannot find config file in any of the standard paths > [ERROR] > (c:\Python23\lib\site-packages\Gnumed\pycommon\gmCfg.py:__get_conf_name@ > 862): cannot find config file in any of the standard paths > retrieved EMR in 15.094 seconds > re-populating notebook with data - nothing to do, really... > > > _______________________________________________ > Gnumed-devel mailing list > [email protected] > http://lists.gnu.org/mailman/listinfo/gnumed-devel -- Sebastian Hilbert Leipzig / Germany [www.openmed.org] -> PGP welcome, HTML ->/dev/null ICQ: 86 07 67 86 -> No files, no URL's VoIP: callto://[EMAIL PROTECTED] My OS: Suse Linux. Geek by Nature, Linux by Choice _______________________________________________ Gnumed-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnumed-devel
