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

[mcclim-devel] (statusp cocoa-port)
by James Crippen 23 Oct '05

23 Oct '05

What's the current status on the Cocoa backend for McCLIM? I have an all Mac environment now, and I'd like to hack on Climacs a bit. But I'd rather have it running in Cocoa than in X. Is the Cocoa port working, for some suitable value of working? Or is it basically dead? If the latter, what needs to be done to ressurect it? Thanks, James

5 6

[mcclim-devel] Resizing windows
by David Lewis 21 Oct '05

21 Oct '05

Hi, Working with Christophe Rhodes on a lute tablature editor under Climacs, I'm using one basic climacs window and a graphical window created with open-window-stream: http://common-lisp.net/project/climacs/tabcode.png Because of the need to resize the graphical display as the text changes, I've put an allocate-space command into our redisplay routine. That seems to work, but resizing the window manually (with the mouse) seems to resize the stream rather than (as I expected it to) the viewport. Is that expected behaviour? Should I be approaching the problem differently? Thanks, David Lewis P.S. A side issue to this is that the scroll-bars seem not to refresh automatically. Should I be running a command to do that or is this a bug/feature?

1 0

[mcclim-devel] a patch for mcclim/Lisp-Dep/mp-acl.lisp
by Max-Gerd Retzlaff 13 Oct '05

13 Oct '05

Hello, what do you think about this patch for mcclim/Lisp-Dep/mp-acl.lisp? Index: mp-acl.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/Lisp-Dep/mp-acl.lisp,v retrieving revision 1.5 diff -a -u -r1.5 mp-acl.lisp --- mp-acl.lisp 10 Mar 2004 12:03:45 -0000 1.5 +++ mp-acl.lisp 13 Oct 2005 15:25:07 -0000 @@ -30,8 +30,24 @@ (eval-when (:load-toplevel :compile-toplevel :execute) (pushnew :clim-mp *features*)) +#+nil (defun make-process (function &key name) (mp:process-run-function name function)) + +;; In ACL each process has its own dynamic enviroment, +;; therefore a special binding doesn't affect the global binding of +;; the variable and the new process doesn't see that special binding. +;; In other words: +;; (let ((*debugger-hook* #'clim-debugger:debugger)) +;; (clim-listener::run-listener :new-process t)) +;; does not work, if *debugger-hook* is not explicitly bound to +;; the current special binding for the new process. +;; mgr, 20050706 +(defun make-process (function &key name) + (mp:process-run-function `(:name ,name + :initial-bindings ((*debugger-hook* . ,*debugger-hook*) + ,@excl:*cl-default-special-bindings*)) + function)) (defun destroy-process (process) (mp:process-kill process)) Regards, Max -- Max-Gerd Retzlaff <m.retzlaff(a)gmx.net> For your amusement: You're currently going through a difficult transition period called "Life."

1 0

[mcclim-devel] Is anyone using McCLIM with :unicode on *features*?
by Andreas Fuchs 09 Oct '05

09 Oct '05

Hi all, short story: I wonder if anyone is using McCLIM on CLX with the :unicode feature. Please test with: (cl:member :unicode cl:*features*) and report non-NIL results to this list. Thank you! long story: while trying to refactor the CLX backend's medium implementation, I found a lot of #+unicode statements in Backends/CLX/medium.lisp. From the comments, it looks like they shouldn't even be there: ; Yes, the following is a nasty hack. ; It's just a proof of concept, I'll try not to commit it :] ; If it does get committed, it shouldn't affect anyone much... These definitions don't *seem* to me like they are used by anyone, so I'd like to nuke them in favour of definitions that have a chance of working with mcclim-freetype's idea of text-style properties without requiring an ugly hack (like the method redefinitions that mcclim-freetype currently employs). So, again, please test if you're using McCLIM with the feature :unicode. Run (cl:member :unicode cl:*features*) and report non-NIL results to this list. I may be breaking your McCLIM soon, and we don't want that to happen without a good reason (-: Thanks, -- Andreas Fuchs, <asf(a)boinkor.net>, asf(a)jabber.at, antifuchs

2 1

[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