[mcclim-devel] One char patch to presentation-defs [Lisp listener problems]

[rpgoldman at real-time.com]

>>>>> "PA" == Paolo Amoroso <amoroso at mclink.it> writes:

    PA> rpgoldman at real-time.com writes:
    >> Is there some reason to do this instead of a Bugzilla?  Is the latter
    >> just too much of a pain to maintain?

    PA> This was discussed here in the past, but I don't have links handy.  I
    PA> seem to remember that this is because such tools make reporting bugs
    PA> too much a hassle.


    >> Would you consider writing up a McCLIM cliki page describing what you
    >> do when you play with the lisp listener?  This is the only application

    PA> I execute this command, which shakes the Listener a bit:

    PA>   Show Class Subclasses (class) t

    PA> Then I walk the file system a bit by clicking on pathnames.

OK, that crashes for me!  The problem is that it tries to use a TREE
style graph formatting while also setting the merge-duplicates
argument to true.  When I patched the code to allow actual duplicate
merging (AFAICT, this was just ignored before), I made it a violation
to have :tree layout and :merge-duplicates = t.  

When the lisp-listener crashed, I was wondering if this was The Right
Thing or not.  Alas, the CLIM specification seems unhelpful and
possibly even garbled on this point:


"If the boolean merge-duplicates is true, then duplicate objects in
the graph will share the same node in the display of the graph. That
is, when merge-duplicates is true, THE RESULTING GRAPH WILL BE A TREE
[emphasis added -rpg]. If merge-duplicates is false (the default),
then duplicate objects will be displayed in separate
nodes. duplicate-key is a function of one argument that is used to
extract the node object component used for duplicate comparison; the
default is identity. duplicate-test is a function of two arguments
that is used to compare two objects to see if they are duplicates; the
default is eql. duplicate-key and duplicate-test have dynamic extent."

The material in all caps above seems to be a flat-out mistake --- if
you merge duplicates, you can introduce cycles.  So it is specifically
if merge-duplicates is FALSE that you get a tree, right?

I tried temporarily changing :merge-duplicates to NIL  Any reason not
to do that?

As far as I can tell

Then when I clicked on an item, the listener crashed for me:

Error: Class #<STANDARD-CLASS CLIM:BOUNDING-RECTANGLE> is not yet
       finalized.
  [condition type: PROGRAM-ERROR]

in COM-SHOW-CLASS-SLOTS...

I get a number of meta-object related bugs when I do this.  Seems like
perhaps ACL's MOP implementation is not particularly happy with the
class browser.  :-(

I probably don't have too much time to spend on that, alas.


    >> As an aside, can anyone point me to a sample application that has some
    >> pane devoted to displaying information about the state of the
    >> application (e.g., a filename that is the current document, mode of

    PA> Do you mean something like a status bar?

Yes, that sort of thing.  Probably one in CLIMACS, I figure.  Seems to
be one in the clim-listener I could probably copy.

There are two interesting things about the clim-listener "wholine"
statusbar:

1.  CLIM's layout algorithm seems inadequate --- it seems to require
    special help to manage the wholine, since there needs to be
    special compose-space and allocate-space methods.  Anyone have any
    idea why that is?  Does this reflect problems with CLIM?

2.  Doesn't use incremental redisplay.  I would have thought that the
    wholine, for example, would be a good application for this, since
    most of the time the user ID won't change, and even the package
    name is probably pretty stable.  Is this because of problems with
    incremental redisplay?  Or is it just that rendering the wholine
    is so cheap it's not worth the trouble?

Thanks,
R