<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 20-06-2013 22:02, Aldcroft, Thomas
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAMtEP6zUXxkyg6sYqXu75xFATC0xGpx-oFMgxXYwwNxLizPhRQ@mail.gmail.com"
      type="cite">
      <div dir="ltr"><br>
        <div class="gmail_extra"><br>
          <br>
          <div class="gmail_quote">On Thu, Jun 20, 2013 at 3:20 PM,
            Adrian Price-Whelan <span dir="ltr"><<a
                moz-do-not-send="true" href="mailto:adrianmpw@gmail.com"
                target="_blank">adrianmpw@gmail.com</a>></span>
            wrote:<br>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm
              totally lost on what thread I'm responding to, but +100 to
              what<br>
              Perry said about GUIs! IMHO there is plenty to keep us
              busy working on<br>
              the modeling and backend, and we should focus our efforts
              on making<br>
              that code super slick and useable *first*, then worry
              about a GUI<br>
              (which, also IMO, are overrated! why do you want to click
              on your<br>
              absorption lines anyways??).<br>
            </blockquote>
            <div><br>
            </div>
            <div>I understand you are being a bit sarcastic, but I did
              half my thesis on QSO absorption lines and I'll tell you
              that being able to click on those lines was a lifesaver.
               I wrote a Fortran / PGPLOT-driven GUI tool for analyzing
              absorption lines which people were still using 10 years
              later.  Suffice to say that GUI's are useful, but I fully
              agree with comments regarding the separation of
              computation from interface.</div>
            <div><br>
            </div>
            <div>- Tom</div>
          </div>
        </div>
      </div>
    </blockquote>
    <br>
    Interesting - I did my Master's Thesis on QSO absorption lines, and
    used a fortran/pgplot based GUI for my modeling. VPfit, to be
    precise.<br>
    That is also when I learned what a difference a good GUI can make:
    Joe Liske's VPguess interface to vpfit was a life saver for me.
    Would your work have happened to be on any of those two tools?<br>
    <br>
    It bears repeating again, of course, that any good GUI is
    characterized by the fact that any important setting an be saved and
    preferably manually edited in a configuration file and loaded at a
    later point. <br>
    <br>
    <blockquote
cite="mid:CAMtEP6zUXxkyg6sYqXu75xFATC0xGpx-oFMgxXYwwNxLizPhRQ@mail.gmail.com"
      type="cite">
      <div dir="ltr">
        <div class="gmail_extra">
          <div class="gmail_quote">
            <div><br>
            </div>
            <div> </div>
            <blockquote class="gmail_quote" style="margin:0 0 0
              .8ex;border-left:1px #ccc solid;padding-left:1ex">
              <div class="HOEnZb">
                <div class="h5"><br>
                  On Thu, Jun 20, 2013 at 3:09 PM, Perry Greenfield <<a
                    moz-do-not-send="true"
                    href="mailto:stsci.perry@gmail.com">stsci.perry@gmail.com</a>>
                  wrote:<br>
                  ><br>
                  > On Jun 20, 2013, at 12:34 PM, Erik Tollerud
                  wrote:<br>
                  ><br>
                  >> I'm of mixed minds about traits UI because
                  once you know it you can make great GUIs with it, but
                  I've spent a lot of time troubleshooting people's
                  python installations to get traits to work.  That is,
                  in general it can be tricky to get installed because
                  of all the dependencies.  Maybe this has improved
                  recently with Enthought's Canopy (or other new python
                  distros), but that's been my past experience.<br>
                  >><br>
                  >> More generally, the view in the astropy core
                  package is that we don't want to put GUIs in the core
                  because GUIs always carry lots of dependencies, which
                  we don't want to be forced to deal with.  But part of
                  the whole reason for affiliated packages was to get
                  around this, so we're happy to see GUI-based
                  affiliated packages.<br>
                  ><br>
                  > To expand on the GUI issue a bit. I certainly see
                  the benefit of an interactive GUI for these tools. But
                  they raise a number of issues that the authors should
                  think about.<br>
                  ><br>
                  > 1) They require one to select a windowing system.
                  It would be nice if we standardized on one. Two
                  obvious (but not the only) candidates are Qt and
                  Tkinter. Qt is much more modern, but as far as I can
                  see still presents significant installation issues for
                  some. Tkinter is long in the tooth, but installation
                  issues are generally much fewer. Yes, there's Wx, Gtk,
                  and others, not to mention the whole browser interface
                  issue, which ought to be considered as well.<br>
                  ><br>
                  > 2) I've seen the danger of someone starting right
                  off with a GUI framework for their spectral (or any
                  other kind of tool), and making their computational
                  functionality entirely intertwined with it. I think
                  that is a mistake. Eventually, many would like to
                  script a lot of that functionality, or use it in other
                  contexts. It's really important to keep the core
                  computational stuff independent of the GUI.<br>
                  ><br>
                  > 3) GUI's are expensive to do well, and expensive
                  to make changes to. For that reason I tend to favor
                  the no-GUI approach for the initial functionality as
                  much as possible, and limit the interactions to
                  simpler tools (or simple GUI) until all the pieces are
                  ready for integration into a full GUI interface. It
                  helps accomplish 2) as well, and gives some experience
                  before too much is invested in a GUI design.<br>
                  ><br>
                  > So even if a GUI is needed, it's quite likely a
                  lot of the underlying machinery should go into the
                  core, or at least into a non-GUI package.<br>
                  ><br>
                  > Perry<br>
                  ><br>
                  > _______________________________________________<br>
                  > AstroPy mailing list<br>
                  > <a moz-do-not-send="true"
                    href="mailto:AstroPy@scipy.org">AstroPy@scipy.org</a><br>
                  > <a moz-do-not-send="true"
                    href="http://mail.scipy.org/mailman/listinfo/astropy"
                    target="_blank">http://mail.scipy.org/mailman/listinfo/astropy</a><br>
                  <br>
                  <br>
                  <br>
                </div>
              </div>
              <span class="HOEnZb"><font color="#888888">--<br>
                  Adrian M. Price-Whelan ~ Columbia University ~ <a
                    moz-do-not-send="true" href="http://adrian.pw"
                    target="_blank">http://adrian.pw</a><br>
                </font></span>
              <div class="HOEnZb">
                <div class="h5">_______________________________________________<br>
                  AstroPy mailing list<br>
                  <a moz-do-not-send="true"
                    href="mailto:AstroPy@scipy.org">AstroPy@scipy.org</a><br>
                  <a moz-do-not-send="true"
                    href="http://mail.scipy.org/mailman/listinfo/astropy"
                    target="_blank">http://mail.scipy.org/mailman/listinfo/astropy</a><br>
                </div>
              </div>
            </blockquote>
          </div>
          <br>
        </div>
      </div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
AstroPy mailing list
<a class="moz-txt-link-abbreviated" href="mailto:AstroPy@scipy.org">AstroPy@scipy.org</a>
<a class="moz-txt-link-freetext" href="http://mail.scipy.org/mailman/listinfo/astropy">http://mail.scipy.org/mailman/listinfo/astropy</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>