mcclim-devel May 2007

mcclim-devel@common-lisp.net

11 participants
9 discussions

[mcclim-devel] Background ink in accept dialog
by daniel＠bigwalter.net 27 May '07

27 May '07

Patch: Change accept-present-default, textual-dialog-view, to use *3d-normal-color* for background ink. A similar change was made for menus in menu-choose.lisp.

1 0

[mcclim-devel] The accept-values command table
by daniel＠bigwalter.net 27 May '07

27 May '07

McCLIM for some reason uses the name accepting-values for the accepting-values command table. The CLIM spec uses a slightly different name; accept-values. This patch changes the name. The change will break some programs. Scigraph uses the McCLIM name in a few places. I made a patch for this program, but I haven't tested it.

1 0

[mcclim-devel] Update object of a presentation.
by Knut Olav Bøhmer 27 May '07

27 May '07

Hi, Let's say I have an object, that is presented with (present ...) on a pane. It is then drawn on the pane with (define-presentation-method present (...) (draw-arrow (start-of object) (end-of object) ...)) The arrow is used to represent the speed and direction of some external object (like the wind) Then the wind speed and direction changes, so the object is updated. Now I need to update the presentation to reflect the changes in the object. How can I update just that object? -- Knut Olav Bøhmer

5 6

[mcclim-devel] small baby clim steps
by Knut Olav Bøhmer 19 May '07

19 May '07

Hei, I'm in the process of learning clim, I have a small code example under. What I want to do is to add my own pane to a the display pane. Later I want to be able to move the pane around in the pane by clicking on the pane and drag it to the new place. My first problem is that I don't know how to insert new panes into the "display" pane.. The with-output-as-gadget require a stream, and I don't know how to obtain this stream, and if the example under will work. (define-application-frame test () () (:panes (display :application :output-record (make-instance 'standard-tree-output-record)) (my-interactor :interactor)) (:layouts (:default (vertically (:height 500 :width 400) (2/3 display) (1/3 my-interactor))))) (define-test-command (com-add :name t :menu "Add") () (with-output-as-gadget (stream) (make-pane 'push-button :label "Click here to exit" :activate-callback #'(lambda (button) (frame-exit (pane-frame button))))))) -- Knut Olav Bøhmer

1 3

[mcclim-devel] Presentation Translator Utilities
by daniel＠bigwalter.net 14 May '07

14 May '07

I began writing the functions in 27.5 "Presentation Translator Utilities", since they are missing in McCLIM, but I'm having trouble reading the spec. The spec does not go into detail on how translators are implemented. The description for define-presentation-translator mentions that they have names and are stored in command tables. The McCLIM implementation is a reasonable interpretation of this. The problem lies with add-presentation-translator-to-command-table. Here it is very clear that the name is used outside command tables too: add-presentation-translator-to-command-table command-table translator-name &key (errorp t) [Function] Adds the translator named by translator-name to command-table. The translator must have been previously defined with define-presentation-translator or define-presentation-to-command-translator. It is not possible to write this function without changing more stuff. I guess it calls for a global translator table (i.e., a hash table.) What do you think? I don't really get it. I would much rather like to change the definition of add-presentation-translator-to-command-table. It makes more sense to me to do it like this: add-presentation-translator-to-command-table command-table translator &key (errorp t) [Function] Adds a presentation translator to command-table. The translator must have been previously defined with define-presentation-translator or define-presentation-to-command-translator. This removes the only usage of the global name. It is more consistent with the other translator functions. I attach a file with the functions from 27.5. See if you like it. It might be an idea to refactor them together with the rest of the translator code, because I copied a lot from there.

1 0

[mcclim-devel] clim-debugger update; keyboard navigation and an .asd file
by Jeremy Rayman 11 May '07

11 May '07

Hi there, Peter Mechlenborg has a copy of clim-debugger.lisp on his webspace with mostly-working keyboard navigation. He was the original author of the clim-debugger. I cleaned up the rough edges, added some other keyboard shortcuts, and made an .asd file for it. The patches against today's CVS are here: http://jlr.freeshell.org/data/mcclim/patches/clim-debugger.asd.patch http://jlr.freeshell.org/data/mcclim/patches/clim-debugger-keyboard-navigat… You can also find the full .asd and clim-debugger.lisp in that dir, in case the patches don't work for you. clim-debugger.asd.patch: * Add an ASDF system for the clim-debugger. clim-debugger-keyboard-navigation.patch: * Keyboard navigation: - Arrow keys move up and down stack frames, space expands current frame - Enter key inspects current object - Select restart by number (0-10) - Shortcuts: #\a abort, #\q quit, #\c continue Thanks so much for McCLIM. - Jeremy Rayman jeremy.rayman @ gmail.com p.s. Peter's original copy is at http://www.daimi.au.dk/~metch/lisp/clim-debugger.lisp .

1 0

[mcclim-devel] com-beginning-of-buffer keybinding
by Thomas Persson 07 May '07

07 May '07

Hi When playing around a bit with climacs I noticed that com-beginning-of-buffer in Drei is bound to: (#\< :shift :meta) which at least on my keyboard is physically impossible to type.

2 1

[mcclim-devel] McCLIM on the Mac
by Christian Lynbech 07 May '07

07 May '07

I could use some pointers on the status of McCLIM on the Mac. In particular, I am interested in how to run against the native graphics system rather than having to run the X11 server. I have looked a bit on the beagle backend but I cannot get it to work. A few fixes is needed just to get it to compile. Once that is done, it does compile and load but once an application (such as the calculator demo) is started, the lisp process freezes with output to the effect of: ? 2007-04-22 20:07:30.708 dppccl[2492] *** Assertion failure in -[NSWindowGraphicsContext reenableDisplayPosting], GraphicsContext.subproj/NSWindowGraphicsContext.m:117 2007-04-22 20:07:30.708 dppccl[2492] *** Assertion failure in -[NSViewHierarchyLock unlockTopMostReader], AppKit.subproj/NSViewHierarchyLock.m:444 2007-04-22 20:07:30.710 dppccl[2492] Error in event loop: Objective-C runtime exception: Invalid parameter not satisfying: th suggesting something going wrong deep down below the lisp level. This was with the latest mcclim CVS, OpenMCL 1.0 and PPC OSX 10.4.9. Before diving in I would like to know if the beagle backend is considered dead beyond repair (or at least if others than myself has any interest in it). Are there alternatives, can the gtkairo or opengl backends be brought to fly without X11? ------------------------+----------------------------------------------------- Christian Lynbech | christian #\@ defun #\. dk ------------------------+----------------------------------------------------- Hit the philistines three times over the head with the Elisp reference manual. - petonic(a)hal.com (Michael A. Petonic)

4 8

[mcclim-devel] Test suites and code coverage
by Christophe Rhodes 07 May '07

07 May '07

Hi, Some people may know that Juho Snellman committed a nice new tool to SBCL recently: a tool to measure code coverage[1]. For laughs, I thought I'd try it out on McCLIM and its test suite... To do so, I first loaded clx, spatial-trees and flexichain. Then (require :sb-cover) (declaim (optimize sb-cover:store-coverage-data)) (asdf:oos 'asdf:load-op :mcclim) (sb-cover:reset-coverage) ; debatable. See below. (defpackage :clim-tests (:use :clim :clim-lisp)) (mapcar #'load (directory "/path/to/mcclim/Tests/*.lisp")) The results I got are available at <http://doc.gold.ac.uk/~mas01cr/tmp/mcclim-tests/>. So, firstly, this is clearly not automated enough; I plan to spend a little time making running tests easier. The point about clearing coverage before running the tests is to remove all the uses of internal code (such as macros) in the building of mcclim itself. I don't know whether that's fair or not, but in doing so I noticed that there are some load-time tests (in e.g. bezier.lisp) which might be better placed in a test suite. I also am aware that I didn't run Drei or automaton test suites in the process of doing this; running those should be a simple matter. What does this show? Well, even though it's difficult to test a UI library in an automated fashion, I'm pretty sure that there are large swathes of things that /are/ testable in an automated fashion that aren't being so tested -- and that maybe by making these statistics available people could find bits that interest them and write tests to exercise those bits. There's also the obvious possibility of collecting the coverage statistics while running demodemo -- which will exercise backend functions and some of the UI code, and show us where some gaps are. (There's also my long-standing idea of using the Null backend to test UI in an automated fashion, but I'm sure more work needs to be done to make that possible.) Anyway. Comments, ideas? Cheers, Christophe [1] Weblog entry at <http://jsnell.iki.fi/blog/archive/2007-05-03-code-coverage-tool-for-sbcl.ht…>; some details at <http://www.sbcl.org/manual/sb_002dcover.html>.

2 2

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

mcclim-devel May 2007