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 …
[View More]()
()
(: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
[View Less]
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 …
[View More]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.
[View Less]
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.patchhttp://jlr.freeshell.org/data/mcclim/patches/clim-debugger-keyboard-navigat…
You can also find the full .asd and clim-…
[View More]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 .
[View Less]
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.
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:…
[View More]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)
[View Less]
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 (…
[View More]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>.
[View Less]
Folks,
A patch implementing the beginnings of a C syntax for McClim/climacs
can be found at http://common-lisp.net/~dmurray/mcclim-c.tar.gz . It
is quite ugly at the moment, but I thought it best to make it
available now than watch it rot. The file contains a diff and 3
additional files: c-syntax.lisp, c-syntax-commands.lisp and
lr-syntax.lisp. This last contains code that is now common to the C
and Lisp syntaxes.
Have fun!
JQS
Hello, McClimmers,
I run Debian GNU/Linux, mostly "stable", some "testing". I'm using SBCL.
I followed the instructions here (http://mcclim.cliki.net/GettingStarted) and
got clean compiles on everything. (Well, I never got the debugger, at least,
so I assume they were clean. :)
The clim demo fails with some kind of font problem:
> * (clim-demo::run-test 'clim-demo::demodemo)
> Received CLX NAME-ERROR in process "#<CLIM-CLX::CLX-PORT :HOST \"localhost\" :DISPLAY-ID 0
> {…
[View More]C8B6749}>'s event process."
>
> debugger invoked on a XLIB:NAME-ERROR in thread #<THREAD "#<CLIM-CLX::CLX-PORT :HOST \"loc
> alhost\" :DISPLAY-ID 0 {C8B6749}>'s event process." {BAE9961}>:
> Asynchronous NAME-ERROR in request 36 (last request was 37) Code 45.0 [OpenFont]
> Received CLX FONT-ERROR in process "initial process"
>
> debugger invoked on a XLIB:FONT-ERROR in thread #<THREAD "initial thread" {A7BD4A1}>:
> FONT-ERROR in current request Code 47.0 [QueryFont] ID #x5E00019
>
> Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.
>
> restarts (invokable by number or by possibly-abbreviated name):
> 0: [ABORT] Exit debugger, returning to top level.
>
> (XLIB::X-ERROR XLIB:FONT-ERROR
> :DISPLAY #<XLIB:DISPLAY localhost:0 (The X.Org Foundation R70101000)>
> :ERROR-KEY XLIB:FONT-ERROR
> :ASYNCHRONOUS NIL
> :CURRENT-SEQUENCE 37
> :RESOURCE-ID 98566169
> :MAJOR 47
> :MINOR 0
> :SEQUENCE 37)
> 0] 0
I *think* this is the relevant part of the backtrace:
> 3: (XLIB::REPORT-ERROR
> #<XLIB:DISPLAY localhost:0 (The X.Org Foundation R70101000)>
> 7
> XLIB:FONT-ERROR
> :ASYNCHRONOUS NIL
> :CURRENT-SEQUENCE 400
> :RESOURCE-ID 98566169
> :MAJOR 47
> :MINOR 0
> :SEQUENCE 400)
> 4: (XLIB::READ-REPLY #<unavailable argument> #<unavailable argument>)
> 5: (XLIB::QUERY-FONT
> #<XLIB:FONT -adobe-helvetica-medium-r-normal--24-173-100-100-p-0-iso8859-1 localhost:0 98566169>)
> 6: (XLIB:OPEN-FONT
> #<XLIB:DISPLAY localhost:0 (The X.Org Foundation R70101000)>
> "-adobe-helvetica-medium-r-normal--24-173-100-100-p-0-iso8859-1")
> 7: ((SB-PCL::FAST-METHOD CLIM:TEXT-STYLE-MAPPING (CLIM-CLX::CLX-PORT T))
> #<unavailable argument>
> #<unavailable argument>
> #<CLIM-CLX::CLX-PORT :HOST "localhost" :DISPLAY-ID 0 {C8B6749}>
> #<CLIM:STANDARD-TEXT-STYLE :SANS-SERIF :ROMAN :HUGE>
> NIL)
> 8: (CLIM-CLX::TEXT-STYLE-TO-X-FONT
> #<CLIM-CLX::CLX-PORT :HOST "localhost" :DISPLAY-ID 0 {C8B6749}>
> #<CLIM:STANDARD-TEXT-STYLE :SANS-SERIF :ROMAN :HUGE>)
So I guess
#<CLIM:STANDARD-TEXT-STYLE :SANS-SERIF :ROMAN :HUGE>
gets transformed into
-adobe-helvetica-medium-r-normal--24-173-100-100-p-0-iso8859-1
but I don't actually have that font on my system:
% xlsfonts | grep -e -adobe-helvetica-medium-r-normal--24-173-100-100-p-0-iso8859-1
%
Any advice? (Hopefully other than "install
-adobe-helvetica-medium-r-normal--24-173-100-100-p-0-iso8859-1". :)
Thanks!
-- Larry Clapp
[View Less]
Your message was not delivered due to the following reason(s):
Your message could not be delivered because the destination computer was
unreachable within the allowed queue period. The amount of time
a message is queued before it is returned depends on local configura-
tion parameters.
Most likely there is a network problem that prevented delivery, but
it is also possible that the computer is turned off, or does not
have a mail system running right now.
Your message was not delivered within …
[View More]5 days:
Host 114.2.70.165 is not responding.
The following recipients could not receive this message:
<mcclim-devel(a)common-lisp.net>
Please reply to postmaster(a)common-lisp.net
if you feel this message to be in error.
[View Less]
Andreas Fuchs wrote:
>
> Jack D. Unrue (junrue) is working on the clim-graphics-forms backend to
> mcclim, so we think he should be able to commit to it.
>
> Project: mcclim, user name: junrue.
Thanks Andreas, et. al.
--
Jack Unrue