From sketerpot at gmail.com Fri Dec 2 15:42:18 2005 From: sketerpot at gmail.com (Peter Scott) Date: Fri, 2 Dec 2005 09:42:18 -0600 Subject: [mcclim-devel] Weird gray regions bug in Clouseau Message-ID: <7e267a920512020742x7845e04bv4b6d6a1a3dd8a065@mail.gmail.com> When I open Clouseau and expand what I'm inspecting so that it goes off the screen, I see gray regions if I scroll to the right or down. Here's a screenshot: http://www.ece.iastate.edu/~pjscott/inspector-bug.png I got that just by doing (clouseau:inspector *features*) and scrolling to the right. The same problem occurs at the bottom if I inspect something too long to properly display. If I scroll down in the previous window: http://www.ece.iastate.edu/~pjscott/inspector-bug2.png This is annoying, and I don't know enough about the internal workings of McCLIM to know where to start fixing it. I think it might be related to this code: (defmethod redisplay-frame-pane :after ((frame inspector) (pane application-pane) &key force-p) (declare (ignore force-p)) (change-space-requirements pane :height (bounding-rectangle-height (stream-output-history pane)))) ...but I'm not sure, and I don't want to just randomly munge code and hope that I accidentally fix the problem. --Peter From rpgoldman at real-time.com Fri Dec 2 16:55:17 2005 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Fri, 2 Dec 2005 10:55:17 -0600 Subject: [mcclim-devel] Weird gray regions bug in Clouseau In-Reply-To: <7e267a920512020742x7845e04bv4b6d6a1a3dd8a065@mail.gmail.com> References: <7e267a920512020742x7845e04bv4b6d6a1a3dd8a065@mail.gmail.com> Message-ID: <17296.31861.579009.477394@necronomicon.sift.info> I think that the gray area problem is probably not a clouseau problem, per se. I have had it on and off with other panes with incremental redisplay (do you have incremental redisplay?) and scrolling. best, R From rpgoldman at real-time.com Fri Dec 2 16:56:37 2005 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Fri, 2 Dec 2005 10:56:37 -0600 Subject: [mcclim-devel] Weird gray regions bug in Clouseau In-Reply-To: <7e267a920512020742x7845e04bv4b6d6a1a3dd8a065@mail.gmail.com> References: <7e267a920512020742x7845e04bv4b6d6a1a3dd8a065@mail.gmail.com> Message-ID: <17296.31941.865382.116245@necronomicon.sift.info> FWIW, I think that the problem has to do with the fact that the space requirement changes don't work properly with scrolling panes (which have internal and external space requirements to manage). I looked into this a while ago, but I never understood the space-requirements code well enough to fix it. R From gilbert at base-engineering.com Sat Dec 3 17:29:57 2005 From: gilbert at base-engineering.com (Gilbert Baumann) Date: 03 Dec 2005 18:29:57 +0100 Subject: [mcclim-devel] Weird gray regions bug in Clouseau In-Reply-To: <7e267a920512020742x7845e04bv4b6d6a1a3dd8a065@mail.gmail.com> References: <7e267a920512020742x7845e04bv4b6d6a1a3dd8a065@mail.gmail.com> Message-ID: <87zmnif5re.fsf@nx01.base> Peter Scott writes: > When I open Clouseau and expand what I'm inspecting so that it goes > off the screen, I see gray regions if I scroll to the right or down. > Here's a screenshot: > > http://www.ece.iastate.edu/~pjscott/inspector-bug.png You all were on the wrong track ... First off, the pane hierarchy in the Clouseau application is a little strange: The stream pane is inside a border pane inside a vrack pane inside a viewport inside the scroller pane. You would get a saner hierarchy by saying :scroll-bars t in the definition of the 'app' pane and skip the scrolling in the layout. Anyhow, still there is a bug. After looking into it, I saw that space requirements are fine. The space requirements of the stream are properly distributed up to the scroller pane, which you can also see in the correct min/max/thumb-size values of the scroll bar. I looked at the sheet regions and transformations and they all looked perfectly fine. Then I investigated actual sheet geometry as the X server believes. And there is our bug: The X server disagrees with CLIM! So the defect is in the coordinate swizzling code of mine. The documentation string of UPDATE-MIRROR-GEOMETRY, which is the function responsible for synchronizing the sheet geometry to the X server, states: | [...] This function is supposed to be called whenever one of the | following happens: | | [...] | - the parent's native transformation changed | - the parent's transformation changed | - the parent's mirror region changed And exactly these are the cases, we miss. Doing (defmethod note-sheet-transformation-changed ((sheet mirrored-sheet-mixin)) (update-mirror-geometry sheet) + (mapc #'update-mirror-geometry (sheet-children sheet))) seems to help. For completeness we also should do: (defmethod note-sheet-region-changed ((sheet mirrored-sheet-mixin)) (update-mirror-geometry sheet) (mapc #'update-mirror-geometry (sheet-children sheet)) ) This should be regarded as a temporary fix, since IMHO UPDATE-MIRROR-GEOMETRY itself should decide when to update the native region or transformation of a child of a sheet. -- Gilbert Baumann From gilbert at base-engineering.com Sat Dec 3 17:45:03 2005 From: gilbert at base-engineering.com (Gilbert Baumann) Date: 03 Dec 2005 18:45:03 +0100 Subject: [mcclim-devel] text-field problem In-Reply-To: <87ek4z9g57.fsf@spacecentre.se> References: <87ek4z9g57.fsf@spacecentre.se> Message-ID: <87u0dqt6qo.fsf@nx01.base> Thomas Persson writes: > Hi > > After a cvs update tonight I noticed that the text-field gadget gets > initialized with a width of 0, if you don't supply a ":value", resulting > in a grey box as seen here: > > http://www.spacecentre.se/thomas/text-field.png > This is kind of fixed now, as the vrack and hrack pane again force the minor dimensions of their children. Anyhow note that the space requirements of the text field pane are still bogus or at least not what you expect. The text field is stating a max width of 0, So for instance this leads to non-intuitive behavior too: (horizontally () (make-pane 'text-field :value "") (make-pane 'push-button :label "Search")) One might expect that the text-field is stretchable by default. This can be however be circumvented by: (horizontally () (+fill+ (make-pane 'text-field :value "")) (make-pane 'push-button :label "Search")) But: In a different application you might expect the text field to not be stretchable. Unfortunatly the spec says nothing about the kind of space requirements a certain gadget will return. We can only try to be resonable. For instance you almost never want a button to the strechable by default, contrast to scrolled pane, which you expect to be strechable in most cases. -- Gilbert Baumann From clemens at endorphin.org Mon Dec 5 09:21:54 2005 From: clemens at endorphin.org (Clemens Fruhwirth) Date: Mon, 05 Dec 2005 10:21:54 +0100 Subject: [mcclim-devel] accepting-values: prompts not clickable, no redraw, improper output recording? Message-ID: <20051205092039.634A33C248@irulan.endorphin.org> The attached test case does produce strange results for accepting-values calls. In the test case you will find 2 commands. The first one causes an implicit accepting values to be generated when you click on the menu button (or type "Implicit AV" in the interactor pane). In my CVS checkout (about 12 hours old), the Implicit AV command presents three prompts, of that only the last one accepts input. Notice, when damaging the draw area only the last one is repainted, even though not shown first. Explicit AV also generates three prompts, of that the first and the last accepts input. Both are redrawn upon X damage. I also put up a video of this behaviour in case it is not reproducable for you. They are at http://clemens.endorphin.org/strange-clim-artefacts/ (Most of them are MPEG4 provided with four different flavors of fourcc. The last is in Motion JPEG, but quite huge. I won't give an off-topic explaination here of what caused the problems seen by those participating in the IRC discussion of this bug, but when you're interested http://itdp.fh-biergarten.de/~itdp/html/mplayer-users/2005-03/msg00069.html ) Regards, -- Fruhwirth Clemens - http://clemens.endorphin.org for robots: sp4mtrap at endorphin.org -------------- next part -------------- (eval-when (:compile-toplevel) (asdf:oos 'asdf:load-op :clim) (asdf:oos 'asdf:load-op :clim-clx)) (in-package :clim-user) (define-application-frame draw-frame () () (:pane (scrolling () (make-pane 'interactor-pane :scroll-bars :both)))) (define-draw-frame-command (com-implicit-AV :menu t :name t) ((string 'string) (x 'integer) (y 'integer)) ()) (define-draw-frame-command (com-explicit-AV :menu t :name t) () (let ((input-stream (frame-standard-input *application-frame*))) (format t "~A~&" input-stream) ; Make sure we got the interactor panes (accepting-values (input-stream) (accept 'string :prompt "A string" :stream input-stream ) (terpri input-stream) (accept 'integer :prompt "An integer" :stream input-stream ) (terpri input-stream) (accept 'integer :prompt "An integer" :stream input-stream )))) From csr21 at cam.ac.uk Mon Dec 5 11:49:48 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Mon, 05 Dec 2005 11:49:48 +0000 Subject: [mcclim-devel] Weird gray regions bug in Clouseau In-Reply-To: <87zmnif5re.fsf@nx01.base> (Gilbert Baumann's message of "03 Dec 2005 18:29:57 +0100") References: <7e267a920512020742x7845e04bv4b6d6a1a3dd8a065@mail.gmail.com> <87zmnif5re.fsf@nx01.base> Message-ID: Gilbert Baumann writes: > Doing > > (defmethod note-sheet-transformation-changed ((sheet mirrored-sheet-mixin)) > (update-mirror-geometry sheet) > + (mapc #'update-mirror-geometry (sheet-children sheet))) > > seems to help. Does this recurse all the way down the hierarchy, or does it stop at the first generation of children? Christophe From gilbert at base-engineering.com Mon Dec 5 12:04:33 2005 From: gilbert at base-engineering.com (Gilbert Baumann) Date: 05 Dec 2005 13:04:33 +0100 Subject: [mcclim-devel] Weird gray regions bug in Clouseau In-Reply-To: References: <7e267a920512020742x7845e04bv4b6d6a1a3dd8a065@mail.gmail.com> <87zmnif5re.fsf@nx01.base> Message-ID: <87acffzr5a.fsf@nx01.base> Christophe Rhodes writes: > Gilbert Baumann writes: > > > Doing > > > > (defmethod note-sheet-transformation-changed ((sheet mirrored-sheet-mixin)) > > (update-mirror-geometry sheet) > > + (mapc #'update-mirror-geometry (sheet-children sheet))) > > > > seems to help. > > Does this recurse all the way down the hierarchy, or does it stop at > the first generation of children? It should recurse all the way down, so it might have ugly performance implications. We might however stop recursion as soon as nothing changes. I noticed another ugly thing: Suppose a sheet S with its region SR and its transformation T within a viewport V with region VR. UPDATE-MIRROR-GEOMETRY works by recognizing that only (SR o T) ^ VR is potentially visible. For example say the sheet S is 1000 pixel height and the viewport is 100 pixels high. Further suppose S is scrolled so that y=200 in S maps to y=0 in V. Then the potentially visible y range (in S) is only [200, 300) so the mirror region of S is actually set to something 300 pixels high. Now you scroll a bit, making y=210 in S mapping y=0 in V. The potential visibile y range now is [210,310) leading to a mirror region 310 pixels high. In this case scrolling will actually resize the mirror. That is UPDATE-MIRROR-GEOMETRY is not clever enough to recognize, that it could make the mirror region larger [and here actually up to the orignal size] and thus avoid resizing on scrolling. If it were smart enough it could even lead to allocating an even larger mirror region of saying 2000 pixels high (in contract to the 1000 high sheet region) and thereby avoiding resizing the sheet in case more content is spilled to S. E.g. if S is a stream pane and you output a couple more lines. -- Gilbert Baumann base engineering gmbh, Norderstedt gilbert at base-engineering.com http://www.base-engineering.com/ From ahefner at gmail.com Tue Dec 6 03:33:39 2005 From: ahefner at gmail.com (Andy Hefner) Date: Mon, 5 Dec 2005 22:33:39 -0500 Subject: [mcclim-devel] Interactor pane, hollow cursor? Message-ID: <31ffd3c40512051933m2bc11d2ah955a90180c4a081f@mail.gmail.com> Why does the text cursor within interactor panes now appear hollow, as though you were not typing to the interactor? From csr21 at cam.ac.uk Tue Dec 6 18:26:22 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Tue, 06 Dec 2005 18:26:22 +0000 Subject: [mcclim-devel] Interactor pane, hollow cursor? In-Reply-To: <31ffd3c40512051933m2bc11d2ah955a90180c4a081f@mail.gmail.com> (Andy Hefner's message of "Mon, 5 Dec 2005 22:33:39 -0500") References: <31ffd3c40512051933m2bc11d2ah955a90180c4a081f@mail.gmail.com> Message-ID: Andy Hefner writes: > Why does the text cursor within interactor panes now appear hollow, as > though you were not typing to the interactor? My immediate suspicion lands on , (but that's only a suspicion) Cheers, Christophe From m.retzlaff at gmx.net Tue Dec 6 18:34:06 2005 From: m.retzlaff at gmx.net (Max-Gerd Retzlaff) Date: Tue, 6 Dec 2005 19:34:06 +0100 Subject: [mcclim-devel] Interactor pane, hollow cursor? In-Reply-To: References: <31ffd3c40512051933m2bc11d2ah955a90180c4a081f@mail.gmail.com> Message-ID: <20051206183405.GA22352@mgr.home> Hi On Tue, Dec 06, 2005 at 06:26:22PM +0000, Christophe Rhodes wrote: > Andy Hefner writes: > > > Why does the text cursor within interactor panes now appear hollow, as > > though you were not typing to the interactor? > > My immediate suspicion lands on > , > (but that's only a suspicion) Yes, that's right. This behaviour was introduced by that patch by Rudi Schlatte; he has sent the patch to this list already on September the 24th. I have had a closer look at the patch after it was commited to investigate the problem, but, sadly, I've forgotten to write a report to the mailinglist. I only remember that the cursor-appearance is set to :SOLID at the wrong place so that it has no impact on the drawing. Hmm, ISTR a discussion about this on #lisp.. Sorry, Max -- Max-Gerd Retzlaff For your amusement: I saw Lassie. It took me four shows to figure out why the hairy kid never spoke. I mean, he could roll over and all that, but did that deserve a series? -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From rudi at constantly.at Tue Dec 6 23:02:37 2005 From: rudi at constantly.at (Rudi Schlatte) Date: Wed, 7 Dec 2005 00:02:37 +0100 Subject: [mcclim-devel] Interactor pane, hollow cursor? In-Reply-To: <31ffd3c40512051933m2bc11d2ah955a90180c4a081f@mail.gmail.com> References: <31ffd3c40512051933m2bc11d2ah955a90180c4a081f@mail.gmail.com> Message-ID: <8A5EA0BB-3959-4864-8C67-29042EE12E46@constantly.at> On 6. Dez 2005, at 04:33, Andy Hefner wrote: > Why does the text cursor within interactor panes now appear hollow, as > though you were not typing to the interactor? That would be because I suck :( I added behaviour to ports.lisp/(setf port-keyboard-input-focus) that toggles hollowness of cursors when the keyboard focus changes, which works nicely for text-fields and text-areas. I didn't check the behaviour for stream panes before checking it in, and before real life intervened, I unsuccessfully tried to find the "real" cursor object for them. I suspect the cursor that is really drawn belongs to some Goatee instance inside the stream; witness the comment in frames.lisp/ default-frame-top-level: ;; We don't need to turn the cursor on here, as Goatee has its own ;; cursor which will appear. In fact, leaving it on causes much ;; bit flipping and slows command output somewhat. So, leave it ;; off by default, and hope this doesn't violate the spec. But I got lost inside a maze of objects. Rudi -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From ahefner at gmail.com Tue Dec 6 23:45:54 2005 From: ahefner at gmail.com (Andy Hefner) Date: Tue, 6 Dec 2005 18:45:54 -0500 Subject: [mcclim-devel] Interactor pane, hollow cursor? In-Reply-To: <8A5EA0BB-3959-4864-8C67-29042EE12E46@constantly.at> References: <31ffd3c40512051933m2bc11d2ah955a90180c4a081f@mail.gmail.com> <8A5EA0BB-3959-4864-8C67-29042EE12E46@constantly.at> Message-ID: <31ffd3c40512061545l2354ff31gf01fd4e455f867df@mail.gmail.com> Ah, that makes sense. Goatee does indeed maintain its own cursor. Funny enough, I implemented this same thing (custom cursor shapes, focus sensitivity) locally about two years ago (and never committed..), and part of that was modifying Goatee to use the stream cursor as its own cursor (they're derived from the same classes anyway, so I only had to touch one or two places). On 12/6/05, Rudi Schlatte wrote: > I didn't check the behaviour for stream panes before checking it in, > and before real life intervened, I unsuccessfully tried to find the > "real" cursor object for them. > I suspect the cursor that is really drawn belongs to some Goatee > instance inside the stream; witness the comment in frames.lisp/ > default-frame-top-level: From asf at boinkor.net Wed Dec 7 07:52:11 2005 From: asf at boinkor.net (Andreas Fuchs) Date: Wed, 07 Dec 2005 08:52:11 +0100 Subject: [mcclim-devel] [patch] minor goatee improvements (arrow keys!) In-Reply-To: <871x35b7m9.wl%asf@boinkor.net> References: <871x35b7m9.wl%asf@boinkor.net> Message-ID: <87iru1ibtg.wl%asf@boinkor.net> On 2005-10-01, Andreas Fuchs wrote: > [1 ] > Hi all, > > I have here a patch to make arrow keys and the Home and End keys in > a goatee input buffer DTRT. I'm not entirely sure if the patch to > lookup-gesture-command is doing the right thing, so I'd like a CLIM > gesture specialist to at least glance over it before I commit it. (: I've tested it with climacs and beirc now and neither broke, so I committed it. Have fun using your arrow keys in clim text input fields. -- Andreas Fuchs, , asf at jabber.at, antifuchs From pw at snoopy.mv.com Fri Dec 9 13:44:03 2005 From: pw at snoopy.mv.com (Paul Werkowski) Date: Fri, 9 Dec 2005 08:44:03 -0500 Subject: [mcclim-devel] Problems with compose-xxx-with-yyy transformation functions Message-ID: <000f01c5fcc6$9e961fd0$0201a8c0@moby> (in-package :clim-user) (defun t1 () ;; works same on mcclim and lw (let* ((a (make-translation-transformation 10 10)) (b (make-scaling-transformation 2 2))) (multiple-value-bind (x y) ;; Spec says; ;; b (scaling) first, then a (translation) (transform-position (compose-transformations a b) 1 1)) (format t "T1 => ~a ~a~%" x y) (assert (= 12 x y)))) (defun t2 () ;; LW CLIM gives (values 12 12), McCLIM gives (values 22 22) ?? (let ((a (compose-transformation-with-translation ;; Spec says; ;; transformation (scaling) first, then translation (make-scaling-transformation 2 2) 10 10))) (multiple-value-bind (x y)(transform-position a 1 1) (format t "T2 => ~a ~a~%" x y) (assert (= 12 x y))))) #+bugged-McCLIM definition ;;; oops, order is reversed! (defun compose-transformation-with-translation (transformation dx dy) (compose-transformations transformation (make-translation-transformation dx dy))) ;;;;; Proposed fixes #+McCLIM (progn (defun compose-translation-with-transformation (transformation dx dy) (compose-transformations transformation (make-translation-transformation dx dy))) (defun compose-scaling-with-transformation (transformation sx sy &optional origin) (compose-transformations transformation (make-scaling-transformation sx sy origin))) (defun compose-rotation-with-transformation (transformation angle &optional origin) (compose-transformations transformation (make-rotation-transformation angle origin))) (defun compose-transformation-with-translation (transformation dx dy) (compose-transformations (make-translation-transformation dx dy) transformation)) (defun compose-transformation-with-scaling (transformation sx sy &optional origin) (compose-transformations (make-scaling-transformation sx sy origin) transformation)) (defun compose-transformation-with-rotation (transformation angle &optional origin) (compose-transformations (make-rotation-transformation angle origin) transformation)) ) ;;;; From pw at snoopy.mv.com Fri Dec 9 15:33:16 2005 From: pw at snoopy.mv.com (Paul Werkowski) Date: Fri, 9 Dec 2005 10:33:16 -0500 Subject: [mcclim-devel] Infinite loop in McCLIM Message-ID: <000501c5fcd5$e0173ca0$0201a8c0@moby> The attached program works the same in McCLIM and Lispworks CLIM, except McCLIM gets into an infinite loop (CMUCL latest) unless incremental-redisplay is enabled. The program just wants its displayed output to track resizing the frame from the window manager. The attachment should run correctly. But then comment out the :incremental-redisplay as shown below and trouble is at hand. (defclass test-pane (application-pane) () (:default-initargs :display-function 'tpdf ;;; YIKES - in McCLIM; without this, infinite loop!! ; :incremental-redisplay t ; :display-time :command-loop )) ;;; Paul From nikodemus at random-state.net Thu Dec 15 12:11:24 2005 From: nikodemus at random-state.net (Nikodemus Siivola) Date: Thu, 15 Dec 2005 12:11:24 +0000 Subject: [mcclim-devel] Patch: window-viewport-position Message-ID: <874q5av9ub.fsf@j178.myrootshell.com> The attached patch makes (multiple-value-bind (x y) (window-viewport-position pane) (setf (window-viewport-position pane) (values x (+ y (stream-line-height pane))))) work as expected -- or at least as I assume it should work... -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-patch Size: 1 bytes Desc: not available URL: -------------- next part -------------- Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs." From nikodemus at random-state.net Fri Dec 16 07:55:37 2005 From: nikodemus at random-state.net (Nikodemus Siivola) Date: Fri, 16 Dec 2005 07:55:37 +0000 Subject: [mcclim-devel] Patch: do-sequence Message-ID: <87acf1lbly.fsf@logxor.random-state.net> The attached patch fixes DO-SEQUENCE which doesn't currently stay in the array bounds -- and hence also fixes DRAW-LINES*. -------------- next part -------------- A non-text attachment was scrubbed... Name: do-sequence.patch Type: text/x-patch Size: 791 bytes Desc: Patch URL: -------------- next part -------------- Cheers, -- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs." From pw at snoopy.mv.com Fri Dec 16 16:02:19 2005 From: pw at snoopy.mv.com (Paul Werkowski) Date: Fri, 16 Dec 2005 11:02:19 -0500 Subject: [mcclim-devel] Problems with compose-xxx-with-yyy transformationfunctions References: <000f01c5fcc6$9e961fd0$0201a8c0@moby> Message-ID: <003e01c6025a$17b38130$0201a8c0@moby> Attached is a patch file to fix the problem I reported last week. I hope someone with privs will commit these changes to transforms.lisp. Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: transforms.pat Type: application/octet-stream Size: 2043 bytes Desc: not available URL: From rpgoldman at real-time.com Fri Dec 16 16:44:54 2005 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Fri, 16 Dec 2005 10:44:54 -0600 Subject: [mcclim-devel] Problems with compose-xxx-with-yyy transformationfunctions In-Reply-To: <003e01c6025a$17b38130$0201a8c0@moby> References: <000f01c5fcc6$9e961fd0$0201a8c0@moby> <003e01c6025a$17b38130$0201a8c0@moby> Message-ID: <17314.61190.75970.681884@necronomicon.sift.info> OK, I tested that with your tests and checked it against the spec. Looks fine according to my (admittedly lame) understanding of CLIM, and works on my (admittedly lame) single test on Allegro CL 7.0. Committed it. I also added a docstring to MAKE-SCALING-TRANSFORMATION. I'm inclined to favor having these added, although not enough to say that people ought to slave to put them in everywhere. But I tend to add them to the code when I'm modding it for some other reasons. How do others feel about this? Is it a Bad Thing (do you prefer to have skinnier binaries at the expense of not having docstrings)? R From rpgoldman at real-time.com Fri Dec 16 16:31:13 2005 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Fri, 16 Dec 2005 10:31:13 -0600 Subject: [mcclim-devel] Problems with compose-xxx-with-yyy transformationfunctions In-Reply-To: <003e01c6025a$17b38130$0201a8c0@moby> References: <000f01c5fcc6$9e961fd0$0201a8c0@moby> <003e01c6025a$17b38130$0201a8c0@moby> Message-ID: <17314.60369.599444.160552@necronomicon.sift.info> I'll be happy to commit the patch. I have just applied it and it seems fine. Can you give me (remind me?) of an example that will show that this works? Preferably one that shows it failing in the past. R From rpgoldman at real-time.com Fri Dec 16 16:34:20 2005 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Fri, 16 Dec 2005 10:34:20 -0600 Subject: [mcclim-devel] Problems with compose-xxx-with-yyy transformationfunctions In-Reply-To: <003e01c6025a$17b38130$0201a8c0@moby> References: <000f01c5fcc6$9e961fd0$0201a8c0@moby> <003e01c6025a$17b38130$0201a8c0@moby> Message-ID: <17314.60556.335593.550125@necronomicon.sift.info> Sorry. Never mind. I found what I needed in the list archives. I'll try your test and let you know. If all is well, I'll do the commit in the next half an hour or so. From pw at snoopy.mv.com Fri Dec 16 17:15:51 2005 From: pw at snoopy.mv.com (Paul Werkowski) Date: Fri, 16 Dec 2005 12:15:51 -0500 Subject: [mcclim-devel] Problems with compose-xxx-with-yyytransformationfunctions References: <000f01c5fcc6$9e961fd0$0201a8c0@moby><003e01c6025a$17b38130$0201a8c0@moby> <17314.61190.75970.681884@necronomicon.sift.info> Message-ID: <000901c60264$5d5deea0$0201a8c0@moby> | OK, I tested that with your tests and checked it against the spec. | Looks fine according to my (admittedly lame) understanding of CLIM, | and works on my (admittedly lame) single test on Allegro CL 7.0. | Committed it. | | I also added a docstring to MAKE-SCALING-TRANSFORMATION. I'm inclined | to favor having these added, although not enough to say that people | ought to slave to put them in everywhere. But I tend to add them to | the code when I'm modding it for some other reasons. How do others | feel about this? Is it a Bad Thing (do you prefer to have skinnier | binaries at the expense of not having docstrings)? Thanks! I tend to favor having doc strings - some editors will display them via ctl-alt-a on the name. Paul From pw at snoopy.mv.com Fri Dec 16 17:17:39 2005 From: pw at snoopy.mv.com (Paul Werkowski) Date: Fri, 16 Dec 2005 12:17:39 -0500 Subject: [mcclim-devel] clipping-region Message-ID: <001101c60264$9e40a660$0201a8c0@moby> What is the supposed status of clipping-region support? A simple test here seem to suggest clipping-region is ignored. Paul From csr21 at cam.ac.uk Sat Dec 17 10:55:18 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Sat, 17 Dec 2005 10:55:18 +0000 Subject: [mcclim-devel] clipping-region In-Reply-To: <001101c60264$9e40a660$0201a8c0@moby> (Paul Werkowski's message of "Fri, 16 Dec 2005 12:17:39 -0500") References: <001101c60264$9e40a660$0201a8c0@moby> Message-ID: "Paul Werkowski" writes: > What is the supposed status of clipping-region support? > A simple test here seem to suggest clipping-region is ignored. I believe that gsharp is currently using it to implement partial beams in musical notation. We patch some things, I think on Gilbert's suggestion, but repaint continues not to work: the graphical display is messed up on reexpose. Cheers, Christophe ;;; this is clim-patches.lisp from gsharp: (in-package :clim-internals) (defmethod replay-output-record :around (record stream &optional region (x-offset 0) (y-offset 0)) (declare (ignore record region x-offset y-offset)) (with-sheet-medium (medium stream) (letf (((medium-ink medium) (medium-ink medium)) ((medium-foreground medium) (medium-foreground medium)) ((medium-background medium) (medium-background medium)) ((medium-transformation medium) (medium-transformation medium)) ((medium-clipping-region medium) (medium-clipping-region medium)) ((medium-line-style medium) (medium-line-style medium)) ((medium-text-style medium) (medium-text-style medium)) ((medium-default-text-style medium) (medium-default-text-style medium))) (call-next-method)))) (defmethod set-medium-graphics-state :after ((state gs-clip-mixin) medium) (setf (medium-clipping-region medium) (region-intersection (medium-clipping-region medium) (graphics-state-clip state)))) From pw at snoopy.mv.com Tue Dec 20 13:56:39 2005 From: pw at snoopy.mv.com (Paul Werkowski) Date: Tue, 20 Dec 2005 08:56:39 -0500 Subject: [mcclim-devel] Bug in draw-circle using transformation Message-ID: <20051220135639.22505.qmail@copper.mv.net> (in-package :clim-user) ;;; In Lispworks CLIM, this program draws an arc (counter-clockwise) ;;; from red dot to blue dot. ;;; In McCLIM, xlib:draw-arc throws a type error, ;;; 7.85398 is not of type (satisfies xlib:anglep) ;;; Changing start angle (as) to zero gets past that error, but the arc ;;; is going in the wrong direction (clockwise) from red dot. (define-application-frame test () () (:panes (p0 :application :display-function (lambda (f p) (declare (ignore f)) (with-translation (p 10 150) (with-scaling (p 1 -1) (let* ((as (/ pi 8)) (ae (+ as (/ pi 2))) (r 20) (x0 50)(y0 50) (xs (+ x0 (* r (cos as)))) (ys (+ y0 (* r (sin as)))) (xe (+ x0 (* r (cos ae)))) (ye (+ y0 (* r (sin ae))))) (draw-line* p 0 0 0 100) (draw-line* p 0 0 100 0) ;; Arc center (draw-circle* p x0 y0 3 :ink +green+) ;; Where the arc should start (draw-circle* p xs ys 3 :ink +red+) ;; Where the arc should end (draw-circle* p xe ye 3 :ink +blue+) (draw-circle* p x0 y0 r :start-angle as :end-angle ae :filled nil))))) :width 200 :height 200)) (:layouts (default p0))) (defun testme () (run-frame-top-level (make-application-frame 'test))) From pw at snoopy.mv.com Tue Dec 20 17:15:42 2005 From: pw at snoopy.mv.com (Paul Werkowski) Date: Tue, 20 Dec 2005 12:15:42 -0500 Subject: [mcclim-devel] Missing realizer in call to MAKE-PANE-1 Message-ID: <20051220171542.4053.qmail@copper.mv.net> ;;; -*- Package: clim-user -*- (in-package :clim-user) ;;; Lispworks CLIM displays a radio box. ;;; McCLIM throws No Primary Method for MAKE-PANE-1 ;;; with NIL as first argument. (define-application-frame test-woag () () (:panes (p0 :application :display-function (lambda (f p) (with-output-as-gadget (p) (with-radio-box (:label "xxx" :type :some-of) :x :y))) :min-width 100 :min-height 100 )) (:layouts (default p0))) (defun testme () (run-frame-top-level (make-application-frame 'test-woag))) From m.retzlaff at gmx.net Wed Dec 21 21:01:24 2005 From: m.retzlaff at gmx.net (Max-Gerd Retzlaff) Date: Wed, 21 Dec 2005 22:01:24 +0100 Subject: [mcclim-devel] Missing realizer in call to MAKE-PANE-1 In-Reply-To: <20051220171542.4053.qmail@copper.mv.net> References: <20051220171542.4053.qmail@copper.mv.net> Message-ID: <20051221210124.GA31183@mgr.home> Hello On Tue, Dec 20, 2005 at 12:15:42PM -0500, Paul Werkowski wrote: > ;;; Lispworks CLIM displays a radio box. > ;;; McCLIM throws No Primary Method for MAKE-PANE-1 > ;;; with NIL as first argument. > > (define-application-frame test-woag () > [...] > (with-output-as-gadget (p) > [...] There is a general problem regarding WITH-OUTPUT-AS-GADGET that is known for quite some time. Christopher Rhodes reported it on the 14th of July: http://common-lisp.net/pipermail/mcclim-devel/2005-July/004100.html And I've sent another bug report on August, the 26th, giving some more information that hopefully helps to narrow down the problem : http://common-lisp.net/pipermail/mcclim-devel/2005-August/004246.html I would really like to see it working but I've not the time to fix it in the moment, even more as I would have to learn more about output records first. Bye, Max -- Max-Gerd Retzlaff http://bl0rg.net/~mgr/ http://blogs.bl0rg.net/mgr/ (soon on http://(blog.)matroid.org) For your amusement: My brother sent me a postcard the other day with this big satellite photo of the entire earth on it. On the back it said: "Wish you were here". -- Steven Wright -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pw at snoopy.mv.com Wed Dec 21 23:14:19 2005 From: pw at snoopy.mv.com (Paul Werkowski) Date: Wed, 21 Dec 2005 18:14:19 -0500 Subject: [mcclim-devel] Missing realizer in call to MAKE-PANE-1 References: <20051220171542.4053.qmail@copper.mv.net> <20051221210124.GA31183@mgr.home> Message-ID: <001701c60684$4541d5b0$0201a8c0@moby> |There is a general problem regarding WITH-OUTPUT-AS-GADGET that is known |for quite some time. Christopher Rhodes reported it on the 14th of July: | http://common-lisp.net/pipermail/mcclim-devel/2005-July/004100.html |And I've sent another bug report on August, the 26th, giving some more |information that hopefully helps to narrow down the problem : | http://common-lisp.net/pipermail/mcclim-devel/2005-August/004246.html | |I would really like to see it working but I've not the time to fix it |in the moment, even more as I would have to learn more about output |records first. Thanks for pointing that out. Maybe I will take a closer look at how all that stuff is supposed to work. Paul From ahefner at gmail.com Thu Dec 22 00:37:27 2005 From: ahefner at gmail.com (Andy Hefner) Date: Wed, 21 Dec 2005 19:37:27 -0500 Subject: [mcclim-devel] Missing realizer in call to MAKE-PANE-1 In-Reply-To: <20051220171542.4053.qmail@copper.mv.net> References: <20051220171542.4053.qmail@copper.mv.net> Message-ID: <31ffd3c40512211637s2eebeb2bi6dea600b1ece66ed@mail.gmail.com> Our behavior is within the bounds of the spec: http://www.stud.uni-karlsruhe.de/~unk6/clim-spec/29-2.html#_6495 http://www.stud.uni-karlsruhe.de/~unk6/clim-spec/29-2.html#_6487 However, perhaps we should emulate the lispworks behavior of not requiring the user to explicitly bind the realizer. Christophe's bugs are unrelated (one involves failure to embed nested gadgets due to a problem in the order w-o-a-g initializes things, the other I never tracked down). On 12/20/05, Paul Werkowski wrote: > ;;; -*- Package: clim-user -*- > > (in-package :clim-user) > > ;;; Lispworks CLIM displays a radio box. > ;;; McCLIM throws No Primary Method for MAKE-PANE-1 > ;;; with NIL as first argument. > > (define-application-frame test-woag () > () > (:panes > (p0 :application > :display-function > (lambda (f p) > (with-output-as-gadget (p) > (with-radio-box > (:label "xxx" :type :some-of) :x :y))) > :min-width 100 > :min-height 100 > )) > (:layouts > (default p0))) > > (defun testme () > (run-frame-top-level > (make-application-frame 'test-woag))) > > _______________________________________________ > mcclim-devel mailing list > mcclim-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel > From pw at snoopy.mv.com Thu Dec 22 12:03:45 2005 From: pw at snoopy.mv.com (Paul Werkowski) Date: Thu, 22 Dec 2005 07:03:45 -0500 Subject: [mcclim-devel] Missing realizer in call to MAKE-PANE-1 Message-ID: <20051222120345.25126.qmail@copper.mv.net> > Our behavior is within the bounds of the spec: > > http://www.stud.uni-karlsruhe.de/~unk6/clim-spec/29-2.html#_6495 > http://www.stud.uni-karlsruhe.de/~unk6/clim-spec/29-2.html#_6487 > > However, perhaps we should emulate the lispworks behavior of not > requiring the user to explicitly bind the realizer. > > Christophe's bugs are unrelated (one involves failure to embed nested > gadgets due to a problem in the order w-o-a-g initializes things, the > other I never tracked down). Hmm, well you've got me there (sort of). I'm pretty sure that as I reduced code from the real program that first showed that problem to the minimal code in my email I did have with-look-and-feel-realization in play with no apparent difference. I probably had some cockpit trouble at that point. Still no cigar though. Now I get a display visible, but no gadget. So, back to the debugging pit. Stay tuned. Paul From tim at tenkan.org Fri Dec 23 12:26:39 2005 From: tim at tenkan.org (Tim Daly Jr.) Date: Fri, 23 Dec 2005 13:26:39 +0100 Subject: [mcclim-devel] [patch] fix typos and postscript backend Message-ID: <1135340799.22500.41.camel@beer.intern> Hi guys, This is a small patch to fix some typos and add output recording for NEW-PAGE in the postscript backend. When I tried to run CLIM-DEMO::POSTSCRIPT-TEST, it produced an invalid postscript file. Ghostscript failed to load it, complaining of a dictionary stack underflow. The reason was that the output from NEW-PAGE was at the top of the file, and not embedded between pages as it was meant to be. This is because WITH-OUTPUT-TO-POSTSCRIPT-STREAM uses output recording, (Perhaps this was introduced to make EPS work? Just a guess.), yet NEW-PAGE draws immediately instead of being recorded. I attempted to add output recording for NEW-PAGE. This patch fixes the postscript test mostly -- page 7 is translated to the lower right corner for some reason, but it's at least syntactically correct. I have no understanding of this stuff, so please check whether I've done something boneheaded. Thanks, Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: fix-typos-and-ps-backend.patch Type: text/x-patch Size: 4433 bytes Desc: not available URL: From athas at sigkill.dk Fri Dec 23 12:38:12 2005 From: athas at sigkill.dk (Troels Henriksen) Date: Fri, 23 Dec 2005 13:38:12 +0100 Subject: [mcclim-devel] Reading in a list of objects Message-ID: <87bqz80z0r.fsf@sigkill.dk> I have defined a presentation-type, column, as well as the appropriate present and accept methods. I need to accept a list of column objects from the user, but I am a bit stumped on how to do this. Do I have to define a new "columns" type, or does McCLIM include facilities to automatically read in sequences of objects from the user? -- \ Troels "Athas" Henriksen /\ sigkill.dk/blog (Danish) From splittist at yahoo.com Fri Dec 23 15:40:36 2005 From: splittist at yahoo.com (John Q) Date: Fri, 23 Dec 2005 07:40:36 -0800 (PST) Subject: [mcclim-devel] Reading in a list of objects In-Reply-To: <87bqz80z0r.fsf@sigkill.dk> Message-ID: <20051223154036.12979.qmail@web33502.mail.mud.yahoo.com> > I have defined a presentation-type,... > I need to accept a list of column objects Look at the sequence presentation type. In fact, look at the whole Presentations chapter in the spec - there are lots of nifty things like completing from subsets of sequences. JQS __________________________________ Yahoo! for Good - Make a difference this year. http://brand.yahoo.com/cybergivingweek2005/ From pw at snoopy.mv.com Fri Dec 23 16:27:10 2005 From: pw at snoopy.mv.com (Paul Werkowski) Date: Fri, 23 Dec 2005 11:27:10 -0500 Subject: [mcclim-devel] Missing realizer in call to MAKE-PANE-1 Message-ID: <20051223162710.4549.qmail@copper.mv.net> > Hmm, well you've got me there (sort of). I'm pretty sure that as I reduced > code from the real program that first showed that problem to the minimal > code in my email I did have with-look-and-feel-realization in play with > no apparent difference. I probably had some cockpit trouble at that point. > > Still no cigar though. Now I get a display visible, but no gadget. > > So, back to the debugging pit. Stay tuned. > It seems that if I change from a radio-box gadget to a label-pane things work as they should. I now cannot get a radio-box to appear at all, even at the frame definition eg (:panes (rb (with-radio-box () :a :b :c))) so maybe something has regressed in that area? Paul From pw at snoopy.mv.com Fri Dec 23 17:25:31 2005 From: pw at snoopy.mv.com (Paul Werkowski) Date: Fri, 23 Dec 2005 12:25:31 -0500 Subject: with-output-as-gadget (was Re: [mcclim-devel] Missing realizer in call to MAKE-PANE-1) Message-ID: <20051223172531.7083.qmail@copper.mv.net> I wrote: > I now cannot get a radio-box to appear at all, even > at the frame definition eg > > (:panes (rb (with-radio-box () :a :b :c))) > > so maybe something has regressed in that area? > No, it seems that radio/check boxes want only strings in the :choices list. I'm not sure the spec limits the items to strings - at least Lispworks CLIM is more inclusive. Anyhow, there still seems to be a problem in the with-output-as-gadget setup. I end up in the debugger with some layout function calling sheet-native-transformation on the parent of the check-box-pane which is NIL at this time. Anyone got a clue as who is responsible for providing a parent for this thing? Paul From pw at snoopy.mv.com Fri Dec 23 18:28:22 2005 From: pw at snoopy.mv.com (Paul Werkowski) Date: Fri, 23 Dec 2005 13:28:22 -0500 Subject: with-output-as-gadget (was Re: [mcclim-devel] Missing realizer in Message-ID: <20051223182822.9578.qmail@copper.mv.net> > Anyhow, there still seems to be a problem in the > with-output-as-gadget setup. I end up in the debugger > with some layout function calling sheet-native-transformation > on the parent of the check-box-pane which is NIL > at this time. Anyone got a clue as who is responsible > for providing a parent for this thing? The problem here is caused by the call to allocate-space in the initialize-instance :after on gadget-output-record. Not calling that results in no errors and a check-box gadget being displayed. I have no idea if this is an appropriate fix but hopefully this will provide food for thought for those that are in the know. Paul From m.retzlaff at gmx.net Fri Dec 23 19:07:47 2005 From: m.retzlaff at gmx.net (Max-Gerd Retzlaff) Date: Fri, 23 Dec 2005 20:07:47 +0100 Subject: with-output-as-gadget (was Re: [mcclim-devel] Missing realizer in call to MAKE-PANE-1) In-Reply-To: <20051223172531.7083.qmail@copper.mv.net> References: <20051223172531.7083.qmail@copper.mv.net> Message-ID: <20051223190747.GA19876@mgr.home> Good evening, On Fri, Dec 23, 2005 at 12:25:31PM -0500, Paul Werkowski wrote: > Anyhow, there still seems to be a problem in the > with-output-as-gadget setup. I end up in the debugger > with some layout function calling sheet-native-transformation > on the parent of the check-box-pane which is NIL > at this time. Anyone got a clue as who is responsible > for providing a parent for this thing? Have you had a closer look at http://common-lisp.net/pipermail/mcclim-devel/2005-August/004246.html ? Regards, Max -- Max-Gerd Retzlaff http://bl0rg.net/~mgr/ http://blogs.bl0rg.net/mgr/ (soon on http://(blog.)matroid.org) For your amusement: The best way to make a fire with two sticks is to make sure one of them is a match. -- Will Rogers -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pw at snoopy.mv.com Fri Dec 23 20:39:43 2005 From: pw at snoopy.mv.com (Paul Werkowski) Date: Fri, 23 Dec 2005 15:39:43 -0500 Subject: with-output-as-gadget (was Re: [mcclim-devel] Missing realizer incall to MAKE-PANE-1) References: <20051223172531.7083.qmail@copper.mv.net> <20051223190747.GA19876@mgr.home> Message-ID: <003a01c60801$01511b80$0201a8c0@moby> > Anyhow, there still seems to be a problem in the > with-output-as-gadget setup. I end up in the debugger > with some layout function calling sheet-native-transformation > on the parent of the check-box-pane which is NIL > at this time. Anyone got a clue as who is responsible > for providing a parent for this thing? |Have you had a closer look at |http://common-lisp.net/pipermail/mcclim-devel/2005-August/004246.html ? | |Regards, |Max Heh, yes, I read it - and promptly forgot about it. Definite evidence of senility creeping in. So, now I can confirm his eloquent explanation since I've traveled far enough down that path to see the cause. Now, if I could just see the solution ;-{ Paul From pw at snoopy.mv.com Sat Dec 24 00:15:11 2005 From: pw at snoopy.mv.com (Paul Werkowski) Date: Fri, 23 Dec 2005 19:15:11 -0500 Subject: [mcclim-devel] with-output-as-gadget, again Message-ID: <000301c6081f$1b7ccd10$0201a8c0@moby> Max, When you were researching this, did you notice that there is no problem with gadgets that have direct drawing methods, such as label-pane and toggle-button-pane. I wonder if there is missing replay-output-record method for the classes that have children (check-box radio-box scroller, etc). Paul From pw at snoopy.mv.com Sun Dec 25 15:57:09 2005 From: pw at snoopy.mv.com (Paul Werkowski) Date: Sun, 25 Dec 2005 10:57:09 -0500 Subject: with-output-as-gadget (was Re: [mcclim-devel] Missing realizerincall to MAKE-PANE-1) References: <20051223172531.7083.qmail@copper.mv.net><20051223190747.GA19876@mgr.home> <003a01c60801$01511b80$0201a8c0@moby> Message-ID: <000701c6096b$dc9b8c50$0201a8c0@moby> | | So, now I can confirm his eloquent explanation since I've traveled far | enough | down that path to see the cause. Now, if I could just see the solution | ;-{ | I think I have it! Change the initialize-instance :after method on gadget-output-record to just doing (setf (gadget record) child) and move the rest of the stuff in there to just after the call to stream-add-output-record in with-output-as-gadget. Seems to work for the cases I have tried. Maybe it will work for Max as well? Paul From m.retzlaff at gmx.net Sun Dec 25 20:49:08 2005 From: m.retzlaff at gmx.net (Max-Gerd Retzlaff) Date: Sun, 25 Dec 2005 21:49:08 +0100 Subject: with-output-as-gadget (was Re: [mcclim-devel] Missing realizerincall to MAKE-PANE-1) In-Reply-To: <000701c6096b$dc9b8c50$0201a8c0@moby> References: <003a01c60801$01511b80$0201a8c0@moby> <000701c6096b$dc9b8c50$0201a8c0@moby> Message-ID: <20051225204908.GA9042@mgr.home> Hello On Sun, Dec 25, 2005 at 10:57:09AM -0500, Paul Werkowski wrote: > I think I have it! > > Change the initialize-instance :after method on gadget-output-record to just > doing > > (setf (gadget record) child) > > and move the rest of the stuff in there to just after the call to > stream-add-output-record in with-output-as-gadget. > > Seems to work for the cases I have tried. Maybe it will work for Max > as well? Yes, it's really better. Some of my tests and also Xophe's gadget-test work now. But there is still a SIMPLE-ERROR "There is no applicable method for the generic function # when called with arguments (NIL)." for my example that has a WITH-OUTPUT-AS-GADGET inside an ACCEPTING-VALUES.. Btw. I've attached a patch for my interpretation of the description you've given for your changes.. There is a problem with the space requirement: I do my tests inside the CLIM-Listener and the scrollbar gets larger than needed, or better there is always some white space after the output-gadget (while its size seems to be related to the size of the actual gadget). (But I've just realized that I have a version of mcclim that is previous to Gilbert's recent work on the scrollbars. (Shame on me.)) And if I call a test in a freshly started Listener the output-gadget will always displayed in the top left corner of the Listener's application pane. Only if the first screen is "full" (that is the scrollbar gets actually useful) it will be displayed *after* the prompt (while it does not scroll past the gadget). Even a second or third output-gadget will be displayed in the top left corner on top of the previous gadgets, if the application pane does not yet scroll. I hope these confused descriptions are not too hard to understand. Thank you, Max -- Max-Gerd Retzlaff For your amusement: Gravity is a myth, the Earth sucks. -------------- next part -------------- --- gadgets.lisp__before-Paul-Werkowski 2005-12-25 21:43:55.957060368 +0100 +++ gadgets.lisp 2005-12-25 21:46:55.621747184 +0100 @@ -2742,13 +2742,8 @@ (defclass gadget-output-record (basic-output-record displayed-output-record) ((gadget :initarg :gadget :accessor gadget))) -(defmethod initialize-instance :after ((record gadget-output-record) &key child x y) - (let* ((sr (compose-space child)) - (width (space-requirement-width sr)) - (height (space-requirement-height sr))) - (allocate-space child width height) - (setf (gadget record) child - (rectangle-edges* record) (values x y (+ x width) (+ y height))))) +(defmethod initialize-instance :after ((record gadget-output-record) &key child) + (setf (gadget record) child)) (defmethod note-output-record-got-sheet ((record gadget-output-record) sheet) (multiple-value-bind (x y) (output-record-position record) @@ -2801,6 +2796,11 @@ (,gadget-output-record (make-instance 'gadget-output-record :child ,gadget :x (round ,x) :y (round ,y)))) (stream-add-output-record ,stream ,gadget-output-record) + (let* ((sr (compose-space ,gadget)) + (width (space-requirement-width sr)) + (height (space-requirement-height sr))) + (allocate-space ,gadget width height) + (setf (rectangle-edges* ,gadget-output-record) (values ,x ,y (+ ,x width) (+ ,y height)))) (setup-gadget-record ,stream ,gadget-output-record (round ,x) (round ,y)) (values ,gadget ,gadget-output-record))))) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From pw at snoopy.mv.com Sun Dec 25 21:20:24 2005 From: pw at snoopy.mv.com (Paul Werkowski) Date: Sun, 25 Dec 2005 16:20:24 -0500 Subject: with-output-as-gadget (was Re: [mcclim-devel] Missingrealizerincall to MAKE-PANE-1) References: <003a01c60801$01511b80$0201a8c0@moby><000701c6096b$dc9b8c50$0201a8c0@moby> <20051225204908.GA9042@mgr.home> Message-ID: <002c01c60999$057b22c0$0201a8c0@moby> > Seems to work for the cases I have tried. Maybe it will work for Max > as well? |Yes, it's really better. Some of my tests and also Xophe's gadget-test |work now. But there is still a SIMPLE-ERROR | "There is no applicable method for the generic function| | # |when | called with arguments (NIL)." |for my example that has a WITH-OUTPUT-AS-GADGET inside an |ACCEPTING-VALUES.. Btw. I've attached a patch for my interpretation of the description you've given for your changes.. I will try some more test - my Lispworks application uses w-o-a-g a lot so maybe that will turn more info. I will also try something with accepting-values. Re your patch, I've found that we can just get rid of the initialize-instance :after method. Make instance then should be called with the :gadget initarg instead of :child. Then the stuff in i-i :after can be stuffed into setup-gadget-record to save some space in the macro expansion. Will need to bind child with (gadget record) first. I'll post a more coherent patch, maybe tomorrow if testing goes well. Paul From pw at snoopy.mv.com Mon Dec 26 17:47:51 2005 From: pw at snoopy.mv.com (Paul Werkowski) Date: Mon, 26 Dec 2005 12:47:51 -0500 Subject: [mcclim-devel] Re: with-output-as-gadget References: <003a01c60801$01511b80$0201a8c0@moby><000701c6096b$dc9b8c50$0201a8c0@moby><20051225204908.GA9042@mgr.home> <002c01c60999$057b22c0$0201a8c0@moby> Message-ID: <000801c60a44$7e1272f0$0201a8c0@moby> | |Yes, it's really better. Some of my tests and also Xophe's gadget-test | |work now. But there is still a SIMPLE-ERROR | | "There is no applicable method for the generic function| | | # |when | | called with arguments (NIL)." | |for my example that has a WITH-OUTPUT-AS-GADGET inside an | |ACCEPTING-VALUES.. | | Btw. I've attached a patch for my interpretation of the description | you've given for your changes.. | | I will try some more test - my Lispworks application uses w-o-a-g a lot | so maybe that will turn more info. I will also try something with | accepting-values. Looks like some more problems here when using accepting-values. 1) The function SETUP-GADGET-RECORD wants (WITH-SLOTS (HEIGHT) ...) but the ACCEPTING-VALUES-STREAM has no such slot :( 2) INVOKE-ACCEPTING-VALUES calls ERASE-OUTPUT-RECORD which signals SHEET-IS-NOT-A-CHILD with child being the gadget - a TOGGLE-BUTTON-PANE in my case, and sheet being the APPLICATION-PANE, the stream arg to ACCEPTING-VALUES. How did that happen? When the gadget is like CHECK-BOX-PANE (with children), then there is the same problem as before where the pane is not yet adopted when someone wants the native-transformation. So, the A-V stream must have a different protocol in play? | I'll post a more coherent patch, maybe tomorrow if testing goes well. I guess my fix is not ready for prime time as yet. Too bad, having gadget-based accept methods depends on all this working right. Paul From pw at snoopy.mv.com Mon Dec 26 18:22:34 2005 From: pw at snoopy.mv.com (Paul Werkowski) Date: Mon, 26 Dec 2005 13:22:34 -0500 Subject: [mcclim-devel] Re: [mcclim-cvs] CVS update: mcclim/dialog.lisp Message-ID: <000301c60a49$57fd0d50$0201a8c0@moby> > In method > #: > No next method for arguments > (# NIL). > [Condition of type PCL::NO-NEXT-METHOD-ERROR] |That does not happen on sbcl. The last line of climi::close in |panes.lisp, the call (call-next-method) is the problem, as currently |there is no such next method. The following patch helps but I'll not |commit it as there might be such a method in the future. See The solution here is (when (next-method-p)(call-next-method))Paul From pw at snoopy.mv.com Wed Dec 28 21:58:27 2005 From: pw at snoopy.mv.com (Paul Werkowski) Date: Wed, 28 Dec 2005 16:58:27 -0500 Subject: [mcclim-devel] Re: with-output-as-gadget References: <003a01c60801$01511b80$0201a8c0@moby><000701c6096b$dc9b8c50$0201a8c0@moby><20051225204908.GA9042@mgr.home><002c01c60999$057b22c0$0201a8c0@moby> <000801c60a44$7e1272f0$0201a8c0@moby> Message-ID: <002001c60bf9$d585b630$0201a8c0@moby> Here is a patch that gets with-output-as-gadget working better. It seems to work correctly but using updating-output has revealed some problems that I don't yet know how to fix (still working on it). The biggest problem with updating-output is that redisplay causes a new gadget-output-record to be created, but the gadget is not adopted by any sheet. The first gadget created remains as the adopted one but each redisplay causes the new, unadopted gadget to be "current". This shows up when erase-output-record is used and sheet-disown-child complains that the supplied gadget is not a child of sheet. Wrapping the with-output-as-gadget form as in (updating-output (stream :cache-value t) (with-output-as-gadget (stream) ...)) is a workaround. That workaround won't work in accepting-values though because invoke-updating-output fails with a no-applicable-method error on the stream ;-( The more minor problem (but still vexing) is that somehow updating-output ignores the stream-cursor-position adjustment that is supposed to move the cursor to after the gadget. The adjustment works fine without updating-output. I think the patch is safe to commit. Maybe someone has some ideas about solving the updating-output problems? Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: gadget.patch Type: application/octet-stream Size: 5783 bytes Desc: not available URL: From athas at sigkill.dk Fri Dec 30 00:16:03 2005 From: athas at sigkill.dk (Troels Henriksen) Date: Fri, 30 Dec 2005 01:16:03 +0100 Subject: [mcclim-devel] Command and non-ASCII problems Message-ID: <87psnfqw1o.fsf@sigkill.dk> Hi, I'm trying to learn CLIM, through McCLIM, from the ground up, but I'm having a slight problem with commands. The following example program shows the issue: (in-package :clim-user) (define-application-frame example-editor () () (:menu-bar menubar-command-table) (:panes (text-edit :text-editor)) (:layouts (default text-edit))) (define-example-editor-command com-quit () (frame-exit *application-frame*)) (make-command-table 'file-command-table :errorp nil :menu '(("Quit" :command com-quit))) (make-command-table 'menubar-command-table :errorp nil :menu '(("File" :menu file-command-table))) The "Quit" menu option shows up just fine, but nothing happens when I click it. Why is this? Furthermore, non-ASCII-input (the Danish special characters ?, ? and ?, for example) does not show up in the text-editor pane. I assume that McCLIM lacks support for this. Where would I want to look, if I am to hack up some support for this? -- \ Troels "Athas" Henriksen /\ sigkill.dk/blog (Danish) From csr21 at cam.ac.uk Fri Dec 30 08:49:39 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Fri, 30 Dec 2005 08:49:39 +0000 Subject: [mcclim-devel] Command and non-ASCII problems In-Reply-To: <87psnfqw1o.fsf@sigkill.dk> (Troels Henriksen's message of "Fri, 30 Dec 2005 01:16:03 +0100") References: <87psnfqw1o.fsf@sigkill.dk> Message-ID: Troels Henriksen writes: > Furthermore, non-ASCII-input (the Danish special characters ?, ? and > ?, for example) does not show up in the text-editor pane. I assume > that McCLIM lacks support for this. Where would I want to look, if I > am to hack up some support for this? This is (unfortunately) a complicated problem. The CLX functions for drawing text take a :translate keyword argument, for translating from characters to (font, glyph index) pairs. has much more detail about this; the default translate function simply maps ascii characters to their char-codes, and assumes that the font never changes. So to hack support for Danish special characters, it might be as simple as finding a font that is encoded in iso-8859-1, making sure it's available on all X servers, using it in McCLIM, and writing a slightly less conservative translate-function. Of course, this won't get (say) the euro symbol to work, because that's not in the iso-8859-1 repertoire; it is in -15, but using that would mean losing some other characters. So a more proper answer might be to find a font encoded in iso-10646-1, which is basically 16-bit Unicode. Typically, fonts don't actually have all 2^16 points filled, but at least the translate function for those is still relatively simple. Otherwise, one might need to use sets of fonts and change between them where necessary. (All of this assumes that you're using the CLX backend, of course; I have no idea how any of this works in other backends...) Cheers, Christophe From moore at bricoworks.com Fri Dec 30 09:57:46 2005 From: moore at bricoworks.com (Timothy Moore) Date: Fri, 30 Dec 2005 10:57:46 +0100 Subject: [mcclim-devel] Command and non-ASCII problems In-Reply-To: <87psnfqw1o.fsf@sigkill.dk> References: <87psnfqw1o.fsf@sigkill.dk> Message-ID: <3e52359d44e85b9bb1f9959460a6bd6e@bricoworks.com> On Dec 30, 2005, at 1:16 AM, Troels Henriksen wrote: > Hi, I'm trying to learn CLIM, through McCLIM, from the ground up, but > I'm having a slight problem with commands. The following example > program shows the issue: > > (in-package :clim-user) > > (define-application-frame example-editor () > () > (:menu-bar menubar-command-table) > (:panes > (text-edit :text-editor)) > (:layouts > (default > text-edit))) > > (define-example-editor-command com-quit () > (frame-exit *application-frame*)) > ... > The "Quit" menu option shows up just fine, but nothing happens when I > click it. Why is this? The problem is that there is no application-pane (standard CLIM drawing area) or interactor-pane (used for entering commands), so the whole CLIM command infrastructure, which includes processing menu clicks, is effectively disabled. I need to ponder whether or not this is correct (I suspect not; the motivation was that with no *standard-input`* there would be no place from which to read commands, but that's obviously not correct in the presence of menus), but in the mean-time you want to conduct your experiments with application panes or interactor panes, or at the least add one of those panes to your application. Tim From pw at snoopy.mv.com Fri Dec 30 17:24:45 2005 From: pw at snoopy.mv.com (Paul Werkowski) Date: Fri, 30 Dec 2005 12:24:45 -0500 Subject: [mcclim-devel] Improved patch for with-output-as-gadget Message-ID: <000e01c60d65$ed939d10$0201a8c0@moby> Here is an improved patch that fixes problems in an earlier post with incorrect cursor position when incremental redisplay was active. It is still required that calls to with-output-as-gadget be wrapped in (updating-output ( ... :cache-value )) to avoid problems if the output-record is ever erased. Happy New Year! Paul -------------- next part -------------- A non-text attachment was scrubbed... Name: gadget.patch Type: application/octet-stream Size: 5717 bytes Desc: not available URL: From csr21 at cam.ac.uk Fri Dec 30 17:50:14 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Fri, 30 Dec 2005 17:50:14 +0000 Subject: [mcclim-devel] [patch] fix apparent typos In-Reply-To: <87psq5cors.fsf@beer.intern> (Tim Daly, Jr.'s message of "16 Oct 2005 20:14:47 +0200") References: <87psq5cors.fsf@beer.intern> Message-ID: tim at tenkan.org (Tim Daly Jr.) writes: > In my travels through the looking-pane, I bumped into these: Thank you. Merged, a few months later... Cheers, Christophe From csr21 at cam.ac.uk Fri Dec 30 18:06:16 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Fri, 30 Dec 2005 18:06:16 +0000 Subject: [mcclim-devel] [patch] fix typos and postscript backend In-Reply-To: <1135340799.22500.41.camel@beer.intern> (Tim Daly, Jr.'s message of "Fri, 23 Dec 2005 13:26:39 +0100") References: <1135340799.22500.41.camel@beer.intern> Message-ID: "Tim Daly Jr." writes: > I attempted to add output recording for NEW-PAGE. This patch fixes the > postscript test mostly -- page 7 is translated to the lower right corner > for some reason, but it's at least syntactically correct. I have no > understanding of this stuff, so please check whether I've done something > boneheaded. I think this works "by accident", because the top-level output record is a sequence output record (rather than some complicated multidimensional data structure output record) and so the new-page-output-records in the replay happen in the same order and at the same points that they happened when drawing. I could have sworn that I checked that postscript-test worked before checking in, but apparently not, and indeed multipage output could not possibly have worked, so I must have tested an older implementation. Sorry about that. I can't immediately see why a transformation has occurred, and I'm afraid my free seconds have run out, so I've merged the patch. Thanks, Christophe From athas at sigkill.dk Fri Dec 30 20:03:07 2005 From: athas at sigkill.dk (Troels Henriksen) Date: Fri, 30 Dec 2005 21:03:07 +0100 Subject: [mcclim-devel] Command and non-ASCII problems In-Reply-To: (Christophe Rhodes's message of "Fri, 30 Dec 2005 08:49:39 +0000") References: <87psnfqw1o.fsf@sigkill.dk> Message-ID: <87k6dms684.fsf@sigkill.dk> Christophe Rhodes writes: > This is (unfortunately) a complicated problem. Indeed it is. I've hacked a few things up in CLX that allows me to read Danish special characters from the keyboard. This was mostly about redefing `translate-default' and modifying *keysym->character-map* in CLX itself (as I said, a hack). It works in pure CLX-applications, but for some reason, not in McCLIM. Have I missed something? I've traced `lookup-keysym' in Backends/CLX/keysyms-common.lisp, and it appears to look up the characters alright, so I don't really understand what is wrong. -- \ Troels "Athas" Henriksen /\ sigkill.dk/blog (Danish)