From o.finnendahl at mh-freiburg.de Mon May 4 08:08:45 2009 From: o.finnendahl at mh-freiburg.de (Orm Finnendahl) Date: Mon, 4 May 2009 10:08:45 +0200 Subject: [mcclim-devel] three questions Message-ID: <20090504080845.GA14169@varese> Hi, still working on my specialized browser I'm starting to implement the gui part of the application. Three questions: - Can I update (redraw) a pane without activating it with the mouse? "(window-refresh pane)" doesn't actually draw unless the window gets activated in the window-manager). - How can I implement scrolling in the pane? The scroll bars are there but they don't get updated if I draw off the visible region of the pane. - Is there a straightforward way to get a reference to an output record upon creation of the output record (to store it in the object which gets presented)? I can get it by searching the list of all output records in a pane and compare it's object slot to the object, but that seems rather inefficient, especially since newly allocated output records are appended to the end of the list. Currently I'm creating the output records in a loop of "draw-line*" embedded in "(with-output-as-presentation)". Maybe I'm doing it wrong by trying to access the output records themselves. This is the idea: I want to present graphical objects and change the shape of some of them using incremental redisplay. As far as I see, this should be done by deleting the respective output record and redrawing it with the new properties. Can anybody help? Sorry if I'm missing the obvious... Thanks, Orm From ahefner at gmail.com Tue May 5 04:30:52 2009 From: ahefner at gmail.com (Andy Hefner) Date: Tue, 5 May 2009 04:30:52 +0000 Subject: [mcclim-devel] three questions In-Reply-To: <20090504080845.GA14169@varese> References: <20090504080845.GA14169@varese> Message-ID: <31ffd3c40905042130j211e6581pc96048617e6082c4@mail.gmail.com> On Mon, May 4, 2009 at 8:08 AM, Orm Finnendahl wrote: > Hi, > > still working on my specialized browser I'm starting to implement the > gui part of the application. Three questions: > > - Can I update (redraw) a pane without activating it with the mouse? > ?"(window-refresh pane)" doesn't actually draw unless the window gets > ?activated in the window-manager). That sounds very odd. I could speculate at causes, but McCLIM's definition of window-refresh looks suspect anyway. I recommend using (repaint-sheet stream (window-viewport stream)) instead of window-refresh. Possibly there's a buffering issue, but in most circumstances McCLIM takes care of that for you. Try calling finish-output on the stream after drawing. > - How can I implement scrolling in the pane? The scroll bars are there > ?but they don't get updated if I draw off the visible region of the > ?pane. After drawing on the pane, at some point the pane has to be resized to fit the output. McCLIM tries to do this itself at appropriate times (such as at the end of lines of text, after calling the display function, or table/graph formatting), but this is somewhat expensive so the various drawing functions don't do it automatically. In particular, if you're working outside the normal paradigm of display functions, you might have to do this manually. One way is to call change-space-requirements on the pane with a width determined from the bounding rectangle of the stream-output-history. A shorter way is to call climi::fit-pane-to-output, which is what mcclim calls internally. > - Is there a straightforward way to get a reference to an output > ?record upon creation of the output record (to store it in the object > ?which gets presented)? with-output-as-presentation returns the output record of the presentation. If you mean it's the output record of the drawn lines you want, I don't know of a good way of obtaining those as such. What I do is to draw things inside with-new-output-record, which will return a standard-sequence-output-record containing your drawing, then come back and add/remove things from this record or delete it altogether. > Maybe I'm doing it wrong by trying to access the output records > themselves. This is the idea: I want to present graphical objects and > change the shape of some of them using incremental redisplay. As far > as I see, this should be done by deleting the respective output record > and redrawing it with the new properties. I do this sort of thing all the time (directly manipulating output records) and it's a powerful approach. Incremental redisplay is a higher level facility intended to spare you from the lower level details of dealing directly with output records, using updating-output to handle caching and update of sections of the output. There might be some confusion of terminology here. Perhaps using the higher level facilities will make things simpler. I personally always go the lower level route that you seem to be taking (mostly because I understand the output recording code quite well and like to maintain complete control), but other software like Climacs and the inspector have used incremental redisplay to good effect. From rm at seid-online.de Tue May 5 07:55:42 2009 From: rm at seid-online.de (Ralf Mattes) Date: Tue, 05 May 2009 09:55:42 +0200 Subject: [mcclim-devel] three questions In-Reply-To: <31ffd3c40905042130j211e6581pc96048617e6082c4@mail.gmail.com> References: <20090504080845.GA14169@varese> <31ffd3c40905042130j211e6581pc96048617e6082c4@mail.gmail.com> Message-ID: <1241510142.7857.3.camel@mhflaptop01> On Tue, 2009-05-05 at 04:30 +0000, Andy Hefner wrote: > On Mon, May 4, 2009 at 8:08 AM, Orm Finnendahl > wrote: > > Hi, Hi Orm, > > still working on my specialized browser I'm starting to implement the > > gui part of the application. Three questions: > > > > - Can I update (redraw) a pane without activating it with the mouse? > > "(window-refresh pane)" doesn't actually draw unless the window gets > > activated in the window-manager). Just a shot into the dark: are you using a "fancy" window system with a composition manager (like compiz or the like)? This could be caused by a broken heuristic off when the composition manager needs to redraw the screen from the buffer. Cheers, RalfD > That sounds very odd. I could speculate at causes, but McCLIM's > definition of window-refresh looks suspect anyway. I recommend using > (repaint-sheet stream (window-viewport stream)) instead of > window-refresh. Possibly there's a buffering issue, but in most > circumstances McCLIM takes care of that for you. Try calling > finish-output on the stream after drawing. > > > - How can I implement scrolling in the pane? The scroll bars are there > > but they don't get updated if I draw off the visible region of the > > pane. > > After drawing on the pane, at some point the pane has to be resized to > fit the output. McCLIM tries to do this itself at appropriate times > (such as at the end of lines of text, after calling the display > function, or table/graph formatting), but this is somewhat expensive > so the various drawing functions don't do it automatically. In > particular, if you're working outside the normal paradigm of display > functions, you might have to do this manually. One way is to call > change-space-requirements on the pane with a width determined from the > bounding rectangle of the stream-output-history. A shorter way is to > call climi::fit-pane-to-output, which is what mcclim calls internally. > > > - Is there a straightforward way to get a reference to an output > > record upon creation of the output record (to store it in the object > > which gets presented)? > > with-output-as-presentation returns the output record of the > presentation. If you mean it's the output record of the drawn lines > you want, I don't know of a good way of obtaining those as such. What > I do is to draw things inside with-new-output-record, which will > return a standard-sequence-output-record containing your drawing, then > come back and add/remove things from this record or delete it > altogether. > > > Maybe I'm doing it wrong by trying to access the output records > > themselves. This is the idea: I want to present graphical objects and > > change the shape of some of them using incremental redisplay. As far > > as I see, this should be done by deleting the respective output record > > and redrawing it with the new properties. > > I do this sort of thing all the time (directly manipulating output > records) and it's a powerful approach. Incremental redisplay is a > higher level facility intended to spare you from the lower level > details of dealing directly with output records, using updating-output > to handle caching and update of sections of the output. There might be > some confusion of terminology here. Perhaps using the higher level > facilities will make things simpler. I personally always go the lower > level route that you seem to be taking (mostly because I understand > the output recording code quite well and like to maintain complete > control), but other software like Climacs and the inspector have used > incremental redisplay to good effect. > > _______________________________________________ > mcclim-devel mailing list > mcclim-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel From o.finnendahl at mh-freiburg.de Tue May 5 09:09:23 2009 From: o.finnendahl at mh-freiburg.de (Orm Finnendahl) Date: Tue, 5 May 2009 11:09:23 +0200 Subject: [mcclim-devel] three questions In-Reply-To: <31ffd3c40905042130j211e6581pc96048617e6082c4@mail.gmail.com> References: <20090504080845.GA14169@varese> <31ffd3c40905042130j211e6581pc96048617e6082c4@mail.gmail.com> Message-ID: <20090505090923.GA9497@varese> Hi Andy, thanks for your post, your insight and the explanations saved me hours! You're right about the confusion on my part about incremental redisplay. I thought it is a generic term and didn't exactly understand the way it is implemented in clim. I found out about the mechanism of updating-output yesterday and got a working example (and a vague idea, how it works internally). The mechanism is amazing and can probably save lots of coding time, but it might be a little too expensive. IIUC a redisplay function has to traverse all output records in order to find out which ones have changed. That might be too inefficient when doing redraws of changing records during pointer-motion, but I'll see about that. I will also check your suggestions about window redrawing. I found out that a call to force-output on the pane will do the redraw on my system (Linux/X11). -- Orm Am Dienstag, den 05. Mai 2009 um 04:30:52 Uhr (+0000) schrieb Andy Hefner: > On Mon, May 4, 2009 at 8:08 AM, Orm Finnendahl > wrote: > > Hi, > > > > still working on my specialized browser I'm starting to implement the > > gui part of the application. Three questions: > > > > - Can I update (redraw) a pane without activating it with the mouse? > > ?"(window-refresh pane)" doesn't actually draw unless the window gets > > ?activated in the window-manager). > > That sounds very odd. I could speculate at causes, but McCLIM's > definition of window-refresh looks suspect anyway. I recommend using > (repaint-sheet stream (window-viewport stream)) instead of > window-refresh. Possibly there's a buffering issue, but in most > circumstances McCLIM takes care of that for you. Try calling > finish-output on the stream after drawing. > > > - How can I implement scrolling in the pane? The scroll bars are there > > ?but they don't get updated if I draw off the visible region of the > > ?pane. > > After drawing on the pane, at some point the pane has to be resized to > fit the output. McCLIM tries to do this itself at appropriate times > (such as at the end of lines of text, after calling the display > function, or table/graph formatting), but this is somewhat expensive > so the various drawing functions don't do it automatically. In > particular, if you're working outside the normal paradigm of display > functions, you might have to do this manually. One way is to call > change-space-requirements on the pane with a width determined from the > bounding rectangle of the stream-output-history. A shorter way is to > call climi::fit-pane-to-output, which is what mcclim calls internally. > > > - Is there a straightforward way to get a reference to an output > > ?record upon creation of the output record (to store it in the object > > ?which gets presented)? > > with-output-as-presentation returns the output record of the > presentation. If you mean it's the output record of the drawn lines > you want, I don't know of a good way of obtaining those as such. What > I do is to draw things inside with-new-output-record, which will > return a standard-sequence-output-record containing your drawing, then > come back and add/remove things from this record or delete it > altogether. > > > Maybe I'm doing it wrong by trying to access the output records > > themselves. This is the idea: I want to present graphical objects and > > change the shape of some of them using incremental redisplay. As far > > as I see, this should be done by deleting the respective output record > > and redrawing it with the new properties. > > I do this sort of thing all the time (directly manipulating output > records) and it's a powerful approach. Incremental redisplay is a > higher level facility intended to spare you from the lower level > details of dealing directly with output records, using updating-output > to handle caching and update of sections of the output. There might be > some confusion of terminology here. Perhaps using the higher level > facilities will make things simpler. I personally always go the lower > level route that you seem to be taking (mostly because I understand > the output recording code quite well and like to maintain complete > control), but other software like Climacs and the inspector have used > incremental redisplay to good effect. From ahefner at gmail.com Tue May 5 21:51:45 2009 From: ahefner at gmail.com (Andy Hefner) Date: Tue, 5 May 2009 21:51:45 +0000 Subject: [mcclim-devel] three questions In-Reply-To: <20090505090923.GA9497@varese> References: <20090504080845.GA14169@varese> <31ffd3c40905042130j211e6581pc96048617e6082c4@mail.gmail.com> <20090505090923.GA9497@varese> Message-ID: <31ffd3c40905051451v6236deacif32eaf0043c681a7@mail.gmail.com> On Tue, May 5, 2009 at 9:09 AM, Orm Finnendahl wrote: > I will also check your suggestions about window redrawing. I found out > that a call to force-output on the pane will do the redraw on my > system (Linux/X11). Out of curiousity, which implementation of lisp are you using? McCLIM is supposed to flush the CLX buffers before going to sleep to wait for events, but this is one of the areas where threaded/unthreaded builds of McCLIM differ, and my impression is that all the active developers use lisps with threading enabled, so the single process path doesn't get tested so often. Maybe it got overlooked. From o.finnendahl at mh-freiburg.de Wed May 6 06:13:37 2009 From: o.finnendahl at mh-freiburg.de (Orm Finnendahl) Date: Wed, 6 May 2009 08:13:37 +0200 Subject: [mcclim-devel] three questions In-Reply-To: <31ffd3c40905051451v6236deacif32eaf0043c681a7@mail.gmail.com> References: <20090504080845.GA14169@varese> <31ffd3c40905042130j211e6581pc96048617e6082c4@mail.gmail.com> <20090505090923.GA9497@varese> <31ffd3c40905051451v6236deacif32eaf0043c681a7@mail.gmail.com> Message-ID: <20090506061337.GE6579@varese> Hi Andy, Am Tuesday, den 05. May 2009 um 21:51:45 Uhr (+0000) schrieb Andy Hefner: > > Out of curiousity, which implementation of lisp are you using? McCLIM I use sbcl, version 1.0.18 (Ubuntu build) and have no idea, whether threading is enabled in sbcl or the mcclim build. How do I find out? -- Orm From ahefner at gmail.com Wed May 6 07:23:34 2009 From: ahefner at gmail.com (Andy Hefner) Date: Wed, 6 May 2009 07:23:34 +0000 Subject: [mcclim-devel] three questions In-Reply-To: <20090506061337.GE6579@varese> References: <20090504080845.GA14169@varese> <31ffd3c40905042130j211e6581pc96048617e6082c4@mail.gmail.com> <20090505090923.GA9497@varese> <31ffd3c40905051451v6236deacif32eaf0043c681a7@mail.gmail.com> <20090506061337.GE6579@varese> Message-ID: <31ffd3c40905060023v745a57fbs4d3d25acfd9e859e@mail.gmail.com> In *features*, :sb-thread is present in builds with threads (and also :clim-mp, once mcclim is loaded). On Wed, May 6, 2009 at 6:13 AM, Orm Finnendahl wrote: > Hi Andy, > > Am Tuesday, den 05. May 2009 um 21:51:45 Uhr (+0000) schrieb Andy Hefner: >> >> Out of curiousity, which implementation of lisp are you using? McCLIM > > I use sbcl, version 1.0.18 (Ubuntu build) and have no idea, whether > threading is enabled in sbcl or the mcclim build. How do I find out? > > -- > Orm > From evgeny.zubok at tochka.ru Tue May 19 10:02:05 2009 From: evgeny.zubok at tochka.ru (Evgeny M. Zubok) Date: Tue, 19 May 2009 14:02:05 +0400 Subject: [mcclim-devel] [PATCH] Fix copy-from-pixmap to work inside with-output-to-pixmap Message-ID: <87ws8dwgv6.fsf@tochka.ru> The attached patch fixes bug when I'm trying to copy pixmap to medium-var inside the body of with-output-to-pixmap macro. The explanation below. >From CLIM 2.0 (LispWorks) with-output-to-pixmap [Macro] Arguments: (medium-var medium &key width height) &body body Summary: Binds `medium-var' to a "pixmap medium" (that is, a medium that does output to a pixmap with the characteristics appropriate to the medium `medium') and then evaluates body in that context. All the output done to the medium designated by `medium-var' inside of body is drawn on the pixmap stream. The pixmap medium supports the medium output protocol, including all of the graphics functions. `width' and `height' are integers that give the dimensions of the pixmap. If they are omitted, the pixmap will be large enough to contain all the output done by body. `medium-var' must be a symbol; it is not evaluated. The returned value is a pixmap that can be drawn onto medium using copy-from-pixmap. As soon as "The pixmap medium supports the medium output protocol, including all of the graphics functions." then the copy-from-pixmap also has to work inside with-output-to-pixmap macro. I've written simple and quick example (attached) to illustrate this. In the handle-repaint method the temporary pixmap `temp-pixmap' is created with yellow background and filled circle in centre. Then `temp-pixmap' is copied with copy-from-pixmap inside with-output-to-pixmap macro into newly created `target-pixmap' and the second circle is drawn above. Finally the `target-pixmap' is copied to canvas. (copy-from-pixmap-test::run) to run the example. -------------- next part -------------- A non-text attachment was scrubbed... Name: mcclim_fix_sheet-direct-mirror.patch Type: text/x-diff Size: 466 bytes Desc: Patch URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: copy-from-pixmap-test.lisp Type: application/octet-stream Size: 1092 bytes Desc: Example URL: From kilian.sprotte at gmail.com Sun May 31 12:55:36 2009 From: kilian.sprotte at gmail.com (Kilian Sprotte) Date: Sun, 31 May 2009 12:55:36 +0000 (UTC) Subject: [mcclim-devel] calling command from activate-callback Message-ID: Hi, I have a very beginners question about calling a command from a push-button. It seems that I need to call redisplay-frame-panes in the activate-callback, although this is not necessary if I invoke the command from the interactor. (button2 push-button :label "incf and call REDISPLAY-FRAME-PANES" :activate-callback (lambda (button) (declare (ignore button)) (com-incf) ;; * (redisplay-frame-panes *application-frame*))) Is an activation of a push-button not an event in the command-loop? I would be glad to know, how this is supposed to be done. Best, Kilian ================================================ My changes to the SUPERAPP: (in-package :common-lisp-user) (defpackage "APP" (:use :clim :clim-lisp) (:export "APP-MAIN")) (in-package :app) (define-application-frame superapp () ((currrent-number :initform 1 :accessor current-number)) (:pointer-documentation t) (:panes (app :application :height 400 :width 600 :display-function 'display-app) (button push-button :label "incf" :activate-callback (lambda (button) (declare (ignore button)) (com-incf))) (button2 push-button :label "incf and call REDISPLAY-FRAME-PANES" :activate-callback (lambda (button) (declare (ignore button)) (com-incf) (redisplay-frame-panes *application-frame*))) (int :interactor :height 200 :width 600)) (:layouts (default (vertically () (horizontally () +fill+ button button2 +fill+) app int)))) (defun display-app (frame pane) (let ((number (current-number frame))) (format pane "~a is ~a" number (cond ((null number) "not a number") ((oddp number) "odd") (t "even"))))) (defun app-main () (run-frame-top-level (make-application-frame 'superapp))) (define-superapp-command (com-quit :name t) () (frame-exit *application-frame*)) (define-superapp-command (com-parity :name t) ((number 'integer)) (setf (current-number *application-frame*) number)) (define-superapp-command (com-incf :name t) () (incf (current-number *application-frame*))) From athas at sigkill.dk Sun May 31 15:50:52 2009 From: athas at sigkill.dk (Troels Henriksen) Date: Sun, 31 May 2009 17:50:52 +0200 Subject: [mcclim-devel] calling command from activate-callback In-Reply-To: (Kilian Sprotte's message of "Sun\, 31 May 2009 12\:55\:36 +0000 \(UTC\)") References: Message-ID: <87prdpe0f7.fsf@lambda.athas.dyndns.dk> Kilian Sprotte writes: > Hi, > > I have a very beginners question about calling a > command from a push-button. > > It seems that I need to call redisplay-frame-panes > in the activate-callback, although this is not necessary if > I invoke the command from the interactor. > > (button2 push-button > :label "incf and call REDISPLAY-FRAME-PANES" > :activate-callback > (lambda (button) > (declare (ignore button)) > (com-incf) > ;; * > (redisplay-frame-panes *application-frame*))) > > Is an activation of a push-button not an event in the command-loop? Indeed not, events/callbacks are asynchronous and separate from the command loop. > I would be glad to know, how this is supposed to be done. Manually redisplaying seems like an adequate solution. If your program is large, or does advanced things with its command loop, you may want to cause callbacks to integrate with it by various means, though. -- \ Troels /\ Henriksen