mcclim-based gui prototype for quicklisp

[John Morrison]

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 at 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20171106/983a295a/attachment.html>