Hi Daniel;

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

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

Thanks again for the feedback, and I will try and address it - especially the unresponsive bit...

-jm

On Sun, Nov 5, 2017 at 4:22 AM, Daniel Kochmański <daniel@turtleware.eu> wrote:

Hey,

cool application. My two cents:

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

- 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

- I like dependency graph, I'd add some margin though

- For presentations :single-box t, so you have only one box for selection when you hover with mouse

- Having two layouts - one with inspector and the second without it would be nice

- Looking at ASD definition - mcclim-truetype is enabled by default now anyway (it is commented)

- Add dependency on #:mcclim-layouts/tab since you use it

That is what comes to my head. I like the idea and general organization of panes. Congrats :)

Best regards,

Daniel

On 04.11.2017 21:46, John Morrison wrote:

Hi All;

https://bitbucket.org/symbolicsimulation/com.symsim.oss.ql-gui

Interested in (roughly decreasing order of importance to me):

usability/usefulness

aesthetics (I am not a front end guy in any language)

compatibility with CLIM best practices and idioms (as this is my first CLIM program in decades, or should I say Dynamic Windows?)

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?)

Please be kind, and thanks for all your contributions to McCLIM!

-jm