March 2005 - mcclim-devel - mailman3.common-lisp.net

[mcclim-devel] Drawing graphs & scaling
by Thibault Langlois 22 Apr '05

22 Apr '05

Hello, I would like to be able to scale a graph: (defmethod plot ((object tree) stream) (with-scaling (stream 0.7) (draw-graph (list (root-node object)) #'draw-node-colors :stream stream))) where draw-graph is directly inspired from an example in allegro CLIM manual: (defun draw-graph (root-nodes draw-node-function &rest keys) (apply #'format-graph-from-roots root-nodes #'(lambda (node s) (multiple-value-bind () (with-output-as-presentation (s node 'node) (funcall draw-node-function node s)))) #'(lambda (n) (if (visible-p n) (children n))) keys)) and draw-node-colors draws a node using draw-rectangle*. The problem is that when the scaling factor is not 1 the nodes are not correctly placed (although they are correctly scaled) with respect to arcs. Any ideas ? Thanks. Thibault

3 6

[mcclim-devel] Better defaults for CLX backend
by Christophe Rhodes 02 Apr '05

02 Apr '05

Hi, Attached are a diff and a new file to implement better defaults for the clx server path: parsing $DISPLAY as a Unix user might expect. Behaviour should be unchanged in the case that the $DISPLAY environment variable is unreadable. The immediate effect of this patch is that clim over ssh will work. That said, I have completely failed to test this patch even to the point of compiling it, as locally both my sbcl and my clx are broken. If someone could test this and report back (or commit it themselves), that would be good. Cheers, Christophe

1 1

[mcclim-devel] sb-bsd-sockets
by Boris Tschirschwitz 31 Mar '05

31 Mar '05

Hi. I am trying to use McCLIM with openmcl. When compiling the beagle backend I get the error message that sb-bsd-sockets can't be found, apparently clx depends on it and mcclim depends on clx, even with beagle. Making sb-bsd-sockets from sbcl-contrib known to asdf helps until sb-bsd-sockets wants sb-grovel and eventually sb-ext. This one I can't find on sbcl. Am I really supposed to use all these SBCL packages? If so, where do I get the sb-ext? Thanks, Boris.

5 4

[mcclim-devel] Image drawing
by Milan Zamazal 30 Mar '05

30 Mar '05

Since image drawing (in clim-extensions.lisp) was excluded in McCLIM 0.9.1, I've implemented my (very primitive for now) own code for that in Springtail (http://www.zamazal.org/software/springtail/index.html) This is just to let you know that if anybody wanted to add image drawing support to McCLIM again, I'd like to cooperate. Regards, Milan Zamazal -- _/_\_/_ o _\_/_\_ o _/_\_/_ o _\_/_\_ o BEWARE! -<_|_|_|_><-- -<_|_|_|_><-- -<_|_|_|_><-- -<_|_|_|_><-- *Bugs* are / \ / o \ / \ o / \ / o \ / \ o approaching!

1 0

[mcclim-devel] Sample code
by David Christiansen 27 Mar '05

27 Mar '05

I've written a Connect Four game that uses McCLIM, complete with a computer player, and I think that it might be a nice little inclusion into the sample code section of McCLIM (i.e., the clim-demos package). How can I go about submitting it? ;;--------------------------------------------------------------- ;; -David Christiansen ;;

1 0

[mcclim-devel] Flipping sheet coords
by Duncan Rose 25 Mar '05

25 Mar '05

This is probably rather Cocoa-centric, so I'll probably be boring anybody that doesn't know any of Apple's frameworks with the following... I've been looking at the Beagle back end again recently looking to complete the remaining functionality and speed it up somewhat. One of the things I want to do to hopefully speed things up is move to a delayed drawing implementation (which is the way Apple recommend doing things anyway; all drawing is done in a 'drawRect' method which is invoked as part of the main event loop by the underlying windowing system). In order to make this work I've migrated the text drawing to append glyphs to an NSBezierPath subclass; in order to implement the delayed drawing I just stack all bezier path objects up in an array and stroke or fill them at the appropriate time. The problem I have is that Cocoa and McCLIM have different coordinate systems (the y-axes are reversed) by 'default'. Previously I dealt with this by setting the view up to be 'flipped' which is standard Cocoa functionality. This works in general but text is rendered upside down. What I'd *like* to do is to be able to set a transform which would automatically take care of this within McCLIM (rather than within Cocoa). What I'm hoping is that there's an easy solution to this (such as applying an inverting transform the the graft and having this by default apply to anything grafted onto it). So my question boils down to "does using a :graphics oriented graft rather than a :default orientation make any difference at all to anything attached to that graft"? An additional question might be "if not, should it?" (I'd like to have a CLIM solution to this but if there appears not to be one I'll hack something into the back end to do it via Cocoa - it seems to me that if I apply the appropriate transform to the graft things should 'just work' but maybe I'm misunderstanding how things fit together). Also, who do I need to see to get CVS commit privs again or should I just be submitting patches? Thanks, -Duncan

1 0

[mcclim-devel] Freetype bindings
by Christophe Rhodes 23 Mar '05

23 Mar '05

Hi, I've been playing with the bindings to freetype in Experimental/freetype, with a view to using them in one of my apps -- there is a font which I need to use which is available to me in truetype format (and, in addition, it makes the Climacs window look pretty). I've run into multiple problems, most of which I've worked around in some way or other. One which is definitely not this list's problem is the fact that sbcl miscompiles freetype-ffi.lisp; it gets confused over some forward declarations, and subsequently refuses to do anything with certain foreign structures. I believe the sbcl experts are working on this problem; however, there is a simple workaround, which is to load the freetype-ffi.lisp file as source. A more serious problem lies in the fact that the ffi bindings are very definitely 32-bit centric; certain things are defined as (signed 32) or (unsigned 32) when they should be long or unsigned-long. (This causes segmentation faults on 64-bit platforms). I have manually corrected the bindings, but I think the right answer is to generate the bindings themselves as part of the compilation process: in other words, do something similar to sbcl's sb-grovel, and ask the C compiler on the host system to emit suitable Lisp code, using sizeof, offsetof, and the C preprocessor itself. One word of warning at this point: it is easy to crash your lisp if you're not careful, because the bindings are not fully type-declared, so sbcl spews compiler diagnostics to *standard-output* when calling the freetype functions. This is bad if the freetype functions are being called in order to emit characters to a clim pane bound to *standard-output*... I've been using (handler-bind ((compiler-note #'muffle-warning)) (climacs-gui::climacs)) or similar to work around this. The remaining glitch -- one that I have not managed to solve, is that there are visual artifacts with the bindings. A full redraw usually solves any such artifacts, but during the course of interaction, characters are often misplaced. A chance mention on IRC suggests that this might be caused by insufficient display-finish-outputs; does anyone have any suggestions as to where to look for these? A screenshot, for the interested: <http://www-jcsu.jesus.cam.ac.uk/~csr21/tabcode-font.png>. Cheers, Christophe

1 0

[mcclim-devel] Copying text to clipboard loops displaying messages to Konsole
by Paolo Amoroso 22 Mar '05

22 Mar '05

When I copy some text with Shift-left-click from the CLIM Listener for later copying somewhere else, I get an infinite loop that displays messages (all identical) like this to the KDE Konsole from which I have started the Listener: #<CLIM-CLX::CLX-SELECTION-REQUEST-EVENT {5850A54D}> is an instance of type CLX-SELECTION-REQUEST-EVENT it has the following slots: TIMESTAMP: 5010524 SHEET: #<CLIM:INTERACTOR-PANE CLIM-LISTENER::INTERACTOR {58B8A0CD}> REGION: <unbound> SELECTION: :PRIMARY REQUESTOR: #<XLIB:WINDOW :0 31457298> TARGET: :COMPOUND_TEXT PROPERTY: :_QT_SELECTION If I later paste with Shift-middle-click the clipboard selection to another Konsole pane, I get a garbled string similar to that described here: http://common-lisp.net/pipermail/mcclim-devel/2004-December/002731.html I have to quit the Listener in order to stop the infinite loop. I use CMUCL Snapshot 2005-02 with the latest McCLIM CVS sources under Slackware Linux 10.0, with a 2.6.10 kernel. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log

4 16

[mcclim-devel] Gadgets in accepting-values (again)
by Anthony Juckel 22 Mar '05

22 Mar '05

With the latest McCLIM CVS, displaying a gadget within accepting-values seems to work quite well now. Unfortunately, I feel that I'm doing something wrong with the functionality. At first, I tried to simply call throw-object-ptype from my gadget's value-changed-callback (it inherits from value-gadget), but that seemed to have no effect. The function was called, but I'm unsure how that thrown value was supposed to propogate. Who is supposed to "catch" it? I finally settled on the following to get my value properly propogated: :value-changed-callback #'(lambda (gadget value) (declare (ignore gadget)) (let ((query (find query-identifier (climi::queries climi::*accepting-values-stream*) :key #'climi::query-identifier :test #'equal))) (setf (climi::value query) value) (setf (climi::changedp query) t)) (climi::throw-object-ptype value `(trait-rating ,max)) (debug-msg "Gadget value changed to: ~A" value)) The throw-object-ptype at near the bottom of the callback remains, but doesn't appear to do anything. This method strikes me as quite unclean for a few reasons, not the least of which is relying on a few unexported symbols from clim-internals. One other thing: com-select-query is not called during the operation of my gadget. Looking at the behavior of the popup menu, I see that it is displayed as a simple value until the query is selected, at which point select-query blocks waiting for the user to make a choice from the newly-drawn popup menu. I'm not sure how to do functionality similar to that in my case. The user may at any time click my gadget to change its value, and I am unsure how to tie in select-query for two reasons: 1) I still don't quite get presentation-to-command-translators, so I don't know how I can make any click on my gadget also translate into com-select-query, as well as having the click register with my gadget to properly change its value. 2) Even if I get com-select-query to be called, I'm unsure how I would block within select-query until the user selects a value in the query. Could anyone help me shed some light on these issues? Anthony W. Juckel

1 0

[mcclim-devel] Possible bug
by David Christiansen 21 Mar '05

21 Mar '05

Hello all, I'm new to the list. I've been writing a little Connect 4 clone with McClim and I think I found a place where the implementation diverges from the standard. I'm using the Mothering Sunday release. When I try to (make-pane 'option-pane :value "foo" :mode :exclusive :items '("foo" "bar")), I get an error saying that :exclusive is not a member of type (or :some-of :one-of). It looks to me as though the spec says that those options should be called :exclusive or :nonexclusive, though :one-of and :some-of seem to work just fine to me. The relevant section of the spec (chapter 30) can be seen at: http://www.mikemac.com/mikemac/clim/gadgets.html Am I reading it correctly? If so, I'll try to grab a recent CVS and work up a patch later this week (though, being a newbie, I'd want someone to see it). It seems localized enough that I should be able to figure it out. Thank you all for this handy library! ;;------------------------------------------------------------------ ;; -David Christiansen ;;

2 3