[Top][All Lists]

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

Re: Re: [Gnumed-devel] Qt licensing issues for GNUmed

From: Tim Churches
Subject: Re: Re: [Gnumed-devel] Qt licensing issues for GNUmed
Date: Tue, 12 Aug 2003 17:22:39 +1000

Roberto Mello <address@hidden> wrote:
> 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.

But that doesn't meet Karsten's very reasonable criterion that the development 
tool should be freely available, so that anyone who wants to modify GNUmed can 
without bothering the original developers.

> 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.

My only experience of a GTK application on Windows is Dia, the free, open 
source diagramming tool. Unfortunately, it doesn't look very good under 
Windows - non-native widgets, dialogue boxes etc, not to mention horribly 
unstable (but that is probably Dia's fault, not GTK's). But I am told that GTK 
is the 
least desirable solution for Windows - and that's what 95% of potential GNUmed 
users will be using, at least initially.

> > 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.

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 
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 
Tim C

reply via email to

[Prev in Thread] Current Thread [Next in Thread]