From strandh at labri.fr Mon Jan 1 07:48:22 2007 From: strandh at labri.fr (Robert Strandh) Date: Mon, 1 Jan 2007 08:48:22 +0100 Subject: [mcclim-devel] profiling redisplay Message-ID: <17816.48326.927565.137450@serveur5.labri.fr> Hello, and a happy new year to everyone. As promised on #lisp, I did some profiling of redisplay, both incremental and non incremental. The program I wrote displays a certain number of paragraphs of text, each paragraph has an average of 10 lines of text, each line has an average of 10 words, and each word has an average of 5.5 characters. Here are the results so far. Experiment 1: 100 paragraphs. Make three nested loops, each time doing a format for each word (and the space after it), a terpri after each line, and another terpri after each paragraph. seconds | consed | calls | sec/call | name ---------------------------------------------------------- 1.788 | 40,813,664 | 18,499 | 0.000097 | STREAM-WRITE-STRING 1.431 | 109,924,368 | 1,085 | 0.001319 | STREAM-WRITE-CHAR 0.416 | 14,113,200 | 18,515 | 0.000022 | CLIM:STREAM-ADD-STRING-OUTPUT ---------------------------------------------------------- 3.635 | 164,851,232 | 38,099 | | Total estimated total profiling overhead: 0.05 seconds overhead estimation parameters: 8.000001e-9s/call, 1.312e-6s total profiling, 4.56e-7s internal profiling Experiment 2: Set drawing-p to nil while the redisplay function is running and do a replay at the end. This experiment shows that most of the time (75%) spent in stream-write-string above was spent actually displaying the string, and not adding output records. It is perhaps a bit surprising that stream-write-string is faster (by a factor 40) than stream-write-char. I have no explanation for that at this point. seconds | consed | calls | sec/call | name ---------------------------------------------------------- 1.107 | 73,825,392 | 1,263 | 0.000877 | STREAM-WRITE-CHAR 0.436 | 15,569,280 | 18,310 | 0.000024 | STREAM-WRITE-STRING 0.344 | 12,530,640 | 18,313 | 0.000019 | CLIM:STREAM-ADD-STRING-OUTPUT ---------------------------------------------------------- 1.887 | 101,925,312 | 37,886 | | Total estimated total profiling overhead: 0.05 seconds overhead estimation parameters: 8.000001e-9s/call, 1.312e-6s total profiling, 4.56e-7s internal profiling Experiment 3: Surround each paragraph and new line output with `with-new-output-record' (no record type give) so that we get a structure of nested output records. This experiment shows that there is a little but not significant difference between inserting new output records when there are already many of them and when there are few of them. seconds | consed | calls | sec/call | name --------------------------------------------------------- 0.823 | 66,124,880 | 1,073 | 0.000767 | STREAM-WRITE-CHAR 0.504 | 14,937,136 | 18,029 | 0.000028 | STREAM-WRITE-STRING 0.312 | 12,665,376 | 18,045 | 0.000017 | CLIM:STREAM-ADD-STRING-OUTPUT --------------------------------------------------------- 1.640 | 93,727,392 | 37,147 | | Total estimated total profiling overhead: 0.05 seconds overhead estimation parameters: 8.000001e-9s/call, 1.312e-6s total profiling, 4.56e-7s internal profiling Experiment 4: Like experiment 3, except give an explicit type of standard-tree-output-record. There is no significant difference compared to experiment 3, though there might have been for many output records. I guess this shows that tree output records can handle large outputs without any significant speed penalty. seconds | consed | calls | sec/call | name --------------------------------------------------------- 0.920 | 65,444,656 | 1,060 | 0.000867 | STREAM-WRITE-CHAR 0.520 | 14,775,504 | 17,995 | 0.000029 | STREAM-WRITE-STRING 0.388 | 12,564,224 | 18,011 | 0.000022 | CLIM:STREAM-ADD-STRING-OUTPUT --------------------------------------------------------- 1.828 | 92,784,384 | 37,066 | | Total estimated total profiling overhead: 0.05 seconds overhead estimation parameters: 8.000001e-9s/call, 1.312e-6s total profiling, 4.56e-7s internal profiling Experiment 5: Use incremental redisplay, and replace the calls to with-new-output-record with calls to updating-output. Do not count initial display of the pane, and instead invoke the redisplay 100 times (by using a command that does nothing). Notice that there are other panes around, so you can't rely on the `calls' and `sec/call' figures of redisplay-frame-pane. This experiment shows that incremental redisplay is doing its job, and costing around 12 ms in this case. seconds | consed | calls | sec/call | name -------------------------------------------------------- 1.260 | 34,307,008 | 1,300 | 0.000970 | CLIM:REDISPLAY-FRAME-PANE 0.048 | 802,576 | 1,700 | 0.000028 | CLIM:STREAM-ADD-STRING-OUTPUT 0.030 | 1,068,960 | 1,600 | 0.000019 | STREAM-WRITE-CHAR 0.016 | 73,456 | 100 | 0.000159 | STREAM-WRITE-STRING -------------------------------------------------------- 1.354 | 36,252,000 | 4,700 | | Total estimated total profiling overhead: 0.01 seconds overhead estimation parameters: 8.000001e-9s/call, 1.312e-6s total profiling, 4.56e-7s internal profiling Experiment 6: Like experiment 5, but do 10 times as many paragraphs (1000 paragraphs, 10k lines in total). Incremental redisplay seems to cost 100ms in this case. seconds | consed | calls | sec/call | name --------------------------------------------------------- 10.429 | 235,221,216 | 1,300 | 0.008023 | CLIM:REDISPLAY-FRAME-PANE 0.027 | 1,532,000 | 1,700 | 0.000016 | CLIM:STREAM-ADD-STRING-OUTPUT 0.026 | 196,448 | 1,600 | 0.000016 | STREAM-WRITE-CHAR 0.008 | 530,816 | 100 | 0.000079 | STREAM-WRITE-STRING --------------------------------------------------------- 10.490 | 237,480,480 | 4,700 | | Total estimated total profiling overhead: 0.01 seconds overhead estimation parameters: 8.000001e-9s/call, 1.312e-6s total profiling, 4.56e-7s internal profiling Experiment 7: Like experiment 6, but instead of a command that does nothing, invoke a command that modifies the first word of the first line of the first paragraph (and changes the output records accordingly). There are about twice as many calls to stream-write-string and stream-add-string-output as I had expected. It should have to redraw around 10 strings (one line) in each call, so I had expected 10000 calls. Still, this experiment shows that incremental redisplay itself is working, but it is a bit slow, around 100ms per call, even though almost all output records are the same and in the same place. seconds | consed | calls | sec/call | name ---------------------------------------------------------- 12.228 | 269,291,632 | 1,300 | 0.009407 | CLIM:REDISPLAY-FRAME-PANE 0.601 | 17,087,472 | 20,400 | 0.000029 | STREAM-WRITE-STRING 0.375 | 12,453,424 | 20,400 | 0.000018 | CLIM:STREAM-ADD-STRING-OUTPUT 0.031 | 86,624 | 1,200 | 0.000026 | STREAM-WRITE-CHAR ---------------------------------------------------------- 13.236 | 298,919,152 | 43,300 | | Total estimated total profiling overhead: 0.06 seconds overhead estimation parameters: 8.000001e-9s/call, 1.312e-6s total profiling, 4.56e-7s internal profiling Experiment 8: Like experiment 7, but instead of adding a word to the first line, either add a new line at the beginning or delete the first line, so that all top-level output records will be in the wrong place. There is a noticeable delay between screen updates in this experiment (around a second). seconds | consed | calls | sec/call | name ------------------------------------------------------------ 90.237 | 2,637,312,912 | 1,300 | 0.069413 | CLIM:REDISPLAY-FRAME-PANE 0.723 | 20,536,496 | 25,210 | 0.000029 | STREAM-WRITE-STRING 0.433 | 17,614,384 | 25,210 | 0.000017 | CLIM:STREAM-ADD-STRING-OUTPUT 0.039 | 57,472 | 1,376 | 0.000029 | STREAM-WRITE-CHAR ------------------------------------------------------------ 91.432 | 2,675,521,264 | 53,096 | | Total estimated total profiling overhead: 0.07 seconds overhead estimation parameters: 8.000001e-9s/call, 1.312e-6s total profiling, 4.56e-7s internal profiling Experiment 9: Similar to experiment 8. Use incremental redisplay. Do not count initial display of the pane. Invoke the redisplay 100 times by using a command that either adds a new line at the beginning or deletes the first line, so that all top-level output records will be in the wrong place. This experiment shows that at least 80% of the time spent in redisplay-frame-pane is spent in invoke-updating-output, and that more than 80% of the time spent in invoke-updating-output is spent in move-output-record. The reason for that is twofold. First, the spec says that the position (and start-cursor-position and end-cursor-position) of an output record is "absolute", i.e. relative to the stream (as opposed to being relative to the parent output record). Second, the spec was interpreted very literally by the McCLIM implementors to mean that the absolute position had to be stored in the output record. Thus, moving a top-level output record involves recursively moving each child. In our case, this means that when a paragraph is moved, each line is moved as well, resulting in at least 10 times as much work as necessary. A better idea would be to store the position relative to the parent, to sum them up when the position is asked for, and to only modify the position of the root record, when it is to be moved. seconds | consed | calls | sec/call | name ------------------------------------------------------------- 64.196 | 1,425,446,000 | 99,900 | 0.000643 | CLIM-INTERNALS::MOVE-OUTPUT-RECORD 9.620 | 162,623,840 | 101,482 | 0.000095 | CLIM:INVOKE-UPDATING-OUTPUT 0.852 | 1,442,704 | 104,846 | 0.000008 | CLIM:ADD-OUTPUT-RECORD ------------------------------------------------------------- 74.669 | 1,589,512,544 | 306,228 | | Total estimated total profiling overhead: 0.40 seconds overhead estimation parameters: 8.000001e-9s/call, 1.312e-6s total profiling, 4.56e-7s internal profiling -- 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. --------------------------------------------------------------------- From strandh at labri.fr Mon Jan 1 16:28:34 2007 From: strandh at labri.fr (Robert Strandh) Date: Mon, 1 Jan 2007 17:28:34 +0100 Subject: [mcclim-devel] program for incremental redisplay benchmark Message-ID: <17817.14002.57728.339141@serveur5.labri.fr> Here is the (last version of the) program I used to obtain the benchmark: (defpackage :example (:use :clim-lisp :clim :esa) (:export)) (in-package :example) (defmethod handle-repaint :before ((pane esa-pane-mixin) region) (declare (ignore region pane)) nil) (defclass example-info-pane (info-pane) () (:default-initargs :height 20 :max-height 20 :min-height 20 :display-function 'display-info :incremental-redisplay t)) (defun display-info (frame pane) (declare (ignore frame)) (format pane "Pane name: ~s" (pane-name (master-pane pane)))) (defclass example-minibuffer-pane (minibuffer-pane) () (:default-initargs :height 20 :max-height 20 :min-height 20)) (defun make-word () (with-output-to-string (string) (loop repeat (+ 4 (random 3)) do (princ (code-char (+ 97 (random 26))) string)))) (defun generate-words () (loop repeat (+ 8 (random 4)) collect (make-word))) (defclass text-line () ((words :initform (generate-words) :initarg :words :accessor words))) (defun generate-lines () (loop repeat (+ 8 (random 4)) collect (make-instance 'text-line))) (defclass paragraph () ((lines :initform (generate-lines) :initarg :lines :accessor lines))) (defun generate-contents () (loop repeat 1000 collect (make-instance 'paragraph))) (defclass example-pane (esa-pane-mixin application-pane) ((contents :initform (generate-contents) :accessor contents))) (define-application-frame example (esa-frame-mixin standard-application-frame) () (:panes (window (let* ((my-pane (make-pane 'example-pane :width 900 :height 400 :name 'my-pane :display-function 'display-my-pane :incremental-redisplay t :command-table 'global-example-table)) (my-info-pane (make-pane 'example-info-pane :master-pane my-pane :width 900))) (setf (windows *application-frame*) (list my-pane)) (vertically () (scrolling () my-pane) my-info-pane))) (minibuffer (make-pane 'example-minibuffer-pane :width 900))) (:layouts (default (vertically (:scroll-bars nil) window minibuffer))) (:top-level (esa-top-level))) (defparameter *counter* 5) (defun display-my-pane (frame pane) (declare (ignore frame)) (with-output-recording-options (pane :record t :draw nil) (loop for paragraph in (contents pane) do (updating-output (pane :unique-id paragraph :cache-value paragraph) (loop for line in (lines paragraph) do (updating-output (pane :unique-id line :cache-value line) (loop for word in (words line) do (format pane "~a " word)) (terpri pane))) (terpri pane)))) (stream-replay pane)) (defun example (&key (width 900) (height 400)) "Starts up the example application" (clim-sys:make-process (lambda () (let ((frame (make-application-frame 'example :width width :height height))) (run-frame-top-level frame))))) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;; ;;; Commands and key bindings (define-command-table global-example-table :inherit-from (global-esa-table keyboard-macro-table)) (define-example-command (com-nothing :name t) () nil) (set-key 'com-nothing 'global-example-table '(#\n)) (define-example-command (com-modify :name t) () (let* ((paragraphs (contents (find-pane-named *application-frame* 'my-pane))) (lines (lines (car paragraphs))) (words (words (car lines))) (new-words (cons (make-word) (cdr words))) (new-lines (cons (make-instance 'text-line :words new-words) (cdr lines))) (new-paragraphs (cons (make-instance 'paragraph :lines new-lines) (cdr paragraphs)))) (setf (contents (find-pane-named *application-frame* 'my-pane)) new-paragraphs))) (set-key 'com-modify 'global-example-table '(#\m)) (define-example-command (com-add :name t) () (let* ((paragraphs (contents (find-pane-named *application-frame* 'my-pane))) (lines (lines (car paragraphs))) (new-lines (if (< (random 100) 55) (cons (make-instance 'text-line) lines) (cdr lines))) (new-paragraphs (cons (make-instance 'paragraph :lines new-lines) (cdr paragraphs)))) (setf (contents (find-pane-named *application-frame* 'my-pane)) new-paragraphs))) (set-key 'com-add 'global-example-table '(#\a)) -- 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. --------------------------------------------------------------------- From strandh at labri.fr Tue Jan 2 08:16:39 2007 From: strandh at labri.fr (Robert Strandh) Date: Tue, 2 Jan 2007 09:16:39 +0100 Subject: [mcclim-devel] performance of incremental redisplay Message-ID: <17818.5351.616963.924842@serveur5.labri.fr> The slowness of my example from the other day seems to be caused by the fact that each top-level output record (of which there are 1000 in my example) is moved individually, and moving an output record triggers a call to recompute-extent-for-changed-child. The parent then scans all the children to compute the new bounding rectangle, resulting in quadratic behavior. The solution to this problem seems to be to realize that incremental redisplay must traverse all the output records anyway (to see what has changed), and so it would be a better idea to put off the computation of the bounding rectangle until the end of this entire process. I maintain my previous analysis that it would be a better idea to store relative positions in output records, so that moving an output record does not require traversing its children. -- 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. --------------------------------------------------------------------- From moore at bricoworks.com Tue Jan 2 08:41:03 2007 From: moore at bricoworks.com (Timothy Moore) Date: Tue, 02 Jan 2007 09:41:03 +0100 Subject: [mcclim-devel] performance of incremental redisplay In-Reply-To: <17818.5351.616963.924842@serveur5.labri.fr> References: <17818.5351.616963.924842@serveur5.labri.fr> Message-ID: <459A1A9F.8050102@bricoworks.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Robert Strandh wrote: > The slowness of my example from the other day seems to be caused by > the fact that each top-level output record (of which there are 1000 in > my example) is moved individually, and moving an output record > triggers a call to recompute-extent-for-changed-child. The parent > then scans all the children to compute the new bounding rectangle, > resulting in quadratic behavior. > > The solution to this problem seems to be to realize that incremental > redisplay must traverse all the output records anyway (to see what has > changed), and so it would be a better idea to put off the computation > of the bounding rectangle until the end of this entire process. > > I maintain my previous analysis that it would be a better idea to > store relative positions in output records, so that moving an output > record does not require traversing its children. It's interesting to note that early versions of CLIM did store the child positions as relative coordinates; it was considered an important optimization to move to fixed coordinates! :) I believe that relative coordinates were identified as a bottleneck in the comparison part of updating-output. Trade-offs that were important 20 years ago may not be relevant today... Tim -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFFmhqeeDhWHdXrDRURAu1TAJwIycuUZcSGOmzf6fn/TEtfSqSuZwCgiIUS eylxeKojeo3bIph3ZU6GXeY= =2drZ -----END PGP SIGNATURE----- From csr21 at cantab.net Wed Jan 3 17:27:06 2007 From: csr21 at cantab.net (Christophe Rhodes) Date: Wed, 03 Jan 2007 17:27:06 +0000 Subject: [mcclim-devel] Listener menus Message-ID: <87fyas9g2d.fsf@cantab.net> Hi, The attached restores working menus to the Listener. (It's not completely clean; I'll try to explain why). The first thing to do, done in the middle hunk of the three-hunk patch, is to put back the listener-view specializations to the interactor and the pointer documentation. (The latter isn't necessary, but I think it's right anyway). The first hunk is the magical one: it defines a command-or-form accept method which treats menu-items specially. The problem is that a menu-item is a perfectly good form, at least according to the various presentation translators around; therefore, the command-or-form input context "captures" the menu item. I'm not sure that this is ever desired behaviour, but it's certainly not desired behaviour inside read-frame-command of the listener, so we reintroduce an input context for menu-item inside the command-or-form context, and throw to the outer context handler established by the McCLIM-provided read-frame-command :around method. As I say, I'm not sure that it's ever desireable for 'expression or 'form input contexts to capture menu-items; if it isn't, then probably mcclim itself ought to prevent it from happening, maybe by a similar trick inside the system accept methods? It all looks a bit horrible, though. It's not great for the user as it stands, though, because as far as I can tell there's no standard menu-item presentation type -- the one that McCLIM implements is good, but it's not in Gilbert's annotatable spec -- and the contents of *input-context* are explicitly unspecified. The third hunk of this diff is an alternative approach, handling menu-items specially if they're returned from read-frame-command. This feels clunkier somehow -- for instance, the menu-item objects are printed at the repl -- but seems to violate fewer abstractions. Comments? Cheers, Christophe PS: when I apply this patch and click on a menu item for, say, Show Class Subclasses, the resulting dialog box eats my first keystroke using Drei, but not using Goatee. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: listener.diff URL: From csr21 at cantab.net Wed Jan 3 18:29:02 2007 From: csr21 at cantab.net (Christophe Rhodes) Date: Wed, 03 Jan 2007 18:29:02 +0000 Subject: [mcclim-devel] Listener menus In-Reply-To: <87fyas9g2d.fsf@cantab.net> (Christophe Rhodes's message of "Wed, 03 Jan 2007 17:27:06 +0000") References: <87fyas9g2d.fsf@cantab.net> Message-ID: <873b6s3qxd.fsf@cantab.net> Christophe Rhodes writes: > As I say, I'm not sure that it's ever desireable for 'expression or > 'form input contexts to capture menu-items; if it isn't, then probably > mcclim itself ought to prevent it from happening, maybe by a similar > trick inside the system accept methods? I had an idea on the way home from work regarding this. If it is the case that menus shouldn't be captured by form and command-or-form accepts, then I think what needs to happen is that menu-items shouldn't have translators to form or expression presentation types. Does that sound more plausible? Cheers, Christophe From csr21 at cantab.net Wed Jan 3 20:35:39 2007 From: csr21 at cantab.net (Christophe Rhodes) Date: Wed, 03 Jan 2007 20:35:39 +0000 Subject: [mcclim-devel] Listener menus In-Reply-To: <873b6s3qxd.fsf@cantab.net> (Christophe Rhodes's message of "Wed, 03 Jan 2007 18:29:02 +0000") References: <87fyas9g2d.fsf@cantab.net> <873b6s3qxd.fsf@cantab.net> Message-ID: <87y7oj3l2c.fsf@cantab.net> Christophe Rhodes writes: > Christophe Rhodes writes: > >> As I say, I'm not sure that it's ever desireable for 'expression or >> 'form input contexts to capture menu-items; if it isn't, then probably >> mcclim itself ought to prevent it from happening, maybe by a similar >> trick inside the system accept methods? > > I had an idea on the way home from work regarding this. If it is the > case that menus shouldn't be captured by form and command-or-form > accepts, then I think what needs to happen is that menu-items > shouldn't have translators to form or expression presentation types. > Does that sound more plausible? (I think so. Patch attached.) -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: menu-item.diff URL: -------------- next part -------------- Cheers, Christophe From ahefner at gmail.com Wed Jan 3 20:57:28 2007 From: ahefner at gmail.com (Andy Hefner) Date: Wed, 3 Jan 2007 15:57:28 -0500 Subject: [mcclim-devel] Listener menus In-Reply-To: <87y7oj3l2c.fsf@cantab.net> References: <87fyas9g2d.fsf@cantab.net> <873b6s3qxd.fsf@cantab.net> <87y7oj3l2c.fsf@cantab.net> Message-ID: <31ffd3c40701031257p33c7d5b8ga6bbf3bc11579ffe@mail.gmail.com> Note that the menu-item presentation type is implied by the spec within the definition of draw-standard-menu (http://www.stud.uni-karlsruhe.de/~unk6/clim-spec/25.html#_1357). Is it possible to simply define a menu-item-to-command translator with a higher priority which would override the translator currently stealing the menu-item? On 1/3/07, Christophe Rhodes wrote: > Christophe Rhodes writes: > > > Christophe Rhodes writes: > > I had an idea on the way home from work regarding this. If it is the > > case that menus shouldn't be captured by form and command-or-form > > accepts, then I think what needs to happen is that menu-items > > shouldn't have translators to form or expression presentation types. > > Does that sound more plausible? From ahefner at gmail.com Wed Jan 3 21:21:02 2007 From: ahefner at gmail.com (Andy Hefner) Date: Wed, 3 Jan 2007 16:21:02 -0500 Subject: [mcclim-devel] Listener menus In-Reply-To: <31ffd3c40701031257p33c7d5b8ga6bbf3bc11579ffe@mail.gmail.com> References: <87fyas9g2d.fsf@cantab.net> <873b6s3qxd.fsf@cantab.net> <87y7oj3l2c.fsf@cantab.net> <31ffd3c40701031257p33c7d5b8ga6bbf3bc11579ffe@mail.gmail.com> Message-ID: <31ffd3c40701031321g6bf60a2an7366cf6a180d17@mail.gmail.com> Or, even better, define such a translator at the default priority, and lower the priorities of the various *-to-[form,expression] translators, defined in builtin-commands.lisp, in order that they never compete with an explicitly defined translator at the default priority. Speaking of such things, I'm curious what happens when you accept '(or type-1 type-2), and have applicable translators to both type-1 and type-2 for some presentation. As currently implemented, I'd guess the translator to type-1 always applies, even if it has lower priority than the translator to type-2. I wonder if this is intuitive. On 1/3/07, Andy Hefner wrote: > Is it possible to simply define a menu-item-to-command translator with > a higher priority which would override the translator currently > stealing the menu-item? From kilian.sprotte at googlemail.com Wed Jan 3 21:29:01 2007 From: kilian.sprotte at googlemail.com (Kilian Sprotte) Date: Wed, 3 Jan 2007 22:29:01 +0100 Subject: [mcclim-devel] :pointer-button (:left :shift) bug? Message-ID: <1d26dc7e0701031329r72a32bfl5c629bec20d8ab54@mail.gmail.com> Hi, am playing around with various pointer gestures. While everything seems to work :), I dont get :pointer-button (:left :shift) to do any action... I was testing with clx_0.7.3 and mcclim-0.9.3 as well as mcclim CVS on osx and ubuntu on sbcl (of course). So, all these are fine: (define-gesture-name :delete3 :pointer-button (:left :control)) (define-gesture-name :delete4 :pointer-button (:left :meta)) and even: (define-gesture-name :delete7 :pointer-button (:left :control :shift)) But here is nothing happening here: (define-gesture-name :delete2 :pointer-button (:left :shift)) Is this combination for some reasons impossible? I tried tracing down this a little, but I dont think, I will actually manage, sorry..... Thanks for any comments, Kilian From ahefner at gmail.com Wed Jan 3 21:53:03 2007 From: ahefner at gmail.com (Andy Hefner) Date: Wed, 3 Jan 2007 16:53:03 -0500 Subject: [mcclim-devel] :pointer-button (:left :shift) bug? In-Reply-To: <1d26dc7e0701031329r72a32bfl5c629bec20d8ab54@mail.gmail.com> References: <1d26dc7e0701031329r72a32bfl5c629bec20d8ab54@mail.gmail.com> Message-ID: <31ffd3c40701031353n51952c00m1ec1b0d50c0665c6@mail.gmail.com> It is probably being stolen by the method that handles select/paste, which is invoked via the shift modifier. This behavior is provided by cut-and-paste-mixin, a superclass of clim-stream-pane, which is in turn a superclass of interactor and application panes. The code responsible is the three dispatch-event methods in text-selection.lisp. If I'm right, replacing the bodies of these with (call-next-method) should cause the method to pass through to the usual gesture handling. Ideally you could define your own pane class which excluded the cut-and-paste-mixin (or other nonstandard but typically desirable behaviors, such as mouse-wheel-scroll-mixin), but at present the class hierarchy doesn't allow it. I guess we should push these mixins down into interactor-pane and application-pane, or some new intermediate point between these and clim-stream-pane. If it's a problem for your application, arrangements can be made. On 1/3/07, Kilian Sprotte wrote: > Hi, > > am playing around with various pointer gestures. While everything seems to > work :), I dont get :pointer-button (:left :shift) to do any action... From csr21 at cantab.net Wed Jan 3 22:06:10 2007 From: csr21 at cantab.net (Christophe Rhodes) Date: Wed, 03 Jan 2007 22:06:10 +0000 Subject: [mcclim-devel] Listener menus In-Reply-To: <31ffd3c40701031257p33c7d5b8ga6bbf3bc11579ffe@mail.gmail.com> (Andy Hefner's message of "Wed, 3 Jan 2007 15:57:28 -0500") References: <87fyas9g2d.fsf@cantab.net> <873b6s3qxd.fsf@cantab.net> <87y7oj3l2c.fsf@cantab.net> <31ffd3c40701031257p33c7d5b8ga6bbf3bc11579ffe@mail.gmail.com> Message-ID: <87tzz73gvh.fsf@cantab.net> "Andy Hefner" writes: > Note that the menu-item presentation type is implied by the spec > within the definition of draw-standard-menu > (http://www.stud.uni-karlsruhe.de/~unk6/clim-spec/25.html#_1357). Yeah, I discovered that. But actually my patch does this right -- because there is already a define-presentation-type menu-item in mcclim, it just got clobbered by the class definition. Defining the menu-item class with a different name (%menu-item) leaves the presentation type untouched -- and that presentation type doesn't inherit from expression or form, and doesn't have a translator to expression or form. So everything comes out right. > Is it possible to simply define a menu-item-to-command translator with > a higher priority which would override the translator currently > stealing the menu-item? I think that this isn't necessary, and that my last patch is the Right Thing as well as actually working. Cheers, Christophe From ahefner at gmail.com Wed Jan 3 22:24:36 2007 From: ahefner at gmail.com (Andy Hefner) Date: Wed, 3 Jan 2007 17:24:36 -0500 Subject: [mcclim-devel] Listener menus In-Reply-To: <87tzz73gvh.fsf@cantab.net> References: <87fyas9g2d.fsf@cantab.net> <873b6s3qxd.fsf@cantab.net> <87y7oj3l2c.fsf@cantab.net> <31ffd3c40701031257p33c7d5b8ga6bbf3bc11579ffe@mail.gmail.com> <87tzz73gvh.fsf@cantab.net> Message-ID: <31ffd3c40701031424i52d79edhd27413a5f959359a@mail.gmail.com> On 1/3/07, Christophe Rhodes wrote: > "Andy Hefner" writes: > > > Note that the menu-item presentation type is implied by the spec > > within the definition of draw-standard-menu > > (http://www.stud.uni-karlsruhe.de/~unk6/clim-spec/25.html#_1357). > > Yeah, I discovered that. But actually my patch does this right -- > because there is already a define-presentation-type menu-item in > mcclim, it just got clobbered by the class definition. Interesting, that is not the behavior I'd expect, but then I also never thought allowing CLOS classes to be considered presentation types was a good idea (but the spec seems to disagree). > > Is it possible to simply define a menu-item-to-command translator with > > a higher priority which would override the translator currently > > stealing the menu-item? > > I think that this isn't necessary, and that my last patch is the Right > Thing as well as actually working. By virtue of simplicity, your patch wins. However, I wonder if defining such a translator means that we can rip out the toplevel magic about creating an input-context for menu items. Along those same lines, maybe we ought to just present them as commands, so they are directly applicable. It doesn't seem useful presenting anything as a menu item (unless you are writing an editor for menus), except perhaps as a way to control the highlighting style, and in that case it wouldn't be the innermost presentation anyway. Anyway, your patch sounds good to me. From ahefner at gmail.com Thu Jan 4 00:58:51 2007 From: ahefner at gmail.com (Andy Hefner) Date: Wed, 3 Jan 2007 19:58:51 -0500 Subject: [mcclim-devel] performance of incremental redisplay In-Reply-To: <17818.5351.616963.924842@serveur5.labri.fr> References: <17818.5351.616963.924842@serveur5.labri.fr> Message-ID: <31ffd3c40701031658o344383b1n626c6a8388541165@mail.gmail.com> On 1/2/07, Robert Strandh wrote: > I maintain my previous analysis that it would be a better idea to > store relative positions in output records, so that moving an output > record does not require traversing its children. I agree completely. Use of absolute coordinates here is a particularly boneheaded aspect of CLIM, particularly in contrast with the very nice sheet/windowing functions based on transformations. > The solution to this problem seems to be to realize that incremental > redisplay must traverse all the output records anyway (to see what has > changed), and so it would be a better idea to put off the computation > of the bounding rectangle until the end of this entire process. Do you think it makes sense to generally make bounding rectangles computed lazily, caching them? Having ran into quadratic behavior a couple times myself (during normal text output, and in the grapher), this seemed like the logical approach. From strandh at labri.fr Thu Jan 4 03:26:45 2007 From: strandh at labri.fr (Robert Strandh) Date: Thu, 4 Jan 2007 04:26:45 +0100 Subject: [mcclim-devel] performance of incremental redisplay In-Reply-To: <31ffd3c40701031658o344383b1n626c6a8388541165@mail.gmail.com> References: <17818.5351.616963.924842@serveur5.labri.fr> <31ffd3c40701031658o344383b1n626c6a8388541165@mail.gmail.com> Message-ID: <17820.29685.190903.912240@serveur5.labri.fr> Andy Hefner writes: > > > The solution to this problem seems to be to realize that incremental > > redisplay must traverse all the output records anyway (to see what has > > changed), and so it would be a better idea to put off the computation > > of the bounding rectangle until the end of this entire process. > > Do you think it makes sense to generally make bounding rectangles > computed lazily, caching them? Having ran into quadratic behavior a > couple times myself (during normal text output, and in the grapher), > this seemed like the logical approach. I don't think so (depending on what you mean by "lazily"). There are essentially two kinds of applications as far as I can see. The first type has :display-time nil or t and has commands that issue calls to drawing functions. The second type has :display-time :command-loop and runs a large display function each time around the command loop, possibly using incremental display. The first type of application is not likely to run into quadratic behavior if the bounding rectangle is computed immediately. In the general case (say if you delete an output record), computing the bounding rectangle will have to go through all the output records and compute min and max coordinates, but there are special cases where you only add an output record, where this can be avoided, and I think the first type of application is like that. The second type of application is more likely to move or delete output records, that makes it necessary to go through all output records to determine the bounding rectangle. For this type of application it would just be easier to compute the bounding rectangle at the end of the command loop. In fact, I don't think we would take a performance hit for the first type of application either if we would just go through all output records at the end of the command loop, but perhaps to be on the safe side, we could do it that way only of :display-time is :command-loop. -- 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. --------------------------------------------------------------------- From ahefner at gmail.com Thu Jan 4 06:21:56 2007 From: ahefner at gmail.com (Andy Hefner) Date: Thu, 4 Jan 2007 01:21:56 -0500 Subject: [mcclim-devel] performance of incremental redisplay In-Reply-To: <17820.29685.190903.912240@serveur5.labri.fr> References: <17818.5351.616963.924842@serveur5.labri.fr> <31ffd3c40701031658o344383b1n626c6a8388541165@mail.gmail.com> <17820.29685.190903.912240@serveur5.labri.fr> Message-ID: <31ffd3c40701032221h68f82bbs9243b7304a4f0d1a@mail.gmail.com> On 1/3/07, Robert Strandh wrote: > Andy Hefner writes: > > Do you think it makes sense to generally make bounding rectangles > > computed lazily, caching them? Having ran into quadratic behavior a > > couple times myself (during normal text output, and in the grapher), > > this seemed like the logical approach. > > I don't think so (depending on what you mean by "lazily"). There are > essentially two kinds of applications as far as I can see. The first > type has :display-time nil or t and has commands that issue calls to > drawing functions. The second type has :display-time :command-loop > and runs a large display function each time around the command loop, > possibly using incremental display. To clarify, I imagined setting the coordinates slot of the bounding rectangle to nil as a signal that the bounding rectangle needs to be recomputed. Recompute-extent-for-changed-child can set the slot to nil rather than immediately recomputing the bounding rectangle, and bounding-rectangle* checks for the nil case and can call tree-recompute-extent itself, saving the value in the slot (until the next change that invalidates it). That way the bounding rectangle is only computed when it is needed, and moving/deleting a number of records does not cause it to be recomputed each time only to be discarded. > The second type of application is more likely to move or delete output > records, that makes it necessary to go through all output records to > determine the bounding rectangle. For this type of application it > would just be easier to compute the bounding rectangle at the end of > the command loop. Can you elaborate on when and for what records recomputing of bounding rectangles would be supressed? Formatting utilities such as surrounding-output-with-border and the table formatter require correct bounding rectangles for their contained output, the process of producing which may at some point require a call to tree-recompute-extent. Restricting this to the topmost (stream-output-history) record would be safer and sufficient for some applications, but others may encounter the same problems deeper in the output tree. From strandh at labri.fr Thu Jan 4 06:57:29 2007 From: strandh at labri.fr (Robert Strandh) Date: Thu, 4 Jan 2007 07:57:29 +0100 Subject: [mcclim-devel] performance of incremental redisplay In-Reply-To: <31ffd3c40701032221h68f82bbs9243b7304a4f0d1a@mail.gmail.com> References: <17818.5351.616963.924842@serveur5.labri.fr> <31ffd3c40701031658o344383b1n626c6a8388541165@mail.gmail.com> <17820.29685.190903.912240@serveur5.labri.fr> <31ffd3c40701032221h68f82bbs9243b7304a4f0d1a@mail.gmail.com> Message-ID: <17820.42329.967353.20356@serveur5.labri.fr> Andy Hefner writes: > > To clarify, I imagined setting the coordinates slot of the bounding > rectangle to nil as a signal that the bounding rectangle needs to be > recomputed. Recompute-extent-for-changed-child can set the slot to nil > rather than immediately recomputing the bounding rectangle, and > bounding-rectangle* checks for the nil case and can call > tree-recompute-extent itself, saving the value in the slot (until the > next change that invalidates it). That way the bounding rectangle is > only computed when it is needed, and moving/deleting a number of > records does not cause it to be recomputed each time only to be > discarded. This sounds like a good idea, and easy to implement. > > The second type of application is more likely to move or delete output > > records, that makes it necessary to go through all output records to > > determine the bounding rectangle. For this type of application it > > would just be easier to compute the bounding rectangle at the end of > > the command loop. > > Can you elaborate on when and for what records recomputing of bounding > rectangles would be supressed? Formatting utilities such as > surrounding-output-with-border and the table formatter require correct > bounding rectangles for their contained output, the process of > producing which may at some point require a call to > tree-recompute-extent. Restricting this to the topmost > (stream-output-history) record would be safer and sufficient for some > applications, but others may encounter the same problems deeper in the > output tree. I haven't thought this through completely, but it seems to me that even table formatting only needs to be computed right before the output is to be replayed. What I am suggesting is to suppress all such computations and just go through the entire tree once, right before replay. Doing that would have to invoke the table-formatting code, of course. But again, I don't know for sure that it will work. -- 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. --------------------------------------------------------------------- From csr21 at cantab.net Thu Jan 4 09:19:04 2007 From: csr21 at cantab.net (Christophe Rhodes) Date: Thu, 04 Jan 2007 09:19:04 +0000 Subject: [mcclim-devel] Listener menus In-Reply-To: <31ffd3c40701031424i52d79edhd27413a5f959359a@mail.gmail.com> (Andy Hefner's message of "Wed, 3 Jan 2007 17:24:36 -0500") References: <87fyas9g2d.fsf@cantab.net> <873b6s3qxd.fsf@cantab.net> <87y7oj3l2c.fsf@cantab.net> <31ffd3c40701031257p33c7d5b8ga6bbf3bc11579ffe@mail.gmail.com> <87tzz73gvh.fsf@cantab.net> <31ffd3c40701031424i52d79edhd27413a5f959359a@mail.gmail.com> Message-ID: <8764bnqhdj.fsf@cantab.net> "Andy Hefner" writes: >> > Is it possible to simply define a menu-item-to-command translator with >> > a higher priority which would override the translator currently >> > stealing the menu-item? >> >> I think that this isn't necessary, and that my last patch is the Right >> Thing as well as actually working. > > By virtue of simplicity, your patch wins. Okay, I've committed it. > However, I wonder if > defining such a translator means that we can rip out the toplevel > magic about creating an input-context for menu items. Along those same > lines, maybe we ought to just present them as commands, so they are > directly applicable. It doesn't seem useful presenting anything as a > menu item (unless you are writing an editor for menus), except perhaps > as a way to control the highlighting style, and in that case it > wouldn't be the innermost presentation anyway. I think that menu-items by default should probably not translate to commands. Why? Because I think that it's legitimate for an application to do (accept 'command) when not planning to run it immediately (maybe to batch it up, to send to a remote process, or something); under those circumstances, I would expect selecting something from the application's menu bar not to fulfil this accept but instead to run its own command directly. It might make sense for individual applications to specify that they would prefer their menu items to be presented as commands; I don't know whether the CLIM spec documents any way of achieving that. Cheers, Christophe From mikemac at mikemac.com Thu Jan 4 14:42:04 2007 From: mikemac at mikemac.com (Mike McDonald) Date: Thu, 04 Jan 2007 07:42:04 -0700 Subject: [mcclim-devel] Listener menus In-Reply-To: Your message of "Thu, 04 Jan 2007 09:19:04 GMT." <8764bnqhdj.fsf@cantab.net> Message-ID: <200701041442.l04Eg4M05725@saturn.mikemac.com> >To: "Andy Hefner" >Date: Thu, 04 Jan 2007 09:19:04 +0000 >From: Christophe Rhodes >I think that menu-items by default should probably not translate to >commands. Why? Because I think that it's legitimate for an >application to do (accept 'command) when not planning to run it >immediately (maybe to batch it up, to send to a remote process, or >something); under those circumstances, I would expect selecting >something from the application's menu bar not to fulfil this accept >but instead to run its own command directly. I disagree. A menu is nothing more than a way of grouping and presenting a bunch of commands, no different than an button box. In your example, if the command I wanted to accept was "Save", picking it off the "File" menu seems like the way to do it. Mike McDonald mikemac at mikemac.com From dtc at scieneer.com Thu Jan 4 23:47:50 2007 From: dtc at scieneer.com (Douglas Crosher) Date: Fri, 05 Jan 2007 10:47:50 +1100 Subject: [mcclim-devel] Patch: gtkairo backend CL source conventions 1/2 Message-ID: <459D9226.7070205@scieneer.com> The gtkairo backend use some source code conventions that are not in the tradition of CL; using C style names for functions and constants. This patch tranforms the source to standard CL conventions. For example: cairo_text_extents -> cairo-text-extents :CAIRO_ANTIALIAS_DEFAULT -> :cairo-antialias-default gdk_cairo_create -> %gdk-cairo-create GdkCapStyle -> gdk-cap-style GTK_POLICY_AUTOMATIC -> *gtk-policy-automatic* Regards Douglas Crosher -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-gtkairo-1.gz Type: application/unix-tar Size: 17376 bytes Desc: not available URL: From dtc at scieneer.com Thu Jan 4 23:47:59 2007 From: dtc at scieneer.com (Douglas Crosher) Date: Fri, 05 Jan 2007 10:47:59 +1100 Subject: [mcclim-devel] Patch: gtkairo backend CL source conventions 2/2 Message-ID: <459D922F.7080604@scieneer.com> The gtkairo backend use some source code conventions that are not in the tradition of CL; using C style names for functions and constants. This patch tranforms the source to standard CL conventions. For example: cairo_text_extents -> cairo-text-extents :CAIRO_ANTIALIAS_DEFAULT -> :cairo-antialias-default gdk_cairo_create -> %gdk-cairo-create GdkCapStyle -> gdk-cap-style GTK_POLICY_AUTOMATIC -> *gtk-policy-automatic* Regards Douglas Crosher -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-gtkairo-2.gz Type: application/unix-tar Size: 22586 bytes Desc: not available URL: From csr21 at cantab.net Fri Jan 5 15:28:25 2007 From: csr21 at cantab.net (Christophe Rhodes) Date: Fri, 05 Jan 2007 15:28:25 +0000 Subject: [mcclim-devel] menu bars Message-ID: <87zm8xsdba.fsf@cantab.net> Hi, Consider the attached code, which demonstrates that it is possible with current McCLIM to change the contents of menus from within the app. So far, no surprises -- we have a nice dynamic UI, right? The surprise is that it isn't possible to do this to the contents of the menu bar itself: the menus there are fixed when the pane is instantiated, I believe. So my question: is this intentional? Is it desireable? (And what does Legacy CLIM do? :-) Cheers, Christophe -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: menus.lisp URL: From ahefner at gmail.com Fri Jan 5 15:45:55 2007 From: ahefner at gmail.com (Andy Hefner) Date: Fri, 5 Jan 2007 10:45:55 -0500 Subject: [mcclim-devel] menu bars In-Reply-To: <87zm8xsdba.fsf@cantab.net> References: <87zm8xsdba.fsf@cantab.net> Message-ID: <31ffd3c40701050745g597dc853j560b47fcb6163c9e@mail.gmail.com> On 1/5/07, Christophe Rhodes wrote: > The surprise is that it isn't possible to do this to the contents of > the menu bar itself: the menus there are fixed when the pane is > instantiated, I believe. So my question: is this intentional? Is it > desireable? (And what does Legacy CLIM do? :-) I can't object to this behaving in the expected way, if you want to take the effort to make it work. It makes sense to me. On the other hand, since a command table (and its menu) are shared global resources rather than part of the local state of a frame, I'm having trouble imagining uses other than resolving the obvious "I just added a new command, why can't I see it?" situation, which shouldn't arise often anyway if you organize your commands into logical menus. From csr21 at cantab.net Fri Jan 5 16:08:33 2007 From: csr21 at cantab.net (Christophe Rhodes) Date: Fri, 05 Jan 2007 16:08:33 +0000 Subject: [mcclim-devel] menu bars In-Reply-To: <31ffd3c40701050745g597dc853j560b47fcb6163c9e@mail.gmail.com> (Andy Hefner's message of "Fri, 5 Jan 2007 10:45:55 -0500") References: <87zm8xsdba.fsf@cantab.net> <31ffd3c40701050745g597dc853j560b47fcb6163c9e@mail.gmail.com> Message-ID: <87vejlsbge.fsf@cantab.net> "Andy Hefner" writes: > On 1/5/07, Christophe Rhodes wrote: >> The surprise is that it isn't possible to do this to the contents of >> the menu bar itself: the menus there are fixed when the pane is >> instantiated, I believe. So my question: is this intentional? Is it >> desireable? (And what does Legacy CLIM do? :-) > > I can't object to this behaving in the expected way, if you want to > take the effort to make it work. It makes sense to me. OK. (No promises yet: my main use case is the one that already works :-) > On the other hand, since a command table (and its menu) are shared > global resources rather than part of the local state of a frame, I'm > having trouble imagining uses other than resolving the obvious "I > just added a new command, why can't I see it?" situation, which > shouldn't arise often anyway if you organize your commands into > logical menus. Well, one use case is for applications (such as gsharp and climacs), with some notion of input state: for instance, if in lyrics mode in gsharp, there should be a lyrics menu in the menubar, where there probably shouldn't be if in notes mode. Similarly, if in Lisp/SWINE mode in climacs, there should probably be menus for lisp interaction, which shouldn't be there for a buffer in Fundamental Syntax. (GNU Emacs, at least, performs manipulations of its own menu bar in much this way). I quite agree that uses of this facility would have to ensure that they modify a frame-specific command table and not a global one... Oh. For some reason I thought it was possible to have anonymous command tables, as in the GENERATE-PANES method in MAKE-SINGLE-GENERATE-PANES-FORM in frames.lisp (naming it with NIL), but maybe this isn't in fact allowed... Cheers, Christophe From rpgoldman at real-time.com Fri Jan 5 17:50:09 2007 From: rpgoldman at real-time.com (Robert Goldman) Date: Fri, 05 Jan 2007 11:50:09 -0600 Subject: [mcclim-devel] modified clim Spec latex Message-ID: <459E8FD1.4000805@real-time.com> I have modified the clim spec to load its images through includegraphics rather than through epsfig, making it equally usable through pdflatex and latex. In pdflatex, I additionally tweaked it to generate hyperlinks, making it easier to read the document online. Anyone have any objections to my committing these changes? Best, Robert From rpgoldman at real-time.com Fri Jan 5 20:37:41 2007 From: rpgoldman at real-time.com (Robert Goldman) Date: Fri, 05 Jan 2007 14:37:41 -0600 Subject: [mcclim-devel] Presenting pathnames Message-ID: <459EB715.9020509@real-time.com> In presentation-defs.lisp there's some code that stuffs :wild into the name field of pathnames before presenting them, together with a comment that says that pathnames can't be represented if they don't have names. I have checked, and pathnames can be printed w/o names, at least on SBCL and ACL. Adding random stuff to the pathname also seems a little like the wrong thing to do. Would the following patch be appropriate: Index: presentation-defs.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/presentation-defs.lisp,v retrieving revision 1.65 diff -b -u -F^(def -r1.65 presentation-defs.lisp --- presentation-defs.lisp 13 Dec 2006 21:33:43 -0000 1.65 +++ presentation-defs.lisp 5 Jan 2007 20:35:08 -0000 @@ -1470,10 +1470,15 @@ (define-presentation-method present ((ob ;; XXX: We can only visually represent the pathname if it has a name ;; - making it wild is a compromise. If the pathname is completely ;; blank, we leave it as-is, though. - (let ((pathname (if (equal object #.(make-pathname)) - object - (merge-pathnames object (make-pathname :name :wild))))) - (princ pathname stream))) + + ;; AFAICT the above assertion is simply untrue. At least it is + ;; possible to princ a directory with no :name component in ACL and + ;; SBCL. +;;; (let ((pathname (if (equal object #.(make-pathname)) +;;; object +;;; (merge-pathnames object (make-pathname :name :wild))))) + (princ object stream)) +; ) (define-presentation-method present ((object string) (type pathname) stream (view textual-view) From ahefner at gmail.com Fri Jan 5 21:10:29 2007 From: ahefner at gmail.com (Andy Hefner) Date: Fri, 5 Jan 2007 16:10:29 -0500 Subject: [mcclim-devel] menu bars In-Reply-To: <87vejlsbge.fsf@cantab.net> References: <87zm8xsdba.fsf@cantab.net> <31ffd3c40701050745g597dc853j560b47fcb6163c9e@mail.gmail.com> <87vejlsbge.fsf@cantab.net> Message-ID: <31ffd3c40701051310k558d91eg2c28beeae820e931@mail.gmail.com> On 1/5/07, Christophe Rhodes wrote: > Well, one use case is for applications (such as gsharp and climacs), > with some notion of input state: for instance, if in lyrics mode in > gsharp, there should be a lyrics menu in the menubar, where there > probably shouldn't be if in notes mode. Similarly, if in Lisp/SWINE > mode in climacs, there should probably be menus for lisp interaction, > which shouldn't be there for a buffer in Fundamental Syntax. (GNU > Emacs, at least, performs manipulations of its own menu bar in much > this way). Interesting. I'd never considered the possibility of using anonymous command tables, but the command table functions seem to support the concept. I'm not sure I understand the problem in using them - if the only hangup is how to sneak it through define-application-frame to make all the frame instantiating grunge cooperate, you can always write your own read-frame-command, or extend mcclim. Being able to add and remove menu items like this sounds useful and is exactly the sort of low level interface I ought to like, but to actually use it in an application is probably wrong in the same way that making frequent use of (setf command-enabled) is stupid and wrong (compared with using mgr's much nicer conditional-commands extension). Here's an alternative approach I dreamed up a while ago which (I think) addresses the uses you've described: Put the menu bar under the control of accept (or possibly read-frame-command), driven by the current input context. It would combine the menus for every command table in the current input context via some protocol, updating the menu items when the input context changes (if necessary). I don't know how the command reading is done in the applications you mention, but I'd expect you have a command table for commands on the application instance (Quit, etc), one or more command tables for the current buffer and its syntax/mode, and yet another for the current input mode, all of which should be part of the current input context (or somehow inherited together). So, commands from any of these tables should satisfy the accept done by read-frame-command, and as such our extension would merge their menus to populate the current menu bar. Recalling your example the other day of reading a command you don't intend to accept, perhaps putting this under the control of read-frame-command makes the most sense (rather than occuring in response to every accept of 'command, regardless of what you intend to do with the command). If implemented, this ought to be unnoticable unless the application is highly modal. In particular, it should not flicker every time through the command loop. :) I'd also expect that entering accepting-values should also not cause my menu bar to change, so it shouldn't apply unconditionally. From ahefner at gmail.com Fri Jan 5 21:29:22 2007 From: ahefner at gmail.com (Andy Hefner) Date: Fri, 5 Jan 2007 16:29:22 -0500 Subject: [mcclim-devel] menu bars In-Reply-To: <31ffd3c40701051310k558d91eg2c28beeae820e931@mail.gmail.com> References: <87zm8xsdba.fsf@cantab.net> <31ffd3c40701050745g597dc853j560b47fcb6163c9e@mail.gmail.com> <87vejlsbge.fsf@cantab.net> <31ffd3c40701051310k558d91eg2c28beeae820e931@mail.gmail.com> Message-ID: <31ffd3c40701051329h73b26daas299debb1bd7fdbdd@mail.gmail.com> On 1/5/07, Andy Hefner wrote: > (compared with using mgr's much nicer conditional-commands extension). Sorry, I take this bit back. I don't understand his extension at all. I assumed, going by the name, that it implemented the simple and obvious thing that CLIM commands should be able to do but don't, namely to compute whether the command is enabled or disabled as a function of the application state, rather than forcing the programmer to manually enable/disable things from other commands. Bah. From rpgoldman at real-time.com Fri Jan 5 21:39:01 2007 From: rpgoldman at real-time.com (Robert Goldman) Date: Fri, 05 Jan 2007 15:39:01 -0600 Subject: [mcclim-devel] file-browser example application Message-ID: <459EC575.80106@real-time.com> The guided-tour has a test application that's a file-browser. I wanted to try to figure out how to read pathnames in an application I'm writing, so I tried to fire up the file-browser. Unfortunately, it didn't work, mostly because it made assumptions about the way that CL pathnames work that didn't map onto either SBCL or ACL, the two applications on which I tried it. I am attaching a patch which makes it work (if the patch about pathname presentations, that I sent earlier today, is also present). I am inclined to commit this, since (a) it's just part of an article, so can't be on anyone's critical path and (b) it seems like a Bad Thing to have a tutorial out there featuring exemplars that don't work. The downside is that CL pathnames are so intractable that the only good way I found to make this work was to use CL-FAD. Dependencies on libraries seems generally like a bad thing in a small tutorial like this, but importing enough code to make it work w/o the library would probably obscure the tutorial intent even worse. BTW, I think a more elegant solution might be made that would use satisfies to define the dir-pathname presentation-type more declaratively. But I couldn't figure out how to do it... best, Robert From ahefner at gmail.com Fri Jan 5 21:55:23 2007 From: ahefner at gmail.com (Andy Hefner) Date: Fri, 5 Jan 2007 16:55:23 -0500 Subject: [mcclim-devel] file-browser example application In-Reply-To: <459EC575.80106@real-time.com> References: <459EC575.80106@real-time.com> Message-ID: <31ffd3c40701051355i3ca293fbl4e0889abed3e95f4@mail.gmail.com> On 1/5/07, Robert Goldman wrote: > I am attaching a patch which makes it work (if the patch about pathname > presentations, that I sent earlier today, is also present). Did you forget to attach the patch? > The downside is that CL pathnames are so intractable that the only good > way I found to make this work was to use CL-FAD. I hate pathnames. Even for something as seemingly trivial as Show Directory in the listener, they turned into an unpredictable, unportable mess. I vowed not to use them as the primary representation in the event I ever get around to adding serious shell-like features to the listener. > BTW, I think a more elegant solution might be made that would use > satisfies to define the dir-pathname presentation-type more > declaratively. But I couldn't figure out how to do it... Good idea. '(and pathname (satisfies my-directory-p)) doesn't do it? From rpgoldman at real-time.com Fri Jan 5 22:22:04 2007 From: rpgoldman at real-time.com (Robert Goldman) Date: Fri, 05 Jan 2007 16:22:04 -0600 Subject: [mcclim-devel] file-browser example application In-Reply-To: <31ffd3c40701051355i3ca293fbl4e0889abed3e95f4@mail.gmail.com> References: <459EC575.80106@real-time.com> <31ffd3c40701051355i3ca293fbl4e0889abed3e95f4@mail.gmail.com> Message-ID: <459ECF8C.1030102@real-time.com> Andy Hefner wrote: > On 1/5/07, Robert Goldman wrote: >> I am attaching a patch which makes it work (if the patch about pathname >> presentations, that I sent earlier today, is also present). > > Did you forget to attach the patch? Argh. Yes. I *always* do that! [I note that kmail actually scans your email and if you say "attach" anywhere in it, and there's no attachment, it prompts you before sending...]. I will attach here > >> The downside is that CL pathnames are so intractable that the only good >> way I found to make this work was to use CL-FAD. > > I hate pathnames. Even for something as seemingly trivial as Show > Directory in the listener, they turned into an unpredictable, > unportable mess. I vowed not to use them as the primary representation > in the event I ever get around to adding serious shell-like features > to the listener. Yes, unpredictable, unportable mess. That's the original file-browser in a nutshell... > >> BTW, I think a more elegant solution might be made that would use >> satisfies to define the dir-pathname presentation-type more >> declaratively. But I couldn't figure out how to do it... > > Good idea. '(and pathname (satisfies my-directory-p)) doesn't do it? Didn't for me, and I didn't have the foggiest idea how to debug it once it didn't.... Probably there's some way to mouse over something on the screen and figure out what kind of presentation it is? [Garnet had an integrated debugger for which I was often very grateful; I don't really have a clue how to debug CLIM yet...] Probably for someone who groks the relationship of presentation objects and objects presented, this will be more obvious. I tried '(and pathname (satisfies cl-fad:directory-pathname-p)) and nothing worked. But perhaps I made some simple error. BTW, the code itself is so short that I will attach it, as well. Might be easier to look at that than to read the patch. -------------- next part -------------- A non-text attachment was scrubbed... Name: file-browser.patch Type: text/x-patch Size: 3032 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: file-browser.lisp URL: From rpgoldman at real-time.com Sun Jan 7 02:20:59 2007 From: rpgoldman at real-time.com (Robert Goldman) Date: Sat, 06 Jan 2007 20:20:59 -0600 Subject: [mcclim-devel] file-browser example application In-Reply-To: <31ffd3c40701051355i3ca293fbl4e0889abed3e95f4@mail.gmail.com> References: <459EC575.80106@real-time.com> <31ffd3c40701051355i3ca293fbl4e0889abed3e95f4@mail.gmail.com> Message-ID: <45A0590B.4060601@real-time.com> Andy Hefner wrote: > On 1/5/07, Robert Goldman wrote: [...snip...] >> BTW, I think a more elegant solution might be made that would use >> satisfies to define the dir-pathname presentation-type more >> declaratively. But I couldn't figure out how to do it... > > Good idea. '(and pathname (satisfies my-directory-p)) doesn't do it? > I made a stab at it, but no, it didn't seem to work. I am attaching two different versions of the file-browser: one that works, using a new presentation-type, dir-pathname, and one that tries to do the job with (and pathname (satisfies cl-fad:directory-pathname-p)), that doesn't work. Probably there's some simple idiocy I've committed that makes this not work, either a bug, or a misunderstanding of presentation types and the relationship between presentation and the presented object. If anyone can correct this, I will appreciate it, and will see to it that the answer, duly credited, appears in the Guided-Tour paper, to enlighten future seekers after CLIMmy wisdom. Best, R -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: file-browser.lisp URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: file-browser.lisp-new-presentation-type URL: From athas at sigkill.dk Sun Jan 7 14:04:14 2007 From: athas at sigkill.dk (Troels Henriksen) Date: Sun, 07 Jan 2007 15:04:14 +0100 Subject: [mcclim-devel] file-browser example application In-Reply-To: <45A0590B.4060601@real-time.com> (Robert Goldman's message of "Sat, 06 Jan 2007 20:20:59 -0600") References: <459EC575.80106@real-time.com> <31ffd3c40701051355i3ca293fbl4e0889abed3e95f4@mail.gmail.com> <45A0590B.4060601@real-time.com> Message-ID: <87mz4vndb5.fsf@sigkill.dk> Robert Goldman writes: > I made a stab at it, but no, it didn't seem to work. I am attaching two > different versions of the file-browser: one that works, using a new > presentation-type, dir-pathname, and one that tries to do the job with > (and pathname (satisfies cl-fad:directory-pathname-p)), that doesn't > work. It seems that the `and' type doesn't work at all. Try doing (present 2 'integer) and then (accept '(and integer)) - the previous output will not be selectable. -- \ Troels "Athas" /\ Henriksen From rpgoldman at real-time.com Sun Jan 7 19:18:36 2007 From: rpgoldman at real-time.com (Robert Goldman) Date: Sun, 07 Jan 2007 13:18:36 -0600 Subject: [mcclim-devel] file-browser example application In-Reply-To: <45A1454F.2050509@real-time.com> References: <459EC575.80106@real-time.com> <31ffd3c40701051355i3ca293fbl4e0889abed3e95f4@mail.gmail.com> <45A0590B.4060601@real-time.com> <87mz4vndb5.fsf@sigkill.dk> <45A1454F.2050509@real-time.com> Message-ID: <45A1478C.1080505@real-time.com> Robert Goldman wrote: > Troels Henriksen wrote: >> Robert Goldman writes: >> >>> I made a stab at it, but no, it didn't seem to work. I am attaching two >>> different versions of the file-browser: one that works, using a new >>> presentation-type, dir-pathname, and one that tries to do the job with >>> (and pathname (satisfies cl-fad:directory-pathname-p)), that doesn't >>> work. >> It seems that the `and' type doesn't work at all. Try doing (present 2 >> 'integer) and then (accept '(and integer)) - the previous output will >> not be selectable. >> > Hm.... > > At least in presentation-defs.lisp, there is no accept presentation > method for AND. Is this the culprit? > > By analogy, I tried whacking together the following definition for > presentation-defs: > (define-presentation-method accept ((type and) > (stream input-editing-stream) > (view textual-view) > &key) > (let ((scan-begin (stream-scan-pointer stream)) > success > value) > (dolist (and-type types) > (setf (stream-scan-pointer stream) scan-begin) > (multiple-value-setq (success value) > (block try-accept > (handler-case (values t (accept and-type > :stream stream > :view view > :prompt nil)) > (parse-error () (return-from try-accept nil))))) > (unless success (simple-parse-error "Input type is not of type ~S" > types))) > value)) > > But then I get an error that SATISFIES is an unknown presentation type. > I suspect that this is because it's not a primary presentation type, so > I need to use presentation-typep here instead of a recursive accept... > > Best, > R > OK, the following works to let me enter values of type (and pathname (satisfies cl-fad:directory-pathname-p)) to the command prompt. But I still don't get the ability to mouse-select the directory list entries for the presentation-to-command-translator. (define-presentation-method accept ((type and) (stream input-editing-stream) (view textual-view) &key) (let* ((subtype (first types)) (value (accept subtype :stream stream :view view :prompt nil))) (unless (presentation-typep value type) (simple-parse-error "Input type is not of type ~S" type)) value)) BTW, the command prompt is pretty uninformative: Edit Directory (and) : Is this where an abbreviation and description would be helpful? Cheers, R From david at lichteblau.com Sun Jan 7 19:47:24 2007 From: david at lichteblau.com (David Lichteblau) Date: Sun, 7 Jan 2007 20:47:24 +0100 Subject: [mcclim-devel] RGBA image drawing Message-ID: <20070107194724.GA14373@argon.home.lichteblau.com> Hi, McCLIM CVS now has experimental support for 32 bit RGBA images, based on Closure's AIMAGE code. Both API and implementation are up for discussion, and I would be glad to receive feedback. One API issue is that Closure draws aimages to CLX pixmaps, and keeps a cache of these pixmaps. To keep this cache functional, I decided to put medium-specific data into the design instances used to draw images. Normally designs are not bound to a particular medium, and existing code for indexed-pattern does not expose its caching to the user. Perhaps a better implementation strategy could be used for both rgb-image-design and indexed-pattern? More serious perhaps is the current implementation's limitation to true color visuals. Closure itself had sophisticated support for all kinds of X11 visuals, including dithering algorithms. The routines used there are similar to the code found in CLIM-CLX's indexed-pattern implementation. Basically, code suitable for the current colormap is compiled at runtime into a function that maps abstract colors and x/y coordinates to X11 colors. (This code can be found in closure/src/renderer/x11.lisp) Perhaps someone who understand the indexed-pattern drawing routines knows what the right approach to this is. Should x11.lisp be moved into McCLIM? Can it be merged with the code that Backends/CLX/medium.lisp already has? Thanks, David From rpgoldman at real-time.com Mon Jan 8 01:31:41 2007 From: rpgoldman at real-time.com (Robert Goldman) Date: Sun, 07 Jan 2007 19:31:41 -0600 Subject: [mcclim-devel] modified clim Spec latex In-Reply-To: <459E8FD1.4000805@real-time.com> References: <459E8FD1.4000805@real-time.com> Message-ID: <45A19EFD.5090300@real-time.com> Robert Goldman wrote: > I have modified the clim spec to load its images through includegraphics > rather than through epsfig, making it equally usable through pdflatex > and latex. In pdflatex, I additionally tweaked it to generate > hyperlinks, making it easier to read the document online. > > Anyone have any objections to my committing these changes? > There was no chorus of outrage, so I have committed the modifications to the LaTeX source. Should work with latex as before and now pdflatex as well. R From rpgoldman at real-time.com Mon Jan 8 17:11:29 2007 From: rpgoldman at real-time.com (Robert Goldman) Date: Mon, 08 Jan 2007 11:11:29 -0600 Subject: [mcclim-devel] presentation-subtypep Message-ID: <45A27B41.1040907@real-time.com> With Xof's help, I have butchered the definition of presentation-subtypep in McCLIM to hand AND types --- previously it only handled OR. Here is a draft new defun (apologies is wrapper gonks it) and, for those who prefer, I will attach (unless I forget again) a patch file: (defun presentation-subtypep (type maybe-supertype) (when (equal type maybe-supertype) (return-from presentation-subtypep (values t t))) (with-presentation-type-decoded (super-name super-parameters) maybe-supertype (when (eq super-name 'or) (loop for or-type in super-parameters when (presentation-subtypep type or-type) do (return-from presentation-subtypep (values t t)) finally (return-from presentation-subtypep (values nil t)))) (when (eq super-name 'satisfies) (return-from presentation-subtypep (values nil nil))) (with-presentation-type-decoded (sub-name sub-parameters) type (when (eq sub-name 'and) (loop for and-type in sub-parameters with subtypep and knownp with answer-knownp = t do (multiple-value-setq (subtypep knownp) (presentation-subtypep and-type maybe-supertype)) if subtypep do (return-from presentation-subtypep (values t t)) else ; track whether we know the answer do (setf answer-knownp (and answer-knownp knownp)) finally (return-from presentation-subtypep (values nil answer-knownp))))) (map-over-presentation-type-supertypes #'(lambda (name massaged) (when (eq name super-name) (return-from presentation-subtypep (funcall-presentation-generic-function presentation-subtypep massaged maybe-supertype)))) type)) (values nil t)) -------------- next part -------------- A non-text attachment was scrubbed... Name: presentation-subtypep.patch Type: text/x-patch Size: 2758 bytes Desc: not available URL: From rpgoldman at real-time.com Tue Jan 9 03:30:44 2007 From: rpgoldman at real-time.com (Robert Goldman) Date: Mon, 08 Jan 2007 21:30:44 -0600 Subject: [mcclim-devel] file-browser demo program Message-ID: <45A30C64.5050401@real-time.com> I have committed a working, but undesirable version of the demo. This one fixes some bugs that weren't really CLIM bugs, per se, but were either incorrect, or at least unportable, treatments of CL pathnames. A remaining problem is that the file-browser would try to edit (really list) directories on any pathname, not just directory pathnames. My attempt to fix this originally relied (I think correctly), on the use of a presentation type of (and pathname (satisfies cl-fad:directory-pathname-p)). Unfortunately, and and satisfies presentation types don't work properly in McCLIM. For now, I have also committed this alternative version for reference as file-browser.lisp-type-abbrev. It could become the real version when the presentation types are fully fixed. Sorry to leave things like this, but I will probably be unable to work on McCLIM again for a week or so, so thought it would be best to leave things at least *better*, if not fully fixed. Cheers, R From csr21 at cantab.net Tue Jan 9 14:32:14 2007 From: csr21 at cantab.net (Christophe Rhodes) Date: Tue, 09 Jan 2007 14:32:14 +0000 Subject: [mcclim-devel] presentation-subtypep In-Reply-To: <45A27B41.1040907@real-time.com> (Robert Goldman's message of "Mon, 08 Jan 2007 11:11:29 -0600") References: <45A27B41.1040907@real-time.com> Message-ID: <87ps9ofez5.fsf@cantab.net> Robert Goldman writes: > With Xof's help, I have butchered the definition of > presentation-subtypep in McCLIM to hand AND types --- previously it only > handled OR. Here is a draft new defun (apologies is wrapper gonks it) > and, for those who prefer, I will attach (unless I forget again) a patch > file: I think that the attached is better, but it still is not perfect. (I will commit it unless I hear screams of pain, though). It comes in two parts (plus some tests): * modifications to PRESENTATION-SUBTYPEP and STUPID-SUBTYPEP to handle most cases of AND and OR presentation types. Some of the cases are about as good as we can get; there's room for improvement in others. There are a few surprises lurking in the definitions of presentation types and their relationships: they don't correspond directly to CL types, so some of the instincts about those are misleading; AND types are somewhat special, in that the first parameter of an AND type is magical. * a modification to DEFAULT-TRANSLATOR to try to get the right behaviour for complicated presentation types. It's not quite right, but actually I think that to get it completely right involves solving SATISFIABILITY, which isn't in my gameplan. This seems to mostly work; the test file which is included in the attached diff passes. A further test at the listener is (present "abc" 'string) (present "def" 'string) (defun foop (x) (char= (char x 0) #\a)) (with-input-context ('(and string (satisfies foop))) (obj otype ev opts) (loop (read-char)) (t obj)) which makes only the "abc" string and not the "def" string mousable. Unfortunately, (accept '(and string (satisfies foop))) doesn't work as expected, as the accept method for AND establishes an inner input-context for STRING, which means that the "def" string is mousable (and causes an error if you click on it). Would something like (define-presentation-method accept ((type and) (stream input-editing-stream) (view textual-view) &key) (let ((subtype (first types))) (multiple-value-bind (ob ty) (funcall-presentation-generic-function accept subtype stream view) (unless (presentation-typep ob type) (simple-parse-error "Object ~S is not of type ~S" ob type)) value))) be acceptable (haha)? It seems to work for me, in that after I define this (accept '(and string (satisfies foop))) makes only the strings beginning with #\a mousable, but I don't know how to handle the keyword arguments (or even if they've already been handled by stuff up the stack). -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: presentation-types.diff URL: -------------- next part -------------- Cheers, Christophe From csr21 at cantab.net Tue Jan 9 15:22:39 2007 From: csr21 at cantab.net (Christophe Rhodes) Date: Tue, 09 Jan 2007 15:22:39 +0000 Subject: [mcclim-devel] Drei(?) problems Message-ID: <87lkkcfcn4.fsf@cantab.net> Hi, In the listener, if I do (defun foo (x) x) and then (clim:accept 'symbol), then wave my mouse around, I get an error from the CLIM-LISTENER:SYMBOL-TO-CLASS-NAME translator, saying that "symbol" isn't a valid argument to find-class. This comes about because of what I believe are two Drei bugs. One is that the unknown-symbol shouldn't inherit from symbol, as the presentation object is not in fact a symbol (and so presentation methods expecting it to be will lose). The other is that FORM-TO-OBJECT methods on token (symbolish?) lexemes seem not to return enough values to satisfy the DISPLAY-PARSE-TREE method on TOKEN-MIXIN, which means that every token gets presented as an unknown-symbol, with the presentation object being the unparsed string. I don't really know what the UNKNOWN-SYMBOL presentation type is for, but maybe it should inherit from STRING instead of SYMBOL? Cheers, Christophe From csr21 at cantab.net Tue Jan 9 15:24:01 2007 From: csr21 at cantab.net (Christophe Rhodes) Date: Tue, 09 Jan 2007 15:24:01 +0000 Subject: [mcclim-devel] T presentation-type Message-ID: <87hcv0fcku.fsf@cantab.net> Hi, While I'm on the bug reporting bandwagon, doing (clim:accept t) at the listener errors from NO-APPLICABLE-METHOD: There is no applicable method for the generic function # when called with arguments (#). This is probably because of the magical nature of T. Cheers, Christophe From rpgoldman at real-time.com Tue Jan 9 18:52:39 2007 From: rpgoldman at real-time.com (Robert Goldman) Date: Tue, 09 Jan 2007 12:52:39 -0600 Subject: [mcclim-devel] T presentation-type In-Reply-To: <87hcv0fcku.fsf@cantab.net> References: <87hcv0fcku.fsf@cantab.net> Message-ID: <45A3E477.2010609@real-time.com> Christophe Rhodes wrote: > Hi, > > While I'm on the bug reporting bandwagon, doing > (clim:accept t) > at the listener errors from NO-APPLICABLE-METHOD: > There is no applicable method for the generic function > # > when called with arguments > (#). > > This is probably because of the magical nature of T. > Do we have any plans to get some sort of McCLIM bug-tracker? A bugzilla or trac system? I'm not a huge fan of adding more gunk to the development process, but counting on people hand-editing the CLIKI or groveling over the mailing list archives doesn't seem like the right thing, either. Best, Robert From metawilm at gmail.com Wed Jan 10 09:05:48 2007 From: metawilm at gmail.com (Willem Broekema) Date: Wed, 10 Jan 2007 10:05:48 +0100 Subject: [mcclim-devel] T presentation-type In-Reply-To: <45A3E477.2010609@real-time.com> References: <87hcv0fcku.fsf@cantab.net> <45A3E477.2010609@real-time.com> Message-ID: On 1/9/07, Robert Goldman wrote: > Do we have any plans to get some sort of McCLIM bug-tracker? A bugzilla > or trac system? I'm not a huge fan of adding more gunk to the > development process, but counting on people hand-editing the CLIKI or > groveling over the mailing list archives doesn't seem like the right > thing, either. As the project is already on common-lisp.net, you could easily ask for Trac to be added. Cheers, - Willem From asf at boinkor.net Thu Jan 11 11:10:53 2007 From: asf at boinkor.net (Andreas Fuchs) Date: Thu, 11 Jan 2007 12:10:53 +0100 Subject: [mcclim-devel] mcclim 0.9.4 freeze Message-ID: <45A61B3D.40104@boinkor.net> Hi there, reliable sources tell me that it's time for another release. The next holiday is jan 14th, the Orthodox New Year, and I'd like to release 0.9.4 on this day. This mail marks the start of the freeze period. Please test as aggressively as you can, and keep changes to the core of mcclim to a minimum (of course, documentation improvements are always welcome). Cheers, -- Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs From athas at sigkill.dk Thu Jan 11 13:32:49 2007 From: athas at sigkill.dk (Troels Henriksen) Date: Thu, 11 Jan 2007 14:32:49 +0100 Subject: [mcclim-devel] mcclim 0.9.4 freeze Message-ID: <5f96e3d5e4edd61f5e84b7011f2b0eee@130.225.96.2> > Hi there, > > reliable sources tell me that it's time for another release. The next > holiday is jan 14th, the Orthodox New Year, and I'd like to release > 0.9.4 on this day. "McCLIM 0.9.4 Orthodox New Year"? > This mail marks the start of the freeze period. Please test as > aggressively as you can, and keep changes to the core of mcclim to a > minimum (of course, documentation improvements are always welcome). It may be necessary to turn Drei off by default, as there are still some somewhat-serious problems: * Reader macros are poorly handled by the Lisp syntax, leading to possible Listener breakage. * Delimiter gestures do not work properly for some reason (rtoy has been affected by this). * Sometimes, Lisp syntax is not properly enabled when the input buffer is changed via the presentation history or similar. * Sometimes, Drei will move its output record when stuff is inserted. I *suspect* this is not the same bug as the one triggered by Closure. Apart from that, great! There's been quite a bunch of changes over the last months, so it's a good time to do a release I think. From gilham at csl.sri.com Thu Jan 11 14:47:32 2007 From: gilham at csl.sri.com (Fred Gilham) Date: Thu, 11 Jan 2007 06:47:32 -0800 Subject: [mcclim-devel] mcclim 0.9.4 freeze In-Reply-To: <45A61B3D.40104@boinkor.net> References: <45A61B3D.40104@boinkor.net> Message-ID: <48290.1168526852@snapdragon.csl.sri.com> Hi, There's a conditionalization for CMUCL in Apps/Listener/cmu-hacks.lisp to allow overriding package locks. (#+CMU19C ext:without-package-locks #-CMU19C progn It would be nice to get rid of the conditionalization. I doubt that ext:without-package-locks will be going away in future releases. I'm pretty sure package locks were in all versions of cmucl 19 and some versions of 18. -- Fred Gilham gilham at csl.sri.com Thou shalt not convince stupid people to try cordless bungee jumping.... Thou shalt not substitute Semtex when all the Playdough's gone.... Thou shalt not bob for hand grenades.... From csr21 at cantab.net Fri Jan 12 11:30:02 2007 From: csr21 at cantab.net (Christophe Rhodes) Date: Fri, 12 Jan 2007 11:30:02 +0000 Subject: [mcclim-devel] mcclim 0.9.4 freeze In-Reply-To: <5f96e3d5e4edd61f5e84b7011f2b0eee@130.225.96.2> (Troels Henriksen's message of "Thu, 11 Jan 2007 14:32:49 +0100") References: <5f96e3d5e4edd61f5e84b7011f2b0eee@130.225.96.2> Message-ID: <87bql4cwjp.fsf@cantab.net> Troels Henriksen writes: > It may be necessary to turn Drei off by default, as there are still some > somewhat-serious problems: > > * Reader macros are poorly handled by the Lisp syntax, leading to possible > Listener breakage. > * Delimiter gestures do not work properly for some reason (rtoy has been > affected by this). > * Sometimes, Lisp syntax is not properly enabled when the input buffer is > changed via the presentation history or similar. > * Sometimes, Drei will move its output record when stuff is inserted. I > *suspect* this is not the same bug as the one triggered by Closure. Would it be OK by you to leave *use-goatee* as nil, but mention these problems prominently in the release notes? (The major points of a release, at least from my point of view, are to have a reference point in time, and to have an excuse to make an announcement; if we can get people to run the code, their feedback might help to narrow down the causes of various problems... but they're most likely to start by running the system in its default configuration). Cheers, Christophe From splittist at yahoo.com Sat Jan 13 09:19:08 2007 From: splittist at yahoo.com (John Q Splittist) Date: Sat, 13 Jan 2007 10:19:08 +0100 Subject: [mcclim-devel] Re: mcclim 0.9.4 freeze In-Reply-To: <87bql4cwjp.fsf@cantab.net> References: <5f96e3d5e4edd61f5e84b7011f2b0eee@130.225.96.2> <87bql4cwjp.fsf@cantab.net> Message-ID: Christophe Rhodes wrote: > Troels Henriksen writes: > >> It may be necessary to turn Drei off by default, as there are still some >> somewhat-serious problems: >> >> * Reader macros... >> * Delimiter gestures do not work properly ... >> * Sometimes, Lisp syntax is not properly enabled ... >> * Sometimes, Drei will move its output record when stuff is inserted.... > > Would it be OK by you to leave *use-goatee* as nil, but mention these > problems prominently in the release notes? FWIW, I agree with Christophe's suggestion. Drei is, in a way, far more McClim-ish than Goatee, and I think enabling it by default is genuine progress (if not on every dimension at once). (All the 'problems' above could be prefaced with 'Sometimes'...) JQS From athas at sigkill.dk Sat Jan 13 19:03:50 2007 From: athas at sigkill.dk (Troels Henriksen) Date: Sat, 13 Jan 2007 20:03:50 +0100 Subject: [mcclim-devel] Re: mcclim 0.9.4 freeze In-Reply-To: (John Q. Splittist's message of "Sat, 13 Jan 2007 10:19:08 +0100") References: <5f96e3d5e4edd61f5e84b7011f2b0eee@130.225.96.2> <87bql4cwjp.fsf@cantab.net> Message-ID: <87ps9ioijt.fsf@sigkill.dk> John Q Splittist writes: > FWIW, I agree with Christophe's suggestion. Okay, then that's how it's going to be. I just dislike the notion of making a release and a few days afterwards tell people to use the CVS version if they want their bug to go away. -- \ Troels "Athas" /\ Henriksen From kilian.sprotte at googlemail.com Sun Jan 14 13:01:12 2007 From: kilian.sprotte at googlemail.com (Kilian Sprotte) Date: Sun, 14 Jan 2007 14:01:12 +0100 Subject: [mcclim-devel] mcclim 0.9.4 freeze trivia Message-ID: <1d26dc7e0701140501s7565c78bi1951ae4a338a388d@mail.gmail.com> Hi, my concerns are centered around mcclim.asd for the moment... I just wanted to let you know that the current (defsystem :drei-mcclim ...) form is unREADable for openmcl. This is due to (mcclim.system::dep-on-swank) returning (or), which it does not seem to like in this context. The other thing is that asdf-binary-locations seems to have a problem with (:file "Extensions/rgb-image"), but that's probably a bug over there... Greetings, Kilian From rydis at cd.chalmers.se Sun Jan 14 13:04:47 2007 From: rydis at cd.chalmers.se (Martin Rydstr|m) Date: Sun, 14 Jan 2007 14:04:47 +0100 Subject: [mcclim-devel] mcclim 0.9.4 freeze trivia In-Reply-To: <1d26dc7e0701140501s7565c78bi1951ae4a338a388d@mail.gmail.com> References: <1d26dc7e0701140501s7565c78bi1951ae4a338a388d@mail.gmail.com> Message-ID: <20070114130447.GI4210@haddock.cd.chalmers.se> On Sun, Jan 14, 2007 at 02:01:12PM +0100, Kilian Sprotte wrote: > The other thing is that asdf-binary-locations seems to have a problem > with (:file "Extensions/rgb-image"), but that's probably a bug over > there... It doesn't work in my plain ASDF under CMUCL, either. I added stuff similar to "Goatee/presentation-history", a few lines above it. Regards, ',mr -- rydis (Martin Rydstr?m) @CD.Chalmers.SE http://www.rydis.se [Emacs] is written in Lisp, which is the only computer language that is beautiful. -- Neal Stephenson, _In the Beginning was the Command Line_ From athas at sigkill.dk Sun Jan 14 18:34:02 2007 From: athas at sigkill.dk (Troels Henriksen) Date: Sun, 14 Jan 2007 19:34:02 +0100 Subject: [mcclim-devel] mcclim 0.9.4 freeze trivia In-Reply-To: <1d26dc7e0701140501s7565c78bi1951ae4a338a388d@mail.gmail.com> (Kilian Sprotte's message of "Sun, 14 Jan 2007 14:01:12 +0100") References: <1d26dc7e0701140501s7565c78bi1951ae4a338a388d@mail.gmail.com> Message-ID: <87y7o5wj8l.fsf@sigkill.dk> "Kilian Sprotte" writes: > I just wanted to let you know that the current (defsystem :drei-mcclim ...) > form is unREADable for openmcl. This is due to (mcclim.system::dep-on-swank) > returning (or), which it does not seem to like in this context. I committed what I think is a fix (but I don't have OpenMCL and can't test it properly). > The other thing is that asdf-binary-locations seems to have a problem > with (:file "Extensions/rgb-image"), but that's probably a bug over > there... Nope, that was our problem too. Should be fixed now. -- \ Troels "Athas" /\ Henriksen From kilian.sprotte at googlemail.com Sun Jan 14 20:51:30 2007 From: kilian.sprotte at googlemail.com (Kilian Sprotte) Date: Sun, 14 Jan 2007 21:51:30 +0100 Subject: [mcclim-devel] mcclim 0.9.4 freeze trivia In-Reply-To: <87y7o5wj8l.fsf@sigkill.dk> References: <1d26dc7e0701140501s7565c78bi1951ae4a338a388d@mail.gmail.com> <87y7o5wj8l.fsf@sigkill.dk> Message-ID: <1d26dc7e0701141251h4fca8a5at9b2bcfdc0e9c274@mail.gmail.com> Hi, thanks! :) Its compiling and loading with sbcl and openmcl now (+ asdf-binary-locations). Cheers, Kilian PS: I have only been working with the last release and I must tell you that I /really/ like Drei !! On 1/14/07, Troels Henriksen wrote: > "Kilian Sprotte" writes: > > > I just wanted to let you know that the current (defsystem :drei-mcclim ...) > > form is unREADable for openmcl. This is due to (mcclim.system::dep-on-swank) > > returning (or), which it does not seem to like in this context. > > I committed what I think is a fix (but I don't have OpenMCL and can't > test it properly). > > > The other thing is that asdf-binary-locations seems to have a problem > > with (:file "Extensions/rgb-image"), but that's probably a bug over > > there... > > Nope, that was our problem too. Should be fixed now. > > -- > \ Troels "Athas" > /\ Henriksen > From mcclim-devel at common-lisp.net Sun Jan 14 22:32:28 2007 From: mcclim-devel at common-lisp.net (McCLIM developers) Date: Sun, 14 Jan 2007 23:32:28 +0100 Subject: [mcclim-devel] McCLIM 0.9.4 released! Message-ID: <45AAAF7C.9040509@common-lisp.net> The McCLIM developers are happy to release version 0.9.4 of McCLIM, code-named "Orthodox New Year". This release was tested and found to work on the following implementations: This release includes some great improvements, from a new editor substrate ("DREI") to many cool new features in the Gtkairo backend, and many compatibility enhancements and extensions to the core of McCLIM. Note that due to the radical changes introduced by the new editor substrate, some bugs may surface in day-to-day use. Refer to the section "Known Bugs" in the included release notes for details. When testing this release, we found that it works on the following implementations: * SBCL * OpenMCL * CLISP * Allegro Common Lisp 8.0 in ANSI Mode For compatibility with other implementations, please see the attached release notes. Get the tarball at or install McCLIM via asdf-install. We are looking forward to your comments and bug reports. Please send them to mcclim-devel at common-lisp.net. The list of currently known bugs can be found at . Have fun using McCLIM, The McCLIM developers. RELEASE NOTES FOR McCLIM 0.9.4, "Orthodox New Year": Compatibility ============= This release was tested and found to work on the following implementations: * SBCL * OpenMCL * CLISP * Allegro Common Lisp 8.0 in ANSI Mode In our tests, this release of McCLIM did not work on the following implementations: * CMUCL (at the time of this release, the released CMUCL has a bug that prevents successful loading of McCLIM; CMUCL 19d + patch 1 and the 2006-12 snapshot or later contain a fix for this problem) Also, McCLIM currently does not support lisps with case-sensitive readers (ACL "modern mode" and lower-case SCL). Known Bugs ========== Due to the radical changes introduced by the new editor substrate, some bugs may surface in day-to-day use. We would very much like to hear about them on mcclim-devel at common-lisp.net. As a work-around, you can enable the old input substrate by using (setf climi::*use-goatee* t) on the REPL when clim is loaded. The following bugs are known to exist: * McCLIM freetype can interact poorly with Drei under some circumstances * Drei does not handle most reader macros well * Sometimes, the ENTER key is not very responsive when editing forms with Drei * Calling stream-input-buffer is still buggy. Changes in mcclim-0.9.4 "Orthodox New Year" relative to 0.9.3: ============================================================== >From the NEWS file: * cleanup: removed the obsolete system.lisp file. * backend improvements: Gtkairo ** Double buffering is now supported (fixes disappearing widgets on Windows). ** X errors no longer terminate the lisp process. ** Some bugfixes, including CMUCL support and better key event handling. ** Native implementation of context menus, list panes, label panes, and option panes. ** Draw text using Pango. (Bug fix: Fixed-width font supported on Windows now. Multiple lines of output in TEXT-SIZE supported now. TEXT-STYLE-FIXED-WIDTH-P works correctly now.) * Improvement: Added new editor substrate ("Drei"). * Improvement: Improved the pathname presentation methods considerably. * specification compliance: DELETE-GESTURE-NAME function now implemented. * specification compliance: PRESENTATION-TYPE-SPECIFIER-P presentaion function now implemented. * specification compliance: DISPLAY-COMMAND-TABLE-MENU function now implemented. * specification compliance: DISPLAY-COMMAND-MENU function now implemented. * specification compliance: POINTER-PLACE-RUBBER-BAND-LINE* function now implemented. * specification compliance: POINTER-INPUT-RECTANGLE* function now implemented. * specification compliance: POINTER-INPUT-RECTANGLE function now implemented. * Improvement: Added font listing support, see section "Fonts and Extended Text Styles" in the manual. * Improvement: Added support for bezier splines (Robert Strandh). To be documented. * better PRESENTATION-SUBTYPEP (more likely to give the right answer on some-of and all-of presentation types) * Improvement: M-n/M-p gestures for navigating presentation histories. From asf at boinkor.net Mon Jan 15 16:06:15 2007 From: asf at boinkor.net (Andreas Fuchs) Date: Mon, 15 Jan 2007 17:06:15 +0100 Subject: [mcclim-devel] splitting mcclim.asd Message-ID: <45ABA677.4020103@boinkor.net> Hi all, I am planning to split mcclim.asd into several .asd files in mcclim's top level directory, for the clim listener, scigraph, the examples, and clouseau. This will allow the asdf-installs of the next release to automatically link these systems into the asdf:*central-registry*. Why is this a good thing? It allows users to load the clim listener without loading mcclim first; also, it allows applications to (in their asdf systems) :depend-on clouseau or the clim-listener if they need it, and remain asdf-installable - provided that we also create a cliki page for these top level systems (which I intend to do). Why is this a bad thing? If you had a setup of mcclim with symlinks to mcclim.asd like this: ~/.sbcl/systems/clim-listener.asd -> /path/to/mcclim.asd (like, I think, the README recommended once), your setup will break, and you won't be able to load the clim listener anymore. The attached symlink-asd-files.sh is a shell script that should fix this problem, and let users of CVS set up their symlinks just as if they had used asdf-install of a future release. I plan to commit it along with the change. Attached, find the new .asd files. I hope you don't find them too appalling (: Oh, and one more nice thing: This setup would also allow easier installation and setup of gtkairo and Beagle; if nobody objects, I'm going to move gtkairo's asd file into the top level, with another warning to the list. Cheers, -- Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: symlink-asd-files.sh URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: mcclim.asd URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: clouseau.asd URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: scigraph.asd URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: clim-listener.asd URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: clim-examples.asd URL: From asf at boinkor.net Mon Jan 15 16:12:54 2007 From: asf at boinkor.net (Andreas Fuchs) Date: Mon, 15 Jan 2007 17:12:54 +0100 Subject: [mcclim-devel] splitting mcclim.asd In-Reply-To: <45ABA677.4020103@boinkor.net> References: <45ABA677.4020103@boinkor.net> Message-ID: <45ABA806.3030906@boinkor.net> Andreas Fuchs wrote: > if [ -f "$CENTRAL_REG"/"$i" ]; then Watch me make a fool of myself. The above shell script has a bug; the -f above should be a -e. Please use the attached file instead. -- Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: symlink-asd-files.sh URL: From csr21 at cantab.net Tue Jan 16 21:16:29 2007 From: csr21 at cantab.net (Christophe Rhodes) Date: Tue, 16 Jan 2007 21:16:29 +0000 Subject: [mcclim-devel] drei-syntax:use-editor-commands-p Message-ID: <87d55ept8y.fsf@cantab.net> Hi, Should drei-syntax:use-editor-commands-p have an additional method specialized on command-table, returning nil? I just got an error from it being called on a non-syntax-command-table. (I'm afraid that the manual is a little too brief on how to use syntax-command-table; what is the intent here? I am working on adapting our existing tablature editor code into something a little more integrated and less hacky: an application with an embedded drei and a display window, with all the functionality of the existing application and none of the window-streams which are uncloseable once the primary application has been closed...) Cheers, Christophe From asf at boinkor.net Thu Jan 18 15:04:18 2007 From: asf at boinkor.net (Andreas Fuchs) Date: Thu, 18 Jan 2007 16:04:18 +0100 Subject: [mcclim-devel] splitting mcclim.asd In-Reply-To: <45ABA677.4020103@boinkor.net> References: <45ABA677.4020103@boinkor.net> Message-ID: <45AF8C72.40004@boinkor.net> Andreas Fuchs wrote: > Why is this a good thing? It allows users to load the clim listener > without loading mcclim first; also, it allows applications to (in their > asdf systems) :depend-on clouseau or the clim-listener if they need it, > and remain asdf-installable - provided that we also create a cliki page > for these top level systems (which I intend to do). > > Why is this a bad thing? If you had a setup of mcclim with symlinks to > mcclim.asd like this: This is now committed. If your setup is broken after updating (e.g. (asdf:oos 'asdf:load-op :clim-listener) breaks), run the script "symlink-asd-files.sh". -- Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs From csr21 at cantab.net Thu Jan 18 15:15:20 2007 From: csr21 at cantab.net (Christophe Rhodes) Date: Thu, 18 Jan 2007 15:15:20 +0000 Subject: [mcclim-devel] Drei and input focus Message-ID: <87wt3kv01j.fsf@cantab.net> Hi, I am pretty sure that Drei gadgets are doing something naughty with input focus. My X11 window manager has focus-follows-mouse (well, strictly, sloppy focus) for top-level windows. If I make a CLIM application containing a drei pane, then the application window will steal focus: if I have my mouse over the drei buffer, and then move it into a window which is above some portion of the drei pane, that window will get focus for a brief moment, and then the drei application will take it back... Cheers, Christophe From athas at sigkill.dk Thu Jan 18 21:44:24 2007 From: athas at sigkill.dk (Troels Henriksen) Date: Thu, 18 Jan 2007 22:44:24 +0100 Subject: [mcclim-devel] Drei and input focus In-Reply-To: <87wt3kv01j.fsf@cantab.net> (Christophe Rhodes's message of "Thu, 18 Jan 2007 15:15:20 +0000") References: <87wt3kv01j.fsf@cantab.net> Message-ID: <871wlsqabr.fsf@sigkill.dk> Christophe Rhodes writes: > I am pretty sure that Drei gadgets are doing something naughty with > input focus. Does Goatee do the same thing for you? Goatee had/has some ugly keyboard-focus grabbing code that I initially didn't copy over to Drei because it seemed to work in my window manager (ratpoison), but people complained that Drei failed to receive keyboard gestures, so I moved it over verbatim (I hope). I'm not really sure why it's necessary, but I'm pretty sure it's very ugly. -- \ Troels "Athas" /\ Henriksen From athas at sigkill.dk Thu Jan 18 22:36:21 2007 From: athas at sigkill.dk (Troels Henriksen) Date: Thu, 18 Jan 2007 23:36:21 +0100 Subject: [mcclim-devel] Drei and input focus In-Reply-To: <871wlsqabr.fsf@sigkill.dk> (Troels Henriksen's message of "Thu, 18 Jan 2007 22:44:24 +0100") References: <87wt3kv01j.fsf@cantab.net> <871wlsqabr.fsf@sigkill.dk> Message-ID: <87tzyootcq.fsf@sigkill.dk> Troels Henriksen writes: > I'm not really sure why it's necessary, but I'm pretty sure it's > very ugly. The attached simple patch seems to make everything work properly, and removes the need for explicit management of keyboard focus in Drei and Goatee, but because of its simplicity, and my lack of knowledge about CLX, I'd like a review before I commit it and make a fool out of myself: -- \ Troels "Athas" /\ Henriksen -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pointer-focus-patch.diff URL: From csr21 at cantab.net Fri Jan 19 09:31:52 2007 From: csr21 at cantab.net (Christophe Rhodes) Date: Fri, 19 Jan 2007 09:31:52 +0000 Subject: [mcclim-devel] Drei and input focus In-Reply-To: <87tzyootcq.fsf@sigkill.dk> (Troels Henriksen's message of "Thu, 18 Jan 2007 23:36:21 +0100") References: <87wt3kv01j.fsf@cantab.net> <871wlsqabr.fsf@sigkill.dk> <87tzyootcq.fsf@sigkill.dk> Message-ID: <874pqnqs53.fsf@cantab.net> Troels Henriksen writes: > Troels Henriksen writes: > >> I'm not really sure why it's necessary, but I'm pretty sure it's >> very ugly. > > The attached simple patch seems to make everything work properly, and > removes the need for explicit management of keyboard focus in Drei and > Goatee, but because of its simplicity, and my lack of knowledge about > CLX, I'd like a review before I commit it and make a fool out of > myself: I don't think that this makes a fool out of you, but I also don't think it's the Right Thing. > (defmethod %set-port-keyboard-focus ((port clx-port) focus &key timestamp) > (let ((mirror (sheet-mirror focus))) > (when mirror > - (xlib:set-input-focus (clx-port-display port) mirror :parent timestamp)))) > + (xlib:set-input-focus (clx-port-display port) :pointer-root :parent timestamp)))) This is in the nature of a workaround: setting the focus to whatever toplevel window is under the pointer. That might work by coincidence for many applications, in the case that I described in my original mail, but I don't think it's defined to work: if the window over which I have moved my mouse has multiple input widgets, it's not clear which will win the focus battle, if that application is not programmed such that the toplevel window will distribute events to its children. I think the Right Thing is tricky to implement. What needs to happen is that the X event which caused Drei to become disarmed needs to be propagated through to the disarmed callback and back out again, so that the timestamp field of the set-input-focus request is set to the timestamp of that event. The key point is that this allows the X server to discard a set-input-focus request with a timestamp that is earlier than a request that has already been dealt with, which is exactly the behaviour we want. (There's much detail about this in the ICCCM document available in the xspecs package on Ubuntu and elsewhere). Well, I say the "Right Thing": _clearly_ the right thing is to abandon this horrific focus-follows-mouse-around-widgets disaster and implement a sane keyboard focus policy. Then much of the complexity can go away. Hooray. (What did Classic CLIM do?) Cheers, Christophe From csr21 at cantab.net Fri Jan 19 13:45:43 2007 From: csr21 at cantab.net (Christophe Rhodes) Date: Fri, 19 Jan 2007 13:45:43 +0000 Subject: [mcclim-devel] Drei, again Message-ID: <878xfzt9iw.fsf@cantab.net> Hi, This time, I have a problem with drei-panes: I would like to specify a fixed width, but adding :max-width 200 :min-width 200 :width 200 didn't seem to clamp the drei gadget's width -- it just grows and shrinks as before. Where should I start looking to fix this? Cheers, Christophe From ahefner at gmail.com Fri Jan 19 15:55:43 2007 From: ahefner at gmail.com (Andy Hefner) Date: Fri, 19 Jan 2007 10:55:43 -0500 Subject: [mcclim-devel] Drei, again In-Reply-To: <878xfzt9iw.fsf@cantab.net> References: <878xfzt9iw.fsf@cantab.net> Message-ID: <31ffd3c40701190755u7119ab8x6d5c8bdef1b10ac3@mail.gmail.com> On 1/19/07, Christophe Rhodes wrote: > This time, I have a problem with drei-panes: I would like to specify a > fixed width, but adding :max-width 200 :min-width 200 :width 200 > didn't seem to clamp the drei gadget's width -- it just grows and > shrinks as before. As a workaround, you might try putting the Drei pane inside a restraining-pane. I'm not 100% certain they work right, though, as I've never seriously used them. From athas at sigkill.dk Fri Jan 19 17:13:48 2007 From: athas at sigkill.dk (Troels Henriksen) Date: Fri, 19 Jan 2007 18:13:48 +0100 Subject: [mcclim-devel] Drei and input focus In-Reply-To: <874pqnqs53.fsf@cantab.net> (Christophe Rhodes's message of "Fri, 19 Jan 2007 09:31:52 +0000") References: <87wt3kv01j.fsf@cantab.net> <871wlsqabr.fsf@sigkill.dk> <87tzyootcq.fsf@sigkill.dk> <874pqnqs53.fsf@cantab.net> Message-ID: <87ps9bj5wz.fsf@sigkill.dk> Christophe Rhodes writes: > I don't think that this makes a fool out of you, but I also don't > think it's the Right Thing. Is it better than the Old Wrong Thing? If so, it might be an acceptable interim fix. > This is in the nature of a workaround: setting the focus to whatever > toplevel window is under the pointer. That might work by coincidence > for many applications, in the case that I described in my original > mail, but I don't think it's defined to work: if the window over which > I have moved my mouse has multiple input widgets, it's not clear which > will win the focus battle, if that application is not programmed such > that the toplevel window will distribute events to its children. Well, fortunately McCLIM is programmed to do this. :-) AFACS, this would not affect any other programs on the X server. -- \ Troels "Athas" /\ Henriksen From ahefner at gmail.com Fri Jan 19 21:22:28 2007 From: ahefner at gmail.com (Andy Hefner) Date: Fri, 19 Jan 2007 16:22:28 -0500 Subject: [mcclim-devel] Drei and input focus In-Reply-To: <874pqnqs53.fsf@cantab.net> References: <87wt3kv01j.fsf@cantab.net> <871wlsqabr.fsf@sigkill.dk> <87tzyootcq.fsf@sigkill.dk> <874pqnqs53.fsf@cantab.net> Message-ID: <31ffd3c40701191322l14d146efpb28019e49c200c2f@mail.gmail.com> On 1/19/07, Christophe Rhodes wrote: > Well, I say the "Right Thing": _clearly_ the right thing is to abandon > this horrific focus-follows-mouse-around-widgets disaster and > implement a sane keyboard focus policy. Then much of the complexity > can go away. Hooray. (What did Classic CLIM do?) I'm not familiar with the horrors of the Goatee input focus kludge, but it seems straightforward to implement click-to-focus. I've attached a trivial test which demonstrates that this does indeed work (click to focus between two mock text-editor gadgets, although it is initially focus-follows-mouse until the focus is first assigned by clicking, as that simply seems to be what X does by default). There appear to be quite a few things left to do on the keyboard focus front. The frame already has a slot to store the focus, so we need to assign the correct initial focus when the frame is adopted. I also notice the correct timestamps do not reach xlib:set-keyboard-focus, which needs fixing. There's also the issue of how a gadget can detect when the window manager has taken the focus away, since there's no 'note' function for it that I'm aware of, and relatedly why my note-input-focus-changed doesn't appear to work, which I'd intended to note transfer of the assigned focus within an application. Then there's the fun parts, like cycling of focus with the tab key. -------------- next part -------------- A non-text attachment was scrubbed... Name: focus-experiment.lisp Type: text/x-lisp-source Size: 1199 bytes Desc: not available URL: From asf at boinkor.net Sat Jan 20 21:50:29 2007 From: asf at boinkor.net (Andreas Fuchs) Date: Sat, 20 Jan 2007 22:50:29 +0100 Subject: [mcclim-devel] more magical dependency analysis Message-ID: <45B28EA5.2000907@boinkor.net> Hi all, I just polished up asdf-dependency-grovel (http://www.cliki.net/asdf-dependency-grovel, now with added asdf-installability) and let it have its way with mcclim.asd. The result is a merged :clim system with 168 components and (apparently) working dependencies. (Yay!) Attached, you can find: * the updated mcclim.asd, * the clim system's components file, * the "master system definition" file used to generate the list (contains just serial definitions), and * a shell script to generate the components file from the master system definition. Drop these files in the top level directory of a recent cvs checkout of mcclim, and you can start testing stuff. (: To re-generate dependencies: 1. have sbcl 2. asdf-install asdf-dependency-grovel 3. run ./grovel-dependencies.sh 4. wait. I would like to hear your comments, especially on the maintainability of the serial definitions in mcclim-dependencies.lisp vs. the blood/sweat/tears hand-maintained dependencies in the old mcclim.asd. Cheers, -- Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: mcclim.asd URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: clim-components.lisp-expr URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: grovel-dependencies.sh URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: mcclim-dependencies.lisp URL: From ahefner at gmail.com Tue Jan 23 07:35:59 2007 From: ahefner at gmail.com (Andy Hefner) Date: Tue, 23 Jan 2007 02:35:59 -0500 Subject: [mcclim-devel] Re: [mcclim-cvs] CVS mcclim (scroll-extent vs. move-sheet) Message-ID: <31ffd3c40701222335mdcd8eb2nb6cfbdf813c560b@mail.gmail.com> On 10/28/06, thenriksen wrote: > + ;; XXX: We cannot use `scroll-extent', because McCLIM ignores it > + ;; unless the scrollee happens to be drawing. Very weird, should > + ;; be fixed. I think I finally deciphered the purpose of the method in recording.lisp which defines this odd behavior: to supress scrolling of the stream when recording output to an offscreen record (such as using with-output-to-output-record). This is a legitimate concern, and simply removing the method would be wrong. This suggests that output to an offscreen output record should also not cause the stream-pane to be resized. McCLIM does not guard against this case. The following program demonstrates the problem: (in-package :clim-user) (define-application-frame oops-1 () () (:pane (scrolling (:width 300 :height 300) (make-pane :application-pane :end-of-line-action :allow :end-of-page-action :allow :display-function (lambda (frame stream) (with-output-to-output-record (stream) (dotimes (i 200) (format stream "~&You never see this.~%"))) (format stream "All those scrollbars for this little line of text?~%")))))) The correct solution might involve checking that the open output record is connected to the stream output history, and supressing resizing and scrolling only if it is not (indicating offscreen drawing). Hmm. From rpgoldman at sift.info Wed Jan 24 16:02:27 2007 From: rpgoldman at sift.info (Robert P. Goldman) Date: Wed, 24 Jan 2007 10:02:27 -0600 Subject: [mcclim-devel] Problem with scrolling windows and repainting Message-ID: <45B78313.3030900@sift.info> I have a problem with scrolling not properly syncing with repaint, I believe. See the picture at http://rpgoldman.real-time.com/inspector-bug.png that shows that I can (in Clouseau, the CLIM inspector) scroll off to the right into what looks like space that is never painted, and so is just gray emptiness. -- Robert P. Goldman Senior Scientist Smart Information Flow Technologies (d/b/a SIFT, LLC) 211 N. First St., Suite 300 Minneapolis, MN 55401 Voice: (612) 384-3454 Email: rpgoldman at SIFT.info From athas at sigkill.dk Wed Jan 24 16:59:09 2007 From: athas at sigkill.dk (Troels Henriksen) Date: Wed, 24 Jan 2007 17:59:09 +0100 Subject: [mcclim-devel] Problem with scrolling windows and repainting In-Reply-To: <45B78313.3030900@sift.info> (Robert P. Goldman's message of "Wed, 24 Jan 2007 10:02:27 -0600") References: <45B78313.3030900@sift.info> Message-ID: <87k5zc744i.fsf@sigkill.dk> "Robert P. Goldman" writes: > I have a problem with scrolling not properly syncing with repaint, I > believe. See the picture at > http://rpgoldman.real-time.com/inspector-bug.png > that shows that I can (in Clouseau, the CLIM inspector) scroll off to > the right into what looks like space that is never painted, and so is > just gray emptiness. Yes, this is an ancient[1] bug. Sometimes, you can make it resize the sheet properly by forcing a redisplay (just click anywhere in Clouseau), sometimes you can't. Clouseau seems to trigger it reliably, but I recall seeing it in other applications too. [1] It has existed at least since I first tried McCLIM. -- \ Troels "Athas" /\ Henriksen From csr21 at cantab.net Thu Jan 25 17:10:55 2007 From: csr21 at cantab.net (Christophe Rhodes) Date: Thu, 25 Jan 2007 17:10:55 +0000 Subject: [mcclim-devel] Drei and input focus In-Reply-To: <31ffd3c40701191322l14d146efpb28019e49c200c2f@mail.gmail.com> (Andy Hefner's message of "Fri, 19 Jan 2007 16:22:28 -0500") References: <87wt3kv01j.fsf@cantab.net> <871wlsqabr.fsf@sigkill.dk> <87tzyootcq.fsf@sigkill.dk> <874pqnqs53.fsf@cantab.net> <31ffd3c40701191322l14d146efpb28019e49c200c2f@mail.gmail.com> Message-ID: <871wljhw0w.fsf@cantab.net> "Andy Hefner" writes: > On 1/19/07, Christophe Rhodes wrote: >> Well, I say the "Right Thing": _clearly_ the right thing is to abandon >> this horrific focus-follows-mouse-around-widgets disaster and >> implement a sane keyboard focus policy. Then much of the complexity >> can go away. Hooray. (What did Classic CLIM do?) > > I'm not familiar with the horrors of the Goatee input focus kludge, > but it seems straightforward to implement click-to-focus. I've > attached a trivial test which demonstrates that this does indeed work > (click to focus between two mock text-editor gadgets, although it is > initially focus-follows-mouse until the focus is first assigned by > clicking, as that simply seems to be what X does by default). I've attached a patch which implements click-to-focus fairly pervasively, without using the X focus mechanism. The basic idea is to separate out port-keyboard-input-focus, which mediates the X focus for top-level windows, and frame-keyboard-input-focus, which is a per-frame setting. This patch deviates from CLIM II in that stream-set-input-focus does not call port-keyboard-input-focus, but merely sets the per-frame slot; the CLX event handler is adjusted to place the proper sheet in keyboard events. The implementation of click-to-focus is kludgy. It's fine for drei-gadgets, and for text-gadgets generally; it's not so hot for general streams. I've taken the line that interactor-panes should be focusable with a click; somewhat to my surprise, you can't just write a method on handle-event to get this, but have to work with frame-input-context-button-press-handler. A potential gotcha is that I have not implented click-to-focus for application-panes; this may cause surprises, but it seemed to me the only way not to break the address book demo ;-) One new spec compliance is that initially keyboard focus really does go to *query-io*. This might cause some surprising behaviour. Somewhat to my surprise, gsharp seems to work -- maybe because its toplevel loop is different -- but ESAs with default-frame-top-level deliver keyboard events to the minibuffer by default, which isn't ideal. On the other hand, the focus behaviour of text gadgets is, to me, much nicer -- and there's no more focus stealing going on. I have to send this in a bit of a hurry; there's more I could say about this, but I'll be happy to hear comments. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: focus.diff URL: -------------- next part -------------- Cheers, Christophe From ahefner at gmail.com Thu Jan 25 18:24:09 2007 From: ahefner at gmail.com (Andy Hefner) Date: Thu, 25 Jan 2007 13:24:09 -0500 Subject: [mcclim-devel] Drei and input focus In-Reply-To: <871wljhw0w.fsf@cantab.net> References: <87wt3kv01j.fsf@cantab.net> <871wlsqabr.fsf@sigkill.dk> <87tzyootcq.fsf@sigkill.dk> <874pqnqs53.fsf@cantab.net> <31ffd3c40701191322l14d146efpb28019e49c200c2f@mail.gmail.com> <871wljhw0w.fsf@cantab.net> Message-ID: <31ffd3c40701251024p665ce748u77135b9a831c5753@mail.gmail.com> On 1/25/07, Christophe Rhodes wrote: > The implementation of click-to-focus is kludgy. It's fine for > drei-gadgets, and for text-gadgets generally; it's not so hot for > general streams. I've taken the line that interactor-panes should be > focusable with a click; somewhat to my surprise, you can't just write > a method on handle-event to get this, but have to work with > frame-input-context-button-press-handler. A potential gotcha is that > I have not implented click-to-focus for application-panes; this may > cause surprises, but it seemed to me the only way not to break the > address book demo ;-) The degree to which read-gesture separates the programmer from the interaction implemented by the stream via various button handling methods, functions bound in special variables, etc., has always made me nervous. It's somehow relieving to see it causing someone difficulty. Maybe we want a slot or method defined on those panes implementing click-to-focus behavior which determines whether they are currently focussable. An interactor-pane would default to t, application-pane nil. If nil, clicks would pass through and be handled as they are currently, without reassigning focus. This should preserve the behavior of the address book. I'm slightly concerned that because frame-input-context-button-press-handler is a function from the spec, users might expect that defining their own method for it would not to break input focus handling. Maybe focus handling should be pushed down into stream-read-gesture, but I'm not sure how/where. > One new spec compliance is that initially keyboard focus really does > go to *query-io*. This might cause some surprising behaviour. > Somewhat to my surprise, gsharp seems to work -- maybe because its > toplevel loop is different -- but ESAs with default-frame-top-level > deliver keyboard events to the minibuffer by default, which isn't > ideal. On the other hand, the focus behaviour of text gadgets is, to > me, much nicer -- and there's no more focus stealing going on. Hmm, that's tricky. Playing around yesterday, I'd added an :initial-input-focus initarg for the frame, but that only works in gadget-y applications where there is no query-io (otherwise run-frame-top-level uses that instead). Maybe we can just change how the specified behavior is achieved, so that (keyboard-input-focus frame) is nil by default, and focus is initially assigned to (or (keyboard-input-focus frame) (frame-query-io frame)) ? From ahefner at gmail.com Thu Jan 25 18:26:35 2007 From: ahefner at gmail.com (Andy Hefner) Date: Thu, 25 Jan 2007 13:26:35 -0500 Subject: [mcclim-devel] Drei and input focus In-Reply-To: <31ffd3c40701251024p665ce748u77135b9a831c5753@mail.gmail.com> References: <87wt3kv01j.fsf@cantab.net> <871wlsqabr.fsf@sigkill.dk> <87tzyootcq.fsf@sigkill.dk> <874pqnqs53.fsf@cantab.net> <31ffd3c40701191322l14d146efpb28019e49c200c2f@mail.gmail.com> <871wljhw0w.fsf@cantab.net> <31ffd3c40701251024p665ce748u77135b9a831c5753@mail.gmail.com> Message-ID: <31ffd3c40701251026u3b39cd04o6c00713c64660203@mail.gmail.com> On 1/25/07, Andy Hefner wrote: > I'm slightly concerned that because > frame-input-context-button-press-handler is a function from the spec, > users might expect that defining their own method for it would not to > break input focus handling. Maybe focus handling should be pushed down > into stream-read-gesture, but I'm not sure how/where. Or, worse, put it in dispatch-event, the same way that wheel-scrolling and select/paste is implemented, but that's really a horrible hack that needs to stop. From csr21 at cantab.net Fri Jan 26 11:40:23 2007 From: csr21 at cantab.net (Christophe Rhodes) Date: Fri, 26 Jan 2007 11:40:23 +0000 Subject: [mcclim-devel] Drei and input focus In-Reply-To: <31ffd3c40701251024p665ce748u77135b9a831c5753@mail.gmail.com> (Andy Hefner's message of "Thu, 25 Jan 2007 13:24:09 -0500") References: <87wt3kv01j.fsf@cantab.net> <871wlsqabr.fsf@sigkill.dk> <87tzyootcq.fsf@sigkill.dk> <874pqnqs53.fsf@cantab.net> <31ffd3c40701191322l14d146efpb28019e49c200c2f@mail.gmail.com> <871wljhw0w.fsf@cantab.net> <31ffd3c40701251024p665ce748u77135b9a831c5753@mail.gmail.com> Message-ID: <87y7nqf23c.fsf@cantab.net> "Andy Hefner" writes: > On 1/25/07, Christophe Rhodes wrote: >> A potential gotcha is that >> I have not implented click-to-focus for application-panes; this may >> cause surprises, but it seemed to me the only way not to break the >> address book demo ;-) > > The degree to which read-gesture separates the programmer from the > interaction implemented by the stream via various button handling > methods, functions bound in special variables, etc., has always made > me nervous. It's somehow relieving to see it causing someone > difficulty. Well, glad to be of service :-) > Maybe we want a slot or method defined on those panes implementing > click-to-focus behavior which determines whether they are currently > focussable. An interactor-pane would default to t, application-pane > nil. If nil, clicks would pass through and be handled as they are > currently, without reassigning focus. This should preserve the > behavior of the address book. > > I'm slightly concerned that because > frame-input-context-button-press-handler is a function from the spec, > users might expect that defining their own method for it would not to > break input focus handling. Maybe focus handling should be pushed down > into stream-read-gesture, but I'm not sure how/where. At the moment, because I've implemented the focus behaviour as a :before method, it shouldn't matter if users define their own methods for it. I generally agree that allowing the user to decide whether individual panes should be focussable is reasonable, though. >> One new spec compliance is that initially keyboard focus really does >> go to *query-io*. This might cause some surprising behaviour. >> Somewhat to my surprise, gsharp seems to work -- maybe because its >> toplevel loop is different -- but ESAs with default-frame-top-level >> deliver keyboard events to the minibuffer by default, which isn't >> ideal. On the other hand, the focus behaviour of text gadgets is, to >> me, much nicer -- and there's no more focus stealing going on. > > Hmm, that's tricky. Playing around yesterday, I'd added an > :initial-input-focus initarg for the frame, but that only works in > gadget-y applications where there is no query-io (otherwise > run-frame-top-level uses that instead). Maybe we can just change how > the specified behavior is achieved, so that (keyboard-input-focus > frame) is nil by default, and focus is initially assigned to (or > (keyboard-input-focus frame) (frame-query-io frame)) ? I'm actually fairly sanguine about query-io; I think it's reasonable for clicks to invoke stream-set-input-focus, thereby taking focus away from query-io, and leaving just the initial focus setting to there by default -- it's in the spec, after all, and for "normal" clim apps this is probably the right thing anyway. For ESAs with their different gesture handling, it's perhaps not surprising that a toplevel customization is needed, and that Bad Things happen if that toplevel isn't present; if there's an adjustment needed, it's probably in ESA's classes, or to the behaviour of the minibuffer when it receives keyboard events... How shall we move this forward? I want (very much) something implementing behaviour similar to that in my patch, because there are applications that I would like to build that would suck much less with that kind of behaviour. I'm sensitive to the fact that I'm not the only mcclim user, though, and I don't really want to break everyone else's applications, or send us down a mire of supporting an unsupportable API... on that subject, what implications does this have for other backends? Cheers, Christophe From athas at sigkill.dk Tue Jan 30 14:34:18 2007 From: athas at sigkill.dk (Troels Henriksen) Date: Tue, 30 Jan 2007 15:34:18 +0100 Subject: [mcclim-devel] Delimiter gestures and the bowels of input editing Message-ID: <87sldsfus5.fsf@sigkill.dk> Observe the following presentation definitions: (define-presentation-type unacceptable ()) (define-presentation-method accept ((type unacceptable) stream view &key) (with-delimiter-gestures (#\Space) (list (accept 'package :stream stream :view view :prompt nil) (accept 'package :stream stream :view view :prompt nil)))) (defun test-unacceptable (&optional (stream *standard-input*)) (with-input-editing (stream) (replace-input stream (format nil "CLIM-USER CL-USER~%") :buffer-start 0) (accept 'unacceptable :stream stream))) When (test-unacceptable) is run, I'd expect a return value of (#.(find-package :clim-user) #.(find-package :cl-user)). In Drei, this won't work, because the call to `replace-input' in `complete-input' will trigger a rescan, and since the delimiter gesture is left unread once "CLIM-USER" has been read, it will prevent the proper parsing of the second element of input (to be specific, it will see it as empty). Goatee gets around this by introducing a nonspecified hack in `replace-input' whereby passing :rescan nil explicitly causes the function to not queue a rescan, even if it is necessary. (This example doesn't work in Goatee anyway, though, but I guess that's for another reason). My question is this: do you think the above code should work and do as I think, and how exactly are delimiter gestures supposed to be handled? -- \ Troels "Athas" /\ Henriksen