mcclim-devel January 2006

mcclim-devel@common-lisp.net

14 participants
15 discussions

[mcclim-devel] Support for :insert-default in `accept'
by Troels Henriksen 17 Jan '06

17 Jan '06

I have tried to implement support for the :insert-default option for the `accept'-function. in McCLIM. Attached to this post is a patch for presentation-defs.lisp that seems to work for the test cases I have tried (mostly some other hacks on Climacs). Could someone with more (Mc)CLIM-fu than me tell me whether or not it is acceptable? -- \ Troels "Athas" Henriksen /\ sigkill.dk/blog (Danish)

1 0

[mcclim-devel] accepting-values: prompts not clickable, no redraw, improper output recording?
by Clemens Fruhwirth 09 Jan '06

09 Jan '06

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<ret>" 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(a)endorphin.org

1 2

[mcclim-devel] Command and non-ASCII problems
by Troels Henriksen 08 Jan '06

08 Jan '06

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)

5 7

[mcclim-devel] space requirements :min-:max options
by Clemens Fruhwirth 04 Jan '06

04 Jan '06

According to the CLIM spec 29.3.1 Layout Pane Options: "If either of the :max-height or :min-height options is not supplied, it defaults to the value of the :height option." However in panes.lisp, I see: ;; NOTE: The defaulting for :min-foo and :max-foo is different from MAKE-SPACE-REQUIREMENT. ;; MAKE-SPACE-REQUIREMENT has kind of &key foo (min-foo 0) (max-foo +fill+) ;; While user space requirements has &key foo (min-foo foo) (max-foo foo). ;; I as a user would pretty much expect the same behavior, therefore I'll take the ;; following route: ;; When the :foo option is given, I'll let MAKE-SPACE-REQUIREMENT decide. May I urge you to change revert that change. The :height and :width initargs loss their usefulness this way. Also it's a bit counter-intutive. Look at (define-application-frame only-red () () (:pane (vertically () (make-pane 'application-pane :background +red+ :min-height 100) +fill+ (make-pane 'application-pane :background +blue+ :height 100)))) Wouldn't you expect to see two panes, one blue with height 100 and a red one at least 100 pixel high? The reason for this query is that I have troubles explaining the readers of my CLIM tutorial why McCLIM violates the spec and why :height as well as :width are mostly useless at the moment. See panes.lisp "merge-one-option" (Line 549) and the commented code ;; (setf user-max-foo (or user-max-foo user-foo) ;; user-min-foo (or user-min-foo user-foo)) Thanks, -- Fruhwirth Clemens - http://clemens.endorphin.org for robots: sp4mtrap(a)endorphin.org

1 0

[mcclim-devel] repaint-sheet, +everywhere+ and output recording
by Clemens Fruhwirth 02 Jan '06

02 Jan '06

(repaint-sheet instance-inheriting-from-output-recording-stream +everywhere+) does not work. The reason is %handle-repaint in recording.lisp. It rewrites region to a bounding-rectangle regardless the type of the region. Hence, %handle-repaint needs to check whether region is region-equal to +nowhere+ or +everywhere+, the only unbounded region types that do not participate in the bounding rectangle protocol. Please comment on my patch, because I personally don't like it. It seems a bit ackward to make explicit checks for these two regions, probably there are better solutions. If you need something to reproduce the bug, try http://paste.lisp.org/display/15284#3 - uncomment standard-output-recording-stream from the long list of superclasses that imitate those of application-pane to reproduce the error. -- Fruhwirth Clemens - http://clemens.endorphin.org for robots: sp4mtrap(a)endorphin.org

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

mcclim-devel January 2006