[Gnumed-devel] RE: Gnumed-devel Digest, Vol 9, Issue 6

[s j tan]

   1. Horst and GNUmed in the national IT press (Tim Churches)
   2. Re: Qt licensing issues for GNUmed (Roberto Mello)
   3. Re: Re: [Gnumed-devel] Qt licensing issues for GNUmed
      (Tim Churches)
   4. Conference Report (Ian Haywood)
   5. Reaching a final decision on GUI Tool (richard terry)
   6. Re: Conference Report (richard terry)
   7. Re: Conference Report (Andreas Tille)
   8. First sample of gui function docs (richard terry)



Message: 2
Date: Mon, 11 Aug 2003 23:10:46 -0600
From: Roberto Mello <address@hidden>
Subject: Re: [Gnumed-devel] Qt licensing issues for GNUmed
To: Les Ferguson <address@hidden>
Cc: address@hidden
Message-ID: <address@hidden>
Content-Type: text/plain; charset=iso-8859-1

On Mon, Aug 11, 2003 at 11:36:42AM +1200, Les Ferguson wrote:
> 
> Note: I have still not gotten up to speed with anything on Linux that
enables 
> me to develop working solutions as fast as I could in Visual Basic,
but QT 
> would be my first choice for rapid UI development on Linux.  Other gui


There's Kylix, or Delphi for Linux. It's proprietary, but allows "free"
applications to be developed without cost.

I've been looking at PyGTK and support for it in Glade, a user-interface
builder for GTK. Supports Windows, Linux and a variety of other
platforms,
and there are no Qt-like licensing issues to deal with. GTK is licensed
under the LGPL.

> designers and libraries are still worth investigating, and I am still 
> contemplating going with Java as the best cross-platform solution.
Has 
> anybody found specific problems with wx, using either wxPython or C++
?

My experience with Java has been that it makes things more complex,
heavy
than they need to be. Take a look at what the BitKeeper guys, who were
building user utilities for their software configuration management
product. Java would not scale pass parsing a couple hundred (or so) 
directories before the JVM would be using all of the machine's memory.

They re-implemented everything in Tcl/Tk, which easily let them parse
through thousands of directories.

-Roberto

-- 
+----|        Roberto Mello   -    http://www.brasileiro.net/  |------+
+       Computer Science Graduate Student, Utah State University      +
+       USU Free Software & GNU/Linux Club - http://fslc.usu.edu/     +
How many chunks could checkchunk check if checkchunk could check chunks?
        -- Alan Cox


Kylix community edition is crippled ; it doesn't even have sockets, let
alone database access support , so it's good for writing standalone file
based single user programs , but not client server stuff.


The comments about java being a resource hog could be correct: it runs 
Noticeably better in windows , and unoptimized stuff ( i.e. no algorithm

Design at all ), may run poorly, and perhaps too slow if one is
recycling
Pentium 2's for a complex client task.  Lately, they've been trying to
get everyone to use a self optimizing virtual machine , which sounds
attractive
In theory. The problem with the leaky vm might not be all that bad, but
With the automatic garbage collector , it seems to pause for a while
when
The gc is catching up . I think c# or some other post java language has
been
Trying to restore C++ destructor like user responsibility for memory
reclamation ( a bad idea? ). The advantage and disadvantages haven't
changed
it seems  (  freely available tools, a non-crippled sdk, code completing
IDEs ,  not as fast as C, garbage collector makes it not good in real
time , 
verbosity when not using code completion , an inelegant balance of
static type checking and casting of general types to invoke static type
checking ,
which IMHO is about as clunky as writing  fn(self...) and self.fn( )  in
Python to pretend it's object-oriented ).




Our experience with a Java-based semi-open source Web GIS - both Java
client 
and Java on teh server, was one of continuous memory leaks - rapidly
using up 
1GB of memory on teh server and then all virtual memory...the developers

blamed the Java Virtual Machine implementations (SUN's in both cases).
We 
gave up and bought a commercial Web-based GIS instead. Others have
similar 
stories of Java use in data-intensive applications. But a typical GP
system will 
not handle huge amounts of data, so maybe Java is a reasonable choice
for such 
settings. But has anyone every seen a Java application with a fast,
responsive 
GUI?
 
Tim C





------------------------------

Message: 5
Date: Tue, 12 Aug 2003 18:12:43 +1000
From: richard terry <address@hidden>
Subject: [Gnumed-devel] Reaching a final decision on GUI Tool
To: "gnumed-devel @ gnu . org" <address@hidden>
Message-ID: <address@hidden>
Content-Type: text/plain;  charset="us-ascii"

Anxious to push this project on lets make a final decision.

>From the thread of the debate from those who really investigate and
understand 
(and BTW I exclude myself from this cohort):

 wxPython  GUI seems to remain the tool or choice for at least the
foreseable 
future.

I can live with that, though it is a bit clunky and tedious.

1) Can we have a final vote on this tool.

2) Can we have a final vote on using the interface I've designed yes or
no.

If Yes, then I'd suggest everyone drop other interfaces and all pull
together 
to sort this one out under my guidence re the design. Someone has to
have the 
final say on what goes into the interface - hence functionality without 
eveyone changing things all the time. Being the resident
gui/functionality 
expert I'm happy to do this.

If we can agree on this. I will start doing the functional
specifications for 
the gui elements and what will go into version 1 so we can progress from

there.

Otherwise we will still be stuffing around in 12 months time despite all
the 
good work done on the backend by those who can actually code, and still
not 
have a product.

BTW are there any dedicated programs/methods/formats when specifying gui

elements and functionality.

Hope I havn't started too vigorous a debate or a flame war, but lets get
this 
going guys!

Richard





------------------------------

Message: 6
Date: Tue, 12 Aug 2003 18:28:39 +1000
From: richard terry <address@hidden>
Subject: Re: [Gnumed-devel] Conference Report
To: gnumed-devel <address@hidden>
Message-ID: <address@hidden>
Content-Type: text/plain;  charset="iso-8859-1"

Well put Ian, much better than my lobsided pathetic previous posting on
choice 
of GUI which was probably more a product of my frustration than cool
logic.

Team should probably ignore my posting and those able to make decisions
on the 
basis of their technical knowledge, on what Ian has said below, make the

choice and I'll go along with whatever is made. But please, make a
choice!

In the meantime I will start on the gui/functional specs.

Richard

On Tue, 12 Aug 2003 06:26 pm, Ian Haywood wrote:
> I  intended  to do this on  Sunday but a combination of technical
> failures and a truly demonic roster for the surgical job have led
> to it being late. Note that this is a synthesis of a number of
separate
> conversations with various people over the 2 days.
>
> We agreed at the conference that gnumed development had proceeded a
lot
> slower than we had hoped, and that
> it was important to expidite client development. We agreed lack of
> proper design and a clear development plan were
> largely responsible for this situation.
> [It is important to note a lot of "infrastructure" work has taken
place.
> mostly by Karsten]
>
> <AU> The point was also raised that the major competitor Medical
> Director is switching to windows SQL in the next year or so, a
> good time to enter the market.</AU>
>
> Horst announced that he would commence work on a "quick" client, using
> Python/Tk, and monolithic postgres server as a
> private project to get something working, this takes the pressure of
us
> a little, but it is universially agreed that the current gnumed client
> is
> the definitive client and work will continue on it.
>
> The current client was criticised on a number of points:
>     - lack of borderless widgets [as an aside, this is probably a
> limitation of the underlying GTK library, a switch to Qt is the only
> real solution here]
>     - lack of good design tools
>     - hacky double plugin structure
>     - hacky UI modules [no offence Richard]
>     - lack of overall design consistency ("Richard space" and "Karsten
> space")
>
> Solving any of these implies a UI code rewrite, even if we stick with
> wxPython.
>
> The Plan:
>
> To construct a Python/Qt client as follows:
>
> 1/ Richard will write plain English functional specs, using his client
> as a guide [1 month]
> 1a/ Specs for clinical notes viewer are added
>
> 2/ UML object design from said specs devised. A skills shortage is
this
> area was identified,
> Tim Churches has indicated he knows some people who may be able to
help
> [1 day workshop + further month]
>
> 3/ actual coding based on above object model [timeline unspecified]
> Need to pick clincial coding system at this point.
>
> Barring some massive advance with drugref, it is agreed that MIMS is
the
> drug database in AU.
>
Is Mims becoming free or open source?

> It is agreed that work on the backend should continue as is.
>
> Architectural concerns: [IMHO, this is where much if the problem lies,
> it
> is difficult to do much work without firm foundations]
>
> Choices discussed:
> 1/ Status quo: wxPython client, pluggable with 2 plugin systems,
> communicating with multiple PostgreSQL servers via middleware
> (which is not truly GUI-independent)
> Pros: what we've already got, design stability
> Cons: see above, IMHO substantial GUI code rewrite is required anyway.
>
> 2/ Qt using Qt's own database objects and data-aware widgets
> Pros: easy, cool, simplifies dependencies
> Cons:
> - fixed to Qt now,
> - will need a middleware layer anyway for some things,
> - complete rewrite of everything except SQL code.
>
> 3/ Qt using Karsten's business objects,
> Pros:
> - portable, can retain existing wxPython codebase (??? but who will
> maintain it ????), plus future Web, PDA, etc.
> - retains important features already implemented in middleware
> (updating, read/write connection separation,
> multiple servers)
> [NB Richard's client only uses 2-3 actual widget types (part of it's
> advantage) so it is easy to add
> data-awareness via the middleware layer]
> - My favourite ;-)
>
> Cons:
> - GUI rewrite
> - need to remove dependence on wxEvents, gmDispatcher throughout code
> - licence issues as noted
> - slower to develop than 2
>
> 4/ 3/ with communication via XML-RPC
> Pros:
>     - uses XML buzzword
>     - sharing services with OSCAR, etc.
>     - simplified client dependencies.
>     - client now very small and portable, can presumably port  Syan's
> Java client to this API at some point.
> Cons:
>     - middleware API rewrite also (no passing objects, no fancy Python
> s**t with mapping
> dictionaries to functions)
>
It seems to be a tradeoff with having to read lots of well(not so well?)
named code doing the same thing, and having to debug a generic logic
that isn't handling some exceptional case, written in obscure "treating
everything as a map" code. I thought the later could avoid tenosynovitis
and
lots of grunts when doing the grunt work. 



> Client design:
>
> Horst has proposed (and offered to write) a unified plugin syatem for
> Qt, which is much more flexible
> than the existing one, with resizable windows.
>
>
> Ian Haywood
>
> [NB whatever the header of this e-mail says, my personal e-mail is
> address@hidden so long
> as the GNU mailservrs are down, which looks like a while....]
>


 

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.497 / Virus Database: 296 - Release Date: 4/07/2003