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

[mcclim-devel] mcclim-0.9.1:system.lisp
by Mike McDonald 19 Aug '05

19 Aug '05

Something looks a bit fishy. (pushnew :clim *features*) (pushnew :mcclim *features*) +;;; I really didn't have good luck with this on Allegro, because +;;; Allegro's CL-USER package uses it's EXCL stuff, which has its own +;;; DEFSYSTEM. [2004/12/21:rpg] +;;;#+mk-defsystem (use-package "MK") (defmacro clim-defsystem ((module &key depends-on) &rest components) `(progn #+mk-defsystem Mike McDonald mikemac(a)mikemac.com

4 4

[mcclim-devel] tar file of nightly "sources"
by Mike McDonald 19 Aug '05

19 Aug '05

Quoting the web page: Releases A compressed tar file of the sources is made nightly. Except it's not the sources. It's the whole CVS repository! Mike McDonald mikemac(a)mikemac.com

1 0

[mcclim-devel] question about abort and accept
by rpgoldman＠real-time.com 18 Aug '05

18 Aug '05

IIUC, the abort gesture is defined to be control-C. (define-gesture-name :abort :keyboard (#\c :control)) So, I was surprised to find when I had mistyped an argument, and pressed control-c, it did not abort the interaction. Is this a bug? I rooted around in the code, and I'm afraid I wasn't sufficiently savvy to guess where the abort gesture should be trapped. I would have guessed, though, that unless it was trapped, it would toss an error. So is there something wrong about accept in an interactor window that is keeping abort from being signalled? thanks, r

1 0

[mcclim-devel] problem with the webarchive of this mailinglist
by Max-Gerd Retzlaff 18 Aug '05

18 Aug '05

Hi, who maintains the web archive? Have a look at: http://common-lisp.net/pipermail/mcclim-devel/2005-August/004217.html What's the problem? Bye, Max -- Max-Gerd Retzlaff <m.retzlaff(a)gmx.net> For your amusement: Text processing has made it possible to right-justify any idea, even one which cannot be justified on any other grounds. -- J. Finnegan, USC.

3 2

[mcclim-devel] trying to clean up incremental-redisplay.lisp
by Robert Strandh 18 Aug '05

18 Aug '05

Hello, I am trying to clean up in incremental-redisplay.lisp. Here is what I suggest for now. If someone has objections, let me know: * get rid of *enable-updating-output*. It is initialized to t in incremental-redisplay.lisp and used there as well as in frames.lisp, but it is never set or bound. I suppose it was meant to be some kind of debugging tool, * get rid of redisplay-add-output-record and redisplay-delete-output-record which are never called, * get rid of clear-moved-record which is never called. What do you think? -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. ---------------------------------------------------------------------

2 2

[mcclim-devel] some patches: accepting-values and partial-commands
by Max-Gerd Retzlaff 18 Aug '05

18 Aug '05

Hi, I've found some problems in McClim yesterday and written some patches (for three of the four problems). Regards, Max-Gerd Retzlaff ======================================================================== - The example in section 10.2.1 of the clim spec v2.2: (define-editor-command (com-save-file :menu t :keystroke (:s :control)) () ...) is either an error and :keystroke (#\s :control) was meant, or it suggests that it should be possible to first define a keystroke :s like for example: (define-gesture-name :s :keyboard (#\s)) and add modifiers later. The latter does not work in McClim; modifiers that are only specified in the :keystroke argument to a define-command are simply ignored. Patch: - none - ======================================================================== - accepting-dialog should behave as if the argument align-prompts had the value :right if it is specified as T (clim spec v2.2, 13.3); only the values nil, :left, :right, and t are possible. Patch to dialog.lisp: -- zipp -- @@ -167,7 +183,10 @@ (frame-class 'accept-values)) (declare (ignore own-window exit-boxes modify-initial-query resize-frame label scroll-bars x-position y-position - width height frame-class)) + width height frame-class)) + (when (and align-prompts ;; t means the same as :right + (not (eq align-prompts :left))) + (setf align-prompts :right)) (multiple-value-bind (cx cy) (stream-cursor-position stream) (let* ((*accepting-values-stream* (make-instance 'accepting-values-stream -- zapp -- ======================================================================== - accepting-values for partial-commands The generated accepting-values shouldn't allow to be exited (via "OK") as long as decent values (i.e. matching the specified presentation type) are supplied for the required arguments of the command. Note: This is a personal taste, I haven't found anything in the clim-spec that requires such a behaviour. Proposed patch (a hack): Apply the following patch to commands.lisp: -- zipp -- --- commands.lisp.~1.53.~ 2005-06-28 06:32:46.000000000 +0200 +++ commands.lisp 2005-08-18 02:05:11.975682512 +0200 @@ -746,6 +746,7 @@ ;; We don't need fresh gensyms of these variables for each accept form. (with-gensyms (value ptype changedp) `(defun ,name (,command-table ,stream ,partial-command) + (do ((still-missing nil t)) (nil) (destructuring-bind (,command-name ,@original-args) ,partial-command (let ((,command-line-name (command-line-name-for-command @@ -755,7 +756,7 @@ ,@(mapcar #'list required-arg-names original-args)) (accepting-values (,stream) (format ,stream - "You are being prompted for arguments to ~S~%" + "You are being prompted for arguments to ~S~%~%" ,command-line-name) ,@(loop for var in required-arg-names @@ -767,9 +768,16 @@ (declare (ignore ,ptype)) (terpri ,stream) (when ,changedp - (setq ,var ,value)))))) - (list ,command-name ,@required-arg-names)))))))) - + (setq ,var ,value))))) + (when still-missing + (format ,stream + "~&Please supply all arguments."))) + (setf ,partial-command (list ,command-name ,@required-arg-names)) + (unless (partial-command-p ,partial-command) + (return ,partial-command)))))))))) ;;; XXX What do to about :acceptably? Probably need to wait for Goatee "buffer ;;; streams" so we can insert an accept-result-extent in the buffer for -- zapp -- ======================================================================== - exit-boxes of accepting-values; 13.3 of the clim spec v2.2 says: -- zipp -- exit-boxes [...] The default behavior is as though you specified the following: '((:exit "OK") (:abort "Cancel")) -- zapp -- The default behavior of McClim correspondends to '((:exit "Exit") (:abort "Abort")) at the moment. Patch: Replace the strings "Exit" and "Abort" in #'display-exit-boxes of dialog.lisp by "Exit" and "Abort", respectively. Patch to dialog.lisp: -- zipp -- --- dialog.lisp.~1.19.~ 2005-02-27 21:52:49.000000000 +0100 +++ dialog.lisp 2005-08-17 08:43:20.000000000 +0200 @@ -224,11 +243,11 @@ (fresh-line stream) (with-output-as-presentation (stream nil 'exit-button) - (format stream "Exit")) + (format stream "OK")) (write-char #\space stream) (with-output-as-presentation (stream nil 'abort-button) - (format stream "Abort")) + (format stream "Cancel")) (terpri stream))) (defmethod stream-accept ((stream accepting-values-stream) type -- zapp -- ======================================================================== -- Max-Gerd Retzlaff <m.retzlaff(a)gmx.net> For your amusement: The human brain is a wonderful thing. It starts working the moment you are born, and never stops until you stand up to speak in public. -- Sir George Jessel

2 1

[mcclim-devel] A new example application for CLIM (town-example.lisp)
by Max-Gerd Retzlaff 18 Aug '05

18 Aug '05

And again.. I had quite a productive day regarding clim programming yesterday; one of the outcomes is the following example for CLIM programming. It tries to demonstrate the following topics: custom view classes, different present presentation methods for different views, completion for accept presentation methods, accepting-values dialogues, presentation to command translators, partial commands in menus, automatically generated menus, and keystroke gestures for commands. At the same time I tried to make the application as simple as possible. As in: Not doing fancy stuff to make the application less senseless (as an application) or more visually appealing. You'll find a screenshot at: http://bl0rg.net/~mgr/flux/town-example.png The code is located at http://bl0rg.net/~mgr/flux/town-example.lisp and also attached to this email. Any comments and proposals for changes are welcome! Did I do something that would better have been done in a different way? Then, please, enlighten me! I currently think about expanding it to a real tutorial with some explanations. But I don't know whether I'll have the time to do it. Regards, Max -- Max-Gerd Retzlaff <m.retzlaff(a)gmx.net> For your amusement: aphorism, n.: A concise, clever statement. afterism, n.: A concise, clever statement you don't think of until too late. -- James Alexander Thom

1 0

[mcclim-devel] tow more patches
by Max-Gerd Retzlaff 18 Aug '05

18 Aug '05

Hi, here are two additional patches. Bye, Max ======================================================================== - :own-window of accepting-values is not implemented I've made a patch based on clim:open-window-stream. Consider it to be a quick and *dirty* hack. Look at the sleep.. -- zipp -- --- dialog.lisp.~1.19.~ 2005-02-27 21:52:49.000000000 +0100 +++ dialog.lisp 2005-08-18 03:21:37.284609600 +0200 @@ -136,6 +136,30 @@ (defvar *accepting-values-stream* nil) +(defmacro with-stream-in-own-window ((&optional (stream '*query-io*) + &rest further-streams) + &rest body) + `(let* ((,stream (open-window-stream)) + ,@(mapcar (lambda (a-stream) + (list a-stream stream)) + further-streams)) + (sleep 0.1) ;; hackhack.. some delay to "ensure" that the window-stream ist opened + (unwind-protect + (progn + ,@body) + (close ,stream)))) + (defmacro accepting-values ((&optional (stream t) &rest args @@ -144,17 +168,22 @@ align-prompts label scroll-bars x-position y-position width height command-table frame-class) &body body) - (declare (ignorable own-window exit-boxes initially-select-query-identifier + (declare (ignorable exit-boxes initially-select-query-identifier modify-initial-query resynchronize-every-pass resize-frame align-prompts label scroll-bars x-position y-position width height command-table frame-class)) (setq stream (stream-designator-symbol stream '*standard-input*)) (with-gensyms (accepting-values-continuation) + (let ((return-form `(flet ((,accepting-values-continuation (,stream) ,@body)) (invoke-accepting-values ,stream #',accepting-values-continuation - ,@args)))) + ,@args)) + )) + (if own-window + `(with-stream-in-own-window (,stream *standard-input* *standard-output*) ,return-form) + return-form)))) (defun invoke-accepting-values (stream body -- zapp -- ======================================================================== - A patch to open-window-stream to be able to do modify the display-function of the created window-stream afterwards, as in: (let ((stream (open-window-stream))) (setf (slot-value stream 'climi::display-function) (lambda (frame pane) (declare (ignore frame)) (write-string "foo" pane))) stream) and not having to explicitly call (redisplay-frame-panes (pane-frame *) :force-p t) after changing the display function. The standalone-event-loop for open-window-stream is quite Spartan. The default-frame-top-level includes a call to redisplay-frame-panes with force (only for the first time) before calling simple-event-loop as well. I conclude that calling redisplay-frame-panes in open-window-stream is the right thing to do. By the way, standard-event-loop is complete copy of simple-event-loop aside from two lines of code to handle FRAME-EXIT. Not very nice. Patch to panes.lisp - zipp - --- panes.lisp.~1.153.~ 2005-06-24 01:12:42.000000000 +0200 +++ panes.lisp 2005-08-18 03:48:55.298593624 +0200 @@ -2591,6 +2596,8 @@ #+clim-mp (unless input-buffer (clim-sys:make-process (lambda () (let ((*application-frame* frame)) + (redisplay-frame-panes frame :force-p t) (standalone-event-loop))))) (slot-value frame 'stream))) - zapp - ======================================================================== -- Max-Gerd Retzlaff <m.retzlaff(a)gmx.net> For your amusement: My brother sent me a postcard the other day with this big satellite photo of the entire earth on it. On the back it said: "Wish you were here". -- Steven Wright

1 0

[mcclim-devel] frames with multiple layouts
by rpgoldman＠real-time.com 17 Aug '05

17 Aug '05

I've used multiple layouts to give me a kind of modal UI. It seemed easier to have multiple, simple diplay functions instead of a single complex one. All well and good, but now I find that when I change layouts, the size of the frame changes. This is annoyingly distracting, especially since it happens in an odd way: 1. go to layout 1. 2. Maximize the window. 3. Go to layout 2. Window shrinks. 4. Return to layout 1. Window has shrinky size of layout 2. Is there some relatively easy way to make CLIM assign the frame a size that is the MAX of all of the sizes of the individual layouts? Thanks, R

1 0

[mcclim-devel] minor bug in CLIM-LISTENER or in FORMAT-GRAPH-FROM-ROOTS
by rpgoldman＠real-time.com 16 Aug '05

16 Aug '05

Often, I find when graphing classes in the CLIM-LISTENER, that I will run off the window size. The reason is that neither the class-grapher, which invokes format-graph-from-roots, nor format-graph-from-roots, calls change-space-requirement on its stream. I'm not at all sure what's the proper fix. It seems to me that Format-graph-from-roots should call change-space-requirements, because I can't imagine a case where one wouldn't want to after drawing a graph. But I recall raising this issue on #lisp one day, and having people argue that they preferred NOT to have anything automatically call change-space-requirements, that this should be left to the programmer, in the interests of efficiency, so that that programmer could bundle up a large number of window writes before updating the space requirements. So, what's the consensus of the group? Where should this be fixed? Robert

1 0