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

[mcclim-devel] CVS commit problems
by Rudi Schlatte 09 Sep '05

09 Sep '05

Hello, I can checkout mcclim via -d:ext:rschlatte@... but trying to commit gives the following message: cvs [server aborted]: could not open lock file `/project/mcclim/ cvsroot/mcclim/,graphics.lisp,': Permission denied Does anyone know of a fix? Many thanks, Rudi

1 0

[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