George Helffrich
This appears to be a breathtaking step backward in capability. If I
understand GTK properly, it is:
1) not network capable like X11 (meaning you can't run SAC on one
machine and display the graphics on another machine);
2) would demand open source for SAC due to it coming under the GPL.
(2) was the motive, I thought, for opting for the {Free,Net}BSD version
of readline rather than GNU readline recently.
(1) is a drastic limitation in capability, if I understand GTK rightly:
you have to run SAC on the same computer that your display is wired to.
Finally, a word of caution/perspective. GTK resembles Tcl/Tk in that
it does not originate in an industrial consortium. PASSCAL was burned
by relying on Tcl/Tk for its PDB interface field apps: subtle
differences in new releases led to user problems in the field.
Is the feature loss, the open source implications, and the possible
release troubles worth borrowing for a spiffier SAC look?
George Helffrich
george<at>geology.bristol.ac.uk
-
George,
I would argue strongly that this in *not* a step backwards in compatibility.
1) GTK *is* network capable, GTK is built upon the X11 framework, which
is network capable, and provides a wrapper around Xlib. By using GTK,
you are using Xlib/X11, but creating a user interface or even drawing to
a window is much easier. This means you can run SAC on one computer and
view the interface on another, just as we could in the past.
2) GTK is distributed under the GNU LGPL, which allows for linking with
proprietary software or even BSD Licensed software. The choice of
License for SAC will still be available to IRIS/LLNL/SAC developers.
http://www.gtk.org/faq/#AEN81
GTK is not Tcl/Tk. GTK is actively developed by a large number of
contributors and is also the base for many projects, including the
Mozilla web browser on Linux and the GNOME interface. The documentation
for GTK is extremely good. Changes from release to release are
documented in one place, and older deprecated functions still work while
issuing warnings about their use.
I would say that we are not losing any features here. The command line
interface will still exist as will all of the underlying processing
capability. I would even argue we would are providing a stable base for
more features to be added.
http://www.mozilla.org/
http://www.gnome.org
Cheers,
Brian
George Helffrich wrote:
This appears to be a breathtaking step backward in capability. If I
understand GTK properly, it is:
1) not network capable like X11 (meaning you can't run SAC on one
machine and display the graphics on another machine);
2) would demand open source for SAC due to it coming under the GPL.
(2) was the motive, I thought, for opting for the {Free,Net}BSD version
of readline rather than GNU readline recently.
(1) is a drastic limitation in capability, if I understand GTK rightly:
you have to run SAC on the same computer that your display is wired to.
Finally, a word of caution/perspective. GTK resembles Tcl/Tk in that it
does not originate in an industrial consortium. PASSCAL was burned by
relying on Tcl/Tk for its PDB interface field apps: subtle differences
in new releases led to user problems in the field.
Is the feature loss, the open source implications, and the possible
release troubles worth borrowing for a spiffier SAC look?
George Helffrich
george<at>geology.bristol.ac.uk
_______________________________________________
sac-dev mailing list
sac-dev<at>iris.washington.edu
http://www.iris.washington.edu/mailman/listinfo/sac-dev
-
Brian,
Although I haven't downloaded and tested what you've done, I like the
concept and appreciate your efforts.
I'm not sure about the licensing issues, but from what I found on the
GTK web site it sounds promising.
I'll check to see if our legal people would have any issues with this
and get back to you.
Cheers,
Peter
At 11:42 AM -0500 11/15/05, Brian Savage wrote:
George,
--
I would argue strongly that this in *not* a step backwards in compatibility.
1) GTK *is* network capable, GTK is built upon the X11 framework,
which is network capable, and provides a wrapper around Xlib. By
using GTK, you are using Xlib/X11, but creating a user interface or
even drawing to a window is much easier. This means you can run SAC
on one computer and view the interface on another, just as we could
in the past.
2) GTK is distributed under the GNU LGPL, which allows for linking
with proprietary software or even BSD Licensed software. The choice
of License for SAC will still be available to IRIS/LLNL/SAC
developers.
http://www.gtk.org/faq/#AEN81
GTK is not Tcl/Tk. GTK is actively developed by a large number of
contributors and is also the base for many projects, including the
Mozilla web browser on Linux and the GNOME interface. The
documentation for GTK is extremely good. Changes from release to
release are documented in one place, and older deprecated functions
still work while issuing warnings about their use.
I would say that we are not losing any features here. The command
line interface will still exist as will all of the underlying
processing capability. I would even argue we would are providing a
stable base for more features to be added.
http://www.mozilla.org/
http://www.gnome.org
Cheers,
Brian
George Helffrich wrote:
This appears to be a breathtaking step backward in capability. If
_______________________________________________
I understand GTK properly, it is:
1) not network capable like X11 (meaning you can't run SAC on one
machine and display the graphics on another machine);
2) would demand open source for SAC due to it coming under the GPL.
(2) was the motive, I thought, for opting for the {Free,Net}BSD
version of readline rather than GNU readline recently.
(1) is a drastic limitation in capability, if I understand GTK
rightly: you have to run SAC on the same computer that your
display is wired to.
Finally, a word of caution/perspective. GTK resembles Tcl/Tk in
that it does not originate in an industrial consortium. PASSCAL
was burned by relying on Tcl/Tk for its PDB interface field apps:
subtle differences in new releases led to user problems in the
field.
Is the feature loss, the open source implications, and the possible
release troubles worth borrowing for a spiffier SAC look?
George Helffrich
george<at>geology.bristol.ac.uk
_______________________________________________
sac-dev mailing list
sac-dev<at>iris.washington.edu
http://www.iris.washington.edu/mailman/listinfo/sac-dev
sac-dev mailing list
sac-dev<at>iris.washington.edu
http://www.iris.washington.edu/mailman/listinfo/sac-dev
Peter Goldstein, Ph.D. (925) 423-1231 (office)
L-103, PO Box 808 (925) 422-5844 (fax)
Livermore, CA 94551 peterg<at>llnl.gov (email)
web pages: http://earthscience.llnl.gov/peterg/
http://www.llnl.gov/sac
-
Brian Savage
Peter Goldstein
