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

[mcclim-devel] question about curves and formatting graphs
by rpgoldman＠real-time.com 10 Apr '06

10 Apr '06

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

4 11

[mcclim-devel] EPS output
by Christophe Rhodes 31 Aug '05

31 Aug '05

Hi, I need EPS output (as opposed to postscript destined for some paper size). I think the attached patch implements this, by using output recording to measure the bounding box of the output. (Though I can imagine that I've got the linesize stuff wrong and am out by 0.5 or something). I'm not happy with the way that I'm handling the transformation (in particular, the hack in obtaining the bounding box, where I've used knowledge of the transformation to reorder the coordinates), nor am I happy with the fact that this breaks in the presence of (newpage) commands, though since that doesn't make sense for EPS output, that might not be so big a deal. I think this works (unlike my previous attempt, which I was equally convinced worked, but failed to draw anything at all). I attach in addition a couple of test forms to try at the REPL, and also a file which could live as Tests/postscript.lisp. (McCLIM with this patch applied passes the tests, though they're by no means exhaustive). Comments? Is anyone else using Postscript output? Cheers, Christophe

1 0

[mcclim-devel] ACL70 bug: Ignorable in argument acceptor functions for define-command
by rpgoldman＠real-time.com 30 Aug '05

30 Aug '05

I find that with allegro version 7.0, McCLIM crashes while compiling. The problem first crops up compiling (define-command (com-query-exit :command-table accepting-values :name nil :provide-output-destination-keyword nil) () (signal 'av-exit)) which macroexpands to: (PROGN (DEFUN COM-QUERY-EXIT () (SIGNAL 'AV-EXIT)) (ADD-COMMAND-TO-COMMAND-TABLE 'COM-QUERY-EXIT 'ACCEPTING-VALUES :NAME NIL :MENU 'NIL :KEYSTROKE 'NIL :ERRORP NIL) (DEFUN COM-QUERY-EXIT%ACCEPTOR%9 (#:STREAM61697) (LET ((#:KEY-RESULTS61698 NIL)) (BLOCK ACTIVATED (FLET ((EAT-DELIMITER-OR-ACTIVATOR NIL (LET ((GESTURE (READ-GESTURE :STREAM #:STREAM61697))) (WHEN (OR (NULL GESTURE) (ACTIVATION-GESTURE-P GESTURE)) (RETURN-FROM ACTIVATED NIL)) (UNLESS (DELIMITER-GESTURE-P GESTURE) (UNREAD-GESTURE GESTURE :STREAM #:STREAM61697))))) (DECLARE (IGNORABLE #'EAT-DELIMITER-OR-ACTIVATOR)) (LET ((GESTURE (READ-GESTURE :STREAM #:STREAM61697 :TIMEOUT 0 :PEEK-P T))) (COND ((AND GESTURE (ACTIVATION-GESTURE-P GESTURE)) (RETURN-FROM ACTIVATED NIL))) NIL))) (LIST* #:KEY-RESULTS61698))) (DEFUN COM-QUERY-EXIT%PARTIAL%8 (#:COMMAND-TABLE61699 #:STREAM61700 #:PARTIAL-COMMAND61701) (DESTRUCTURING-BIND (#:COMMAND-NAME61702) #:PARTIAL-COMMAND61701 (LET ((#:COMMAND-LINE-NAME61703 (COMMAND-LINE-NAME-FOR-COMMAND #:COMMAND-NAME61702 #:COMMAND-TABLE61699 :ERRORP NIL))) (ACCEPTING-VALUES (#:STREAM61700) (FORMAT #:STREAM61700 "You are being prompted for arguments to ~S~%" #:COMMAND-LINE-NAME61703)) (LIST #:COMMAND-NAME61702)))) (DEFUN |COM-QUERY-EXIT%unparser%9| (#:COMMAND61707 #:STREAM61709) (DECLARE (IGNORABLE #:STREAM61709)) (LET* ((#:SEPERATOR61712 #\Space) (#:COMMAND-ARGS61708 (CDR #:COMMAND61707))) (DECLARE (IGNORABLE #:SEPERATOR61712 #:COMMAND-ARGS61708)))) NIL (SETF (GETHASH 'COM-QUERY-EXIT *COMMAND-PARSER-TABLE*) (MAKE-INSTANCE 'COMMAND-PARSERS :PARSER #'COM-QUERY-EXIT%ACCEPTOR%9 :PARTIAL-PARSER #'COM-QUERY-EXIT%PARTIAL%8 :REQUIRED-ARGS 'NIL :KEYWORD-ARGS 'NIL :ARGUMENT-UNPARSER #'|COM-QUERY-EXIT%unparser%9|)) 'COM-QUERY-EXIT) Allegro v 7.0 chokes on (DECLARE (IGNORABLE #'EAT-DELIMITER-OR-ACTIVATOR)) AFAICT, Allegro 7.0 can't compile ignorable declarations applied to constant functions like this. I believe this is an allegro bug, as is suggested by the error message: ; While compiling COM-QUERY-EXIT%ACCEPTOR%0: Error: We don't yet handle ignore of #'EAT-DELIMITER-OR-ACTIVATOR. For now, I was just going to put the following conditional compilation directive in commands.lisp: #-ALLEGRO-V7.0 (declare (ignorable (function eat-delimiter-or-activator))) Any reason not to commit this change? Actually, I'm on vacation, and it may be difficult for me to make this commit for a week or so, so if anyone else would like to, that would be great! R

2 1

[mcclim-devel] current CVS McCLIM broken?
by Max-Gerd Retzlaff 30 Aug '05

30 Aug '05

Hello, I've just got a fresh CVS checkout und built a new sbcl core with mcclim, mcclim-freetype, mcclim-examples, clouseau, clim-listener, swank-loader, and the clim-debugger. Sadly, if I start sbcl with this core and call the clim-listener I get: -- zipp -- $ sbcl --core new-sbcl-asdf-install-clim-listener-clouseau-slime-swank-clim-debugger.core This is SBCL 0.9.1.65, an implementation of ANSI Common Lisp. More information about SBCL is available at <http://www.sbcl.org/>. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. * (clim-listener::run-listener) debugger invoked on a TYPE-ERROR in thread 3085365376: The value #<MCCLIM-FREETYPE::FREETYPE-FACE {94F0DD1}> is not of type (OR XLIB:FONT XLIB:GCONTEXT). Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT ] Return to application command loop 1: [RETURN-TO-LISTENER] Return to listener. 2: Exit debugger, returning to top level. (XLIB:TEXT-EXTENTS #<MCCLIM-FREETYPE::FREETYPE-FACE {94F0DD1}> "mgr") 0] -- zapp -- Note that my SBCL is about two months old but that was no problem until recently (my last test was slightly more than one week ago). Bye, Max PS: If you want to know, I usually build new cores with this command: sbcl --core /usr/local/lib/sbcl/sbcl.core_org --userinit ~/.sbclrc_core-dumping --eval '(progn (require :mcclim) (require :mcclim-freetype) (require :clim-examples) (require :clouseau) (require :clim-listener) (load #p"lispdir:slime;swank-loader") (load (merge-pathnames "Apps/Debugger/clim-debugger" (truename #p"lispdir:site;mcclim"))) (save-lisp-and-die "new-sbcl-asdf-install-clim-listener-clouseau-slime-swank-clim-debugger.core"))' ~/.sbclrc_core-dumping is the following; it sets up my ASDF: -- zipp -- ;;; -*- Mode: LISP -*- (setf (logical-pathname-translations "coding") '(("**;*.*.*" #P"/home/mgr/daten/coding/lisp/**/*.*"))) (setf (logical-pathname-translations "sbcldir") '(("**;*.*.*" #P"/usr/src/lisp/sbcl/**/*.*"))) (setf (logical-pathname-translations "lispdir") '(("**;*.*.*" #P"/usr/src/lisp/**/*.*"))) ;; (setf (logical-pathname-translations "lispdir") ;; `(("lispdir:**;*.*.*" ;; ,(make-pathname :directory ;; '(:absolute "usr" "src" "lisp" :wild-inferiors) ;; :name :wild :type :wild :version :wild)))) (require 'asdf) (push #p"lispdir:systems;" asdf:*central-registry*) (push #p"sbcldir:systems;" asdf:*central-registry*) (push #p"coding:systems;" asdf:*central-registry*) (require 'asdf-install) (setf ASDF-INSTALL:*LOCATIONS* '((#p"coding:site;" #p"coding:systems;" "coding ASDF directory") (#p"lispdir:site;" #p"lispdir:systems;" "shared ASDF directory") (#p"sbcldir:site;" #p"sbcldir:systems;" "SBCL ASDF directory"))) -- zapp -- -- Max-Gerd Retzlaff <m.retzlaff(a)gmx.net> For your amusement: I will make you shorter by the head. -- Elizabeth I

2 2

[mcclim-devel] a new File Selector, patches for the CLIM-Listener, and a general problem with ACCEPT
by Max-Gerd Retzlaff 30 Aug '05

30 Aug '05

Hello, My File Selector is completed. The source code is attached. New versions will be available at http://bl0rg.net/~mgr/flux/file-selector.lisp You'll *have* to apply the also the following patch for the CLIM-Listener (attached and at http://bl0rg.net/~mgr/flux/CLIM-Listener.patch ). This patch mandatory as the File Selector will not work correctly without it. (More below.) Also you'll need a quite new CVS version of McCLIM. That is after 00:39:32 CEST of today... Screenshots: http://bl0rg.net/~mgr/flux/File-Selector-in-its-own-window-1.0.png and http://bl0rg.net/~mgr/flux/File-Selector-embedded-into-the-Clim-Listener-1.… (Note in the second screenshot that, although only "syntax" is specified as Filename, "syntax.fasl" is selected (i.e. will be returned if one clicks on OK). This is because "fasl" is the current Filetype and there is no file "syntax" (without the extension). I hope I've got other minor details right, as well.) Problem with ACCEPT: There is a general problem regarding ACCEPT and its parameter :DEFAULT. The clim 2.0 spec says in the section about ACCEPT-1: If default is supplied, then it and default-type are returned as values from accept-1 when the input is empty. In McCLIM there is currently no way to specify "" in an ACCEPT with :DEFAULT (that is non-equal to ""), as "" is considered to be "empty". (If you enter nothing or explicitely "" to a promt of an ACCEPT outside an ACCEPTING-VALUES the default value will be returned; inside an ACCEPTING-VALUES dialog a text-field will be displayed in which "" is normally not displayed, unnecessary to say that in that case the specified default is also returned.) Even worse, there is *no way* to distinguish between the cases that the user left the default untouched and he or she removed the content of the field completely. No third return value for that. Quite inconvenient! It would also be inconvenient to have to enter "" for the empty string. There is no keyword :ONLY-INSERT-DEFAULT. That would be the behaviour that I want: The default is only inserted into the field but whatever is there after the user edited the field will be the return value of the ACCEPT call, *untouched*. The clim 2.0 specification seems to supply no way to do this! As a workaround I can only think of a button "empty the field" right next to each accept text-field. I really hope I missed something. This means for the File Selector that you cannot empty a formerly speciefied Filename of Filetype again *by editing the text-field*. To empty those textfields just left-click on a directory for the Filename, and middle-click for the Filetype. The "Parent Directory" and the pathname in the title of the directory listing always work for this. It would be very nice if somebody had a closer look at CLIMI::HANDLE-EMPTY-INPUT, CLIMI::INVOKE-HANDLE-EMPTY-INPUT, and friends. More information on the patch to the CLIM-Listener I hope Andy Hefner likes the patch. It adds : - sort-by for filenames to COM-SHOW-DIRECTORY, - an icon and a cond-clause in ICON-OF for wild pathnames, - a wrapper for LIST-DIRECTORY (that NCONCs the subdirectories of the directory to the output of LIST-DIRECTORY if it is called with a wild pathname), - and does some minor changes to COM-SHOW-DIRECTORY. Also it removes the SB-POSIX LIST-DIRECTORY for SBCL as that one completely ignores the pathname-name and -type, which renders it quite useless for :wild searches (pune or play on words intended). Comments are welcome, of course. Hope you like it, Max -- Max-Gerd Retzlaff <m.retzlaff(a)gmx.net> For your amusement: Chance is perhaps the work of God when He did not want to sign. -- Anatole France

1 1

[mcclim-devel] Drawing xpm-icons to an accepting-values-steram
by Max-Gerd Retzlaff 29 Aug '05

29 Aug '05

Hello, This: (defun test (&key (stream *query-io*)) (accepting-values (stream) (clim-listener::draw-icon stream (clim-listener::icon-of #p"/non-existing")))) does not work. It only draws a black box in the size of the icon. Any ideas? Regards, Max -- Max-Gerd Retzlaff <m.retzlaff(a)gmx.net> For your amusement: The perversity of nature is nowhere better demonstrated by the fact that, when exposed to the same atmosphere, bread becomes hard while crackers become soft.

1 0

[mcclim-devel] with-output-as-gadget, again
by Max-Gerd Retzlaff 26 Aug '05

26 Aug '05

Hello, I've tried to get with-output-as-gadget working but I was not successful. The problem being that I have not understood recording and several further parts of CLIM, yet. In this mail I want to present my observation about the problem, in the hope that someone with more experience and knowledge might see a solution. I would really like to have it working for a file selector that I need for several projects. Christophe reported the problem already in July: http://common-lisp.net/pipermail/mcclim-devel/2005-July/004100.html You might want to read that mail first. Basically the panes of the whole gadget are only adopted to the stream's sheet (stream being the stream that is given as an argument to the call of WITH-OUTPUT-AS-GADGET) when the output-record of the sheet is replayed (or what is the right term?). The adoption happens via note-output-record-got-sheet method calls that are made when output-records about "parent/child-relationships" are processed; there is specialization on (record gadget-output-record) for that method, in which the adoption takes place. The problem is that the output methods of the clx-backend (window-clear-area (called from window-clear), medium-draw-text* (called from write-string), .. ) try to access the native-transformation (and later native-region) of the gadget's panes quite early, and that does not work if the panes are not yet adopted. Either the adoption has to happen earlier, or the clx output method have to be delayed via output-records as well. I suspect that the clx backend needs an general overhaul to make it be (more) "output-recording aware". But perhaps a single, deliberately inserted line would work a miracle.. Consider Christophe's example: (clim:with-output-as-gadget (*standard-output*) (clim:with-look-and-feel-realization ((clim:frame-manager clim:*application-frame*) clim:*application-frame*) (clim:labelling (:label "Hello") (clim:make-pane 'clim:text-field :activate-callback (lambda (g) (princ (clim:gadget-value g))))))) The flow to the error NO-APPLICABLE-METHOD on sheet-native-transformation when called with an argument of NIL is: In WITH-OUTPUT-AS-GADGET a instance of 'GADGET-OUTPUT-TYPE is created (with the evaluated body of the call as its :child argument). There is a initialize-instance :after method for instances of this class, in which ALLOCATE-SPACE for the child (the label-pane) is called. ALLOCATE-SPACE calls MOVE-SHEET for the first child of the label-pane (the text-field-pane). MOVE-SHEET SETFs the SHEET-TRANSFORMATION of the text-field-pane. There is a method (setf sheet-transformation) :after (transformation (sheet basic-sheet)). It calls (note-sheet-transformation-changed sheet), which calls UPDATE-MIRROR-GEOMETRY. Inside UPDATE-MIRROR-GEOMETRY (sheet-native-transformation (sheet-parent sheet)) is called, but as the sheet is not adopted yet, that gives nil and sheet-native-transformation is not defined for nil. => NO-APPLICABLE-METHOD on sheet-native-transformation when called with an argument of NIL It is quite the same for simpler examples where the WRITE-STRING is called with a pane of the gadget as output stream. There it is: WRITE-STRING -> %WRITE-STRING -> .. -> MEDIUM-DRAW-TEXT* -> (sheet-native-transformation (medium-sheet medium)) Inside sheet-native-transformation the same function is called again for the sheet-parent. As the sheet is not adopted yet, that gives nil and sheet-native-transformation is not defined for nil. Naively, I tried something like: (let ((my-stream (find-pane-named *application-frame* 'clim-listener::interactor))) (replay (STREAM-CURRENT-OUTPUT-RECORD my-stream) my-stream)) right after WITH-OUTPUT-AS-GADGET and before the WRITE-STRING, in the hope that this would force recorded adoption records to take place earlier. Is this completely wrong, should it have been replay-output-record instead? Well, it would only be an ugly workaround at it doesn't help against the problems with labelling and scrolling. I could confirm my assumption that the delayed adoption is the problem as with neatly placed calls to SHEET-ADOPT-CHILD and SHEET-DISOWN-CHILD I got my file-selector kind of running (only the first ACCEPTING-VALUES iteration draws correctly and there is no scrolling for the embedded pane: http://bl0rg.net/~mgr/flux/file-selector-dialog.png (In the end it should become a accept method for pathname presentations in gadget-dialog-view.) There are additional problem when the stream for WITH-OUTPUT-AS-GADGET is an ACCEPTING-VALUES-STREAM: When attempting to read the slot's value (slot-value), the slot CLIM-INTERNALS::HEIGHT is missing from the object #<CLIM-INTERNALS::ACCEPTING-VALUES-STREAM {92BF441}>. [Condition of type SIMPLE-ERROR] It would be especially nice to get this running as well.. Regards, Max -- Max-Gerd Retzlaff <m.retzlaff(a)gmx.net> For your amusement: I don't make the rules, Gil, I only play the game. -- Cash McCall

1 0

[mcclim-devel] Re: [mcclim-cvs] CVS update: mcclim/dialog.lisp
by Max-Gerd Retzlaff 26 Aug '05

26 Aug '05

Hello On Fri, Aug 26, 2005 at 01:50:21PM +0200, Paolo Amoroso wrote: > mretzlaff(a)common-lisp.net (Max-Gerd Retzlaff) writes: > > > Modified Files: > > dialog.lisp > > Log Message: > > (climi::frame-event-queue *application-frame*) as argument :INPUT-BUFFER > > to the call of OPEN-WINDOW-STREAM in WITH-STREAM-IN-OWN-WINDOW (was not > > specified previously). > > I still don't get separate windows in dialogs of town-example.lisp > that have :own-window t. The accepting-values dialogs still appear in > the interactor. I use the latest McCLIM CVS sources. Did you change the call TO ACCEPTING-VALUES in the macro ACCEPTING-VALUES-WITH-STYLE-AND-TITLE (and a recompile of the whole file)? ACCEPTING-VALUES-WITH-STYLE-AND-TITLE is only used for the *output* of the commands COM-SHOW-TOWN-INFO and COM-GET-DISTANCE. And that did not work for you? I just grabbed a fresh cvs checkout and it worked for me. If you want the accepting-values dialogs of the partial-command-parser (i.e. if you click in the menu on "Show Town Info" or "Get Distance") to appear in a new window, you have to change the :own-window argument of that call. It is burried in MAKE-PARTIAL-PARSER-FUN in mcclim/commands.lisp, try this patch: -- zipp -- --- commands.lisp_old 2005-08-26 15:06:27.370372680 +0200 +++ commands.lisp 2005-08-26 15:06:29.218091784 +0200 @@ -755,7 +755,7 @@ ,command-table :errorp nil)) ,@(mapcar #'list required-arg-names original-args)) - (accepting-values (,stream) + (accepting-values (,stream :own-window t) (format ,stream "You are being prompted for arguments to ~S~%~%" ,command-line-name) -- zapp -- There seems to be no simple way to just change the default for a single application frame. The right way seems to be to modify the application-frame's top-level with something like (:top-level (default-frame-top-level :partial-command-parser ..) in one's DEFINE-APPLICATION-FRAME. But that seems to be a lot of work as the default, COMMAND-LINE-READ-REMAINING-ARGUMENTS-FOR-PARTIAL-COMMAND, calls the partial-command-parsers that are created via mentioned MAKE-PARTIAL-PARSER-FUN when the commands of the application are defined (DEFINE-..-COMMAND -> DEFINE-COMMAND -> %DEFINE-COMMAND).. Bye, Max -- Max-Gerd Retzlaff <m.retzlaff(a)gmx.net> For your amusement: Scientists will study your brain to learn more about your distant cousin, Man.

2 2

[mcclim-devel] Re: [mcclim-cvs] CVS update: mcclim/dialog.lisp
by Andy Hefner 26 Aug '05

26 Aug '05

On 8/25/05, Max-Gerd Retzlaff <mretzlaff(a)common-lisp.net> wrote: > (Broken because OPEN-WINDOW-STREAM doesn't really work yet. I think > there has to be a (redisplay-frame-panes frame) or something like that > in its event-loop (that is the function STANDALONE-EVENT-LOOP).) Why do you think that?

3 4

[mcclim-devel] One char patch to presentation-defs
by David Murray 25 Aug '05

25 Aug '05

[resent to the correct address - I hope...] I was wondering why the :highlight option to :single-box wasn't working as I thought it should. Turns out there was a wee typo. Patch attached. JQS Index: presentation-defs.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/presentation-defs.lisp,v retrieving revision 1.44 diff -u -r1.44 presentation-defs.lisp --- presentation-defs.lisp 22 Jun 2005 09:49:15 -0000 1.44 +++ presentation-defs.lisp 25 Jul 2005 13:05:48 -0000 @@ -993,7 +993,7 @@ (multiple-value-bind (min-x min-y max-x max-y) (output-record-hit-detection-rectangle* record) (if (and (<= min-x x max-x) (<= min-y y max-y)) - (if (or (null single-box) (eq single-box :higlighting)) + (if (or (null single-box) (eq single-box :highlighting)) (funcall-presentation-generic-function presentation-refined-position-test (presentation-type record) record x y)

10 34