mcclim-devel

mcclim-devel@common-lisp.net

820 discussions

[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

[mcclim-devel] Adding vertical orientation to Listener's graphing commands
by Paolo Amoroso 16 Mar '05

16 Mar '05

The very simple patch described in this blog entry: McCLIM grapher now supports vertical orientation http://www.paoloamoroso.it/log/050316.html adds vertical orientation to some of the CLIM Listener's class graphing commands. It is easy to extend the functionality to other similar commands. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log

1 0

[mcclim-devel] Please remove the debian/ directory
by Milan Zamazal 12 Mar '05

12 Mar '05

Please remove the obsolete debian/ directory from CVS. The package is contained and maintained in Debian. Thanks, Milan Zamazal -- real programmer? don't get me started. if you need to hide your pathetic excuse for a carreer behind super-macho languages like C, C++, and/or Perl instead of writing clean, maintainable, efficient code, you aren't much of a real programmer in my view. -- Erik Naggum in comp.emacs

1 0

[mcclim-devel] Another Beagle %set-port-keyboard-focus 'patch'
by Duncan Rose 11 Mar '05

11 Mar '05

Hrm. Not sure how to turn this into a patch without some messing around (will cvs diff generate a patchfile with the right options?) but since it's only one line... I think this was overlooked in the recent patches (or maybe I'm not loading Beagle in the preferred manner any more) -Duncan Index: beagle-backend.asd =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/Backends/beagle/beagle-backend.asd,v retrieving revision 1.1 diff -r1.1 beagle-backend.asd 27c27 < #:set-port-keyboard-focus --- > #:%set-port-keyboard-focus

2 1

[mcclim-devel] Proper place for inspector documentation
by Peter Scott 10 Mar '05

10 Mar '05

I wrote some documentation on how to extend the inspector, and it's in TeX format, but I'm not sure where to put it. Should it go in Doc/manual.tex? If so, how? Should I introduce a Part 3 for utility programs like the listener and the inspector? Or should it go in its own seperate manual? -Peter

2 1

← Newer
1
...
70
71
72
73
74
75
76
...
82
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

mcclim-devel