Hi;
The McCLIM app I am writing has both a pan/zoom application pane and an interactor pane. I am trying to track down why the top-level frame gets resized (radically - too big to fit the X11 screen) when things get drawn onto the canvas.
Immediately upon tracing clim:layout-frame, I was surprised to see it (unexpectedly, to me) getting called as each letter it typed into the interactor pane - before I actually start drawing anything (much) onto the canvas/application pane. I am guessing that my output-record-producing drawing similarly triggers the layout protocol again...
Is this expected behavior? I was hoping/expecting that the frame layout was computed a "final" time, and then I could draw onto one of its panes with impunity, counting on visible region clipping.
If it is not expected behavior, I would be happy to try and track it down. If it is expected behavior, is there some way to prevent it? It is indeed strange for the application to "spontaneously" and dramatically change its size/realization on the screen.
Thanks!
-jm
Hi;
Should have provided an example of the behavior that, at a minimum, doesn't include my code (which may be at fault). Sorry for the omission.
If you run the following, bring up the address-book demo, then type "help" its interactor...
sbcl --eval '(ql:quickload :clim-examples)' --eval '(trace clim:layout-frame)' --eval '(clim-demo:demodemo)'
you will see the repeated calls to layout-frame...
-jm
On Thu, Nov 16, 2017 at 12:08 PM, John Morrison jm@symbolic-simulation.com wrote:
Hi;
The McCLIM app I am writing has both a pan/zoom application pane and an interactor pane. I am trying to track down why the top-level frame gets resized (radically - too big to fit the X11 screen) when things get drawn onto the canvas.
Immediately upon tracing clim:layout-frame, I was surprised to see it (unexpectedly, to me) getting called as each letter it typed into the interactor pane - before I actually start drawing anything (much) onto the canvas/application pane. I am guessing that my output-record-producing drawing similarly triggers the layout protocol again...
Is this expected behavior? I was hoping/expecting that the frame layout was computed a "final" time, and then I could draw onto one of its panes with impunity, counting on visible region clipping.
If it is not expected behavior, I would be happy to try and track it down. If it is expected behavior, is there some way to prevent it? It is indeed strange for the application to "spontaneously" and dramatically change its size/realization on the screen.
Thanks!
-jm
Hello John,
sorry for a late reply. layout-frame is invoked by pointer-documentation. If you skip it in your frame, then there is no redundant calls to layout-frame on typing in the inspector. Generally layout-frame is invoked when:
- new layout is set (with `(setf (frame-current-layout) 'foo)`)
- space-requirements change
If you do something what changes size requirements repeatedly but you want to batch them into single layout-frame call `*change-space-requirements*`.
For more information please consult: http://bauhh.dyndns.org:8000/clim-spec/29-3.html#_1662
If it is possible to make pointer-documentation-pane changing space requirements less frequent, I'm up to it of course.
Best regards, Daniel
On 16.11.2017 19:35, John Morrison wrote:
sbcl --eval '(ql:quickload :clim-examples)' --eval '(trace clim:layout-frame)' --eval '(clim-demo:demodemo)'
-
Daniel Kochmański -
John Morrison