September 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] Re: [climacs-devel] Small patch to commands.lisp
by Christophe Rhodes 30 Sep '05

30 Sep '05

John Q Splittist <splittist(a)yahoo.com> writes: > Christophe Rhodes wrote: > >> I wonder if it would be possible to add a test case for the failure >> you've seen in the Tests/ directory? > > I'm not sure whether this fits the bill, but here is an attempt. > Corrections, suggestions etc. welcome. I guess three weeks is an adequate timescale for corrections and suggestions for a one-line patch with tests, so I've merged your patch and test file (adding a completely untested extra test). Thanks. Cheers, Christophe

1 0

[mcclim-devel] mcclim + sbcl
by Irene DURAND 29 Sep '05

29 Sep '05

Hello, Back in Bordeaux after one year in Germany I am trying to setup things here. Formerly I used CMUCL but Robert Strandh told me that I should use rather SBCL. So I would like to have sbcl + mcclim + slime. I have read that there are problems with certain combinations of versions. So my question is which combination of version number should work. Right now I have SBCL 0.9.5 with CLX clx_0.7.1 and the latest version of MCCLIM and I fail compiling MCCLIM. I plan to use MCCLIM with my students and I am desesperate to have something running. Can anyone help me? -- Irène DURAND http://dept-info.labri.u-bordeaux.fr/~idurand This is SBCL 0.9.5, 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. * (require 'asdf) ("ASDF") * (require 'clx) ; loading system definition from ; /usr/labri/idurand/Common-Lisp/sbcl/lib/sbcl/systems/sb-bsd-sockets.asd into ; #<PACKAGE "ASDF3917"> ; registering #<SYSTEM SB-BSD-SOCKETS {97490B1}> as SB-BSD-SOCKETS ; registering #<SYSTEM SB-BSD-SOCKETS-TESTS {9B638A9}> as SB-BSD-SOCKETS-TESTS ("SB-GROVEL" "SB-BSD-SOCKETS") * (load "/usr/labri/idurand/Common-Lisp/mcclim/system.lisp") ; in: LAMBDA NIL ; (OR "Lisp-Dep/mp-nil") ; ==> ; "Lisp-Dep/mp-nil" ; ; note: deleting unreachable code ; ; compilation unit finished ; printed 1 note debugger invoked on a ASDF:DUPLICATE-NAMES in thread #<THREAD "initial thread" {90033C9}>: Condition ASDF:DUPLICATE-NAMES was signalled. Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level. (ASDF::PARSE-COMPONENT-FORM NIL (:MODULE "scigraph" :PATHNAME #P"/usr/labri/idurand/Common-Lisp/mcclim/" :DEPENDS-ON (:CLIM :CLIM-LOOKS) :SERIAL T :COMPONENTS ((:FILE "package" :PATHNAME #P"/usr/labri/idurand/Common-Lisp/mcclim/Apps/Scigraph/dwim/package.lisp") (:FILE "feature-case" :PATHNAME #P"/usr/labri/idurand/Common-Lisp/mcclim/Apps/Scigraph/dwim/feature-case.lisp") (:FILE "macros" :PATHNAME #P"/usr/labri/idurand/Common-Lisp/mcclim/Apps/Scigraph/dwim/macros.lisp") (:FILE "tv" :PATHNAME #P"/usr/labri/idurand/Common-Lisp/mcclim/Apps/Scigraph/dwim/tv.lisp") (:FILE "draw" :PATHNAME #P"/usr/labri/idurand/Common-Lisp/mcclim/Apps/Scigraph/dwim/draw.lisp") (:FILE "present" :PATHNAME #P"/usr/labri/idurand/Common-Lisp/mcclim/Apps/Scigraph/dwim/present.lisp") (:FILE "extensions" :PATHNAME #P"/usr/labri/idurand/Common-Lisp/mcclim/Apps/Scigraph/dwim/extensions.lisp") (:FILE "wholine" :PATHNAME #P"/usr/labri/idurand/Common-Lisp/mcclim/Apps/Scigraph/dwim/wholine.lisp") (:FILE "export" :PATHNAME #P"/usr/labri/idurand/Common-Lisp/mcclim/Apps/Scigraph/dwim/export.lisp") (:FILE "package" :PATHNAME #P"/usr/labri/idurand/Common-Lisp/mcclim/Apps/Scigraph/scigraph/package.lisp") (:FILE "copy" :PATHNAME #P"/usr/labri/idurand/Common-Lisp/mcclim/Apps/Scigraph/scigraph/copy.lisp") (:FILE "dump" :PATHNAME #P"/usr/labri/idurand/Common-Lisp/mcclim/Apps/Scigraph/scigraph/dump.lisp") ...))) 0]

2 1

[mcclim-devel] [PATCH] hollow cursors for unfocused text-fields
by Rudi Schlatte 24 Sep '05

24 Sep '05

Hi, Another one I'm not quite sure of ... displaying of hollow/filled cursor upon mouse enter/exit seems to work ok, and it's nice to see where a keystroke will end up ... The only drawback is that the user can't change cursor visibility in :armed-callback / :disarmed- callback functions. Nevertheless, I think I'll check this in after a few days if there are no objections. Cheers, Rudi Index: gadgets.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/gadgets.lisp,v retrieving revision 1.90 diff -u -r1.90 gadgets.lisp --- gadgets.lisp 23 May 2005 12:43:34 -0000 1.90 +++ gadgets.lisp 24 Sep 2005 14:27:03 -0000 @@ -2642,6 +2642,33 @@ (setf (port-keyboard-input-focus port) (previous-focus gadget)) (setf (previous-focus gadget) nil))) + +;;; also, hack the full/hollow cursor displaying -- don't leave +;;; artifacts when the value of the gadget is called during arm/disarm +;;; events (otherwise, a hollow cursor is "erased" with a full one and +;;; vice versa). +;;; BUG (rudi 2005-09-24): this code overwrites changes to cursor +;;; visibility within a user-supplied armed-callback / +;;; disarmed-callback, though ... + +(defmethod handle-event :around ((pane text-field-pane) + (event pointer-enter-event)) + (let* ((area (area pane)) + (cursor-p (cursor-visibility area))) + (when cursor-p (setf (cursor-visibility area) nil)) + (call-next-method) + (when (and cursor-p (not (cursor-visibility area))) + (setf (cursor-visibility area) cursor-p)))) + +(defmethod handle-event :around ((pane text-field-pane) + (event pointer-exit-event)) + (let* ((area (area pane)) + (cursor-p (cursor-visibility area))) + (when cursor-p (setf (cursor-visibility area) nil)) + (call-next-method) + (when (and cursor-p (not (cursor-visibility area))) + (setf (cursor-visibility area) cursor-p)))) + (defmethod handle-event ((gadget text-field-pane) (event key-press- event)) (let ((gesture (convert-to-gesture event)) (*activation-gestures* (activation-gestures gadget))) Index: stream-output.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/stream-output.lisp,v retrieving revision 1.56 diff -u -r1.56 stream-output.lisp --- stream-output.lisp 13 Aug 2005 14:28:20 -0000 1.56 +++ stream-output.lisp 24 Sep 2005 14:27:07 -0000 @@ -142,7 +142,7 @@ (draw-rectangle* (sheet-medium (cursor-sheet cursor)) x y (+ x width) (+ y height) - :filled t + :filled (slot-value (cursor-sheet cursor) 'armed) :ink +flipping-ink+))))) (defmethod display-cursor ((cursor cursor-mixin) state) @@ -154,7 +154,7 @@ (:draw (draw-rectangle* (sheet-medium (cursor-sheet cursor)) x y (+ x width) (+ y height) - :filled t + :filled (slot-value (cursor-sheet cursor) 'armed) :ink +foreground-ink+ )) (:erase @@ -168,7 +168,7 @@ (draw-rectangle* (sheet-medium (cursor-sheet cursor)) x y (+ x width) (+ y height) - :filled t + :filled (slot-value (cursor-sheet cursor) 'armed) :ink +background-ink+)))))) ;;; Standard-Text-Cursor class

1 0

[mcclim-devel] [PATCH] Space layout calculation: make user-supplied options take precedence
by Rudi Schlatte 24 Sep '05

24 Sep '05

Hello, I noticed that a text-field created with an explicit :width option nevertheless had a width calculated from its initial contents. Fixed by the attached patch, which also introduces a fast path for the common case of no user-supplied options. There's still work to be done in the layout code, e.g. the following code creates a frame 100px wide (I'd expect 500): (define-application-frame textedit-frame () () (:panes (edit :text-field :value "edit" :width 500)) (:layouts (:default (vertically (:min-width 1 :width 100 :max-width +fill+) edit)))) Nevertheless, it's better than what's there currently, so I'll commit it shortly if there are no objections. Cheers, Rudi Index: panes.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/panes.lisp,v retrieving revision 1.155 diff -u -r1.155 panes.lisp --- panes.lisp 29 Aug 2005 22:39:31 -0000 1.155 +++ panes.lisp 24 Sep 2005 12:37:08 -0000 @@ -538,63 +538,48 @@ (defun merge-one-option (pane foo user-foo user-min-foo user-max-foo min-foo max-foo) - + ;; Some of the hair in the code below is because the user-supplied + ;; values need not be given in device units - ;; NOTE: The defaulting for :min-foo and :max-foo is different from MAKE-SPACE-REQUIREMENT. - ;; MAKE-SPACE-REQUIREMENT has kind of &key foo (min-foo 0) (max-foo +fill+) - ;; While user space requirements has &key foo (min-foo foo) (max-foo foo). - ;; I as a user would pretty much expect the same behavior, therefore I'll take the - ;; following route: - ;; When the :foo option is given, I'll let MAKE-SPACE- REQUIREMENT decide. - ;; - ;; old code: - ;; - ;; ;; Then we resolve defaulting. sec 29.3.1 says: - ;; ;; | If either of the :max-width or :min-width options is not - ;; ;; | supplied, it defaults to the value of the :width option. If - ;; ;; | either of the :max-height or :min-height options is not - ;; ;; | supplied, it defaults to the value of the :height option. - ;; (setf user-max-foo (or user-max-foo user-foo) - ;; user-min-foo (or user-min-foo user-foo)) - ;; --GB 2003-01-23 + (cond + ((not (or user-min-foo user-max-foo user-foo)) + ;; fast path + (values foo min-foo max-foo)) + (t + ;; sec 29.3.1 says: + ;; | If either of the :max-width or :min-width options is not + ;; | supplied, it defaults to the value of the :width option. If + ;; | either of the :max-height or :min-height options is not + ;; | supplied, it defaults to the value of the :height option. + (setf user-min-foo (or user-min-foo user-foo min-foo) + user-max-foo (or user-max-foo user-foo max-foo)) - (when (and (null user-max-foo) (not (null user-foo))) - (setf user-max-foo (space-requirement-max-width - (make-space-requirement - :width (spacing-value-to-device-units pane foo))))) - (when (and (null user-min-foo) (not (null user-foo))) - (setf user-min-foo (space-requirement-min-width - (make-space-requirement - :width (spacing-value-to-device-units pane foo))))) - - ;; when the user has no idea about the preferred size just take the - ;; panes preferred size. - (setf user-foo (or user-foo foo)) - (setf user-foo (spacing-value-to-device-units pane user-foo)) + ;; when the user has no idea about the preferred size just take + ;; the panes preferred size. + (setf user-foo (or user-foo foo)) + (setf user-foo (spacing-value-to-device-units pane user-foo)) - ;; dito for min/max - (setf user-min-foo (or user-min-foo min-foo) - user-max-foo (or user-max-foo max-foo)) - - ;; | :max-width, :min-width, :max-height, and :min-height can - ;; | also be specified as a relative size by supplying a list of - ;; | the form (number :relative). In this case, the number - ;; | indicates the number of device units that the pane is - ;; | willing to stretch or shrink. - (labels ((resolve-relative (dimension sign base) - (if (and (consp dimension) (eq (car dimension) :relative)) - (+ base (* sign (cadr dimension))) - (spacing-value-to-device-units pane dimension)))) - (setf user-min-foo (and user-min-foo - (resolve-relative user-min-foo -1 user-foo)) - user-max-foo (and user-max-foo - (resolve-relative user-max-foo +1 user-foo)))) - - ;; Now we have two space requirements which need to be 'merged'. - (setf min-foo (clamp user-min-foo min-foo max-foo) - max-foo (clamp user-max-foo min-foo max-foo) - foo (clamp user-foo min-foo max-foo)) - (values foo min-foo max-foo)) + ;; | :max-width, :min-width, :max-height, and :min-height can + ;; | also be specified as a relative size by supplying a list of + ;; | the form (number :relative). In this case, the number + ;; | indicates the number of device units that the pane is + ;; | willing to stretch or shrink. + (labels ((resolve-relative (dimension sign base) + (if (and (consp dimension) (eq (car dimension) :relative)) + (+ base (* sign (cadr dimension))) + (spacing-value-to-device-units pane dimension)))) + (setf user-min-foo (resolve-relative user-min-foo -1 user-foo) + user-max-foo (resolve-relative user-max-foo +1 user- foo))) + + ;; again, user options take precedence + (setf min-foo (min min-foo user-min-foo) + max-foo (max max-foo user-max-foo)) + + ;; Now we have two space requirements which need to be 'merged'. + (setf min-foo (clamp user-min-foo min-foo max-foo) + max-foo (clamp user-max-foo min-foo max-foo) + foo (clamp user-foo min-foo max-foo)) + (values foo min-foo max-foo)))) (defmethod merge-user-specified-options ((pane space-requirement- options-mixin) sr)

1 0

[mcclim-devel] trivial fix for line-style-equalp
by Christophe Rhodes 20 Sep '05

20 Sep '05

Hi, There's a cut-and-pasteo in line-style-equalp, which the attached patch fixes. Could someone with a non-mutant mcclim tree please apply it? (my medium.lisp contains a completely broken text-style refactoring, which I don't think it would be wise to inflict on the world). Index: medium.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/medium.lisp,v retrieving revision 1.54 diff -u -F^( -r1.54 medium.lisp --- medium.lisp 24 Jan 2005 23:03:41 -0000 1.54 +++ medium.lisp 20 Sep 2005 16:07:00 -0000 @@ -585,7 +597,7 @@ (defmethod line-style-equalp ((style1 st (eql (line-style-thickness style1) (line-style-thickness style2)) (eql (line-style-joint-shape style1) (line-style-joint-shape style2)) (eql (line-style-cap-shape style1) (line-style-cap-shape style2)) - (eql (line-style-thickness style1) (line-style-thickness style2)))) + (eql (line-style-dashes style1) (line-style-dashes style2)))) ;;; Misc ops Cheers, Christophe

1 0

[mcclim-devel] file-selector problem
by rpgoldman＠real-time.com 18 Sep '05

18 Sep '05

[SELECT-FILE crashes under ACL if called with no arguments.] OK, seems like one problem for me is that the file-selector is not happy when given a pathname argument (or a default) that has no :name component. In that case it crashes (at least for me). I haven't identified why. So (select-file) crashes but (select-file :pathname (parse-namestring "/home/rpg/lisp/mcclim/file-selector.lisp")) is fine.[1] Here are my *default-pathname-defaults*: CL-USER(11): *default-pathname-defaults* #p"/home/rpg/lisp/mcclim/" CL-USER(12): (describe *) #p"/home/rpg/lisp/mcclim/" is a structure of type PATHNAME. It has these slots: HOST NIL DEVICE :UNSPECIFIC DIRECTORY (:ABSOLUTE "home" "rpg" "lisp" "mcclim") NAME NIL TYPE NIL VERSION :UNSPECIFIC NAMESTRING "/home/rpg/lisp/mcclim/" HASH NIL DIR-NAMESTRING "/home/rpg/lisp/mcclim/" PLIST NIL ... I don't know if these are odd... gen-wild-pathname gives the following: CL-USER(13): (clim-listener::gen-wild-pathname *default-pathname-defaults*) #p"/home/rpg/lisp/mcclim/*.*" CL-USER(14): (describe (clim-listener::gen-wild-pathname *default-pathname-defaults*)) #p"/home/rpg/lisp/mcclim/*.*" is a structure of type PATHNAME. It has these slots: HOST NIL DEVICE :UNSPECIFIC DIRECTORY (:ABSOLUTE "home" "rpg" "lisp" "mcclim") NAME :WILD TYPE :WILD VERSION :UNSPECIFIC NAMESTRING NIL HASH NIL DIR-NAMESTRING NIL PLIST NIL Aha! If I change the default pathname argument to be the following: (pathname (clim-listener::gen-wild-pathname *default-pathname-defaults*)) instead of just *default-pathname-defaults*, that seems to fix things by changind NIL to :WILD for NAME. A couple of remaning problems: 1. running select-file makes the size of the clim-listener window go crazy. First, it shrinks to fit only the accepting-values (I'm not sure I have the right term here), and leaves the directory listing pane out of the window. Then, after I select a file, it leaves only the 2. Unless I press return after entering a string in the filename textbox, that input is simply discarded when I press Exit for the file-selector as a whole. This is probably McCLIM's fault as a whole, rather than yours, right? But it's quite annoying. The user has the right to expect that what's on the screen is what is going to be accepted. Adding an extra requirement for a "Simon Says" gesture [2] is really a Bad Thing. Footnotes: [1] Ouch! I wish I could cut and paste out of the clim-listener! :-/ [2] This is an American (poss British, too?) children's game, where one player tries to trick the other into doing an action without explicit permission being given.

4 4

[mcclim-devel] arglist, tester-arglist, and doc-arglist for presentation translators
by Max-Gerd Retzlaff 16 Sep '05

16 Sep '05

Hello, please have a look at 23.7.1 of the CLIM 2.0 specification. In the section about DEFINE-PRESENTATION-TRANSLATOR it says: "arglist, tester-arglist, and doc-arglist are each an argument list that must "match" the following "canonical" argument list. (object &key presentation context-type frame event window x y) In order to "match" the canonical argument list, there must be a single positional argument that corresponds to the presentation's object, and several named arguments that must match the canonical names above (using string-equal to do the comparison)." They are defined in the same way for DEFINE-PRESENTATION-TO-COMMAND-TRANSLATOR, DEFINE-PRESENTATION-ACTION, and DEFINE-DRAG-AND-DROP-TRANSLATOR, with the only exception that the doc-arglist "includes a named (keyword) stream argument as well". If my interpretation is correct, you have not only to use theses names *literally* (because of the STRING-EQUAL requirement), but also the empty list is not allowed and the first argument is always required and has to be (STRING-EQUAL to) OBJECT. I added an ASSERT to beginning of CLIMI::MAKE-TRANSLATOR-LL because I've made the error earlier to try to bind the object to a symbol non-equal to OBJECT, and I've seen that there are presentation translators in beirc that just try to bind PRESENTATION. The ASSERT is: (assert (string-equal (car translator-args) "object") () "The first parameter of the presentation translator's argument list~%has to be STRING-EQUAL to OBJECT. (See 23.7.1)") Well, afterwards McCLIM doesn't compile anymore. There are two presentation to command translators in dialog.lisp: COM-EXIT-BUTTON and COM-ABORT-BUTTON. After I allowed also the empty arglist it still did not compile because (at least) the presentation to command translator COM-DESCRIBE-PRESENTATION-TRANSLATOR has the list (presentation) as its arglist as well as its tester-arglist. Personally I think the requirement that the arglists have always to be at least the list (object) (if I interpret the spec correctly) is quite odd. There are perfectly reasonable cases to have an empty list: E.g. COM-EXIT-BUTTON doesn't need the object itself. And likewise COM-DESCRIBE-PRESENTATION-TRANSLATOR doesn't need the object but only the presentation. Why should OBJECT be bound if it isn't used at all? The way DEFINE-PRESENTATION-TRANSLATOR and its friends are specified you cannot insert a DECLARE IGNORE (or IGNORABLE), and that means you would always get style warnings on SBCL in these cases. The "canonical" argument list should be the following in my opinion: (&key object presentation context-type frame event window x y) And also the empty list should be considered to match it. What do you think? Should we just CLIMI::MAKE-TRANSLATOR-LL leave as it is, and add this to a list of known but wanted nonconformances to the CLIM specification? Bye, Max -- Max-Gerd Retzlaff <m.retzlaff(a)gmx.net> For your amusement: People who claim they don't let little things bother them have never slept in a room with a single mosquito.

3 3

[mcclim-devel] Re: [clo-devel] CVS commit problems
by Rudi Schlatte 10 Sep '05

10 Sep '05

On 9. Sep 2005, at 17:08, Marco Baringer wrote: > i know who you are, but you can still get a mcclim commiter to send me > an email requesting write privs to mcclim? > > p.s. - this may be one of those things which were lost in the june > debian-update mess. did you ever have commit access? I hadn't committed anything to date, but rstrandh said in private mail that he remembers sneakily adding me as a mcclim developer, perhaps during the move to common-lisp.net. Robert, can you confirm? Cheers, Rudi

2 1

[mcclim-devel] calling display function on resize
by Thibault Langlois 09 Sep '05

09 Sep '05

Hello, Does anybody knows how to call a application pane's display-function when the user resizes the window with the mouse ? I have found some old messages on a clim-list about this subject but it does not seem to work with McCLIM. http://openmap.bbn.com/hypermail/clim/0323.html There must be a way. Thanks. Thibault

1 0

[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