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

[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

[mcclim-devel] Spam at McCLIM CLiki
by Paolo Amoroso 05 Jan '05

05 Jan '05

The first spammed page at McCLIM CLiki: http://mcclim.cliki.net/Recent%20Changes shows that spammers have found also the site. An uphill battle starts... Paolo -- Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film

1 0

[mcclim-devel] problem with Goatee
by Matley 05 Jan '05

05 Jan '05

I am using mcclim (from cvs) and i am playing with goatee and his test (goatee-test.lisp) If i change the :initial-contents to a string with a newline inside, like (format nil "The fox jumped ~% over the goatee") i get corrupted output ([] characters). Bigger the string i put in it, more corrupted i get the output. I tried to debug it, without success because i didnt understand all the protocol (buffer, dblhead, etc.) inside it. So my questions are: Is it a bug or is there another mechanism to insert more line? Is goatee the standard text editing tool (usable as an enhanced gadget)?

1 0

[mcclim-devel] running clim apps over ssh -X fails
by Timmy Douglas 03 Jan '05

03 Jan '05

the following fixes it: 16:01 < dan_b> I would hazard that if you replace the call to xlib:open-display with xlib:oipen-default-display (and no arguments) it'd probably work fine 16:01 < timmyd> and the other error message is echod to the terminal 16:01 < dan_b> but open-default-display is not part of standard CLX 16:02 < dan_b> (that's in the initialize-clx method in Backends/CLX/port.lisp, around line 236 in my copy) (defmethod initialize-clx ((port clx-port)) (let ((options (cdr (port-server-path port)))) (setf (clx-port-display port) (xlib:open-default-display)) (progn (setf (xlib:display-error-handler (clx-port-display port)) #'clx-error-handler)

1 0

[mcclim-devel] CPU usage > 95% when running McCLIM apps
by Paolo Amoroso 03 Jan '05

03 Jan '05

When I run a McCLIM application, according to `top' CPU usage is constantly above 95% or so, and the KDE System Monitor reports about 50% for CPU 1. Here is a typical `top' entry when running the CLIM Listener: top - 09:52:31 up 3 min, 1 user, load average: 0.37, 0.23, 0.10 Tasks: 78 total, 2 running, 76 sleeping, 0 stopped, 0 zombie Cpu(s): 14.3% us, 36.0% sy, 0.0% ni, 49.7% id, 0.0% wa, 0.0% hi, 0.0% si Mem: 2075012k total, 301272k used, 1773740k free, 11244k buffers Swap: 2004420k total, 0k used, 2004420k free, 165556k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2728 paolo 25 0 1284m 37m 45m S 99.9 1.8 0:18.87 cmucl [...] When only the CMUCL toplevel is running, it is below 1%. Why is CPU usage so high with McCLIM applications? Is it real or some sort of measuring artifact? I use the latest McCLIM CVS sources with CMUCL Snapshot 2004-12 under Slackware Linux 10.0. My PC is a 2.8 GHz Pentium IV with 2 GB of RAM. Paolo -- Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film

3 7

[mcclim-devel] Bug list page at McCLIM CLiki: new resource
by Paolo Amoroso 03 Jan '05

03 Jan '05

I have created a simple McCLIM bug list at: http://mcclim.cliki.net/Bug It is meant as a useful, lightweight resource for both users and developers. Usage, as described in the short instructions at the top, should be straightforward. The only non obvious issue is the use of a NAME HTML tag, such as `my-bug', for each entry, This makes it possible to have URLs such as: http://mcclim.cliki.net/Bug#my-bug do the right thing and point the browser to the appropriate entry. Of course, I hope the page will not get long enough to make this feature useful :) Since the mcclim-devel list is archived, I will repost old bug reports of mine, and add links from the bug list, so that they can now be permanently archived. If this is an inconvenience for you, just let me know and I will not do it. Your feedback--better yet, your edits--is welcome. Paolo -- Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film

4 7