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

[mcclim-devel] Customizing interactor panes
by Peter Scott 27 Jan '05

27 Jan '05

I'm writing a GUI for a chemistry program with McCLIM. My problem is that I want the user to be able to type commands into the interactor pane in a special syntax, which I have written a parser for. For example, typing "Krypton" should call the Inspect Element command on the element called "Krypton". Typing "12 g C H4" should display how many moles of methane there are in 12 g. There's more like that, but I have the code to handle it all written---except for the code that hooks it into an interactor pane. There's a way of getting an interactor pane to differentiate between commands and s-expressions, for use in a listener, so I think that what I want is possible. Can anybody tell me how? -Peter

2 1

[mcclim-devel] patch to fix-acl.lisp
by Robert P. Goldman 27 Jan '05

27 Jan '05

I am not at all sure that this is The Right Thing, but I found that the fix-acl code that makes the clim-mop package didn't work for me, because it assumed that the right thing was to export all the external symbols from the CLOS package from CLIM-MOP. But some of the symbols we want seem to actually be in the COMMON-LISP package, instead. Anyway, here's a proposed fix. Please let me know if I've committed some solecism or other: Index: fix-acl.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/Lisp-Dep/fix-acl.lisp,v retrieving revision 1.9 diff -u -F^(def -r1.9 fix-acl.lisp --- fix-acl.lisp 21 Mar 2003 15:15:09 -0000 1.9 +++ fix-acl.lisp 27 Jan 2005 21:56:35 -0000 @@ -5,15 +5,49 @@ ;;; Needed to keep ACL from issuing warnings about toplevel (shadow ...) forms (setq comp:*cltl1-compile-file-toplevel-compatibility-p* nil) -(require :loop) +(eval-when (:compile-toplevel :load-toplevel :execute) + (require :loop) + (require :mop)) (defpackage :clim-mop - (:use :clos)) - + (:use :clos :common-lisp) + (:export + #:validate-superclass + #:class-finalized-p + #:finalize-inheritance + #:class-prototype + #:class-name + #:class-precedence-list + #:class-direct-superclasses + #:class-direct-subclasses + #:class-direct-slots + "CLASS-SLOTS" + "SLOT-DEFINITION-NAME" + "SLOT-DEFINITION-TYPE" + "SLOT-DEFINITION-INITARGS" + "SLOT-DEFINITION-INITFUNCTION" + "SLOT-DEFINITION-INITFORM" + "SLOT-DEFINITION-READERS" + "SLOT-DEFINITION-WRITERS" + "SLOT-DEFINITION-ALLOCATION" + #:ensure-class + #:funcallable-standard-class + #:method-specializers + #:method-qualifiers + #:method-lambda-list + #:method-generic-function + #:generic-function-methods + #:generic-function-name + "GENERIC-FUNCTION-LAMBDA-LIST" + "GENERIC-FUNCTION-ARGUMENT-PRECEDENCE-ORDER" + #:eql-specializer + #:eql-specializer-object + #:intern-eql-specializer + #:compute-applicable-methods-using-classes)) -(eval-when (:compile-toplevel :load-toplevel :execute) - (do-external-symbols (sym :clos) - (export sym :clim-mop))) +;;;(eval-when (:compile-toplevel :load-toplevel :execute) +;;; (do-external-symbols (sym :clos) +;;; (export sym :clim-mop))) (eval-when (:compile-toplevel :load-toplevel :execute) (export '(clim-lisp-patch::defclass)

1 0

[mcclim-devel] Show Command Table Listener command: error left-clicking field in ACCEPTING-VALUES dialog
by Paolo Amoroso 27 Jan '05

27 Jan '05

I have found a bug that can be reproduced this way. Run the CLIM Listener, enter the command "Show Command Table" and hit ENTER without providing an argument. An ACCEPTING-VALUES dialog prompting for the missing argument appears. Left-clicking the input field generates this error: No matching method for the generic function #<STANDARD-GENERIC-FUNCTION CLIM:COMMAND-TABLE-NAME (1) {284FF439}>, when called with arguments (NIL). [Condition of type PCL::NO-APPLICABLE-METHOD-ERROR] Restarts: 0: [CONTINUE ] Retry call to :FUNCTION. 1: [ABORT ] Return to application command loop 2: [RETURN-TO-LISTENER] Return to listener. 3: [DESTROY ] Destroy the process Debug (type H for help) ("DEFMETHOD NO-APPLICABLE-METHOD (T)" #<unused-arg> #<unused-arg> #<STANDARD-GENERIC-FUNCTION CLIM:COMMAND-TABLE-NAME (1) {284FF439}> (NIL)) Source: Error finding source: Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM: Source file no longer exists: target:pcl/braid.lisp. 0] I use the latest McCLIM CVS sources with CMUCL Snapshot 2005-01 under Slackware Linux 10.0. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log

2 2

Re: [mcclim-devel] Confused by with-room-for-graphics
by pw＠snoopy.mv.com 27 Jan '05

27 Jan '05

> Can people with classic CLIM try this function in a listener (I believe > classic CLIM has such a thing) and try (draw-compass *standard-output* > 'symbol t) and > (draw-compass *standard-output* nil)? I would like to know if the > entire compass is visible and if it overlaps other graphics in the > output stream. I don't use a clim listener but I ran the test in an application-pane. The first case draws a compass with S on top and N at bottom. The second case draws it with N at top and S at bottom. Lines of text around calls appear as expected. Calling draw-compass after outputting some text but no terminating newline results with the compass drawn to the right of that text with the top of the N seemingly aligned with the top of the text string and the left of the W aligned with the end of text. I can try and get more precise alignment of the bounding box if you need that. Let me know if you really need the test run in a listener. I think there is one in the clim demo directory. Paul

2 1

Re: [mcclim-devel] Confused by with-room-for-graphics
by pw＠snoopy.mv.com 27 Jan '05

27 Jan '05

Calling draw-compass after outputting some text but no terminating newline > results with the compass drawn to the right of that text with the top of > the N seemingly aligned with the top of the text string and the left of > the W aligned with the end of text. To be clear, that last statement was about the second test, with the quadrant parameter NIL (North on top). Paul

1 0

[mcclim-devel] find-keystroke-item slowness
by Cyrus Harmon 27 Jan '05

27 Jan '05

Dear mcclim-devel, It looks like find-keystroke-item is doing a lot of work (linear search through the keystrokes) every time there's a key event. I know this is the lispy way to do things, and clim wants to be flexible enough to provide other tests besides event-matches-gesture-name-p, but this seems like an awful lot of work for every key stroke. Am I missing something here? BTW, I bring this up to try to address the generally poor response I get typing in climacs with the beagle back end. Thanks, Cyrus

4 4

[mcclim-devel] Confused by with-room-for-graphics
by Timothy Moore 27 Jan '05

27 Jan '05

In the course of fixing a replay problem in with-room-for-graphics I took it upon myself to rewrite it to be consistent with the spec and the Franz manual, but now I'm thoroughly confused, especially by the menu drawing example. I had believed that the origin of the local coordinate system would be placed at the current cursor, possibly offset vertically by the height (if supplied) or by the maximum y value in the first quadrant case, even if this would result in some output with negative x coordinates being lost of the left edge of the screen. But that means that the menu example in the Franz manual would lose the North and West points of the compass, which can't be right. Can people with classic CLIM try this function in a listener (I believe classic CLIM has such a thing) and try (draw-compass *standard-output* 'symbol t) and (draw-compass *standard-output* nil)? I would like to know if the entire compass is visible and if it overlaps other graphics in the output stream. (defun draw-compass (stream &optional (type 'symbol) (quadrant nil)) (labels ((draw-compass-point (stream type symbol x y) (clim:with-output-as-presentation (stream symbol type) (clim:draw-text* stream (symbol-name symbol) x y :align-x :center :align-y :center :text-style '(:sans-serif :roman :large))))) (clim:with-room-for-graphics (stream :first-quadrant quadrant) (clim:draw-line* stream 0 25 0 -25 :line-thickness 2) (clim:draw-line* stream 25 0 -25 0 :line-thickness 2) (dolist (point '((n 0 -30) (s 0 30) (e 30 0) (w -30 0))) (apply #'draw-compass-point stream type point))))) Thanks a lot, Tim

1 0

[mcclim-devel] Re: beagle
by Boris Tschirschwitz 23 Jan '05

23 Jan '05

Hey. Trying to compile the beagle backend to test climacs, I noticed that the load paths are hardwired to 'Users/duncan/...'. Is there any reason for keeping this. If not, is there already a patch somewhere, or would one be welcome? Boris.

1 0

[mcclim-devel] Re: [mcclim-cvs] CVS update: mcclim/presentation-defs.lisp
by Andy Hefner 20 Jan '05

20 Jan '05

Having read the spec, I see I'm wrong about this. Sorry about that. On Wed, 19 Jan 2005 19:05:51 -0500, Andy Hefner <ahefner(a)gmail.com> wrote: > I think this is wrong. McCLIM now returns the class name of the object > even when no corresponding presentation type has been defined. On Jan > 2nd I commited a change to stop this from happening (I think it was > causing problems with the listener), which this seems to undo. > > Thoughts? > > > On Wed, 19 Jan 2005 14:44:46 -0800 (PST), Timothy Moore > <tmoore(a)common-lisp.net> wrote: > > Update of /project/mcclim/cvsroot/mcclim > > In directory common-lisp.net:/tmp/cvs-serv20050 > > > > Modified Files: > > presentation-defs.lisp > > Log Message: > > For CLOS objects, make presentation-type-of return the name of the class if possible > > Date: Wed Jan 19 14:44:46 2005 > > Author: tmoore > > > > Index: mcclim/presentation-defs.lisp > > diff -u mcclim/presentation-defs.lisp:1.39 mcclim/presentation-defs.lisp:1.40 > > --- mcclim/presentation-defs.lisp:1.39 Tue Jan 11 05:02:19 2005 > > +++ mcclim/presentation-defs.lisp Wed Jan 19 14:44:46 2005 > > @@ -87,11 +87,15 @@ > > (defmethod presentation-type-of ((object standard-object)) > > (multiple-value-bind (name lambda-list) > > (get-ptype-from-class-of object) > > - (if (and name > > - (or (null lambda-list) > > - (member (first lambda-list) lambda-list-keywords))) > > - name > > - (call-next-method)))) > > + (cond ((and name > > + (or (null lambda-list) > > + (member (first lambda-list) lambda-list-keywords))) > > + name) > > + (name > > + 'standard-object) > > + (t (let* ((class (class-of object)) > > + (class-name (class-name class))) > > + (or class-name class)))))) > > > > (defmethod presentation-type-of ((object structure-object)) > > (multiple-value-bind (name lambda-list) > > @@ -100,7 +104,6 @@ > > (member lambda-list lambda-list-keywords)) > > name > > (call-next-method)))) > > - > > > > (define-presentation-generic-function > > %map-over-presentation-type-supertypes > > > > _______________________________________________ > > mcclim-cvs mailing list > > mcclim-cvs(a)common-lisp.net > > http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-cvs > > >

1 0

[mcclim-devel] Re: [mcclim-cvs] CVS update: mcclim/presentation-defs.lisp
by Andy Hefner 20 Jan '05

20 Jan '05

I think this is wrong. McCLIM now returns the class name of the object even when no corresponding presentation type has been defined. On Jan 2nd I commited a change to stop this from happening (I think it was causing problems with the listener), which this seems to undo. Thoughts? On Wed, 19 Jan 2005 14:44:46 -0800 (PST), Timothy Moore <tmoore(a)common-lisp.net> wrote: > Update of /project/mcclim/cvsroot/mcclim > In directory common-lisp.net:/tmp/cvs-serv20050 > > Modified Files: > presentation-defs.lisp > Log Message: > For CLOS objects, make presentation-type-of return the name of the class if possible > Date: Wed Jan 19 14:44:46 2005 > Author: tmoore > > Index: mcclim/presentation-defs.lisp > diff -u mcclim/presentation-defs.lisp:1.39 mcclim/presentation-defs.lisp:1.40 > --- mcclim/presentation-defs.lisp:1.39 Tue Jan 11 05:02:19 2005 > +++ mcclim/presentation-defs.lisp Wed Jan 19 14:44:46 2005 > @@ -87,11 +87,15 @@ > (defmethod presentation-type-of ((object standard-object)) > (multiple-value-bind (name lambda-list) > (get-ptype-from-class-of object) > - (if (and name > - (or (null lambda-list) > - (member (first lambda-list) lambda-list-keywords))) > - name > - (call-next-method)))) > + (cond ((and name > + (or (null lambda-list) > + (member (first lambda-list) lambda-list-keywords))) > + name) > + (name > + 'standard-object) > + (t (let* ((class (class-of object)) > + (class-name (class-name class))) > + (or class-name class)))))) > > (defmethod presentation-type-of ((object structure-object)) > (multiple-value-bind (name lambda-list) > @@ -100,7 +104,6 @@ > (member lambda-list lambda-list-keywords)) > name > (call-next-method)))) > - > > (define-presentation-generic-function > %map-over-presentation-type-supertypes > > _______________________________________________ > mcclim-cvs mailing list > mcclim-cvs(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-cvs >

1 0