<div dir="ltr">Hi Daniel;<div><br></div><div>Thank you for the detailed feedback.  Sorry for the delay, as I was looking into a few of the following (and making various, mostly unsatisfying, progress)...</div><div><ul><li>Re: synching on each tab switch & resultant unresponsiveness - I briefly looked into this a while back (because I also hate waiting), and it looked like the app's various display functions asking about version availability triggers the fetches.  I also expected some caching, but the slots I thought would contain the fetch results seemed to remain unbound after the fetch.  I will look harder, as this smells like I don't understand what I'm looking at.</li><li>Re: the dependency graph - FYI is it a dependency graph of the known-to-ASDF systems (often updated after installing a quicklisp release/system).  I suppose one could argue that it is out of place here.  Please let me know what you think.</li><li>Re: the dependency graph - I also suppose one could argue that perhaps I should have instead/additionally drawn a dependency diagram of the selected quicklisp system. I only go so far as to textually indicate which quicklisp systems are provided by the selected quicklisp release, and textually indicate which quicklisp systems depend upon the selected quicklisp system.</li><li>Re: single-box t - what is the best idiomatic way/place to do this?  I (perhaps naively or ignorantly) expected to be able to do this in the define-presentation-type, but seem not up to the task.</li><li>Would you please elaborate on "two layouts?"  Do you mean just stop hanging "inspector" commands on the various presentations?  If so, I agree I would like to be able to do this (a "release" build vs a "debug" build).  What is the best idiomatic way to do this?  Should I push something onto *features* and use #-DEBUG or something like that, or is there some ASDF derived system definition idiom?</li></ul><div>Thanks again for the feedback, and I will try and address it - especially the unresponsive bit...</div></div><div><br></div><div>-jm</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Nov 5, 2017 at 4:22 AM, Daniel Kochmański <span dir="ltr"><<a href="mailto:daniel@turtleware.eu" target="_blank">daniel@turtleware.eu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  
    
  
  <div text="#000000" bgcolor="#FFFFFF">
    <p>Hey,</p>
    <p>cool application. My two cents:</p>
    <p>- I don't like that it synchronizes over http on each tab switch
      (even if I go back to already visited tab) - some cache maybe?<br>
    </p>
    <p>- Fetching makes window unresponsive for a sec or two, maybe it
      is worth to consider fetching in background, so user can change
      his mind and switch to another tab</p>
    <p>- I like dependency graph, I'd add some margin though</p>
    <p>- For presentations :single-box t, so you have only one box for
      selection when you hover with mouse</p>
    <p>- Having two layouts - one with inspector and the second without
      it would be nice</p>
    <p>- Looking at ASD definition - mcclim-truetype is enabled by
      default now anyway (it is commented)</p>
    <p>- Add dependency on #:mcclim-layouts/tab since you use it</p>
    <p>That is what comes to my head. I like the idea and general
      organization of panes. Congrats :)<br>
    </p>
    <p>Best regards,</p>
    <p>Daniel<br>
    </p><div><div class="h5">
    <br>
    <div class="m_6739722782774252810moz-cite-prefix">On 04.11.2017 21:46, John Morrison
      wrote:<br>
    </div>
    <blockquote type="cite">
      <div dir="ltr">
        <div>Hi All;</div>
        <div><br>
        </div>
        <div><a href="https://bitbucket.org/symbolicsimulation/com.symsim.oss.ql-gui" target="_blank">https://bitbucket.org/<wbr>symbolicsimulation/com.symsim.<wbr>oss.ql-gui</a><br>
        </div>
        <div><br>
        </div>
        <div>Interested in (roughly decreasing order of importance to
          me):</div>
        <div>
          <ul>
            <li>usability/usefulness</li>
            <li>aesthetics (I am not a front end guy in any language)</li>
            <li>compatibility with CLIM best practices and idioms (as
              this is my first CLIM program in decades, or should I say
              Dynamic Windows?)</li>
            <li>compatibility with CL best practices and idioms (as this
              is my first real Common Lisp program after decades of
              C/C++, or should I say Zetalisp?)</li>
          </ul>
          <div>Please be kind, and thanks for all your contributions to
            McCLIM!</div>
        </div>
        <div><br>
        </div>
        <div>-jm</div>
        <div><br>
        </div>
      </div>
    </blockquote>
    <br>
  </div></div></div>

</blockquote></div><br></div>