mcclim-devel

mcclim-devel@common-lisp.net

820 discussions

Re: [mcclim-devel] patch for text-field-pane bug #608280
by David Lewis 09 Feb '11

09 Feb '11

When I tried to apply the patch for the bug described at https://bugs.launchpad.net/mcclim/+bug/608280 , my text fields suddenly became read only. The default value of editable-p does not seem to be being propagated where it is needed, although specifying :editable-p t does work. My hacky fix is to change the editable-p to (editable-p t) in this bit: @@ -364,7 +366,8 @@ &key id client armed-callback disarmed-callback activation-gestures activate- callback - value value-changed-callback) + value value-changed-callback + editable-p) ;; Make an editor substrate object for the gadget. (let ((substrate (make-text-field-substrate object :id id :client client :armed-callback armed-callback David Lewis Research Fellow, Department of Computing Goldsmiths, University of London & Birmingham Conservatoire d.lewis(a)gold.ac.uk

1 0

[mcclim-devel] Compiler warnings
by James Ashley 23 Jan '11

23 Jan '11

I'm trying to learn McCLIM using ccl, and I just noticed several compiler warnings during the load process. I remember that, way back when, these were a big concern. One set looks silly/simple enough that I think I'm qualified to submit a patch. To deal with some variables that get defvar'd in a different file (and a really minor typo): --- design.lisp.original 2011-01-23 10:13:13.000000000 -0600 +++ design.lisp 2011-01-23 11:50:01.000000000 -0600 @@ -21,7 +21,7 @@ ;;;; Some Notes -;; The design design has a pitfall: +;; The design has a pitfall: ;; ;; As drawing is specified, a design of class opacity carries no color ;; and thus borrows its color from +foreground-ink+. So that @@ -344,6 +344,7 @@ 0.0) (defun make-opacity (value) + (declare (special +everywhere+)) ; squash a compiler warning (setf value (clamp value 0 1)) ;defensive programming (cond ((= value 0) +transparent-ink+) ((= value 1) +everywhere+) ; used to say +foreground-ink+ @@ -669,7 +670,8 @@ design) (defmethod compose-in ((design design) (mask nowhere-mixin)) - (declare (ignore design mask)) + (declare (ignore design mask) + (special +nowhere+)) +nowhere+) ;;; IN-COMPOSITUM @@ -782,7 +784,8 @@ ;;;; (defmethod compose-out ((design design) (mask everywhere-mixin)) - (declare (ignore design mask)) + (declare (ignore design mask) + (special +nowhere+)) +nowhere+) (defmethod compose-out ((design design) (mask nowhere-mixin)) @@ -790,7 +793,8 @@ design) (defmethod compose-out ((design design) (mask color)) - (declare (ignore design mask)) + (declare (ignore design mask) + (special +nowhere+)) +nowhere+) (defmethod compose-out ((design design) (mask uniform-compositum)) =============================================================================== Well, AFAICT that didn't break anything...undertested newb code warning. I don't know how to handle the rest. Both graphics.lisp and design.lisp seem to have a very subtly different definition of (defmethod draw-design (medium (design rgb-image-design) &rest options &key (x 0) (y 0) &allow-other-keys) ... (They seem to have different return values). This is the first time I've knuckled down and started looking at the source code, so I don't have the foggiest notion which definition is correct. The defclass for standard-text-displayed-output-record in recording.lisp has many of its slots using :start-x and :start-y for :initarg's. This had to have been done on purpose, and it seems to make sense in that particular situation. But how to eliminate the compiler warnings? (I'm just going with the assumption that this is conforming in the first place). stream-input.lisp -- line 134, (defmethod stream-read-gesture :around specifies *input-wait-test* as one of the default arguments. It looks like (proclaim (special *input-wait-test*)) at some point is the right way to fix this one. But that seems pretty heavy-handed. *input-wait-handler* and *pointer-button-press-handler* have the same issue, in the same lambda list. (Then again, maybe just rearranging the load order in the ASD is the "correct" way to fix it). bezier.lisp and regions.lisp have conflicting definitions for (region-equal ((? point) (? point)) ... And it looks like line 782 in bezier.lisp where climi:with-medium-options is used before it was defined. When I exited and restarted emacs and re-ran (require :clim) (which very well may be the wrong way to load it), most of the warnings went away. I don't think there was any reason for it to rebuild things the first time, but I could be mistaken there. I'm using the 20101006 CVS snapshot distributed via quicklisp. Respectfully, James

2 1

[mcclim-devel] change cursor
by Orm Finnendahl 08 Jan '11

08 Jan '11

Hi, is it possible to change the default cursor in a pane from the standard arrow to a horizontal and vertical line spanning the height and width of the pane and intersecting at the cursor position (like in some CAD applications)? I defined a command to invoke a tracking-pointer routine, but I'd rather have the cursor in the top-level loop of the application frame, changing to the cross whenever the mouse enters the visible portion of the pane (preferably showing the current cursor position in sheet coordinates in a corner of the pane). -- Orm

1 0

[mcclim-devel] presentations insensitive after window-clear and redisplay
by Orm Finnendahl 06 Jan '11

06 Jan '11

Hello, issuing a window-clear on a pane and redisplaying its presentations with redisplay-frame-pane (using incremental redisplay) makes the presentations insensitive to mouse gestures. Is that intended behaviour or a bug? The clim spec for window-clear states that the ouput-history is cleared, but the display routine of the pane is explicitely redrawing the contents as presentations (and they appear on the display). I'm using mcclim 0.9.6 with sbcl 1.0.29.11.debian on 64-bit linux. -- Orm

1 0

[mcclim-devel] mouse wheel gesture?
by Orm Finnendahl 29 Dec '10

29 Dec '10

Hi, thanks to your help, the first prototype of the apps behaviour is surfacing and clim's mechanisms are getting less and less obscure. I couldn't find documentation, whether mouse wheel movement is implemented as gesture in mcclim. In my app this would be very useful, but I could imagine, clim was invented long before mousewheels appeared. On a related topic I tried to define a keystroke to invoke a command if the mouse is over a presentation. This didn't seem to work directly (via define gesture-name and define-presentation-to-command-translator). I resorted to defining a global variable in the application frame to hold a highlighted presentation (or nil if nothing is highlighted) and use this as reference for a command invoked by a keystroke. To me this seems to be rather a workaround than a solution. In case I'm missing something I'd be grateful for comments. Nice holidays to all of you, Orm

4 5

[mcclim-devel] CLX backend or OpenGL backend with ClozureCL on OS X (also posted on c.l.l)
by Frank Gönninger 27 Dec '10

27 Dec '10

Hi all: Being completely new to McCLIM and Clozure CL I tried running the sample apps from McCLIM doc's chapter 3. All fine with the Gtk Cairo backend, but no chance with the CLX or OpenGL backends. CLX itself works fine. Using Quicklisp I loaded the required packages: ? (ql:quickload "clx") To load "clx": Load 1 ASDF system: clx ; Loading "clx" ("clx") ? (ql:quickload "spatial-trees") To load "spatial-trees": Load 1 ASDF system: spatial-trees ; Loading "spatial-trees" ("spatial-trees") ? (ql:quickload "clim") To load "clim": Load 1 ASDF system: clim ; Loading "clim" .... ("clim") ;;; OK, so far. Now let's define CLX as the backend... ? (setq clim:*default-server-path* '(:clx)) (:CLX) ;;; Following the McCLIM's Chapter 3 "The First Application" I ;;; tried the sample app: ? (app::app-main) > Error: NIL is not of type (OR SYMBOL FUNCTION), and can't be FUNCALLed or APPLYed > While executing: CLIM:FIND-PORT, in process Listener(6). > Type cmd-. to abort, cmd-\ for a list of available restarts. > Type :? for other options. ;;; Hmpf ?!? Ok, CLX seems to be the problem. Backtrace shows: 1 > :b *(161D78B8) : 0 (FIND-PORT :SERVER-PATH (:CLX)) 265 (161D7930) : 1 (FIND-FRAME-MANAGER) 509 (161D7968) : 2 (FUNCALL #'#<#<STANDARD-METHOD CLIM:RUN-FRAME-TOP-LEVEL :AROUND (CLIM:APPLICATION-FRAME)>> #<APP::SUPERAPP #x302003283C0D>) 405 (161D7A40) : 3 (%%STANDARD-COMBINED-METHOD-DCODE (#<STANDARD-METHOD CLIM:RUN-FRAME-TOP-LEVEL :AROUND #> #<STANDARD-METHOD CLIM:RUN-FRAME-TOP-LEVEL #>) 46378838) 693 (161D7AC0) : 4 (CALL-CHECK-REGS APP:APP-MAIN) 221 (161D7AF8) : 5 (TOPLEVEL-EVAL (APP:APP-MAIN) NIL) 701 (161D7B98) : 6 (READ-LOOP :INPUT-STREAM #<SYNONYM-STREAM to *TERMINAL-IO* #x302000B013BD> :OUTPUT-STREAM #<SYNONYM-STREAM to *TERMINAL-IO* #x302000B0125D> :BREAK-LEVEL 0 :PROMPT-FUNCTION #<Compiled-function (:INTERNAL CCL::READ-LOOP) (Non-Global) #x30000058146F>) 2269 (161D7DF0) : 7 (TOPLEVEL-LOOP) 101 (161D7E18) : 8 (FUNCALL #'#<(:INTERNAL CCL::MAKE-MCL-LISTENER-PROCESS)>) 741 (161D7EB8) : 9 (RUN-PROCESS-INITIAL-FORM #<COCOA-LISTENER-PROCESS Listener(6) [Active] #x302000B63D7D> (#<COMPILED-LEXICAL-CLOSURE # #x302000B6372F>)) 677 (161D7F48) : 10 (FUNCALL #'#<(:INTERNAL (CCL::%PROCESS-PRESET-INTERNAL (PROCESS)))> #<COCOA-LISTENER-PROCESS Listener(6) [Active] #x302000B63D7D> (#<COMPILED-LEXICAL-CLOSURE # #x302000B6372F>)) 389 (161D7F98) : 11 (FUNCALL #'#<(:INTERNAL CCL::THREAD-MAKE-STARTUP-FUNCTION)>) 301 1 > I'd have to dig deeper but maybe there's someone on here you already can point in the right direction ?!? THX! Best, Frank

5 7

[mcclim-devel] presentations as childs of specific output records
by Orm Finnendahl 11 Dec '10

11 Dec '10

Hi, it seems to me appropriate to map a list of hierarchically grouped displayed line objects onto output records (using the same hierarchy). Those lines have to be sensitive to mouse gestures so I'd like to implement them as presentations. In my understanding this means I have to create and maintain the output-records manually in the code rather than leaving that up to mcclim, which seems to always append to the end of the output history. Is there a simple canonicle way to create an instance of a presentation and insert it as a child of a certain output record? I can find how to add an output record at a certain point, but the present method seems to work on a stream rather than a specific output record. -- Orm

2 3

[mcclim-devel] The Manual
by James Ashley 03 Dec '10

03 Dec '10

I realize it's a work in progress, but it really deserves much more credit than it receives on the site. As far as an overview/introduction, it's probably the best I've run across so far. In section 3.7, "Displaying Data Structures," it gets rid of the previous version's :display-time nil parameter to the pane showing the output stream. Using the CVS version of McCLIM (from 2010-10-06) and 64-bit clozure CL release 1.5 (on linux) using the CLX backend, this shows the initial "NIL is not a number," but calling Parity after that doesn't seem to have any affect. I haven't begun to do anywhere near enough digging to really even to begin to guess where to start looking. I don't see anything that resembles this in the past few months worth of archives. Is this known and expected behavior? Can someone clueful point me in the general direction so I can take a stab at fixing the "problem" (maybe just that part of the manual's slightly out of date?) Thanks, James

1 0

[mcclim-devel] Trying to wrap my head around presentations
by James Ashley 03 Dec '10

03 Dec '10

I'm still just toying with ideas, and trying to wrap my brain around the basics. Right this second, just on a whim, I'm thinking of a character-builder for old-school AD&D. Something like a radio-button list where you choose either your race '(human elf half-elf dwarf halfling half-orc) or your class '(fighter magic-user cleric thief monk) and both lists depend on what you've chosen in the other. So you'd be able to select one in the list, and the other would indicate that certain options weren't available. But they aren't actually disabled...just discouraged. Choose a discouraged option, and the other list clears your choice. Maybe some options just aren't available, based on the way you've set your stats. >From what I'm reading so far, this is pretty much the way CLIM was designed. Am I on the right track, or am I still completely missing the point? Thanks, James

1 0

[mcclim-devel] some questions
by Orm Finnendahl 02 Dec '10

02 Dec '10

Hi all, I posted here before quite some time ago but had to interrupt my work. Now I reserved time to be able to concentrate on the implementation in mcclim. I'm trying to program a frontend for the definition of specialized scores of a self-designed system for live-electronics in contemporary music (the backend is done in pure data, but most of the hard work is already getting done in lisp). One part of the frontend is supposed to be similar to a vector graphics program, enabling the creation of straight horizontal colored lines and the nested grouping of those lines. The user should be able to move those lines/groups around, stretch them, clip them and do some other basic editing operations such as copying, insertion and deletion (for an idea, how those graphics look like, you can have a look at: http://icem-www.folkwang-hochschule.de/~finnendahl/download/sandgetriebe-au… ). I used the clim-fig demo application as a point of departure and try to build around this to get a better grasp of the concepts before restarting from scratch. Here are my questions: 1. highlighting: I successfully hooked into the highlighting function. All lines are a presentation using output-recording and highlight on mouse over. I would like to be able to change the highlighting context (with some keystroke) so that e.g. not a single line is highlighted, but all lines of the group, it is contained in. I could do that manually within the highlighting routine by traversing the parent tree of the highlighted object, but I wonder whether it could be possible to hierarchically nest the presentation type classes (and their objects) in a way that the presentations are sensitive to the current context and highlight accordingly without having to replay them on change of context. 2. selection: clicking on a presentation (or a group of presentations) should select that group by displaying a dashed line around the smallest enclosing region of the selected objects and attaching a small square or icon to that square for resizing. If I got the concept correctly, the dashed line plus small square should be displayed as one or more presentations (e.g. of type "region"), which are sensitive to mouse gestures for moving or resizing. Should these presentations get appended to the output record? It seems a little awkward to always replay the whole output record if presentations are deselected. So I wonder how would be the canonical way to do it (I know about incremental redisply, but would it fit here)? 3. I didn't succeed in changing the command invoked on a left mouse-click on a canvas. It is initially defined with "define-presentation-to-command-translator" but I couldn't change the definition to invoke different comands depending on the state of the program. (Like in a drawing programm: when you change the tool in the toolbar, the mouse-click invokes a different command). As far as I understood, the command table is resposible for the bindings, but I didn't find the mechanism for changing the current commmand table. Any help or correction of my assumptions is greatly appreciated! Yours, Orm

1 0

← Newer
1
...
11
12
13
14
15
16
17
...
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