April 2005 - mcclim-devel - mailman3.common-lisp.net

[mcclim-devel] possible buglet in highlighting shapes
by rpgoldman＠real-time.com 09 May '05

09 May '05

I have built a grapher-based tool, that allows me to distinguish between multiple types of node by using shapes. When I highlight rectangular nodes, all is well. But I have "roundtangle" nodes, and when I pass the mouse over them, instead of seeing a box around them, or a highlight outline around the roundtangle, McCLIM gives me THREE rectangles, one around the body of the node, and one each around the semi-circles on the end. Actually, even the rectangle highlighting seems to me a little odd, since the highlight outline is drawn INSIDE the node, instead of around its outline. Here's the code that draws the nodes: (defun draw-taems-node (object stream) (declare (special normal-ink text-style)) (with-drawing-options (stream :ink normal-ink :text-style text-style) (with-output-as-presentation (stream object 'taems-node) (if (typep object 'taems:tmethod) (surrounding-output-with-border (stream :shape :rectangle) (format stream "~D: ~A" (musliner:name object) (taems:taems-name object))) (surrounding-output-with-border (stream :shape :oval) (format stream "~D: ~A" (musliner:name object) (taems:taems-name object))))))) Alas, I am too stupid to figure out how to grab a screendump from X to illustrate this; any suggestions? I wasn't sure how to get xwd to wait until I had a node highlighted before writing its output.... Thanks, R

12 38

[mcclim-devel] re: Black art
by C Y 03 May '05

03 May '05

>> And a graphical CLIM interface builder could possibly go >> a long way towards helping people create "correct" code or at >> least avoid errors. > > I built one of these more than 10 years ago. I'll dust off the > code and post it to the list in the next few days. (It probably > needs updating since I haven't looked at it in at least 5 years.) In case I forgot to say it elsewhere, drool... :-) CY __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

[mcclim-devel] interactor-pane scrolls off the bottom
by tim＠tenkan.org 02 May '05

02 May '05

If you say (define-application-frame foo () () (:pane (make-pane 'interactor-pane :width 400 :height 300))) (clim:run-frame-top-level (clim:make-application-frame 'foo)) You get a window. Hit RET a few times in that window, and the prompt will scroll off the bottom of it, never to return. Is it meant to work that way? -- -Tim

4 6

[mcclim-devel] Command translator question
by Duncan Rose 01 May '05

01 May '05

I'm trying to define a presentation command translator which will invoke 'describe presentation' on specific types. Unfortunately it doesn't work (or at least, works in a way that I'm not expecting so if it's working it's not doing what I want ;-) Looking at the translators defined in the Listener and in builtin-commands.lisp hasn't helped. Here's the translator: (define-presentation-to-command-translator port-select-to-command ; name (t ; from-type com-describe ; command-name - maybe com-describe-presentation? global-command-table ; command table containing command :gesture :select ; activate on :select (left-button click) ;; :tester ... :documentation "Invoke the 'describe presentation' command on the selected presentation" :pointer-documentation ((object stream) (format stream "Describe ~A" object)) :menu t ; command should appear in popped-up menus ;; :priority ... :echo nil) ; don't echo the command when it is invoked ;; arglist must be a subset (using string-equal) of: ;; (object presentation context-type frame event window x y) (object) ;; body of translator; returns a list of the arguments to the command ;; named by command-name. (list object)) In case I was providing the wrong 'from-type' I changed it to T (all types, I hope). I've written this using the Beagle back end but it doesn't work for me when run under CLX either... Any suggestions would be appreciated, I'm obviously missing something... I've attached the complete code for context in case it's helpful. -Duncan

6 11

Re: [mcclim-devel] resizeable panes
by C Y 30 Apr '05

30 Apr '05

--- Paolo Amoroso <amoroso(a)mclink.it> wrote: > rpgoldman(a)real-time.com writes: > > > Is there any easy way to give a McCLIM pane one of those > handy-dandy > > stretch interactors that conventional UIs have? You know, where > you > > can re-allocate space across a pair of panes by dragging on the > > bounday line, or a little icon attached to the boundary? > > At least one CLIM implementation, probably Franz's, provides access > to > the Motif sashes. > > > Paolo So CLIM itself doesn't address this? CY __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

[mcclim-devel] resizeable panes
by rpgoldman＠real-time.com 29 Apr '05

29 Apr '05

Is there any easy way to give a McCLIM pane one of those handy-dandy stretch interactors that conventional UIs have? You know, where you can re-allocate space across a pair of panes by dragging on the bounday line, or a little icon attached to the boundary? Thanks, R

3 2

[mcclim-devel] Subclassing text-field?
by Yoel Jacobsen 29 Apr '05

29 Apr '05

I would like to have a numeric-only text-field. I want it to return numbers with gadget-value, and to be able to setf it with numbers (and not strings). Is subclassing text-field (and text-field-pane?) and defining gadget-value and (setf gadget-value) the solution? If so, it seems to be more complicated than I thought. Any idea/help/example? Thanks, Yoel

2 1

Re: [mcclim-devel] Black art
by C Y 28 Apr '05

28 Apr '05

I think what it comes down to is there simply is no beginner level guide written (or even tutorial that I can find) which says "here's how to create an application." Because, at root level, that's what new developers are asking - I have an interface in my head, how do build it and I get it to run? One suggestion I do have is an extension of the requests to include the file-selector as a component in McCLIM - create a library of "standard interface components" that people can quickly bolt together, and then they will have only to define the tricky, application specific parts of the code. Thinks like menu bars, file-selectors, tabbed windows, scrollable windows, status bars, slidable controllers, button palettes, example configuration dialogs, etc. would be really nice to have available as bolt on components. These would also form a very good basis for a graphical UI designer ala glade or QT Designer. For each of these, a sort of mini API can be defined, and how they are implimented internally can change without bothering user code. This is probably way beyond the CLIM spec, but it would be an excellent way to lower the barrier of entry. And as people create new components, if appropriate they can be added to the available library until it's only a special case presentation like a spreadsheet grid or a mathematical document or an image editing display/interaction that would need to be custom written - most of the rest of the graphical components could be gotten from "standard" or even previous custom objects contributed to the library. And a graphical CLIM interface builder could possibly go a long way towards helping people create "correct" code or at least avoid errors. Does this make sense to anyone else? CY __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

4 3

Re: [mcclim-devel] Axiom
by C Y 28 Apr '05

28 Apr '05

I note, to my surprise, the screenshots page on Axiom only has the TeXmacs screenshots. I'll try to get this sucker working tonight and make some of the browser. Basically, as far as I can remember, it was a text browser with the ability to imbed images and send commands to Axiom. A breakthrough for its time but rather dated now - it should be pretty simple (in theory) to mock up something like it. (Sinking feeling as this gets filed under famous last words...) CY --- Andy Hefner <ahefner(a)gmail.com> wrote: > What kind of browser? > > On 4/28/05, C Y <smustudent1(a)yahoo.com> wrote: > > "I've looked at McClim which is a path I'd dearly love to take but > so > > far I've not gotten it to work. If someone could reproduce the > first > > page of the browser (a few buttons, an image) in McClim that might > be > > enough to get me over the hurdle. A pure lisp solution is > preferred." > > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

[mcclim-devel] Axiom
by C Y 28 Apr '05

28 Apr '05

There has been some discussion going on on the Axiom list about graphics, and Tim Daly made the following interesting remark: "I've looked at McClim which is a path I'd dearly love to take but so far I've not gotten it to work. If someone could reproduce the first page of the browser (a few buttons, an image) in McClim that might be enough to get me over the hurdle. A pure lisp solution is preferred." How difficult would this be to create (assume current McCLIM skills = <very small quantity>) ? I would like to take a stab at this (or if somebody with actual skill does that would be even better) because if Axiom impliments a GUI in McCLIM it would (IMHO) do a world of good for both Axiom and McCLIM. I have gotten McCLIM to work before (though not on GCL) and if it's not insanely difficult I'd like to take a shot at it. CY __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Re: [mcclim-devel] Axiom
by C Y 28 Apr '05

28 Apr '05

I should mention the browser is not the most complicated thing in the world graphically, as it dates from a rather earlier period in interface history. (A few buttons, objects, etc.) I can't produce a screenshot right now because my last install went wonky :-(. CY --- C Y <smustudent1(a)yahoo.com> wrote: > There has been some discussion going on on the Axiom list about > graphics, and Tim Daly made the following interesting remark: > > "I've looked at McClim which is a path I'd dearly love to take but so > far I've not gotten it to work. If someone could reproduce the first > page of the browser (a few buttons, an image) in McClim that might be > enough to get me over the hurdle. A pure lisp solution is preferred." > > How difficult would this be to create (assume current McCLIM skills = > <very small quantity>) ? I would like to take a stab at this (or if > somebody with actual skill does that would be even better) because if > Axiom impliments a GUI in McCLIM it would (IMHO) do a world of good > for > both Axiom and McCLIM. I have gotten McCLIM to work before (though > not > on GCL) and if it's not insanely difficult I'd like to take a shot at > it. > > CY > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > _______________________________________________ > mcclim-devel mailing list > mcclim-devel(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

Re: [mcclim-devel] possible buglet in highlighting shapes
by pw＠snoopy.mv.com 27 Apr '05

27 Apr '05

> I have built a grapher-based tool, that allows me to distinguish > between multiple types of node by using shapes. When I highlight > rectangular nodes, all is well. But I have "roundtangle" nodes, and > when I pass the mouse over them, instead of seeing a box around them, > or a highlight outline around the roundtangle, McCLIM gives me THREE > rectangles, one around the body of the node, and one each around the > semi-circles on the end. You probably want to use :single-box T in with-output-as-presentation. Paul

1 0

[mcclim-devel] A couple of Beagle changes
by Duncan Rose 26 Apr '05

26 Apr '05

The following patch (generated with 'cvs diff -u beagle', which I hope is correct) should modify Beagle so that the following are 'fixed' (i.e. as fixed as they ever get when I do things which is not very ;-) + rectangular tiles + line dashes + patterns (not stencils though) + dispatch repaint when mirror transform is set now untransforms the mirror region by the mirror transformation to hopefully speed things up a little (still veeery slow when the output history is large) beagle/image.lisp can be removed from Beagle, and the lisp-bezier-path.lisp file needs adding. Thanks, -Duncan

1 0

[mcclim-devel] Re: clim-debugger
by Matthew D Swank 26 Apr '05

26 Apr '05

It's not much, but: ;;; -*- Mode: Lisp; Package: COMMON-LISP-USER -*- ;;; ASDF system definition for the clim-debugger. (asdf:defsystem clim-debugger :serial t :components ((:file "clim-debugger"))) -- "You do not really understand something unless you can explain it to your grandmother." — Albert Einstein.

1 0

[mcclim-devel] clim-debugger
by Peter Mechlenborg 25 Apr '05

25 Apr '05

Hi all I finally took some time off to do a bit on the debugger again. It can be found here: http://www.daimi.au.dk/~metch/lisp/clim-debugger.lisp Changes: - A "more button" have been added, so more stack-frames can be viewed if 20 isn't enough. - Scroll-bars have been added, thanks to Elliott Johnson. There's still a small problem though. The scroll-bars do not remember their position when a stack-frame or "more" is pressed. I don't know how to fix this, couldn't find anything in the specs and Clouseau didn't help either. Do anyone of you know how to do this? - Frame variables are viewed with Clouseau when pressed. What do you think? Have fun, -- Peter

5 8

[mcclim-devel] Drawing graphs & scaling
by Thibault Langlois 22 Apr '05

22 Apr '05

Hello, I would like to be able to scale a graph: (defmethod plot ((object tree) stream) (with-scaling (stream 0.7) (draw-graph (list (root-node object)) #'draw-node-colors :stream stream))) where draw-graph is directly inspired from an example in allegro CLIM manual: (defun draw-graph (root-nodes draw-node-function &rest keys) (apply #'format-graph-from-roots root-nodes #'(lambda (node s) (multiple-value-bind () (with-output-as-presentation (s node 'node) (funcall draw-node-function node s)))) #'(lambda (n) (if (visible-p n) (children n))) keys)) and draw-node-colors draws a node using draw-rectangle*. The problem is that when the scaling factor is not 1 the nodes are not correctly placed (although they are correctly scaled) with respect to arcs. Any ideas ? Thanks. Thibault

3 6

[mcclim-devel] How to change color of a text field
by Paolo Amoroso 21 Apr '05

21 Apr '05

How can I change the color of the text displayed in a text field? Does the CLIM specification allow this? Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log

3 6

[mcclim-devel] keymap switching in McCLIM frame
by glitch 20 Apr '05

20 Apr '05

I heard that i probably get help in this mailing list. I have stumbled on problem with keymap switching in McCLIM frames. What i did: $ clim * (some-loading) * (run-frame-top-level 'any-frame) -> user gesture, that causes setxkbmap -> no reaction ^C (ext:quit) $ clim * (run-frame-top-level 'any-frame) -> typing any keys *trace-output*: lookup-gesture-command: 0 :|cyrillic-<something>| - why now? cmucl19a clx5.2 McCLIM 0.9 Excuse me please for my broken English :( best regards /glitch

1 0

[mcclim-devel] keymap switching in McCLIM frame
by glitch 20 Apr '05

20 Apr '05

I heard that i probably get help in this mailing list. I have stumbled on problem with keymap switching in McCLIM frames. What i did: $ clim * (some-loading) * (run-frame-top-level 'any-frame) -> user gesture, that causes setxkbmap -> no reaction ^C (ext:quit) $ clim * (run-frame-top-level 'any-frame) -> typing any keys *trace-output*: lookup-gesture-command: 0 :|cyrillic-<something>| - why now? cmucl19a clx5.2 McCLIM 0.9 Excuse me please for my broken English :( best regards /glitch

1 0

[mcclim-devel] mcclim.asd patch for Allegro CL
by rpgoldman＠real-time.com 18 Apr '05

18 Apr '05

Here's a patch that causes Allegro (or at least my beloved, increasingly aged ACL 6.2), to load CLX while loading MCCLIM. Per Christophe's instructions on #lisp, consider this to be an official whine to have the patch applied! :-) I don't believe that there's any way this could muck things up for anyone not using ACL, but I am not infallible... R --- mcclim.asd 1 Mar 2005 15:46:13 -0000 1.4 +++ mcclim.asd 18 Apr 2005 17:19:18 -0000 @@ -80,6 +80,25 @@ (defsystem :clim-lisp #+clisp "fix-clisp"))) (:file "package" :depends-on ("Lisp-Dep")))) +;;; possibly this should be further refined to funciton properly for +;;; Allegro on Windows platforms. [2005/04/18:rpg] +#+allegro +(defclass requireable-system (asdf:system) + () + ) + +#+allegro +(defmethod asdf:perform ((op asdf:load-op) (system requireable-system)) + (require (intern (slot-value system 'asdf::name) "KEYWORD"))) + +#+allegro +(defmethod asdf::traverse ((op asdf:load-op) (system requireable-system)) + (list (cons op system))) + +#+allegro +(defsystem :clx + :class requireable-system) + (defsystem :clim-core :depends-on (:clim-lisp) :components ((:file "decls") @@ -216,7 +235,7 @@ (defsystem :clim )) (defsystem :clim-clx - :depends-on (:clim #+(or sbcl openmcl ecl) :clx) + :depends-on (:clim #+(or sbcl openmcl ecl allegro) :clx) :components ((:module "Backends/CLX" :pathname #.(make-pathname :directory '(:relative "Backends" "CLX")) @@ -276,7 +295,7 @@ (defsystem :clim-looks :depends-on (:clim ;; If we're on an implementation that ships CLX, use ;; it. Same if the user has loaded CLX already. - #+(or sbcl openmcl ecl clx) :clim-clx + #+(or sbcl openmcl ecl clx allegro) :clim-clx #+gl :clim-opengl ;; OpenMCL and MCL support the beagle backend (native ;; OS X look&feel on OS X).

1 0

[mcclim-devel] error on modifying example code
by Jason Wang 16 Apr '05

16 Apr '05

hi, i just got McClim and see how it works.. and got my first attempt in modifying the example code(s) in trying to get a feel how everything works.. though, what seem to be a simple layout edition turned out crashing my program upon start up (note, the example program calculator is working fine before modification).. i modified the following code snippet: (:layouts (default (with-slots (text-field) *application-frame* (vertically (:width 150 :max-width 500) (setf text-field screen) (horizontally (:height 50) ac ce) (tabling (:grid t) (list one two three four) (list five six seven eight) (list nine zero plus dash) (list multiply divide result)))))) (:top-level (calculator-frame-top-level . nil))) the fifth last line to second last line would be the lines of interest.. i just modified some layout component (or i thought to be), and it gave me the following error: There is no applicable method for the generic function #<STANDARD-GENERIC-FUNCTION CLIM:MOVE-SHEET (2)> when called with arguments (NIL 69 99). [Condition of type SIMPLE-ERROR] Backtrace: 0: ((SB-PCL::FAST-METHOD NO-APPLICABLE-METHOD (T)) #<unavailable argument> #<unavailable argument> #<STANDARD-GENERIC-FUNCTION CLIM:MOVE-SHEET (2)> (NIL 69 99)) 1: ((SB-PCL::FAST-METHOD NO-APPLICABLE-METHOD (T)) #<unavailable argument> #<unavailable argument> #<STANDARD-GENERIC-FUNCTION CLIM:MOVE-SHEET (2)> (NIL 69 99)) 2: ((SB-PCL::FAST-METHOD CLIM:ALLOCATE-SPACE (CLIM:GRID-PANE T T)) (#(NIL 37) . #()) #<unavailable argument> #<CLIM:GRID-PANE "(Unnamed Pane)" {9D40E49}> 92 132) 3: ((SB-PCL::FAST-METHOD CLIM-INTERNALS::BOX-LAYOUT-MIXIN/VERTICALLY-ALLOCATE-SPACE (CLIM-INTERNALS::BOX-LAYOUT-MIXIN T T)) (#(NIL 32) . #()) #<unavailable argument> #<CLIM:VRACK-PANE "(Unnamed Pane)" {9D49159}> 92 186) 4: ((SB-PCL::FAST-METHOD CLIM-INTERNALS::BOX-LAYOUT-MIXIN/VERTICALLY-ALLOCATE-SPACE (CLIM-INTERNALS::BOX-LAYOUT-MIXIN T T)) (#(NIL 32) . #()) #<unavailable argument> #<CLIM:VRACK-PANE "(Unnamed Pane)" {9D50D69}> 92 190) 5: ((LAMBDA (SB-PCL::.PV-CELL. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. SB-PCL::.ARG1. SB-PCL::.ARG2.)) #<unavailable argument> #<unavailable argument> #<CLIM-INTERNALS::TOP-LEVEL-SHEET-PANE CLIM-INTERNALS::TOP-LEVEL-SHEET {A305B91}> 92 190) 6: ((LAMBDA (SB-PCL::.PV-CELL. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. SB-PCL::.ARG1.)) #<unavailable argument> #<unavailable argument> #<CLIM-CLX::CLX-FRAME-MANAGER {9A226E9}> #<CLIM-DEMO::CALCULATOR {A35C971}>) 7: ((SB-PCL::FAST-METHOD CLIM:ADOPT-FRAME (CLIM:FRAME-MANAGER CLIM:APPLICATION-FRAME)) (#(NIL 1 15 12) . #()) #<unavailable argument> #<CLIM-CLX::CLX-FRAME-MANAGER {9A226E9}> #<CLIM-DEMO::CALCULATOR {A35C971}>) 8: ((LAMBDA (SB-PCL::.PV-CELL. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0. SB-PCL::.ARG1.)) #<unavailable argument> #<unavailable argument> #<CLIM-CLX::CLX-FRAME-MANAGER {9A226E9}> #<CLIM-DEMO::CALCULATOR {A35C971}>) 9: ((SB-PCL::FAST-METHOD CLIM:RUN-FRAME-TOP-LEVEL :AROUND (CLIM:APPLICATION-FRAME)) #<unavailable argument> #S(SB-PCL::FAST-METHOD-CALL :FUNCTION #<FUNCTION (SB-PCL::FAST-METHOD CLIM:RUN-FRAME-TOP-LEVEL #)> :PV-CELL NIL :NEXT-METHOD-CALL NIL :ARG-INFO (1 . T)) #<CLIM-DEMO::CALCULATOR {A35C971}> NIL) 10: (CLIM-DEMO::CALCULATOR) 11: (SB-INT:EVAL-IN-LEXENV (CLIM-DEMO::CALCULATOR) #<NULL-LEXENV>) 12: (SWANK::EVAL-REGION "(clim-demo::calculator) " T) 13: ((LAMBDA NIL)) 14: ((SB-PCL::FAST-METHOD SWANK-BACKEND:CALL-WITH-SYNTAX-HOOKS (T)) #<unused argument> #<unused argument> #<CLOSURE (LAMBDA NIL) {A35C0B5}>) 15: (SWANK:LISTENER-EVAL "(clim-demo::calculator) ") 16: (SB-INT:EVAL-IN-LEXENV (SWANK:LISTENER-EVAL "(clim-demo::calculator) ") #<NULL-LEXENV>) 17: ((LAMBDA NIL)) 18: ((SB-PCL::FAST-METHOD SWANK-BACKEND:CALL-WITH-DEBUGGER-HOOK (T T)) #<unused argument> #<unused argument> #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK> #<CLOSURE (LAMBDA NIL) {A35BF25}>) 19: ((LAMBDA NIL)) 20: (SWANK::CALL-WITH-REDIRECTED-IO #<SWANK::CONNECTION {A4ACDA1}> #<FUNCTION (LAMBDA NIL) {B45C885}>) 21: (SWANK::HANDLE-REQUEST #<SWANK::CONNECTION {A4ACDA1}>) 22: ((LAMBDA NIL)) 23: ((LAMBDA NIL)) 24: (SWANK::CALL-WITH-REDIRECTED-IO #<SWANK::CONNECTION {A4ACDA1}> #<CLOSURE (LAMBDA NIL) {9070075}>) 25: (SWANK::REPL-LOOP #<SWANK::CONNECTION {A4ACDA1}>) 26: (SWANK::CALL-WITH-BINDINGS NIL #<CLOSURE (LAMBDA NIL) {9070055}>) 27: ((LAMBDA NIL)) 28: ("foreign function: call_into_lisp") 29: ("foreign function: funcall0") anyone know what's wrong? thanks alot :D -- www.programer.name - my own personal blog : )

1 0

[mcclim-devel] question about format-graph-from-roots
by rpgoldman＠real-time.com 13 Apr '05

13 Apr '05

One suggested patch and one question: 1. Suggested patch: should we modify format-graph-from roots so that the defualt value for :arc-drawer is #'clim-internals::standard-arc-drawer? 2. I have been trying to figure out how to draw a graph that has multiple different kinds of edges. Actually, more specifically, I would like to draw a graph that is "mostly" a tree: it has a tree backbone, and then has some cross-edges. It isn't at all obvious how to do this nicely. There are (at least) two problems: i. I don't see an elegant way to indicate the type of edges. AFAICT, the CLIM spec indicates that we simply generate children, i.e., nodes. We never generate edges, except implicitly. My best guess is that the way to do this is either: a. have the "from" node always have enough information to determine what sort of edge is to be drawn from it to the "to" node. This actually breaks down a little in the case where there can be multiple arcs from one "from" to a single "to." b. create a new data structure (some form of association like a hash table, alist or whatever) that records the type of arc to be drawn, and stuff it into your arc drawer function. ii. More seriously, there doesn't seem any obvious way to say that an arc between "from" and "to" is a cross-edge, and shouldn't increment the depth of "to," rather than being a child edge that DOES increment the depth. Anyone have any suggestions for this? It seems the more difficult problem. Best, R

3 4

[mcclim-devel] typesetting CLIM spec
by rpgoldman＠real-time.com 12 Apr '05

12 Apr '05

Flushed with my success pdf-ulating the manual, I had a run up at the CLIM spec. This seems to work with minimal patching. Simply apply the following, and use pdflatex instead of latex, and you get a version that has bookmarks and hyperlinks in it. One problem: regions.tex seems to require a file named file-normalization.epsi. I was going to translate it into pdf, but found that it's nowhere in the copy of mcclim that I checked out. Is this a bug with the spec LaTex? Best, r Index: clim.tex =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/Spec/src/clim.tex,v retrieving revision 1.1 diff -c -r1.1 clim.tex *** clim.tex 11 Dec 2000 06:59:59 -0000 1.1 --- clim.tex 12 Apr 2005 18:54:56 -0000 *************** *** 17,22 **** --- 17,29 ---- {\end{small}\clearpage} \makeatother + %% added to try to make nice bookmarks in PDF... [2005/04/12:rpg] + \ifx\pdfoutput\undefined \csname newcount\endcsname\pdfoutput \fi + \ifcase\pdfoutput \else + \usepackage[pdftex]{hyperref} + \fi + + %\usepackage{times} %% For PDF

1 0

[mcclim-devel] fussy clean-up items
by rpgoldman＠sift.info 07 Apr '05

07 Apr '05

I was just reading over the warnings the ACL compiler gives me, and I noticed that we have three definitions of make-keyword, in presentations.lisp, commands.lisp, and utils.lisp. I don't claim to understand the dueling system definitions (mk-defsystem and asdf) to know which ones should be killed, but any objections to killing a couple? Also, the compiler beefs about double definitions of (METHOD %PRESENTATION-TYPEP (T T T)) and (METHOD %PRESENT (T T T T TEXTUAL-VIEW)) is this due to the eval-when form being evaluated first at compile time, and then at load time? Cheers, r

1 0

[mcclim-devel] question about format-graph-from-roots
by rpgoldman＠sift.info 07 Apr '05

07 Apr '05

Some time ago, Paolo (IIRC) posted a suggested patch to format-graph-from-roots to supply a default for the arc-drawer keyword argument. Again, IIRC, the CLIM spec requires that there be such a default. I was just updating this morning, and noticed that the patch has never been applied. Would someone please apply it (unless there's something wrong with it)? One possible problem is that it ignores the arc-drawing-options keyword, but it still seems better than not having a default at all. Here's the patch: Index: graph-formatting.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/graph-formatting.lisp,v retrieving revision 1.11 diff -u -F^(def -r1.11 graph-formatting.lisp --- graph-formatting.lisp 5 Dec 2004 19:37:52 -0000 1.11 +++ graph-formatting.lisp 7 Apr 2005 14:18:17 -0000 @@ -120,14 +120,20 @@ (define-graph-type :digraph digraph-grap ;;;; Entry (defun format-graph-from-roots (root-objects object-printer inferior-producer - &rest graph-options - &key stream orientation cutoff-depth - merge-duplicates duplicate-key duplicate-test - generation-separation - within-generation-separation - center-nodes arc-drawer arc-drawing-options - graph-type (move-cursor t) - &allow-other-keys) + &rest graph-options + &key stream orientation cutoff-depth + merge-duplicates duplicate-key duplicate-test + generation-separation + within-generation-separation + center-nodes + (arc-drawer + #'(lambda (stream from to from-x from-y to-x to-y) + (declare (ignore from to)) + (draw-line* stream from-x from-y to-x to-y))) + + arc-drawing-options + graph-type (move-cursor t) + &allow-other-keys) (declare (ignore orientation generation-separation within-generation-separation center-nodes)) ;; Mungle some arguments (check-type cutoff-depth (or null integer))

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

mcclim-devel April 2005