mcclim-devel September 2005

mcclim-devel@common-lisp.net

11 participants
17 discussions

[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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

mcclim-devel September 2005