mcclim-devel January 2005

mcclim-devel@common-lisp.net

23 participants
26 discussions

[mcclim-devel] find-keystroke-item slowness
by Cyrus Harmon 27 Jan '05

27 Jan '05

Dear mcclim-devel, It looks like find-keystroke-item is doing a lot of work (linear search through the keystrokes) every time there's a key event. I know this is the lispy way to do things, and clim wants to be flexible enough to provide other tests besides event-matches-gesture-name-p, but this seems like an awful lot of work for every key stroke. Am I missing something here? BTW, I bring this up to try to address the generally poor response I get typing in climacs with the beagle back end. Thanks, Cyrus

4 4

[mcclim-devel] Confused by with-room-for-graphics
by Timothy Moore 27 Jan '05

27 Jan '05

In the course of fixing a replay problem in with-room-for-graphics I took it upon myself to rewrite it to be consistent with the spec and the Franz manual, but now I'm thoroughly confused, especially by the menu drawing example. I had believed that the origin of the local coordinate system would be placed at the current cursor, possibly offset vertically by the height (if supplied) or by the maximum y value in the first quadrant case, even if this would result in some output with negative x coordinates being lost of the left edge of the screen. But that means that the menu example in the Franz manual would lose the North and West points of the compass, which can't be right. Can people with classic CLIM try this function in a listener (I believe classic CLIM has such a thing) and try (draw-compass *standard-output* 'symbol t) and (draw-compass *standard-output* nil)? I would like to know if the entire compass is visible and if it overlaps other graphics in the output stream. (defun draw-compass (stream &optional (type 'symbol) (quadrant nil)) (labels ((draw-compass-point (stream type symbol x y) (clim:with-output-as-presentation (stream symbol type) (clim:draw-text* stream (symbol-name symbol) x y :align-x :center :align-y :center :text-style '(:sans-serif :roman :large))))) (clim:with-room-for-graphics (stream :first-quadrant quadrant) (clim:draw-line* stream 0 25 0 -25 :line-thickness 2) (clim:draw-line* stream 25 0 -25 0 :line-thickness 2) (dolist (point '((n 0 -30) (s 0 30) (e 30 0) (w -30 0))) (apply #'draw-compass-point stream type point))))) Thanks a lot, Tim

1 0

[mcclim-devel] Re: beagle
by Boris Tschirschwitz 23 Jan '05

23 Jan '05

Hey. Trying to compile the beagle backend to test climacs, I noticed that the load paths are hardwired to 'Users/duncan/...'. Is there any reason for keeping this. If not, is there already a patch somewhere, or would one be welcome? Boris.

1 0

[mcclim-devel] Re: [mcclim-cvs] CVS update: mcclim/presentation-defs.lisp
by Andy Hefner 20 Jan '05

20 Jan '05

Having read the spec, I see I'm wrong about this. Sorry about that. On Wed, 19 Jan 2005 19:05:51 -0500, Andy Hefner <ahefner(a)gmail.com> wrote: > I think this is wrong. McCLIM now returns the class name of the object > even when no corresponding presentation type has been defined. On Jan > 2nd I commited a change to stop this from happening (I think it was > causing problems with the listener), which this seems to undo. > > Thoughts? > > > On Wed, 19 Jan 2005 14:44:46 -0800 (PST), Timothy Moore > <tmoore(a)common-lisp.net> wrote: > > Update of /project/mcclim/cvsroot/mcclim > > In directory common-lisp.net:/tmp/cvs-serv20050 > > > > Modified Files: > > presentation-defs.lisp > > Log Message: > > For CLOS objects, make presentation-type-of return the name of the class if possible > > Date: Wed Jan 19 14:44:46 2005 > > Author: tmoore > > > > Index: mcclim/presentation-defs.lisp > > diff -u mcclim/presentation-defs.lisp:1.39 mcclim/presentation-defs.lisp:1.40 > > --- mcclim/presentation-defs.lisp:1.39 Tue Jan 11 05:02:19 2005 > > +++ mcclim/presentation-defs.lisp Wed Jan 19 14:44:46 2005 > > @@ -87,11 +87,15 @@ > > (defmethod presentation-type-of ((object standard-object)) > > (multiple-value-bind (name lambda-list) > > (get-ptype-from-class-of object) > > - (if (and name > > - (or (null lambda-list) > > - (member (first lambda-list) lambda-list-keywords))) > > - name > > - (call-next-method)))) > > + (cond ((and name > > + (or (null lambda-list) > > + (member (first lambda-list) lambda-list-keywords))) > > + name) > > + (name > > + 'standard-object) > > + (t (let* ((class (class-of object)) > > + (class-name (class-name class))) > > + (or class-name class)))))) > > > > (defmethod presentation-type-of ((object structure-object)) > > (multiple-value-bind (name lambda-list) > > @@ -100,7 +104,6 @@ > > (member lambda-list lambda-list-keywords)) > > name > > (call-next-method)))) > > - > > > > (define-presentation-generic-function > > %map-over-presentation-type-supertypes > > > > _______________________________________________ > > mcclim-cvs mailing list > > mcclim-cvs(a)common-lisp.net > > http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-cvs > > >

1 0

[mcclim-devel] Re: [mcclim-cvs] CVS update: mcclim/presentation-defs.lisp
by Andy Hefner 20 Jan '05

20 Jan '05

I think this is wrong. McCLIM now returns the class name of the object even when no corresponding presentation type has been defined. On Jan 2nd I commited a change to stop this from happening (I think it was causing problems with the listener), which this seems to undo. Thoughts? On Wed, 19 Jan 2005 14:44:46 -0800 (PST), Timothy Moore <tmoore(a)common-lisp.net> wrote: > Update of /project/mcclim/cvsroot/mcclim > In directory common-lisp.net:/tmp/cvs-serv20050 > > Modified Files: > presentation-defs.lisp > Log Message: > For CLOS objects, make presentation-type-of return the name of the class if possible > Date: Wed Jan 19 14:44:46 2005 > Author: tmoore > > Index: mcclim/presentation-defs.lisp > diff -u mcclim/presentation-defs.lisp:1.39 mcclim/presentation-defs.lisp:1.40 > --- mcclim/presentation-defs.lisp:1.39 Tue Jan 11 05:02:19 2005 > +++ mcclim/presentation-defs.lisp Wed Jan 19 14:44:46 2005 > @@ -87,11 +87,15 @@ > (defmethod presentation-type-of ((object standard-object)) > (multiple-value-bind (name lambda-list) > (get-ptype-from-class-of object) > - (if (and name > - (or (null lambda-list) > - (member (first lambda-list) lambda-list-keywords))) > - name > - (call-next-method)))) > + (cond ((and name > + (or (null lambda-list) > + (member (first lambda-list) lambda-list-keywords))) > + name) > + (name > + 'standard-object) > + (t (let* ((class (class-of object)) > + (class-name (class-name class))) > + (or class-name class)))))) > > (defmethod presentation-type-of ((object structure-object)) > (multiple-value-bind (name lambda-list) > @@ -100,7 +104,6 @@ > (member lambda-list lambda-list-keywords)) > name > (call-next-method)))) > - > > (define-presentation-generic-function > %map-over-presentation-type-supertypes > > _______________________________________________ > mcclim-cvs mailing list > mcclim-cvs(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-cvs >

1 0

[mcclim-devel] Presentation types, accept and the like
by Anthony Juckel 18 Jan '05

18 Jan '05

This message doesn't pertain to the internal development of McCLIM, but is rather a general CLIM question. The only CLIM mailing list that I've found seems to have next to no traffic on it, so this seemed the best place to send my questions. Perhaps it would be prudent (if messages like this become a hassle) to create a mcclim-user mailing list on common-lisp.net? What is the proper way to go about defining presentation types with their associated methods, especially accept? For some background, I'm working on an application for working with a set of objects that I've defined. In defining these objects, I've done some MOP-ery to allow me to specify for a given slot on an object, which values are allowed: (defclass my-class () ((slot-a :allowed-values ("some" "allowed" "values"))) (:metaclass restricted-slot-value-class)) I've also got the necessary machinery to easily get the allowable values for a given slot of an object. Now, I'd like to use this machinery to ease the creation of dialogs pertaining to these objects. For example, if a user is needing to supply a value for slot-a, I'd like to display a menu to the user containing the valid values. The way that I've tried to accomplish this is that I've created a presentation type for each slot in the object (I know there must be a more general solution...). Then I've defined an accept method for these presentation types. Now, in my accept method, I'm trying to use menu-choose as follows: (clim:define-presentation-method clim:accept ((type slot-a) stream view &key &allow-other-keys) (declare (ignore view)) (clim:menu-choose (allowed-values 'slot-a))) I then create a dialog using accepting-values, which in turn calls this accept method. This isn't giving me the desired behavior though. When I click on the input field for slot-a, I do get the proper menu displayed, but when I first choose an option, it doesn't appear to have any effect, but does redisplay the menu again. After choosing a menu option a second time, the choice does indeed seem to stick. Am I just missing a step, or have I wondered down a wrong path entirely? Does anyone have any advice for how better to handle such a situation? Anthony W. Juckel

2 3

[mcclim-devel] <integer> is not of type XLIB:GCONTEXT error when using pixmaps in Listener
by Paolo Amoroso 17 Jan '05

17 Jan '05

I have updated my McCLIM CVS working copy with the latest commits since last January 11. In the CLIM Listener, when I left-click the current directory presentation in the wholine pane, I get this error: Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER: 39 is not of type XLIB:GCONTEXT [Condition of type TYPE-ERROR] Restarts: 0: [ABORT ] Return to application command loop 1: [RETURN-TO-LISTENER] Return to listener. 2: Return to Top-Level. Debug (type H for help) (XLIB:DRAW-RECTANGLE 7 #<XLIB:WINDOW :0 44040284> 39 0 ...)[:EXTERNAL] 0] backtrace 0: (XLIB:DRAW-RECTANGLE 7 #<XLIB:WINDOW :0 44040284> 39 0 ...)[:EXTERNAL] 1: ((METHOD CLIM-CLX::MEDIUM-DRAW-RECTANGLE-USING-INK* NIL (CLIM-CLX::CLX-MEDIUM T T T T ...)) (#(2 5 8 NIL) . #()) #<unused-arg> #<CLIM-CLX::CLX-MEDIUM {588E952D}> #<unused-arg> ...) 2: ((METHOD CLIM-INTERNALS::DO-GRAPHICS-WITH-OPTIONS-INTERNAL NIL (CLIM:MEDIUM T T)) (#(2 5 6 3 2 ...) . #(# #)) #<unused-arg> #<CLIM-CLX::CLX-MEDIUM {588E952D}> #<CLIM-CLX::CLX-MEDIUM {588E952D}> ...) 3: (CLIM-LISTENER::DRAW-ICON T #<CLIM-INTERNALS::INDEXED-PATTERN {5843D4C5}> :EXTRA-SPACING 3) 4: ((FLET #:CONTINUATION22 (FLET #:CONT20 #))) 5: ((FLET #:CONTINUATION24 (FLET #:CONT20 #)) #<CLIM:INTERACTOR-PANE CLIM-LISTENER::INTERACTOR {588E8A65}> #<unused-arg>) 6: ((FLET #:CONTINUATION24 (FLET #:CONT20 #)) 2 #<CLIM:INTERACTOR-PANE CLIM-LISTENER::INTERACTOR {588E8A65}> #<unused-arg>)[:EXTERNAL] 7: ((METHOD CLIM:INVOKE-WITH-NEW-OUTPUT-RECORD NIL (CLIM:OUTPUT-RECORDING-STREAM T T T)) (#() . #(#)) #<unused-arg> #<CLIM:INTERACTOR-PANE CLIM-LISTENER::INTERACTOR {588E8A65}> #<Function (FLET #:CONTINUATION24 #) {580CA3A1}> ...) 8: ((FLET #:CONT20 (FLET #:DESTINATION-CONTINUATION0 CLIM-LISTENER::COM-SHOW-DIRECTORY)) #<CLIM:INTERACTOR-PANE CLIM-LISTENER::INTERACTOR {588E8A65}>) 9: ((METHOD CLIM:INVOKE-WITH-TEXT-STYLE NIL (CLIM:MEDIUM T T)) #<unused-arg> #<unused-arg> #<CLIM-CLX::CLX-MEDIUM {588E952D}> #<Closure Over Function (FLET #:CONT19 ) {58CB7AA9}> ...) 10: ("LAMBDA (G8058 G8059 G8060)" #<unused-arg> #<unused-arg> #<CLIM-LISTENER::LISTENER {588E559D}> (CLIM-LISTENER::COM-SHOW-DIRECTORY #P"/home/paolo/")) 11: ((METHOD CLIM:DEFAULT-FRAME-TOP-LEVEL NIL (CLIM:APPLICATION-FRAME)) (#() . #(# # # # # ...)) #<unused-arg> #<CLIM-LISTENER::LISTENER {588E559D}> (:PROMPT CLIM-LISTENER::PRINT-LISTENER-PROMPT)) 12: ("LAMBDA (.KEYARGS-START. .VALID-KEYS. G4608)" #<unused-arg> #<unused-arg> #<CLIM-LISTENER::LISTENER {588E559D}> (:PROMPT CLIM-LISTENER::PRINT-LISTENER-PROMPT)) 13: ((METHOD CLIM:RUN-FRAME-TOP-LEVEL NIL (CLIM:APPLICATION-FRAME)) (#(22) . #()) #<unused-arg> #<CLIM-LISTENER::LISTENER {588E559D}> #<unused-arg>) 14: ((METHOD CLIM:RUN-FRAME-TOP-LEVEL NIL (CLIM-LISTENER::LISTENER)) #<unused-arg> #S(PCL::FAST-METHOD-CALL :FUNCTION #<Function # {1167A9D1}> :PV-CELL (# . #) :NEXT-METHOD-CALL NIL :ARG-INFO (1 . T)) #<CLIM-LISTENER::LISTENER {588E559D}> (:LISTENER-FUNCALL NIL)) 15: ((METHOD CLIM:RUN-FRAME-TOP-LEVEL (:AROUND) (CLIM:APPLICATION-FRAME)) (#(18 17) . #(#)) #S(PCL::FAST-METHOD-CALL :FUNCTION #<Function # {590472D9}> :PV-CELL NIL :NEXT-METHOD-CALL #S(PCL::FAST-METHOD-CALL :FUNCTION # :PV-CELL # :NEXT-METHOD-CALL NIL :ARG-INFO #) :ARG-INFO (1 . T)) #<CLIM-LISTENER::LISTENER {588E559D}> (:LISTENER-FUNCALL NIL)) 16: (INTERACTIVE-EVAL (CLIM-LISTENER:RUN-LISTENER)) 17: (LISP::%TOP-LEVEL) 18: ((LABELS LISP::RESTART-LISP SAVE-LISP)) 0] If I load Experimental/pointer-doc-hack.lisp in the Listener and move the mouse pointer toward the current directory presentation, I get this similar, possibly related error: Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER: 0 is not of type XLIB:GCONTEXT [Condition of type TYPE-ERROR] Restarts: 0: [ABORT ] Return to application command loop 1: [RETURN-TO-LISTENER] Return to listener. 2: Return to Top-Level. Debug (type H for help) (XLIB:DRAW-RECTANGLE 7 #<XLIB:WINDOW :0 44040277> 0 0 ...)[:EXTERNAL] 0] I use CMUCL Snapshot 2004-12 with the latest McCLIM CVS sources under Slackware Linux 10.0. Paolo -- Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film

1 0

[mcclim-devel] cvs problem?
by Paul Werkowski 16 Jan '05

16 Jan '05

Tried to do a cvs update, got cvs server: cannot open directory /project/mcclim/cvsroot/mcclim/images: No such file or directory cvs server: skipping directory images Paul

4 4

[mcclim-devel] Running McCLIM and CL-SDL together: is it possible?
by Paolo Amoroso 08 Jan '05

08 Jan '05

Is it possible to run a McCLIM and a CL-SDL (cl-sdl.sourceforge.net) application within the same Lisp image? When I try this with CMUCL, only the CL-SDL application runs and the McCLIM one--say, the CLIM Listener--is frozen, i.e. the window is not refreshed and does not process input events. Things do not change if I start the CLIM Listener with :new-process t. I understand that the OpenGL/SDL event loop is a bit "pervasive", but I wonder whether there are any workarounds. Paolo -- Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film

1 1

Re: [mcclim-devel] question about display functions and control apps
by rpgoldman＠real-time.com 08 Jan '05

08 Jan '05

I'm afraid I'm restarting an old discussion, but I've had it on the backburner, and now that I'm moving forward, I'm not quite sure how to finish out the solution. >>>>> "AH" == Andy Hefner <ahefner(a)gmail.com> writes: AH> What I might do is run a separate thread from the GUI that monitors AH> external conditions. It can close over your frame event queue, and AH> communicate changes to the GUI via events as necessary. Just define AH> your own event subclasses and write handle-event methods for them, AH> which will run in the GUI thread and can perform the necessary AH> updates. McCLIM itself already works in this fashion on threaded AH> platforms, events are collected from CLX in a background thread which AH> queues them up for the applications to handle. I think this is the right solution for control applications. One has a second thread, which gets status updates and latches them into slots in the application frame, and then we queue up an event. Here are a couple of follow-ons, though: 1. Do I just make an event that will translate into setting frame-needs-redisplay? 2. How do I ensure that the slots that I'm latching into are stable over the redisplay? I imagine I make a clim-sys:lock object to make the update process and the redisplay process mutually exclusive, but can anyone give me a little guidance about what to protect in the CLIM code? I have been thinking that I should make a method for redisplay-frame-pane for my application that will hold the lock and (call-next-method). Is this the right level of granularity? Thanks! Robert

3 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

mcclim-devel January 2005