From tom.winchester at internode.on.net Tue Mar 1 01:23:18 2005 From: tom.winchester at internode.on.net (Tom Winchester) Date: Tue, 1 Mar 2005 11:53:18 +1030 Subject: [mcclim-devel] help needed with the beagle backend In-Reply-To: References: <3d1d83fa9e0d4a0be8625273b24f3442@internode.on.net> Message-ID: On 28/02/2005, at 5:35 PM, Christophe Rhodes wrote: >>> Error in process Listener(3): Cannot IMPORT >> "SET-PORT-KEYBOARD-FOCUS" from package "CLIMI" > > I believe that the backend protocol changed recently, and this symbol > was renamed to %set-port-keyboard-focus. Try changing uses of it in > the beagle backend (and adding a timestamp keyword argument to the > method definition). Thanks for the tip. I have done this (events.lisp, and package.lisp), and the listener comes up as stated. It also has the problems discussed eleswhere, but that is another story. Regards. From csr21 at cam.ac.uk Tue Mar 1 07:22:47 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Tue, 01 Mar 2005 07:22:47 +0000 Subject: [mcclim-devel] help needed with the beagle backend In-Reply-To: (Tom Winchester's message of "Tue, 1 Mar 2005 11:53:18 +1030") References: <3d1d83fa9e0d4a0be8625273b24f3442@internode.on.net> Message-ID: Tom Winchester writes: > On 28/02/2005, at 5:35 PM, Christophe Rhodes wrote: > >>>> Error in process Listener(3): Cannot IMPORT >>> "SET-PORT-KEYBOARD-FOCUS" from package "CLIMI" >> >> I believe that the backend protocol changed recently, and this symbol >> was renamed to %set-port-keyboard-focus. Try changing uses of it in >> the beagle backend (and adding a timestamp keyword argument to the >> method definition). > > Thanks for the tip. > > I have done this (events.lisp, and package.lisp), and the listener > comes up as stated. It also has the problems discussed eleswhere, but > that is another story. Since you've tested it, could you send a patch to this list? As you may be aware, the mcclim developers are attempting to put a release together for this weekend, and I'm pretty sure that elementary build fixes are in scope. Cheers, Christophe From tom.winchester at internode.on.net Tue Mar 1 12:33:22 2005 From: tom.winchester at internode.on.net (Tom Winchester) Date: Tue, 1 Mar 2005 23:03:22 +1030 Subject: [mcclim-devel] help needed with the beagle backend In-Reply-To: References: <3d1d83fa9e0d4a0be8625273b24f3442@internode.on.net> Message-ID: Hi there. I'm sending to the list the patches that Christopher has prodded me into generating. They are the output of diff. The patches attached when applied to the files in Backends/beagle/events.lisp, and Backends/beagle/package.lisp work in the sense that on my system (mac os x 10.3.8, openmcl from darwinports) the nerw files compile, and produce clim windows similar to ones thrown up by a google search. They were tested by pasting the following lines into an OpenMCL Listener (use (require "cocoa") in a command line openmcl, or launch the .app version): ;;;; Load asdf. #-:asdf (load "/opt/local/share/openmcl/0.14.2-p1/tools/asdf") (pushnew "/Users/tom/.asdf-install-openmcl-dir/systems/" asdf:*central-registry*) #-:asdf-install (asdf:operate 'asdf:load-op :asdf-install) ;;;; Load mcclim. (asdf:operate 'asdf:load-op :mcclim) (asdf:operate 'asdf:load-op :clim-examples) (asdf:operate 'asdf:load-op :clim-listener) (asdf:operate 'asdf:load-op :clouseau) ;;;; Load the beagle backend (asdf:operate 'asdf:load-op :beagle) (setf climi::*default-server-path* :beagle) The listener is launched by (clim-listener:run-listener :new-process t). I include this description of the invocation as the method in the README file in the beagle directory has hard coded paths (mentioned in a page google threw up), and clearly precedes the recent introduction of the mcclim.asd file. Of course, as it stands the beagle backend is not that functional, but that is another story. Regards. -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-events Type: application/octet-stream Size: 1946 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-package Type: application/octet-stream Size: 728 bytes Desc: not available URL: -------------- next part -------------- On 01/03/2005, at 5:52 PM, Christophe Rhodes wrote: > Tom Winchester writes: > >> On 28/02/2005, at 5:35 PM, Christophe Rhodes wrote: >> >>>>> Error in process Listener(3): Cannot IMPORT >>>> "SET-PORT-KEYBOARD-FOCUS" from package "CLIMI" >>> >>> I believe that the backend protocol changed recently, and this symbol >>> was renamed to %set-port-keyboard-focus. Try changing uses of it in >>> the beagle backend (and adding a timestamp keyword argument to the >>> method definition). >> >> Thanks for the tip. >> >> I have done this (events.lisp, and package.lisp), and the listener >> comes up as stated. It also has the problems discussed eleswhere, but >> that is another story. > > Since you've tested it, could you send a patch to this list? As you > may be aware, the mcclim developers are attempting to put a release > together for this weekend, and I'm pretty sure that elementary build > fixes are in scope. > > Cheers, > > Christophe > From asf at boinkor.net Fri Mar 4 07:58:21 2005 From: asf at boinkor.net (Andreas Fuchs) Date: Fri, 04 Mar 2005 08:58:21 +0100 Subject: [mcclim-devel] help needed with the beagle backend In-Reply-To: References: <3d1d83fa9e0d4a0be8625273b24f3442@internode.on.net> Message-ID: <873bvbu9k2.wl%asf@boinkor.net> On 2005-03-01, Tom Winchester wrote: > I'm sending to the list the patches that Christopher has prodded me > into generating. They are the output of diff. Thanks, I committed the two patches. Unfortunately, I lack the Mac to test them, so testing from other McCLIM users would be appreciated (-: Cheers, -- Andreas Fuchs, , asf at jabber.at, antifuchs From mcclim-devel at common-lisp.net Sun Mar 6 22:08:32 2005 From: mcclim-devel at common-lisp.net (McCLIM developers) Date: Sun, 06 Mar 2005 23:08:32 +0100 Subject: [mcclim-devel] Announcing McCLIM 0.9.1 - "Mothering Sunday" Message-ID: <87sm38s9zz.wl%asf@boinkor.net> The McCLIM developers are happy to release version 0.9.1 of McCLIM. It was extensively tested on SBCL (threaded and unthreaded), OpenMCL and CMUCL. It's also known to work with Allegro Common Lisp (tested with 6.2 Trial Edition). Lots of things changed since the last release, so I appended the release notes after the announcement. We're hoping to make this release the first in a series of time-boxed releases of McCLIM. You can get a tarball at . Of course, we are looking forward to comments and bug reports. Please direct these at mcclim-devel common-lisp.net. The current list of known bugs can be found at . Have fun using McCLIM (and build good things with it), the McCLIM developers. RELEASE NOTES FOR McCLIM 0.9.1 - "Mothering Sunday": Changes to the McCLIM Installation Process ========================================== McCLIM now comes with a native ASDF system definition in mcclim.asd, along with the traditional (still ASDF-compatible) system.lisp. See INSTALL.ASDF for details. Changes to Backends =================== Support for Copy&Paste of selections (both into and out from McCLIM applications) in the X11 backend was added. Copying text from McCLIM into some applications (and vice versa) like KDE's Konsole is broken, unfortunately. Shift + left-mouse-drag and Shift + mouse-middle-down now activate a selection and paste in your McCLIM application, respectively. There is now rudimentary support for printing non-Latin1 characters to X11 ports on SBCL. Beagle, A new experimental backend using Mac OS X's Cocoa bindings was added. Note that this backend is still incomplete and breaks in some places. It is not loaded automatically. To try it out, consult Backends/beagle/README. Changes to the Manual ===================== A chapter on presentation types was added. The chapter on command tables was improved. Changes to Contributed Applications and Examples ================================================ Clouseau, a graphical Inspector application was added. The CLIM Listener saw many improvements, among these: package graphing, better directory stack handling and a new Edit Definition command. A Method Browser was added to the examples. Status of the CLIM 2 Spec Implementation ======================================== Here is a list of what we think works, organized by chapters and sections of the CLIM 2 specification. Chapter 3 Regions Mostly finished. There are some troublesome parts of the specification that may not be implemented for all possible regions, for instance region-contains-region-p. There may not be an efficient way of implementing this function for all kinds of regions. Chapter 4, Bounding rectangles Finished Chapter 5, Affine transformations Finished Chapter 6, Overview of window facilities Finished Chapter 7, Properties of sheets Finished, though the correct behavior of sheet transformations may not have been tested. Chapter 8, Sheet protocols Finished Chapter 9, Ports, Grafts, and Mirrored sheets Finished Chapter 10, Sheet and medium output facilities Finished Chapter 11, Text styles Finished Chapter 12, Graphics Finished Chapter 13, Drawing in Color I am note sure about the state of this. I thought we were doing only full opacity and full transparency, but I see traces of more general designs. Chapter 14, General Designs The composition of designs is not supported. We do support regions as designs. Chapter 15, Extended Stream Output Extended output streams are fully supported. Chapter 16, Output Recording Output recording is mostly implemented. We do not have a true standard-tree-output-record type or the R-tree type of real CLIM, so some operations may be slow with lots of output records. make-design-from-output-record is not implemented. *Note*: the coordinates in output records are relative to the stream. This is in conformance with the Spec, but not necessarily compatible with other CLIM implementations. There is now a protocol in place for Drag-and-Drop of output records. Output recording inside formatting-tables now works. Chapter 17, Table Formatting Table formatting is completely implemented. Chapter 18, Graph Formatting Graph formatting is fully implemented. The :hash-table argument to format-graph-from-roots is ignored. Chapter 19, Bordered Output Bordered output is fully supported. The :move-cursor argument to surrounding-output-with-border is now working. Chapter 20, Text Formatting With the exception of the :after-line-break-initially argument to filling-output, this chapter is fully implemented. Chapter 21 Incremental Redisplay The updating-output interface to incremental redisplay is implemented. McCLIM makes no effort to move i.e., bitblit, output records; they are always erased and redrawn if their position changes. This is much more compatible with support for partial transparency. The :x, :y, :parent-x and :parent-y arguments to redisplay-output-record are ignored. McCLIM follows the spirit of 21.3 "Incremental Redisplay Protocol", but we have not tried very hard to implement the vague description in the Spec. augment-draw-set, note-output-record-child-changed and propagate-output-record-changes-p are not implemented. Incremental redisplay in McCLIM can suffer from performance problems because there are no spatially-organized compound output record types. The generic function incremental-redisplay is now implemented. Chapter 22, Extended Stream Input The implementation of extended input streams is quite complete. (setf* pointer-position) is not implemented. There is no stream numeric argument, so that slot of the accelerator-gesture condition is always 1. drag-output-record and dragging-output are now implemented. Chapter 23 Presentation Types Most of the literal specification of this chapter is implemented. Specific accept and present presentation methods for some types are not implemented, so the default method may be surprising. The output record bounding rectangle is always used or highlighting and pointer testing. presentation-default-processor is not implemented. The presentation method mechanism supports all method combinations. The body of a presentation method is surrounded with a block of the same name as the presentation method, not just the magic internal name. The method by which presentation type parameters and options are decoded for the method bodies is a bit different from real CLIM. In particular, you cannot refer to the type parameters and options in the lambda list of the method. The NIL value of presentation-single-box is now supported. Presentation type histories are now partially implemented. The gesture C-M-y should recall the last entered presentation. define-drag-and-drop-translator is now implemented. Chapter 24 Input Editing and Completion Facilities with-input-editor-typeout is not implemented. The noise strings produced by input-editor-format and the strings produced by presentation-replace-input are not read-only. This could lead to interesting "issues" if the user edits them. Only a few of the suggested editing commands are implemented. An additional command that is implemented is control-meta-B, which drops into the debugger. add-input-editor-command is not implemented. with-accept-help is not implemented. Chapter 25 Menu Facilities The protocol is implemented, but McCLIM doesn't use it to draw command table menus. Chapter 26 Dialog Facilities McCLIM contains a basic, somewhat buggy implementation of accepting-values. There is little user feedback as to what has been accepted in a dialog. The user has to press the "Exit" button to exit the dialog; there are no short cuts. There are no special accept-present-default methods for member or subset presentation types. Command-buttons are not implemented. There is no gadget-based implementation of accepting-values. own-window is not supported. The internal structure of accepting-values should be "culturally compatible" with real CLIM; if you have some spiffy hack, check the source. Chapter 27 Command Processing command-line-complete-input is not implemented (the functionality does exist in the accept method for command-name). display-command-table-menu and menu-choose-command-from-table are not implemented. Menu-command-parser is not implemented, though the functionality obviously is. Nothing is done about partial menu commands. There is no support for numeric arguments. The command-or-form presentation type is not implemented. Chapter 28 Application Frames raise-frame, bury-frame and notify-user are not implemented. :accept-values panes are not implemented. frame-maintain-presentation-histories, frame-drag-and-drop-feedback and frame-drag-and-drop-highlighting are not implemented. execute-frame-command ignores the possibility that frame and the current frame might be different. display-command-menu isn't implemented. command-enabled is now implemented. Chapter 29 Panes Due to the way the space-allocation protocol is implemented, it is not easy to create application-specific layout-panes. Client code needs to know about :AROUND methods to compose-space, but they are not mentioned in the spec. restraining-pane is partially implemented. Chapter 30 Gadgets This chapter is implemented. From csr21 at cam.ac.uk Mon Mar 7 12:54:13 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Mon, 07 Mar 2005 12:54:13 +0000 Subject: [mcclim-devel] Copying text to clipboard loops displaying messages to Konsole In-Reply-To: <87650d111r.fsf@plato.moon.paoloamoroso.it> (Paolo Amoroso's message of "Mon, 28 Feb 2005 10:33:36 +0100") References: <87650d111r.fsf@plato.moon.paoloamoroso.it> Message-ID: Paolo Amoroso writes: > 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: If it's still not working for you, could you please try the attached patch? If this fails to work correctly, could you provide me with a few more details about your setup? You're working in Konsole -- could you tell me also what your LANG and LC_ALL settings are, and what the following program produces? #include #include int main () { printf("CODESET: %s\n", nl_langinfo(CODESET)); } -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: paste.diff URL: -------------- next part -------------- Thanks, Christophe From amoroso at mclink.it Mon Mar 7 16:31:24 2005 From: amoroso at mclink.it (Paolo Amoroso) Date: Mon, 07 Mar 2005 17:31:24 +0100 Subject: [mcclim-devel] Copying text to clipboard loops displaying messages to Konsole References: <87650d111r.fsf@plato.moon.paoloamoroso.it> Message-ID: <87vf83xvs3.fsf@plato.moon.paoloamoroso.it> Christophe Rhodes writes: > If it's still not working for you, could you please try the attached > patch? With the latest McCLIM CVS sources, I can correctly paste text from the CLIM Listener to a Konsole. But I get an endless stream of identical messages like this in the Konsole from which I start McCLIM: is an instance of type CLX-SELECTION-REQUEST-EVENT it has the following slots: TIMESTAMP: 3664352 SHEET: # REGION: SELECTION: :PRIMARY REQUESTOR: # TARGET: :COMPOUND_TEXT PROPERTY: :_QT_SELECTION ;; clim-clx::send-selection - Requested target COMPOUND_TEXT, sent COMPOUND_TEXT to property _QT_SELECTION. > If this fails to work correctly, could you provide me with a few more With your patch applied to the latest CVS sources, when I Shift-middle-click to paste some text from the CLIM Listener to a Konsole, the Listener and the Konsole hang for a few tens of seconds and then I get the message, error and backtrace included below. > details about your setup? You're working in Konsole -- could you tell > me also what your LANG and LC_ALL settings are, and what the following LANG: en_US. LC_ALL is not set. > program produces? > > #include > #include > > int main () { > printf("CODESET: %s\n", nl_langinfo(CODESET)); > } It produces: CODESET: ANSI_X3.4-1968 I use KDE 3.2.3. Paolo -------------------------------------------------------------------------- # is an instance of type CLX-SELECTION-REQUEST-EVENT it has the following slots: TIMESTAMP: 2845031 SHEET: # REGION: SELECTION: :PRIMARY REQUESTOR: # TARGET: :TARGETS PROPERTY: :_QT_SELECTION ;; clim-clx::send-selection - Requested target TARGETS, sent TARGETS to property _QT_SELECTION. Received CLX LENGTH-ERROR in process "#'s event process." Asynchronous LENGTH-ERROR in request 10634 (last request was 10635) Code 110.0 [ListHosts] [Condition of type XLIB:LENGTH-ERROR] Restarts: 0: [CONTINUE ] Ignore 1: [RESTART-EVENT-LOOP] Restart CLIM's event loop. 2: [DESTROY ] Destroy the process Debug (type H for help) (XLIB::READ-ERROR-INPUT # 10634 #S(XLIB::REPLY-BUFFER :SIZE 32 :IBUF8 #(0 16 138 41 38 ...) :NEXT #S(XLIB::REPLY-BUFFER :SIZE 32 :IBUF8 # :NEXT # :DATA-SIZE 32) :DATA-SIZE 32) #'s event process. {59729FED}>) Source: Error finding source: Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM: Source file no longer exists: target:clx/input.lisp. 0] backtrace 0: (XLIB::READ-ERROR-INPUT # 10634 #S(XLIB::REPLY-BUFFER :SIZE 32 :IBUF8 #(0 16 138 41 38 ...) :NEXT #S(XLIB::REPLY-BUFFER :SIZE 32 :IBUF8 # :NEXT # :DATA-SIZE 32) :DATA-SIZE 32) #'s event process. {59729FED}>) 1: (XLIB::READ-INPUT # NIL NIL # ...) 2: (XLIB::READ-REPLY # #S(XLIB::PENDING-COMMAND :SEQUENCE 10635 :REPLY-BUFFER NIL :PROCESS #'s event process. {59729FED}> :NEXT NIL)) 3: (XLIB::WITH-BUFFER-REQUEST-AND-REPLY-FUNCTION # NIL # #) 4: (XLIB:DISPLAY-FINISH-OUTPUT #) 5: ((METHOD CLIM-BACKEND:GET-NEXT-EVENT NIL (CLIM-CLX::CLX-PORT)) (#(14) . #()) # # (:WAIT-FUNCTION NIL :TIMEOUT NIL)) 6: ("LAMBDA (.KEYARGS-START. .VALID-KEYS. G6851 G6852 G6853)" # # # (:WAIT-FUNCTION NIL :TIMEOUT NIL)) 7: ((METHOD CLIM:PROCESS-NEXT-EVENT NIL (CLIM:BASIC-PORT)) (#() . #(#)) # # NIL) 8: ("DEFMETHOD INITIALIZE-CLX (CLX-PORT)") 9: ("DEFUN MAKE-PROCESS") 0] -------------------------------------------------------------------------- -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From csr21 at cam.ac.uk Mon Mar 7 17:11:07 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Mon, 07 Mar 2005 17:11:07 +0000 Subject: [mcclim-devel] Copying text to clipboard loops displaying messages to Konsole In-Reply-To: <87vf83xvs3.fsf@plato.moon.paoloamoroso.it> (Paolo Amoroso's message of "Mon, 07 Mar 2005 17:31:24 +0100") References: <87650d111r.fsf@plato.moon.paoloamoroso.it> <87vf83xvs3.fsf@plato.moon.paoloamoroso.it> Message-ID: Paolo Amoroso writes: > Christophe Rhodes writes: > >> If it's still not working for you, could you please try the attached >> patch? > > With the latest McCLIM CVS sources, I can correctly paste text from > the CLIM Listener to a Konsole. But I get an endless stream of > identical messages like this in the Konsole from which I start McCLIM: OK. I still have no idea what's going on -- all of these work as expected for me, with Konsole 1.3.2 (KDE 3.2.3, Qt 3.2.3). > 9: ("DEFUN MAKE-PROCESS") Can you try running the clim-listener single-threaded, please -- there might be slightly less to go wrong. In addition, if you could try (clipboard:main) from , clicking in the clx window which appears, then middle-clicking in console, and sending in the transcript, that would help. Thanks, Christophe From amoroso at mclink.it Mon Mar 7 17:40:34 2005 From: amoroso at mclink.it (Paolo Amoroso) Date: Mon, 07 Mar 2005 18:40:34 +0100 Subject: [mcclim-devel] Copying text to clipboard loops displaying messages to Konsole In-Reply-To: (Christophe Rhodes's message of "Mon, 07 Mar 2005 17:11:07 +0000") References: <87650d111r.fsf@plato.moon.paoloamoroso.it> <87vf83xvs3.fsf@plato.moon.paoloamoroso.it> Message-ID: <87hdjnxskt.fsf@plato.moon.paoloamoroso.it> Christophe Rhodes writes: > OK. I still have no idea what's going on -- all of these work as > expected for me, with Konsole 1.3.2 (KDE 3.2.3, Qt 3.2.3). I have Konsole 1.3.2, KDE 3.2.3, Qt 3.3.3 and X.Org 6.7.0 under Slackware Linux 10.0 with a customized 2.6.10 kernel. >> 9: ("DEFUN MAKE-PROCESS") > > Can you try running the clim-listener single-threaded, please -- there Do you mean starting the Listener like this? (clim-listener:run-listener) If so, I already did this for these tests. > In addition, if you could try (clipboard:main) from > , clicking in > the clx window which appears, then middle-clicking in console, and > sending in the transcript, that would help. With CMUCL Snapshot 2005-02 I get: * (load "clipboard") ; Loading #P"/home/paolo/clipboard.lisp". T * (clipboard:main) ; ; Warning: This function is undefined: ; CLIPBOARD::OPEN-DEFAULT-DISPLAY Error in KERNEL:%COERCE-TO-FUNCTION: the function CLIPBOARD::OPEN-DEFAULT-DISPLAY is undefined. [Condition of type UNDEFINED-FUNCTION] Restarts: 0: [ABORT] Return to Top-Level. Debug (type H for help) (KERNEL:%COERCE-TO-FUNCTION CLIPBOARD::OPEN-DEFAULT-DISPLAY) Source: Error finding source: Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM: Source file no longer exists: target:code/fdefinition.lisp. 0] backtrace 0: (KERNEL:%COERCE-TO-FUNCTION CLIPBOARD::OPEN-DEFAULT-DISPLAY) 1: (CLIPBOARD:MAIN) 2: (INTERACTIVE-EVAL (CLIPBOARD:MAIN)) 3: (LISP::%TOP-LEVEL) 4: ((LABELS LISP::RESTART-LISP SAVE-LISP)) 0] Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From csr21 at cam.ac.uk Mon Mar 7 17:46:15 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Mon, 07 Mar 2005 17:46:15 +0000 Subject: [mcclim-devel] Copying text to clipboard loops displaying messages to Konsole In-Reply-To: <87hdjnxskt.fsf@plato.moon.paoloamoroso.it> (Paolo Amoroso's message of "Mon, 07 Mar 2005 18:40:34 +0100") References: <87650d111r.fsf@plato.moon.paoloamoroso.it> <87vf83xvs3.fsf@plato.moon.paoloamoroso.it> <87hdjnxskt.fsf@plato.moon.paoloamoroso.it> Message-ID: Paolo Amoroso writes: >>> 9: ("DEFUN MAKE-PROCESS") >> >> Can you try running the clim-listener single-threaded, please -- there > > Do you mean starting the Listener like this? > > (clim-listener:run-listener) > > If so, I already did this for these tests. Well, maybe, but the backtrace you provided indicates that multithreading was running. Could you turn it off completely, please? I'd like to see the results when there is precisely one cmucl thread. >> In addition, if you could try (clipboard:main) from >> , clicking in >> the clx window which appears, then middle-clicking in console, and >> sending in the transcript, that would help. > > With CMUCL Snapshot 2005-02 I get: > > * (load "clipboard") > > ; Loading #P"/home/paolo/clipboard.lisp". > T > * (clipboard:main) > ; > > ; Warning: This function is undefined: > ; CLIPBOARD::OPEN-DEFAULT-DISPLAY Oh, yes, CMUCL's clx doesn't have this useful feature. Please replace the call to OPEN-DEFAULT-DISPLAY with however you manage to open displays; maybe (open-display "localhost") or (open-display "your-host-name") or (open-display ""). Cheers, Christophe From ahefner at gmail.com Mon Mar 7 18:53:39 2005 From: ahefner at gmail.com (Andy Hefner) Date: Mon, 7 Mar 2005 13:53:39 -0500 Subject: [mcclim-devel] Copying text to clipboard loops displaying messages to Konsole In-Reply-To: References: <87650d111r.fsf@plato.moon.paoloamoroso.it> <87vf83xvs3.fsf@plato.moon.paoloamoroso.it> <87hdjnxskt.fsf@plato.moon.paoloamoroso.it> Message-ID: <31ffd3c405030710532ab9a06b@mail.gmail.com> I'm not sure there's an easy way to disable threading in CMUCL. It might involve finding where :clim-mp gets pushed onto *features* and preventing that from happening, then recompiling McCLIM from scratch. On Mon, 07 Mar 2005 17:46:15 +0000, Christophe Rhodes wrote: > Paolo Amoroso writes: > > >>> 9: ("DEFUN MAKE-PROCESS") > >> > >> Can you try running the clim-listener single-threaded, please -- there > > > > Do you mean starting the Listener like this? > > > > (clim-listener:run-listener) > > > > If so, I already did this for these tests. > > Well, maybe, but the backtrace you provided indicates that > multithreading was running. Could you turn it off completely, please? > I'd like to see the results when there is precisely one cmucl thread. > > >> In addition, if you could try (clipboard:main) from > >> , clicking in > >> the clx window which appears, then middle-clicking in console, and > >> sending in the transcript, that would help. > > > > With CMUCL Snapshot 2005-02 I get: > > > > * (load "clipboard") > > > > ; Loading #P"/home/paolo/clipboard.lisp". > > T > > * (clipboard:main) > > ; > > > > ; Warning: This function is undefined: > > ; CLIPBOARD::OPEN-DEFAULT-DISPLAY > > Oh, yes, CMUCL's clx doesn't have this useful feature. Please replace > the call to OPEN-DEFAULT-DISPLAY with however you manage to open > displays; maybe (open-display "localhost") or (open-display > "your-host-name") or (open-display ""). > > Cheers, > > Christophe > _______________________________________________ > mcclim-devel mailing list > mcclim-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel > From amoroso at mclink.it Mon Mar 7 19:23:38 2005 From: amoroso at mclink.it (Paolo Amoroso) Date: Mon, 07 Mar 2005 20:23:38 +0100 Subject: [mcclim-devel] Copying text to clipboard loops displaying messages to Konsole References: <87650d111r.fsf@plato.moon.paoloamoroso.it> <87vf83xvs3.fsf@plato.moon.paoloamoroso.it> <87hdjnxskt.fsf@plato.moon.paoloamoroso.it> Message-ID: <87k6oj45vp.fsf@plato.moon.paoloamoroso.it> Christophe Rhodes writes: > Paolo Amoroso writes: [...] >>> Can you try running the clim-listener single-threaded, please -- there >> >> Do you mean starting the Listener like this? >> >> (clim-listener:run-listener) >> >> If so, I already did this for these tests. > > Well, maybe, but the backtrace you provided indicates that > multithreading was running. Could you turn it off completely, please? To do these tests I start CMUCL with CLX, load the CLIM Listener with: (asdf:operate 'asdf:load-op :mcclim) and start it with: (clim-listener:run-listener) Just before starting the Listener, the state of CMUCL multithreading is as follows: * (mp:show-processes) -> # "Run" ACTIVE NIL * Is multithreading running at this stage? If so, how do I turn it off? > Oh, yes, CMUCL's clx doesn't have this useful feature. Please replace > the call to OPEN-DEFAULT-DISPLAY with however you manage to open > displays; maybe (open-display "localhost") or (open-display > "your-host-name") or (open-display ""). I replaced it with (open-display "localhost") and run the test, i.e. started the program, left clicked in its window, and midlle-clicked in a Konsole. The pasted string is: Hello, World (from the CLX clipboard)! Just after starting the program, the output is: * (clipboard:main) PropertyNotify :_KDE_NET_WM_USER_CREATION_TIME :NEW-VALUE PropertyNotify :_NET_WM_DESKTOP :NEW-VALUE PropertyNotify :_KDE_NET_WM_FRAME_STRUT :NEW-VALUE PropertyNotify :_NET_WM_ALLOWED_ACTIONS :NEW-VALUE PropertyNotify :WM_STATE :NEW-VALUE PropertyNotify :_NET_WM_STATE :NEW-VALUE PropertyNotify :_NET_WM_ICON_GEOMETRY :NEW-VALUE PropertyNotify :_NET_WM_ICON_GEOMETRY :NEW-VALUE ButtonPress When left clicking, an endless loop displaying messages like this starts: > set-selection-owner SelectionRequest :PRIMARY :TIMESTAMP :KLIPPER > sending none SelectionRequest :PRIMARY :TARGETS :_QT_SELECTION > sending targets list SelectionRequest :PRIMARY :STRING :_QT_SELECTION > sending text data SelectionRequest :PRIMARY :TIMESTAMP :KLIPPER > sending none SelectionRequest :PRIMARY :TARGETS :_QT_SELECTION > sending targets list SelectionRequest :PRIMARY :STRING :_QT_SELECTION > sending text data SelectionRequest :PRIMARY :TIMESTAMP :KLIPPER > sending none SelectionRequest :PRIMARY :TARGETS :_QT_SELECTION > sending targets list SelectionRequest :PRIMARY :STRING :_QT_SELECTION > sending text data SelectionRequest :PRIMARY :TIMESTAMP :KLIPPER > sending none PropertyNotify :_NET_WM_ICON_GEOMETRY :NEW-VALUE SelectionRequest :PRIMARY :TARGETS :_QT_SELECTION > sending targets list SelectionRequest :PRIMARY :STRING :_QT_SELECTION > sending text data SelectionRequest :PRIMARY :TARGETS :_QT_SELECTION > sending targets list SelectionRequest :PRIMARY :STRING :_QT_SELECTION > sending text data SelectionRequest :PRIMARY :TIMESTAMP :KLIPPER > sending none [...] Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From amoroso at mclink.it Mon Mar 7 20:07:31 2005 From: amoroso at mclink.it (Paolo Amoroso) Date: Mon, 07 Mar 2005 21:07:31 +0100 Subject: [mcclim-devel] Copying text to clipboard loops displaying messages to Konsole In-Reply-To: <31ffd3c405030710532ab9a06b@mail.gmail.com> (Andy Hefner's message of "Mon, 7 Mar 2005 13:53:39 -0500") References: <87650d111r.fsf@plato.moon.paoloamoroso.it> <87vf83xvs3.fsf@plato.moon.paoloamoroso.it> <87hdjnxskt.fsf@plato.moon.paoloamoroso.it> <31ffd3c405030710532ab9a06b@mail.gmail.com> Message-ID: <87k6oj2pa4.fsf@plato.moon.paoloamoroso.it> Andy Hefner writes: > I'm not sure there's an easy way to disable threading in CMUCL. It > might involve finding where :clim-mp gets pushed onto *features* and > preventing that from happening, then recompiling McCLIM from scratch. I see. Christophe was probably talking about disabling threading in McCLIM, but I misunderstood and thought he referred to CMUCL's multithreading. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From pw at snoopy.mv.com Mon Mar 7 20:51:05 2005 From: pw at snoopy.mv.com (Paul Werkowski) Date: Mon, 7 Mar 2005 15:51:05 -0500 Subject: [mcclim-devel] Copying text to clipboard loops displayingmessages to Konsole References: <87650d111r.fsf@plato.moon.paoloamoroso.it> <87vf83xvs3.fsf@plato.moon.paoloamoroso.it> <87hdjnxskt.fsf@plato.moon.paoloamoroso.it> <87k6oj45vp.fsf@plato.moon.paoloamoroso.it> Message-ID: <001801c52357$61d5b6d0$0201a8c0@moby> -> # "Run" ACTIVE | NIL | * | | Is multithreading running at this stage? If so, how do I turn it off? (mp::shutdown-multi-processing) Paul From csr21 at cam.ac.uk Mon Mar 7 21:58:33 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Mon, 07 Mar 2005 21:58:33 +0000 Subject: [mcclim-devel] Copying text to clipboard loops displaying messages to Konsole In-Reply-To: <87k6oj45vp.fsf@plato.moon.paoloamoroso.it> (Paolo Amoroso's message of "Mon, 07 Mar 2005 20:23:38 +0100") References: <87650d111r.fsf@plato.moon.paoloamoroso.it> <87vf83xvs3.fsf@plato.moon.paoloamoroso.it> <87hdjnxskt.fsf@plato.moon.paoloamoroso.it> <87k6oj45vp.fsf@plato.moon.paoloamoroso.it> Message-ID: Paolo Amoroso writes: > Christophe Rhodes writes: >> Oh, yes, CMUCL's clx doesn't have this useful feature. Please replace >> the call to OPEN-DEFAULT-DISPLAY with however you manage to open >> displays; maybe (open-display "localhost") or (open-display >> "your-host-name") or (open-display ""). > > I replaced it with (open-display "localhost") and run the test, > i.e. started the program, left clicked in its window, and > midlle-clicked in a Konsole. The pasted string is: > > Hello, World (from the CLX clipboard)! OK, so my clipboard demo succesfully pastes to console... > Just after starting the program, the output is: > > * (clipboard:main) > > PropertyNotify :_KDE_NET_WM_USER_CREATION_TIME :NEW-VALUE > PropertyNotify :_NET_WM_DESKTOP :NEW-VALUE > PropertyNotify :_KDE_NET_WM_FRAME_STRUT :NEW-VALUE > PropertyNotify :_NET_WM_ALLOWED_ACTIONS :NEW-VALUE > PropertyNotify :WM_STATE :NEW-VALUE > PropertyNotify :_NET_WM_STATE :NEW-VALUE > PropertyNotify :_NET_WM_ICON_GEOMETRY :NEW-VALUE > PropertyNotify :_NET_WM_ICON_GEOMETRY :NEW-VALUE > ButtonPress > > When left clicking, an endless loop displaying messages like this > starts: > >> set-selection-owner > SelectionRequest :PRIMARY :TIMESTAMP :KLIPPER >> sending none > SelectionRequest :PRIMARY :TARGETS :_QT_SELECTION >> sending targets list > SelectionRequest :PRIMARY :STRING :_QT_SELECTION >> sending text data > SelectionRequest :PRIMARY :TIMESTAMP :KLIPPER ... but "KLIPPER", probably some bizarre KDE thing, is now getting in the way. OK, but in this test you're not getting any length-errors. Hmm. So I might not be seeing the problems you're seeing because I'm not running a KDE environment; I'm simply testing in the terminals you're saying you see problems with. If there are desktop-specific clipboard daemons, there is quite reasonably MORE PAIN to be experienced. I don't really know what to suggest; I'd probably ask the developers of whatever desktop environment you're using about known interoperability issues with clipboard handling, and see if they act shy and bashful. I claim that clipboard.lisp is ICCCM-compliant code, but I've been wrong before -- specifically, I've been wrong when I reported a bug in gdk about it, so it's possible there are bugs lurking. There is C code referenced from the lisp file which might be of assistance when talking to C-based developers; asking them why the C code produces an endless loop might prompt a response. Cheers, Christophe From ch-mcclim at bobobeach.com Tue Mar 8 01:31:22 2005 From: ch-mcclim at bobobeach.com (Cyrus Harmon) Date: Mon, 7 Mar 2005 17:31:22 -0800 Subject: [mcclim-devel] Announcing McCLIM 0.9.1 - "Mothering Sunday" In-Reply-To: <87sm38s9zz.wl%asf@boinkor.net> References: <87sm38s9zz.wl%asf@boinkor.net> Message-ID: <83dc02cdb67270cb240339f0f1389397@bobobeach.com> The following was necessary to get beagle to build properly for me. Sorry I didn't get a chance to test this prior to mothering sunday. :-( Index: beagle-backend.asd =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/Backends/beagle/beagle-backend.asd,v retrieving revision 1.1 diff -u -r1.1 beagle-backend.asd --- beagle-backend.asd 8 Aug 2004 16:20:44 -0000 1.1 +++ beagle-backend.asd 8 Mar 2005 01:30:10 -0000 @@ -24,7 +24,7 @@ #:port-disable-sheet #:port-motion-hints #:port-force-output - #:set-port-keyboard-focus + #:%set-port-keyboard-focus #:set-sheet-pointer-cursor ;; #:port-set-mirror-region From ch-mcclim at bobobeach.com Tue Mar 8 01:42:46 2005 From: ch-mcclim at bobobeach.com (Cyrus Harmon) Date: Mon, 7 Mar 2005 17:42:46 -0800 Subject: [mcclim-devel] more beagle stuff Message-ID: <0c4df14767c91b1aca6d47f2c87ce34b@bobobeach.com> While I'm at it, the following made the command/esc/etc... key situation much better for climacs: -------------- next part -------------- A non-text attachment was scrubbed... Name: beagle-20050307.patch Type: application/octet-stream Size: 8362 bytes Desc: not available URL: -------------- next part -------------- From rpgoldman at real-time.com Tue Mar 8 02:12:22 2005 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Mon, 7 Mar 2005 20:12:22 -0600 Subject: [mcclim-devel] problem building McCLIM mothering on Linux ACL 6.2 Message-ID: <16941.2566.558238.843531@gargle.gargle.HOWL> I, too, was unable to do any testing before the release. I just updated my repository, wiped out the fasls, and tried to rebuild (this time from the asdf def, instead of system.lisp). I got a problem with package dependencies. Building mcclim/Looks/pixie.lisp got an error because the IMAGE package was undefined. Here's the error message. I'll have a look to try to track down the bug whenever I can get any time. Error: Package "IMAGE" not found. [file position = 36821] [condition type: READER-ERROR] Restart actions (select using :continue): 0: retry the compilation of /home/rpg/lisp/mcclim/Looks/pixie.lisp 1: continue compiling /home/rpg/lisp/mcclim/Looks/pixie.lisp but generate no output file 2: Retry performing # on #. 3: Continue, treating # on # as having been successful. 4: Return to Top Level (an "abort" restart). 5: Abort entirely from this process. Best, R From rpgoldman at real-time.com Tue Mar 8 02:57:11 2005 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Mon, 7 Mar 2005 20:57:11 -0600 Subject: [mcclim-devel] problem building McCLIM mothering on Linux ACL 6.2 In-Reply-To: <16941.2566.558238.843531@gargle.gargle.HOWL> References: <16941.2566.558238.843531@gargle.gargle.HOWL> Message-ID: <16941.5255.645335.781779@gargle.gargle.HOWL> I have been able to build the clim-clx-user system (which loads clim) using the defsystem that comes in system.lisp for mcclim. So it seems like the package problem I just reported is somehow in mcclim.asd, but not in system.lisp. If I find out any more, I'll report. best, r From asf at boinkor.net Tue Mar 8 08:10:48 2005 From: asf at boinkor.net (Andreas Fuchs) Date: Tue, 08 Mar 2005 09:10:48 +0100 Subject: [mcclim-devel] problem building McCLIM mothering on Linux ACL 6.2 In-Reply-To: <16941.5255.645335.781779@gargle.gargle.HOWL> References: <16941.2566.558238.843531@gargle.gargle.HOWL> <16941.5255.645335.781779@gargle.gargle.HOWL> Message-ID: <87vf82lfqv.wl%asf@boinkor.net> Today, wrote: > I have been able to build the clim-clx-user system (which loads > clim) using the defsystem that comes in system.lisp for mcclim. So > it seems like the package problem I just reported is somehow in > mcclim.asd, but not in system.lisp. > > If I find out any more, I'll report. Oh. I should have been more explicit about that in the INSTALL.ASDF, then. On ACL6.2, you need to (require :clx) (as step 2 says) before you (asdf:oos 'asdf:load-op :mcclim). Unfortunately, CLX doesn't come with an ASDF system on ACL. Perhaps we should make a clx-compat system that pulls in CLX the traditional way (but is visible to ASDF for dependencies), like so: (asdf:defsystem :mcclim-clx-compat) (defmethod asdf:perform ((o asdf:load-op) (c (eql (asdf:find-system :mcclim-clx-compat)))) #+acl (require :clx)) This could also help with the (require "carbon") requirement for the beagle backend. What do you think? -- Andreas Fuchs, , asf at jabber.at, antifuchs From rpgoldman at real-time.com Tue Mar 8 15:02:23 2005 From: rpgoldman at real-time.com (rpgoldman at real-time.com) Date: Tue, 8 Mar 2005 09:02:23 -0600 Subject: [mcclim-devel] problem building McCLIM mothering on Linux ACL 6.2 In-Reply-To: <87vf82lfqv.wl%asf@boinkor.net> References: <16941.2566.558238.843531@gargle.gargle.HOWL> <16941.5255.645335.781779@gargle.gargle.HOWL> <87vf82lfqv.wl%asf@boinkor.net> Message-ID: <16941.48767.179840.333960@gargle.gargle.HOWL> >>>>> "asf" == Andreas Fuchs writes: asf> Today, wrote: >> I have been able to build the clim-clx-user system (which loads >> clim) using the defsystem that comes in system.lisp for mcclim. So >> it seems like the package problem I just reported is somehow in >> mcclim.asd, but not in system.lisp. >> >> If I find out any more, I'll report. asf> Oh. I should have been more explicit about that in the INSTALL.ASDF, asf> then. No, entirely my fault. I had looked at the installation instructions some time ago, and assumed (incorrectly) that I knew what to do. I'm not sure I would have recalled that ACL needs (require :CLX), anyway. The only other graphics toolkit I use is garnet and I hacked in the require there myself :-) asf> On ACL6.2, you need to (require :clx) (as step 2 says) before you asf> (asdf:oos 'asdf:load-op :mcclim). Unfortunately, CLX doesn't come with asf> an ASDF system on ACL. asf> Perhaps we should make a clx-compat system that pulls in CLX the asf> traditional way (but is visible to ASDF for dependencies), like so: asf> (asdf:defsystem :mcclim-clx-compat) asf> (defmethod asdf:perform ((o asdf:load-op) (c (eql (asdf:find-system :mcclim-clx-compat)))) asf> #+acl (require :clx)) asf> This could also help with the (require "carbon") requirement for the asf> beagle backend. What do you think? Doesn't this still have the problem that ASDF has no way of determining which back-end you want, so that for example, one can try to load one of the applications and end up with no back-end at all? Would it be possible to make a :clim-with-backend system that would have a load-op method that would simply ask the user what backend s/he would prefer (and presumably offer a reasonable default by platform)? Then we could have the clim applications require :clim-with-backend, rather than just :clim. I confess that I have not the foggiest idea what this half-baked idea would do to ASDF's dependency tracing. Best, R From amoroso at mclink.it Tue Mar 8 16:18:02 2005 From: amoroso at mclink.it (Paolo Amoroso) Date: Tue, 08 Mar 2005 17:18:02 +0100 Subject: [mcclim-devel] Copying text to clipboard loops displaying messages to Konsole References: <87650d111r.fsf@plato.moon.paoloamoroso.it> <87vf83xvs3.fsf@plato.moon.paoloamoroso.it> <87hdjnxskt.fsf@plato.moon.paoloamoroso.it> <87k6oj45vp.fsf@plato.moon.paoloamoroso.it> Message-ID: <87acpe9kn9.fsf@plato.moon.paoloamoroso.it> Christophe Rhodes writes: > ... but "KLIPPER", probably some bizarre KDE thing, is now getting in > the way. OK, but in this test you're not getting any length-errors. According to the KDE documentation: Klipper is the KDE clipboard utility. It stores clipboard history, and allows you to link clipboard contents to application actions. If I disable it and try pasting text from the CLIM Listener to a Konsole, the text is pasted correctly and I only get these 2 messages (no longer an infinite loop): # is an instance of type CLX-SELECTION-REQUEST-EVENT it has the following slots: TIMESTAMP: 4226073 SHEET: # REGION: SELECTION: :PRIMARY REQUESTOR: # TARGET: :TARGETS PROPERTY: :_QT_SELECTION ;; Warning, unhandled type "TARGETS". Trying to send as UTF8_STRING. ;; clim-clx::send-selection - Requested target TARGETS, sent UTF8_STRING to property NIL. # is an instance of type CLX-SELECTION-REQUEST-EVENT it has the following slots: TIMESTAMP: 4226073 SHEET: # REGION: SELECTION: :PRIMARY REQUESTOR: # TARGET: :COMPOUND_TEXT PROPERTY: :_QT_SELECTION ;; clim-clx::send-selection - Requested target COMPOUND_TEXT, sent COMPOUND_TEXT to property _QT_SELECTION. So, it looks like this is a KDE thing. No big deal, once I am aware of this. > I don't really know what to suggest; I'd probably ask the developers I don't use Klipper much anyway, so I'll probably keep it disabled. Thanks, Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From sketerpot at gmail.com Wed Mar 9 22:22:27 2005 From: sketerpot at gmail.com (Peter Scott) Date: Wed, 9 Mar 2005 15:22:27 -0700 Subject: [mcclim-devel] Proper place for inspector documentation Message-ID: <7e267a92050309142258160255@mail.gmail.com> 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 From strandh at labri.fr Thu Mar 10 04:11:55 2005 From: strandh at labri.fr (Robert Strandh) Date: Thu, 10 Mar 2005 05:11:55 +0100 Subject: [mcclim-devel] Proper place for inspector documentation In-Reply-To: <7e267a92050309142258160255@mail.gmail.com> References: <7e267a92050309142258160255@mail.gmail.com> Message-ID: <16943.51467.37609.933838@serveur5.labri.fr> Peter Scott writes: > 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? I would vote for part 3 for now, and then, if applications require too much documentation, to rip it out and make a separate manual. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- From gilham at csl.sri.com Thu Mar 10 00:24:18 2005 From: gilham at csl.sri.com (Fred Gilham) Date: Wed, 09 Mar 2005 16:24:18 -0800 Subject: [mcclim-devel] Scigraph Message-ID: <200503100024.j2A0OIvI006216@snapdragon.csl.sri.com> Hi, Here's a scigraph.asd file to allow easy building of Scigraph. It seems like it almost (where almost = about 95%) works. Great work by everyone. Put this file in mcclim/Apps/Scigraph and do the usual: (asdf:oos 'asdf:load-op :scigraph-system) ;;; -*- Mode: Lisp; Syntax: Common-lisp; Package: Common-Lisp-User -*- (in-package :common-lisp-user) (asdf:defsystem scigraph-system :serial t :components ((:module "dwim" :serial t :components ((:file "package") (:file "feature-case") (:file "macros") (:file "tv") (:file "draw") (:file "present") (:file "extensions") (:file "wholine") (:file "export"))) (:module "scigraph" :serial t :components ((:file "package") (:file "copy") (:file "dump") (:file "duplicate") (:file "random") (:file "menu-tools") (:file "basic-classes") (:file "draw") (:file "mouse") (:file "color" ) (:file "basic-graph") (:file "graph-mixins") (:file "axis") (:file "moving-object") (:file "symbol" ) (:file "graph-data") (:file "legend" ) (:file "graph-classes") (:file "present" ) (:file "annotations") (:file "annotated-graph") (:file "contour" ) (:file "equation") (:file "popup-accept") (:file "popup-accept-methods") (:file "duplicate-methods" ) (:file "frame" ) (:file "export" ) (:file "demo-frame"))))) -- Fred Gilham gilham at csl.sri.com REPRODUCTIVE RIGHTS: the right not to reproduce, no matter what else you do. PLANNED PARENTHOOD: an organization that helps you plan to avoid becoming a parent. From duncan at robotcat.demon.co.uk Thu Mar 10 21:33:39 2005 From: duncan at robotcat.demon.co.uk (Duncan Rose) Date: Thu, 10 Mar 2005 21:33:39 +0000 Subject: [mcclim-devel] Another Beagle %set-port-keyboard-focus 'patch' Message-ID: <115D4796-91AC-11D9-B537-000A9577B8A2@robotcat.demon.co.uk> 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 From mikemac at mikemac.com Fri Mar 11 03:39:46 2005 From: mikemac at mikemac.com (Mike McDonald) Date: Thu, 10 Mar 2005 20:39:46 -0700 Subject: [mcclim-devel] Another Beagle %set-port-keyboard-focus 'patch' In-Reply-To: Your message of "Thu, 10 Mar 2005 21:33:39 GMT." <115D4796-91AC-11D9-B537-000A9577B8A2@robotcat.demon.co.uk> Message-ID: <200503110339.j2B3dkL01630@saturn.mikemac.com> >To: mcclim-devel at common-lisp.net >Date: Thu, 10 Mar 2005 21:33:39 +0000 >From: Duncan Rose > > >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 Yes. Mike McDonald mikemac at mikemac.com From csr21 at cam.ac.uk Fri Mar 11 16:02:30 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Fri, 11 Mar 2005 16:02:30 +0000 Subject: [mcclim-devel] Copying text to clipboard loops displaying messages to Konsole In-Reply-To: <87acpe9kn9.fsf@plato.moon.paoloamoroso.it> (Paolo Amoroso's message of "Tue, 08 Mar 2005 17:18:02 +0100") References: <87650d111r.fsf@plato.moon.paoloamoroso.it> <87vf83xvs3.fsf@plato.moon.paoloamoroso.it> <87hdjnxskt.fsf@plato.moon.paoloamoroso.it> <87k6oj45vp.fsf@plato.moon.paoloamoroso.it> <87acpe9kn9.fsf@plato.moon.paoloamoroso.it> Message-ID: Paolo Amoroso writes: > Christophe Rhodes writes: > >> I don't really know what to suggest; I'd probably ask the developers > > I don't use Klipper much anyway, so I'll probably keep it disabled. Hi, Paolo. Could you try pasting with Klipper enabled and with the attached patch? (I spent some time with the ICCCM, and some more time debugging my use of CLX, but I /think/ the attached now behaves at least partly correctly). [ Andy, if you're listening in: there have been several issues involved here: Klipper is entitled per ICCCM to assume that we implement the :TARGETS and :TIMESTAMP selection targets. More to follow on the CLX lists. ] -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: foo.diff URL: -------------- next part -------------- Cheers, Christophe From amoroso at mclink.it Fri Mar 11 16:56:52 2005 From: amoroso at mclink.it (Paolo Amoroso) Date: Fri, 11 Mar 2005 17:56:52 +0100 Subject: [mcclim-devel] Copying text to clipboard loops displaying messages to Konsole References: <87650d111r.fsf@plato.moon.paoloamoroso.it> <87vf83xvs3.fsf@plato.moon.paoloamoroso.it> <87hdjnxskt.fsf@plato.moon.paoloamoroso.it> <87k6oj45vp.fsf@plato.moon.paoloamoroso.it> <87acpe9kn9.fsf@plato.moon.paoloamoroso.it> Message-ID: <873bv22ka3.fsf@plato.moon.paoloamoroso.it> Christophe Rhodes writes: > Hi, Paolo. > > Could you try pasting with Klipper enabled and with the attached > patch? (I spent some time with the ICCCM, and some more time Sure. Now, when I copy from the CLIM Listener and paste to a Konsole pane, the text is pasted correctly, and a stream of messages like the ones included below are displayed until I quit the listener. My current setup is: CMUCL Snapshot 2005-03, latest McCLIM CVS sources with your patch applied. Paolo ----------------------------------------------------------------------- # is an instance of type CLX-SELECTION-REQUEST-EVENT it has the following slots: TIMESTAMP: 1328099 SHEET: # REGION: SELECTION: :PRIMARY REQUESTOR: # TARGET: :COMPOUND_TEXT PROPERTY: :_QT_SELECTION ;; clim-clx::send-selection - Requested target COMPOUND_TEXT, sent COMPOUND_TEXT to property _QT_SELECTION. # is an instance of type CLX-SELECTION-REQUEST-EVENT it has the following slots: TIMESTAMP: 1328099 SHEET: # REGION: SELECTION: :PRIMARY REQUESTOR: # TARGET: :STRING PROPERTY: :_QT_SELECTION ;; clim-clx::send-selection - Requested target STRING, sent STRING to property _QT_SELECTION. # is an instance of type CLX-SELECTION-REQUEST-EVENT it has the following slots: TIMESTAMP: 1329099 SHEET: # REGION: SELECTION: :PRIMARY REQUESTOR: # TARGET: :TIMESTAMP PROPERTY: :KLIPPER ;; clim-clx::send-selection - Requested target TIMESTAMP, sent TIMESTAMP to property KLIPPER. ----------------------------------------------------------------------- -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From csr21 at cam.ac.uk Fri Mar 11 17:15:10 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Fri, 11 Mar 2005 17:15:10 +0000 Subject: [mcclim-devel] Copying text to clipboard loops displaying messages to Konsole In-Reply-To: <873bv22ka3.fsf@plato.moon.paoloamoroso.it> (Paolo Amoroso's message of "Fri, 11 Mar 2005 17:56:52 +0100") References: <87650d111r.fsf@plato.moon.paoloamoroso.it> <87vf83xvs3.fsf@plato.moon.paoloamoroso.it> <87hdjnxskt.fsf@plato.moon.paoloamoroso.it> <87k6oj45vp.fsf@plato.moon.paoloamoroso.it> <87acpe9kn9.fsf@plato.moon.paoloamoroso.it> <873bv22ka3.fsf@plato.moon.paoloamoroso.it> Message-ID: Paolo Amoroso writes: > Sure. Now, when I copy from the CLIM Listener and paste to a Konsole > pane, the text is pasted correctly, and a stream of messages like the > ones included below are displayed until I quit the listener. OK. So I think the clipboard-handling code is now correct, and to make the user experience better one would simply not print the debugging cruft to *trace-output*. Anyone care to review the latest patch I sent? Cheers, Christophe From pdm at zamazal.org Sat Mar 12 10:03:45 2005 From: pdm at zamazal.org (Milan Zamazal) Date: Sat, 12 Mar 2005 11:03:45 +0100 Subject: [mcclim-devel] Please remove the debian/ directory Message-ID: <8764zxw58e.fsf@zamazal.org> 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 From amoroso at mclink.it Wed Mar 16 13:07:26 2005 From: amoroso at mclink.it (Paolo Amoroso) Date: Wed, 16 Mar 2005 14:07:26 +0100 Subject: [mcclim-devel] Adding vertical orientation to Listener's graphing commands Message-ID: <874qfbeo35.fsf@plato.moon.paoloamoroso.it> 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 From chri0665 at uidaho.edu Mon Mar 21 00:40:54 2005 From: chri0665 at uidaho.edu (David Christiansen) Date: Sun, 20 Mar 2005 16:40:54 -0800 Subject: [mcclim-devel] Possible bug Message-ID: <023482c370c9711871778f3de54536b2@uidaho.edu> 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 ;; From ahefner at gmail.com Mon Mar 21 02:39:16 2005 From: ahefner at gmail.com (Andy Hefner) Date: Sun, 20 Mar 2005 21:39:16 -0500 Subject: [mcclim-devel] Possible bug In-Reply-To: <023482c370c9711871778f3de54536b2@uidaho.edu> References: <023482c370c9711871778f3de54536b2@uidaho.edu> Message-ID: <31ffd3c40503201839de8bd80@mail.gmail.com> Strangely enough the vendor CLIMs call these keywords :some-of and :one-of, despite what the spec says. My intent was to support both, not sure why this isnt't working.. On Sun, 20 Mar 2005 16:40:54 -0800, David Christiansen wrote: > 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! From chri0665 at uidaho.edu Mon Mar 21 06:40:27 2005 From: chri0665 at uidaho.edu (David Christiansen) Date: Sun, 20 Mar 2005 22:40:27 -0800 Subject: [mcclim-devel] Possible bug In-Reply-To: <31ffd3c40503201839de8bd80@mail.gmail.com> References: <023482c370c9711871778f3de54536b2@uidaho.edu> <31ffd3c40503201839de8bd80@mail.gmail.com> Message-ID: <13cd3d9980a465cc0a1630d77cccfec6@uidaho.edu> I've tracked down what seems to be the spot.... The defclass for meta-list-pane contains the following slot specifier: (mode :initarg :mode :initform :exclusive :reader list-pane-mode :type (member :one-of :some-of)) Perhaps the :type should read (member :one-of :some-of :exclusive :nonexclusive) instead? It looks like list-pane-exclusive-p already handles the options listed in the spec. ;;------------------------------------------------------------------ ;; -David Christiansen ;; On 20 Mar, 2005, at 18:39, Andy Hefner wrote: > Strangely enough the vendor CLIMs call these keywords :some-of and > :one-of, despite what the spec says. My intent was to support both, > not sure why this isnt't working.. > > > > On Sun, 20 Mar 2005 16:40:54 -0800, David Christiansen > wrote: >> 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! > _______________________________________________ > mcclim-devel mailing list > mcclim-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel > From ahefner at gmail.com Mon Mar 21 12:48:41 2005 From: ahefner at gmail.com (Andy Hefner) Date: Mon, 21 Mar 2005 07:48:41 -0500 Subject: [mcclim-devel] Possible bug In-Reply-To: <13cd3d9980a465cc0a1630d77cccfec6@uidaho.edu> References: <023482c370c9711871778f3de54536b2@uidaho.edu> <31ffd3c40503201839de8bd80@mail.gmail.com> <13cd3d9980a465cc0a1630d77cccfec6@uidaho.edu> Message-ID: <31ffd3c40503210448dc9c55b@mail.gmail.com> Ah, right. I guess the lisps I use don't check that type declaration, so I never noticed. Nice work. On Sun, 20 Mar 2005 22:40:27 -0800, David Christiansen wrote: > I've tracked down what seems to be the spot.... > The defclass for meta-list-pane contains the following slot specifier: > (mode :initarg :mode > :initform :exclusive > :reader list-pane-mode > :type (member :one-of :some-of)) > Perhaps the :type should read (member :one-of :some-of :exclusive > :nonexclusive) instead? > It looks like list-pane-exclusive-p already handles the options listed > in the spec. > > ;;------------------------------------------------------------------ > ;; -David Christiansen > ;; > > > On 20 Mar, 2005, at 18:39, Andy Hefner wrote: > > > Strangely enough the vendor CLIMs call these keywords :some-of and > > :one-of, despite what the spec says. My intent was to support both, > > not sure why this isnt't working.. > > > > > > > > On Sun, 20 Mar 2005 16:40:54 -0800, David Christiansen > > wrote: > >> 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! > > _______________________________________________ > > mcclim-devel mailing list > > mcclim-devel at common-lisp.net > > http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel > > > > _______________________________________________ > mcclim-devel mailing list > mcclim-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel > From ajuckel at gmail.com Tue Mar 22 12:58:43 2005 From: ajuckel at gmail.com (Anthony Juckel) Date: Tue, 22 Mar 2005 06:58:43 -0600 Subject: [mcclim-devel] Gadgets in accepting-values (again) Message-ID: 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 From csr21 at cam.ac.uk Tue Mar 22 12:49:04 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Tue, 22 Mar 2005 12:49:04 +0000 Subject: [mcclim-devel] Copying text to clipboard loops displaying messages to Konsole In-Reply-To: <873bv22ka3.fsf@plato.moon.paoloamoroso.it> (Paolo Amoroso's message of "Fri, 11 Mar 2005 17:56:52 +0100") References: <87650d111r.fsf@plato.moon.paoloamoroso.it> <87vf83xvs3.fsf@plato.moon.paoloamoroso.it> <87hdjnxskt.fsf@plato.moon.paoloamoroso.it> <87k6oj45vp.fsf@plato.moon.paoloamoroso.it> <87acpe9kn9.fsf@plato.moon.paoloamoroso.it> <873bv22ka3.fsf@plato.moon.paoloamoroso.it> Message-ID: Paolo Amoroso writes: > Christophe Rhodes writes: > >> Hi, Paolo. >> >> Could you try pasting with Klipper enabled and with the attached >> patch? (I spent some time with the ICCCM, and some more time > > Sure. Now, when I copy from the CLIM Listener and paste to a Konsole > pane, the text is pasted correctly, and a stream of messages like the > ones included below are displayed until I quit the listener. > > My current setup is: CMUCL Snapshot 2005-03, latest McCLIM CVS sources > with your patch applied. Right. Reading around the web indicates that Klipper is not completely alone in its strategy of polling the selection owner for the timestamp of its selection ownership to see if anything has changed. I've therefore committed more-or-less what I sent, along with something which disables logging these events to the console. I hope that I haven't broken anything in the process. In the meantime, here are some things which don't currently work (they didn't before the patch either): * pasting high-latin characters into the listener. (pasting them out from the listener is fine). This is possibly because the paste is implemented in terms of generating key-press-events -- is there a mismatch somewhere between what is a key press and what is a character? * selecting user-typed input to the listener. I think this is because such user-typed input has no associated output records; getting this right might be tricky. * (relatedly) pasting from Climacs doesn't work as expected, because Space and Tab characters in the buffer don't get associated output records. Presumably what needs to happen here is that Climacs needs to implement its own methods for these protocol functions. Cheers, Christophe From tl at di.fc.ul.pt Tue Mar 22 15:49:42 2005 From: tl at di.fc.ul.pt (Thibault Langlois) Date: Tue, 22 Mar 2005 15:49:42 +0000 (UTC) Subject: [mcclim-devel] Drawing graphs & scaling Message-ID: 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 From amoroso at mclink.it Tue Mar 22 16:11:24 2005 From: amoroso at mclink.it (Paolo Amoroso) Date: Tue, 22 Mar 2005 17:11:24 +0100 Subject: [mcclim-devel] Copying text to clipboard loops displaying messages to Konsole In-Reply-To: (Christophe Rhodes's message of "Tue, 22 Mar 2005 12:49:04 +0000") References: <87650d111r.fsf@plato.moon.paoloamoroso.it> <87vf83xvs3.fsf@plato.moon.paoloamoroso.it> <87hdjnxskt.fsf@plato.moon.paoloamoroso.it> <87k6oj45vp.fsf@plato.moon.paoloamoroso.it> <87acpe9kn9.fsf@plato.moon.paoloamoroso.it> <873bv22ka3.fsf@plato.moon.paoloamoroso.it> Message-ID: <87fyynslsj.fsf@plato.moon.paoloamoroso.it> Christophe Rhodes writes: > Right. Reading around the web indicates that Klipper is not > completely alone in its strategy of polling the selection owner for > the timestamp of its selection ownership to see if anything has > changed. > > I've therefore committed more-or-less what I sent, along with > something which disables logging these events to the console. I hope > that I haven't broken anything in the process. Text paste seems to be working fine with Klipper now. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From amoroso at mclink.it Tue Mar 22 16:39:36 2005 From: amoroso at mclink.it (Paolo Amoroso) Date: Tue, 22 Mar 2005 17:39:36 +0100 Subject: [mcclim-devel] Drawing graphs & scaling In-Reply-To: (Thibault Langlois's message of "Tue, 22 Mar 2005 15:49:42 +0000 (UTC)") References: Message-ID: <877jjzskhj.fsf@plato.moon.paoloamoroso.it> Thibault Langlois writes: > I would like to be able to scale a graph: [...] > 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. I run across this limitation some time ago: Scaled class graphs with McCLIM's listener http://www.paoloamoroso.it/log/040819.html and ended up not drawing the nodes. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From csr21 at cam.ac.uk Wed Mar 23 09:22:00 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Wed, 23 Mar 2005 09:22:00 +0000 Subject: [mcclim-devel] Freetype bindings Message-ID: 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: . Cheers, Christophe From tl at di.fc.ul.pt Thu Mar 24 09:40:35 2005 From: tl at di.fc.ul.pt (Thibault Langlois) Date: Thu, 24 Mar 2005 09:40:35 +0000 (UTC) Subject: [mcclim-devel] Re: Drawing graphs & scaling References: <877jjzskhj.fsf@plato.moon.paoloamoroso.it> Message-ID: Paolo Amoroso mclink.it> writes: > > I run across this limitation some time ago: > > Scaled class graphs with McCLIM's listener > http://www.paoloamoroso.it/log/040819.html > > and ended up not drawing the nodes. > > Paolo I check regularly your blog but I missed this one ... *Maybe* the problem occurs because different transformations are used for drawing nodes and arcs. Then scaling changes distances in a different way for nodes and arcs. Thibault From amoroso at mclink.it Thu Mar 24 13:22:49 2005 From: amoroso at mclink.it (Paolo Amoroso) Date: Thu, 24 Mar 2005 14:22:49 +0100 Subject: [mcclim-devel] Re: Drawing graphs & scaling In-Reply-To: (Thibault Langlois's message of "Thu, 24 Mar 2005 09:40:35 +0000 (UTC)") References: <877jjzskhj.fsf@plato.moon.paoloamoroso.it> Message-ID: <873bul9o0m.fsf@plato.moon.paoloamoroso.it> Thibault Langlois writes: > *Maybe* the problem occurs because different transformations > are used for drawing nodes and arcs. Then scaling changes > distances in a different way for nodes and arcs. I'm not sure whether text scaling is supported. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From duncan at robotcat.demon.co.uk Fri Mar 25 22:49:59 2005 From: duncan at robotcat.demon.co.uk (Duncan Rose) Date: Fri, 25 Mar 2005 22:49:59 +0000 Subject: [mcclim-devel] Flipping sheet coords Message-ID: <374CB0A0-9D80-11D9-BCE0-000A9577B8A2@robotcat.demon.co.uk> 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 From chri0665 at uidaho.edu Sun Mar 27 00:59:30 2005 From: chri0665 at uidaho.edu (David Christiansen) Date: Sat, 26 Mar 2005 16:59:30 -0800 Subject: [mcclim-devel] Sample code Message-ID: 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 ;; From pdm at zamazal.org Wed Mar 30 10:52:39 2005 From: pdm at zamazal.org (Milan Zamazal) Date: Wed, 30 Mar 2005 12:52:39 +0200 Subject: [mcclim-devel] Image drawing Message-ID: <87hditmmmg.fsf@blackbird.zamazal.org> 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! From boris at math.ubc.ca Wed Mar 30 20:10:16 2005 From: boris at math.ubc.ca (Boris Tschirschwitz) Date: Wed, 30 Mar 2005 12:10:16 -0800 Subject: [mcclim-devel] sb-bsd-sockets Message-ID: <424B07A8.3060500@math.ubc.ca> 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. From csr21 at cam.ac.uk Wed Mar 30 20:32:20 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Wed, 30 Mar 2005 21:32:20 +0100 Subject: [mcclim-devel] sb-bsd-sockets In-Reply-To: <424B07A8.3060500@math.ubc.ca> (Boris Tschirschwitz's message of "Wed, 30 Mar 2005 12:10:16 -0800") References: <424B07A8.3060500@math.ubc.ca> Message-ID: Boris Tschirschwitz writes: > 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. I believe that the recommended way to load telent-clx -- which is what I guess you're using -- with openmcl is not the asd file but something which is distributed with openmcl's clx distribution only. (That is, you should probably consult with the openmcl distributors as to how they create and load their own distributions; it is possible that they don't distribute an unmodified telent-clx tree). In particular, it appears that there are no openmcl-specific implementations of necessary functions in the telent clx tree as distributed; you should really consult your implementation's documentation and support channel, I guess. (Maybe an openmcl-using mcclim hacker can advise?) Cheers, Christophe From rudi at constantly.at Wed Mar 30 21:01:51 2005 From: rudi at constantly.at (Rudi Schlatte) Date: Wed, 30 Mar 2005 23:01:51 +0200 Subject: [mcclim-devel] sb-bsd-sockets In-Reply-To: References: <424B07A8.3060500@math.ubc.ca> Message-ID: <573543b4cb49118fb75735137037e316@constantly.at> On 30. M?r 2005, at 22:32, Christophe Rhodes wrote: > In particular, it appears that there are no openmcl-specific > implementations of necessary functions in the telent clx tree as > distributed; you should really consult your implementation's > documentation and support channel, I guess. (Maybe an openmcl-using > mcclim hacker can advise?) > http://www.cliki.net/CLX gives the following location for an openmcl-compatible clx: ftp://clozure.com/pub/CLX/ -- that's what I use when running openmcl. Rudi -------------- next part -------------- A non-text attachment was scrubbed... Name: PGP.sig Type: application/pgp-signature Size: 186 bytes Desc: This is a digitally signed message part URL: From moore at bricoworks.com Wed Mar 30 21:11:56 2005 From: moore at bricoworks.com (Timothy Moore) Date: Wed, 30 Mar 2005 23:11:56 +0200 Subject: [mcclim-devel] sb-bsd-sockets In-Reply-To: References: <424B07A8.3060500@math.ubc.ca> Message-ID: On Mar 30, 2005, at 10:32 PM, Christophe Rhodes wrote: > Boris Tschirschwitz writes: > >> 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. > > I believe that the recommended way to load telent-clx -- which is what > I guess you're using -- with openmcl is not the asd file but something > which is distributed with openmcl's clx distribution only. (That is, Actually, the recommended clx for OpenMCL is clx-040210.tar.gz from clozure.com's ftp area. > documentation and support channel, I guess. (Maybe an openmcl-using > mcclim hacker can advise?) > Hope that helps, Tim From duncan at robotcat.demon.co.uk Thu Mar 31 10:33:15 2005 From: duncan at robotcat.demon.co.uk (Duncan Rose) Date: Thu, 31 Mar 2005 11:33:15 +0100 Subject: [mcclim-devel] sb-bsd-sockets In-Reply-To: Message-ID: <4A5ED233-A1D0-11D9-9F80-000A9577B8A2@robotcat.demon.co.uk> On Wednesday, March 30, 2005, at 10:11 PM, Timothy Moore wrote: > > On Mar 30, 2005, at 10:32 PM, Christophe Rhodes wrote: > >> Boris Tschirschwitz writes: >> >>> 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. >> >> I believe that the recommended way to load telent-clx -- which is what >> I guess you're using -- with openmcl is not the asd file but something >> which is distributed with openmcl's clx distribution only. (That is, > Actually, the recommended clx for OpenMCL is clx-040210.tar.gz from > clozure.com's ftp area. There shouldn't be a dependency on CLX when running Beagle; there wasn't in the McCLIM sources from a week or so back and I haven't noticed anything changing (not seen any CVS commit notifications). It's possible I set something up a while ago in my system (I run McCLIM with both CLX + Beagle back ends, from time to time) so that the necessary CLX parts are loaded by default in my system but I don't remember doing so if I did. Which file(s) are complaining at compilation time? -Duncan From csr21 at cam.ac.uk Thu Mar 31 14:41:52 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Thu, 31 Mar 2005 15:41:52 +0100 Subject: [mcclim-devel] Better defaults for CLX backend Message-ID: 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. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: clim-clx.diff URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: fix-clx.lisp URL: -------------- next part -------------- Cheers, Christophe