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