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

[mcclim-devel] Re: [climacs-devel] Small patch to commands.lisp
by Christophe Rhodes 07 Sep '05

07 Sep '05

John Q Splittist <splittist(a)yahoo.com> writes: > Attached is a small patch I needed to make mapping over > commands/keystrokes work correctly. Aha, a victim! I wonder if it would be possible to add a test case for the failure you've seen in the Tests/ directory? Not that they're run automatically as yet, but it's a good way both to document the previous problem and to ensure that it doesn't recur... Cheers, Christophe

1 0

[mcclim-devel] Displayed Output Records Proposal
by Gilbert Baumann 03 Sep '05

03 Sep '05

Hi there, i am working on a Cairo[1] backend for mcclim. While doing so i noticed two issues with the current implementation of displayed-output-records: a) displayed-output-records want to store transformed graphics. It however is not always possible to fully transform a graphics request. This most notably is the case with DRAW-TEXT* while :transform-glyphs is non-NIL. Also line styles are hard to transform. I recognize that that storing transformed graphics request seems easier from the perspective of the CLX backend, since CLX itself can't do transformations; so you need to transform the graphics request anyway before hitting the backend. This however looks different from the perspective of the Cairo backend (and also of the PS backend and a possible OpenGL), as these graphics systems can perfectly well transform graphics requests. [In case of OpenGL they perhaps can do this even faster than we will ever be due to HW acceleration]. b) the bounding boxes are not always quite correct. Which I believe is because of anti-aliasing, since some pixels at the border of a shape spill over. PROPOSAL I propose that we open an opportunity for the backend to implement its own output recording classes. Which would have the following benefits: - bounding boxes are likely to be correct (E.g. the Cairo backend can tell me the bounding box of graphics requests). - the backend can decide if it is more economic to store transformed or untransformed coordinates. - the backend perhaps has a faster way to capture, save and restore the drawing options of a medium than we can have sticking to the medium protocol. - the backend can decide on the representation of the graphics request. E.g. it might want to save the fully tessellated representation of a shape, it might want to keep references to rasterizied ink in case of drawing with patterns, it might construct display lists. etc. PROTOCOL We could specify MEDIUM-RECORD-xyz* methods to complement MEDIUM-DRAW-xyz, like this: MEDIUM-RECORD-LINE* medium x1 y1 x2 y2 drawp recordp [Generic Function] If /drawp/ is non-NIL, behave as MEDIUM-DRAW-LINE*. If /recordp/ is non-NIL, return a displayed output record which, when replayed has the effect or MEDIUM-DRAW-LINE* with the given arguments and the current drawing options installed in /medium/. Since some work to be done on recording and drawing perhaps is similar, i chose to go with this combined record and/or draw protocol function. We could specify that an implementation of MEDIUM-RECORD-LINE* for a medium is optional and that a default implementation is provided by CLIM. So the implementation of MEDIUM-DRAW-LINE* on output recording streams would look like this: (defmethod medium-draw-line* ((stream output-record-stream) x1 y1 x2 y2) (let ((record (medium-record-line* stream x1 y1 x2 y2 (stream-drawing-p stream) (stream-recording-p stream)))) (when (stream-recording-p stream) (stream-add-output-record stream record)))) Before heading to implement this, i wanted to gather some comments on this. -- Gilbert Baumann [1] for those that are not familiar with Cairo: It is a graphics API which somewhat resembles Postscript; based on fills and strokes. Additionally an alpha channel is supported and so it does anti-aliasing. Also every graphics request is transformed by an affine transformation. See <URL:http://cairographics.org/introduction>

2 1

[mcclim-devel] multithreaded SBCL and mcclim
by Friedrich Dominicus 03 Sep '05

03 Sep '05

May I ask if there are any known issues about this combination on a 64-bit processor? I'm wondering because everything gets compiled find but while starting an mcclim applicatoin nothing happens. Well in fact a thread start but not output can be seen have I overread something in the manual? Regards Friedrich

2 1

[mcclim-devel] [patch] with-output-to-pixmap without sizes given
by Rudi Schlatte 02 Sep '05

02 Sep '05

Hi, I hacked with-output-to-pixmap so :width and :height need not be given. I'm generally confused about various aspects of [Mc]CLIM, but the following code (adapted from Franz's CLIM manual) was observed to paint a something at mouse click position, so it might just work. Patch is attached. (define-test-command (test-pixmaps :menu t) () (let* ((stream (get-frame-pane *application-frame* 'display)) (medium (clim:sheet-medium stream))) (let ((pixmap (clim:with-output-to-pixmap (mv stream) (with-drawing-options (mv :ink +red+) (clim:draw-circle* mv 50 50 20 :filled t) (clim:draw-rectangle* mv 0 0 90 90 :filled nil))))) (multiple-value-bind (x y) (block get-position (clim:tracking-pointer (stream) (:pointer-button-press (x y) (return-from get-position (values x y))))) (clim:copy-from-pixmap pixmap 0 0 (clim:pixmap-width pixmap) (clim:pixmap-height pixmap) medium x y))))) Cheers, Rudi

1 0

[mcclim-devel] abort-gesture, again
by Christophe Rhodes 02 Sep '05

02 Sep '05

Hi, Regarding the following patch, of August 25th: Modified Files: presentation-defs.lisp Log Message: This patch HANDLER-BINDs the ABORT-GESTURE condition to #'abort for the function ACCEPT in presentation-defs.lisp. I believe this has had the side effect of making C-g in climacs, while in the process of typing an extended command (e.g. com-find-file, started by C-x C-f) abort the entire application rather than just the command input -- as the ESA-TOP-LEVEL does not provide an ABORT restart -- instead, it tries to handle abort-gesture itself, but the control is never passed to that handler because the inner handler in ACCEPT unconditionally handles the gesture. What was the intent of all of this? How is it meant to behave? Cheers, Christophe

2 1

[mcclim-devel] ideas on presentation methods for pathnames (was: [climacs-devel] Re: a patch for climacs (mainly regarding COMPLETABLY-PATHNAME) + a gimmick)
by Max-Gerd Retzlaff 02 Sep '05

02 Sep '05

Hello, this thread actually started on climacs-devel. As the discussion has become more McCLIM than Climacs specific (at least in this sub-thread), I'll send this answer to mcclim-devel. If you're not subscribed to climacs-devel, refer to the following links for the context: http://article.gmane.org/gmane.lisp.climacs.devel/275 http://article.gmane.org/gmane.lisp.climacs.devel/276 On Thu, Sep 01, 2005 at 09:16:17PM +0200, Robert Strandh wrote: > Max-Gerd Retzlaff writes: > > I propose that COM-SHOW-DIRECTORY should become a general PRESENT method > > for a presentation LIST OF PATHNAMES, as well as the construct > > > > (let ((icon (clim-listener::icon-of pathname))) > > (when icon > > (clim-listener::draw-icon stream icon :extra-spacing 30))) > > (princ (clim-listener::pathname-printing-name pathname long-name) stream)) > > > > should be CLIM's general PRESENT method for PATHNAME in TEXTUAL-DIALOG-VIEW. > > (The latter is already defined in file-selector.lisp.) > > This code has a problem (aside from the very unfortunate indentation), Sorry, I had copied it from the Emacs on my other machine via the mouse and the other Emacs didn't know about proper Lisp indentation, as it was in the Fundamental mode. > [This code has a problem ] namely that it assumes that the listener > is present. At the moment, I do not think that is a good idea. > > This is going to be a general problem for other applications as well. > We are often going to want code that means "if this package exists and > this symbol has a function definition in that package, then call the > function with the following arguments" . Perhaps a macro > FUNCALL-IN-PACKAGE like this: > > (funcall-in-package :clim-listener (#:icon-of pathname) > (message "sorry...")) I don't think that this is a good idea. We have ASDF to load all required packages. Already we have to insert #-/#+ constructs to do things that depend on implementation features. We shouldn't do the equivalent for packages. And regarding COM-SHOW-DIRECTORY (as PRESENT LIST-OF-PATHNAMES, or something like that), ICON-OF, DRAW-ICON, etc.: I think they should become part of McCLIM together with the FILE-SELECTOR and ACCEPT and PRESENT methods for the GADGET-VIEW class or subclasses thereof. Perhaps in the files mcclim/gadget-pathname.lisp and gadget-pathname-utilities.lisp; at least as an extension of McCLIM. ICON-OF, DRAW-ICON and so on should only be used in the presentation methods (or in functions that are only called from these methods). That is the actual applications only call PRESENT and ACCEPT directly. And if the extension of the "nicer" pathname presentation methods (if it will be an extension) is not loaded, the current (more general) presentation methods will be used. No problem there. (That could even work for the PRESENT LIST-OF-PATHNAMES method, if it will be implemented as proposed and if it will be included in the file presentation-defs.lisp (and not in the assumed extension package), as it would also use the current general presentation methods, if the extension package is not loaded.) But I really think that an extension package is the wrong thing, as the specification defines a PATHNAME presentation type and also the standard views. I couldn't find it stated but the spec surely arranges for presentations methods for the standard presentation types and views. Dialog.lisp actually states: ;;; Hack until more views / dialog gadgets are defined. Moving the presentation methods from the Clim-Listener to McCLIM (or an extension of it) is a good idea in my opinion, as these methods are right now not only used by the Listener itself anymore but also by the file-selector, and you can surely think of other application that could make use of more intuitive and simply nicer presentation methods for the GADGET-VIEW class and/or subclasses of it. For example the file-manger and the Dired-like application that John Splittist has suggested. Hm, I think I'll accept the challenge and try to write a simple file-manager. Once there are the presentation methods it shouldn't be really that hard thanks to CLIM: Two panes (perhaps based on ESA) for directory listings (PRESENT LIST-OF-PATHNAMES), some presentation-to-command translators, some accepting-values dialogs (for renaming, etc), some drag and drop translators.. And you have it. --- Of course, it will nevertheless take quite some time as the supposedly simple things are always much harder to achieve than expected. :) At least the result will likely be not very long. Well, just let me some time and I'll try to reorganise the existing methods and write the proposed ones. And if they are indeed as nice as I hope we can think about including them into McCLIM, then. (Be prepared that it'll take some weeks as I have not much time during the next weeks. But I don't think that's a problem. Perhaps it's not to bad to think about it for some time.) Ah, actually I just noted that there is the sequence presentation type with one parameter "type": "The [presentation] type that represents a sequence of elements of type type. So "my" LIST-OF-PATHNAMES presentation type will just be the type SEQUENCE (of) PATHNAME. Very nice. Regards, Max -- Max-Gerd Retzlaff <m.retzlaff(a)gmx.net> For your amusement: Make it idiot-proof, and someone will breed a better idiot. -- Oliver Elphick

1 1

[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