If one wanted to draw curvy lines in McCLIM, is there any way of doing this? I had assumed, foolish me, that this could be done using Bezier curves, but now I see that those were an Allegro extension to the standard, and not part of CLIM 2.0....
I'm not much of a graphics person, and don't understand X very well, so I was wondering --- is there anything about X itself that makes drawing curved lines particularly difficult?
Also, has anyone been thinking about the possibility of dynamic graphs? I.e., graphs where one might want to enter leaves? Or the possibility of having a fixed graph where a user might move the nodes around to make the graph more readable. CLIM doesn't have any sort of "smart link" object that would support this, does it?
Thanks, Robert
rpgoldman@real-time.com writes:
Also, has anyone been thinking about the possibility of dynamic graphs? I.e., graphs where one might want to enter leaves? Or the possibility of having a fixed graph where a user might move the nodes around to make the graph more readable. CLIM doesn't have any sort of
Scigraph provides a similar feature, i.e. the ability of interactively editing certain chart attributes such as titles and labels.
Paolo
"PA" == Paolo Amoroso amoroso@mclink.it writes:
PA> rpgoldman@real-time.com writes: >> Also, has anyone been thinking about the possibility of dynamic >> graphs? I.e., graphs where one might want to enter leaves? Or the >> possibility of having a fixed graph where a user might move the nodes >> around to make the graph more readable. CLIM doesn't have any sort of
PA> Scigraph provides a similar feature, i.e. the ability of interactively PA> editing certain chart attributes such as titles and labels.
Sorry. I'm just too much of a CS person and not enough of a mathematician! By "graph" I meant the kind with nodes and links, not the kind with x and y axes...
R
rpgoldman@real-time.com writes:
Sorry. I'm just too much of a CS person and not enough of a mathematician! By "graph" I meant the kind with nodes and links, not the kind with x and y axes...
Ooops... disregard.
You may try this file:
simple-graphedit.lisp A toy graph editor, written by John Aspinall
in this collection of graphers/browsers:
ftp://ftp.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/gui/clim/clim_2/browsers/0.html
Paolo
rpgoldman@real-time.com writes:
Also, has anyone been thinking about the possibility of dynamic graphs? I.e., graphs where one might want to enter leaves? Or the
Other possibly relevant code:
class browser http://bauhh.dyndns.org:8000/hacklets/class-browser.lisp
Petri net editor (does not work with McCLIM) http://www.sts.tu-harburg.de/~mi.wessel/papers/petri2.lisp
graphers collection (see clim.grapher, which seems to be based on CLIM 1.x) ftp://ftp.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/lisp/gui/graphers/0.html
Paolo
It was interesting to me that the grapher Paolo pointed to last time did NOT use format-graph-from-roots. I don't know whether this was because that grapher was built before format-graph-from-roots was generally available (I think it's always been in CLIM), or because the graph layout algorithm in format-graph-from-roots is not very amenable to having the user intervene into graph layout.
It might be instructive to compare format-graph-from-roots with the grapher that appears in Garnet, which is based on a cells-like constraint architecture. In that framework there are edge objects that are constrained to be attached to points on graph nodes. I don't see how one could really build a user-modifiable graph w/o such objects. On the other hand, I'm not sure how one could introduce such entities, since CLIM doesn't necessarily easily admit for propagation cycles. I.e., such objects would only work in panes with particular sorts of display-functions.
BTW, on a dual SMP 3G with 1G of RAM last night, I tried to layout a graph with approx 5K nodes, and McCLIM went into GC thrashing and took the lisp process down (which I take to be an accomplishment). I hope to be able to have some time to run the profiler and try to figure out what might be optimized --- I haven't tweaked my compiler settings at all, so this might simply be badly-compiled iterative code eating the stack...
It's too early, and I'm probably rambling, so I'll sign off...
rpgoldman@real-time.com writes:
It was interesting to me that the grapher Paolo pointed to last time did NOT use format-graph-from-roots. I don't know whether this was
In my reading of CLIM literature and code, I don't remember running across the use of format-graph-from-roots for dynamic graphs.
BTW, on a dual SMP 3G with 1G of RAM last night, I tried to layout a graph with approx 5K nodes, and McCLIM went into GC thrashing and took the lisp process down (which I take to be an accomplishment). I hope
Can you try evaluating this form at the CLIM Listener?
(time (clim-listener::com-show-class-subclasses t))
I don't know how many nodes the generated graph contains, but there are many. It takes under a second on my 2.8 GHz Pentium IV machine with 2 GB of RAM.
Paolo
On 5/19/05, rpgoldman@real-time.com rpgoldman@real-time.com wrote:
If one wanted to draw curvy lines in McCLIM, is there any way of doing this? I had assumed, foolish me, that this could be done using Bezier curves, but now I see that those were an Allegro extension to the standard, and not part of CLIM 2.0....
Lacking any better ideas, I'd break the curves down into line segments and draw them as such.
Also, has anyone been thinking about the possibility of dynamic graphs? I.e., graphs where one might want to enter leaves? Or the possibility of having a fixed graph where a user might move the nodes around to make the graph more readable. CLIM doesn't have any sort of "smart link" object that would support this, does it?
I don't have any thoughts on dynamic graphs, but 'adjustable' graphs are a fine idea. I've been interested in such a thing for a while now, but lacked any real immediate need for it. Now that someone else has mentioned it, I've been inspired to take a little time to bash out an implementation.
I started with Tim Moore's dragndrop example, extending the basic ide aby implementing draggable presentations via a new draggable-presentation and a command and translator to invoke the dragging. Adding :record-type 'draggable-presentation in calls to clim:present makes presentaitons draggable. This allowed me to drag presentations within graph nodes around, but with no knowledge of the graph edges. Clearly some work on the graph formatter is need. (this code is attached as draggable-presentations.lisp)
To remedy this, I've attached an experimental patch which refactors graph edge layout and incorporates the needed bookkeeping to associate a graph node with its edges. This allowed my second attempt, also attached, to drag graph nodes around, updating the edges correctly.
Perhaps this is of some interest.
Andy Hefner ahefner@gmail.com writes:
Perhaps this is of some interest.
Well, it's definitely fun to play with! :-)
Cheers,
Christophe
"PA" == Paolo Amoroso amoroso@mclink.it writes:
PA> rpgoldman@real-time.com writes: >> It was interesting to me that the grapher Paolo pointed to last time >> did NOT use format-graph-from-roots. I don't know whether this was
PA> In my reading of CLIM literature and code, I don't remember running PA> across the use of format-graph-from-roots for dynamic graphs.
>> BTW, on a dual SMP 3G with 1G of RAM last night, I tried to layout a >> graph with approx 5K nodes, and McCLIM went into GC thrashing and took >> the lisp process down (which I take to be an accomplishment). I hope
PA> Can you try evaluating this form at the CLIM Listener?
PA> (time (clim-listener::com-show-class-subclasses t))
PA> I don't know how many nodes the generated graph contains, but there PA> are many. It takes under a second on my 2.8 GHz Pentium IV machine PA> with 2 GB of RAM.
Well, that was very fast for me, too:
CL-USER(9): (clim-listener:run-listener) ; cpu time (non-gc) 1,100 msec user, 10 msec system ; cpu time (gc) 340 msec user, 0 msec system ; cpu time (total) 1,440 msec user, 10 msec system ; real time 1,446 msec ; space allocation: ; 297,880 cons cells, 12,937,112 other bytes, 0 static bytes
I will check and see what's up with my MDP's state space that makes it go out to lunch.
Sorry to be so dilatory. Travel and the resulting email avalanche to handle are going to keep me slow investigating this.
R
Andy Hefner ahefner@gmail.com writes:
To remedy this, I've attached an experimental patch which refactors graph edge layout and incorporates the needed bookkeeping to associate a graph node with its edges. This allowed my second attempt, also attached, to drag graph nodes around, updating the edges correctly.
Perhaps this is of some interest.
I've been running with this for so long that I thought I would commit it; it seems to do no harm, and it was the last diff I had with HEAD.
Andy: I've slapped on the traditional LGPL licence on your demo code; I hope that's alright.
Cheers,
Christophe
Christophe Rhodes csr21@cam.ac.uk writes:
Andy Hefner ahefner@gmail.com writes:
To remedy this, I've attached an experimental patch which refactors graph edge layout and incorporates the needed bookkeeping to associate a graph node with its edges. This allowed my second attempt, also attached, to drag graph nodes around, updating the edges correctly.
[...]
I've been running with this for so long that I thought I would commit it; it seems to do no harm, and it was the last diff I had with HEAD.
Way cool.
Paolo
-
Andy Hefner -
Christophe Rhodes -
Paolo Amoroso -
rpgoldman＠real-time.com