From o.finnendahl at inm.mh-freiburg.de Thu Dec 2 21:08:24 2010 From: o.finnendahl at inm.mh-freiburg.de (Orm Finnendahl) Date: Thu, 2 Dec 2010 22:08:24 +0100 Subject: [mcclim-devel] some questions Message-ID: <20101202210824.GC12507@varese> Hi all, I posted here before quite some time ago but had to interrupt my work. Now I reserved time to be able to concentrate on the implementation in mcclim. I'm trying to program a frontend for the definition of specialized scores of a self-designed system for live-electronics in contemporary music (the backend is done in pure data, but most of the hard work is already getting done in lisp). One part of the frontend is supposed to be similar to a vector graphics program, enabling the creation of straight horizontal colored lines and the nested grouping of those lines. The user should be able to move those lines/groups around, stretch them, clip them and do some other basic editing operations such as copying, insertion and deletion (for an idea, how those graphics look like, you can have a look at: http://icem-www.folkwang-hochschule.de/~finnendahl/download/sandgetriebe-ausschnitt.gif ). I used the clim-fig demo application as a point of departure and try to build around this to get a better grasp of the concepts before restarting from scratch. Here are my questions: 1. highlighting: I successfully hooked into the highlighting function. All lines are a presentation using output-recording and highlight on mouse over. I would like to be able to change the highlighting context (with some keystroke) so that e.g. not a single line is highlighted, but all lines of the group, it is contained in. I could do that manually within the highlighting routine by traversing the parent tree of the highlighted object, but I wonder whether it could be possible to hierarchically nest the presentation type classes (and their objects) in a way that the presentations are sensitive to the current context and highlight accordingly without having to replay them on change of context. 2. selection: clicking on a presentation (or a group of presentations) should select that group by displaying a dashed line around the smallest enclosing region of the selected objects and attaching a small square or icon to that square for resizing. If I got the concept correctly, the dashed line plus small square should be displayed as one or more presentations (e.g. of type "region"), which are sensitive to mouse gestures for moving or resizing. Should these presentations get appended to the output record? It seems a little awkward to always replay the whole output record if presentations are deselected. So I wonder how would be the canonical way to do it (I know about incremental redisply, but would it fit here)? 3. I didn't succeed in changing the command invoked on a left mouse-click on a canvas. It is initially defined with "define-presentation-to-command-translator" but I couldn't change the definition to invoke different comands depending on the state of the program. (Like in a drawing programm: when you change the tool in the toolbar, the mouse-click invokes a different command). As far as I understood, the command table is resposible for the bindings, but I didn't find the mechanism for changing the current commmand table. Any help or correction of my assumptions is greatly appreciated! Yours, Orm From james.ashley at gmail.com Fri Dec 3 03:25:23 2010 From: james.ashley at gmail.com (James Ashley) Date: Fri, 3 Dec 2010 03:25:23 +0000 Subject: [mcclim-devel] Trying to wrap my head around presentations Message-ID: I'm still just toying with ideas, and trying to wrap my brain around the basics. Right this second, just on a whim, I'm thinking of a character-builder for old-school AD&D. Something like a radio-button list where you choose either your race '(human elf half-elf dwarf halfling half-orc) or your class '(fighter magic-user cleric thief monk) and both lists depend on what you've chosen in the other. So you'd be able to select one in the list, and the other would indicate that certain options weren't available. But they aren't actually disabled...just discouraged. Choose a discouraged option, and the other list clears your choice. Maybe some options just aren't available, based on the way you've set your stats. >From what I'm reading so far, this is pretty much the way CLIM was designed. Am I on the right track, or am I still completely missing the point? Thanks, James From james.ashley at gmail.com Fri Dec 3 22:03:53 2010 From: james.ashley at gmail.com (James Ashley) Date: Fri, 3 Dec 2010 16:03:53 -0600 Subject: [mcclim-devel] The Manual Message-ID: I realize it's a work in progress, but it really deserves much more credit than it receives on the site. As far as an overview/introduction, it's probably the best I've run across so far. In section 3.7, "Displaying Data Structures," it gets rid of the previous version's :display-time nil parameter to the pane showing the output stream. Using the CVS version of McCLIM (from 2010-10-06) and 64-bit clozure CL release 1.5 (on linux) using the CLX backend, this shows the initial "NIL is not a number," but calling Parity after that doesn't seem to have any affect. I haven't begun to do anywhere near enough digging to really even to begin to guess where to start looking. I don't see anything that resembles this in the past few months worth of archives. Is this known and expected behavior? Can someone clueful point me in the general direction so I can take a stab at fixing the "problem" (maybe just that part of the manual's slightly out of date?) Thanks, James From o.finnendahl at inm.mh-freiburg.de Thu Dec 9 19:44:07 2010 From: o.finnendahl at inm.mh-freiburg.de (Orm Finnendahl) Date: Thu, 9 Dec 2010 20:44:07 +0100 Subject: [mcclim-devel] presentations as childs of specific output records Message-ID: <20101209194407.GA9816@varese> Hi, it seems to me appropriate to map a list of hierarchically grouped displayed line objects onto output records (using the same hierarchy). Those lines have to be sensitive to mouse gestures so I'd like to implement them as presentations. In my understanding this means I have to create and maintain the output-records manually in the code rather than leaving that up to mcclim, which seems to always append to the end of the output history. Is there a simple canonicle way to create an instance of a presentation and insert it as a child of a certain output record? I can find how to add an output record at a certain point, but the present method seems to work on a stream rather than a specific output record. -- Orm From strandh at labri.fr Fri Dec 10 05:44:04 2010 From: strandh at labri.fr (Robert Strandh) Date: Fri, 10 Dec 2010 06:44:04 +0100 Subject: [mcclim-devel] presentations as childs of specific output records In-Reply-To: <20101209194407.GA9816@varese> References: <20101209194407.GA9816@varese> Message-ID: <19713.48676.901232.868365@ssh1.labri.fr> Hello, Orm Finnendahl writes: > > it seems to me appropriate to map a list of hierarchically grouped > displayed line objects onto output records (using the same hierarchy). > Those lines have to be sensitive to mouse gestures so I'd like to > implement them as presentations. If I understand you correctly, you don't want each line to be highlighted, but just the group. In that case, wrap with-output-as-presentation around the drawing of the lines. Then you can choose whatever type you want for the presentation, and you can customize the highlighting. > In my understanding this means I have to create and maintain the > output-records manually in the code rather than leaving that up to > mcclim, which seems to always append to the end of the output history. It appends to the end of the current output record, but that is fact is important only to the display order. The records are conceptually drawn from bottom to top according to this order. But you can create hierarchies of output records and presentations by opening a new output records. One way of doing that is to use with-output-as-presentation. Does this solve your problem? -- 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 o.finnendahl at inm.mh-freiburg.de Fri Dec 10 11:04:56 2010 From: o.finnendahl at inm.mh-freiburg.de (Orm Finnendahl) Date: Fri, 10 Dec 2010 12:04:56 +0100 Subject: [mcclim-devel] presentations as childs of specific output records In-Reply-To: <19713.48676.901232.868365@ssh1.labri.fr> References: <20101209194407.GA9816@varese> <19713.48676.901232.868365@ssh1.labri.fr> Message-ID: <20101210110456.GA20644@varese> Hello Robert, Am Friday, den 10. December 2010 um 06:44:04 Uhr (+0100) schrieb Robert Strandh: > > If I understand you correctly, you don't want each line to be > highlighted, but just the group. that depends on the current focus. The main point in the application is to be able to change the focus from one single line to the group it is contained in (and to the group the groups are contained in and so forth). Those changes of focus are quite frequent and I try to avoid having to replay the whole drawing on focus change (that's why I try to maintain the output records and it's hierarchy directly). > It appends to the end of the current output record, but that is fact > is important only to the display order. The records are conceptually > drawn from bottom to top according to this order. But you can create > hierarchies of output records and presentations by opening a new > output records. One way of doing that is to use > with-output-as-presentation. I think it would solve my problem, but I haven't figured out, how to accomplish that in code. I know how to instantiate output records and insert them into the tree (using add-output-record), but I don't know how to attach presentations to them. Here is what I tried: I used with-output-as-presentation, giving it the (undocumented) :parent keyword, hoping it would add the presentation as a child of the given output record, but that gave an error: (defmethod display-quolines ((frame clim-quo) stream) (dolist (quoline *quolines*) (with-output-as-presentation (stream quoline 'quoline :parent (stream-current-output-record stream))))) The error: # already has a parent #. [Condition of type SIMPLE-ERROR] It would be great if someone could push me in the right direction. -- Orm From strandh at labri.fr Sat Dec 11 05:29:29 2010 From: strandh at labri.fr (Robert Strandh) Date: Sat, 11 Dec 2010 06:29:29 +0100 Subject: [mcclim-devel] presentations as childs of specific output records In-Reply-To: <20101210110456.GA20644@varese> References: <20101209194407.GA9816@varese> <19713.48676.901232.868365@ssh1.labri.fr> <20101210110456.GA20644@varese> Message-ID: <19715.3129.930684.310829@ssh1.labri.fr> Hello, Orm Finnendahl writes: > > > If I understand you correctly, you don't want each line to be > > highlighted, but just the group. > > that depends on the current focus. The main point in the application > is to be able to change the focus from one single line to the group it > is contained in (and to the group the groups are contained in and so > forth). Those changes of focus are quite frequent and I try to avoid > having to replay the whole drawing on focus change (that's why I try > to maintain the output records and it's hierarchy directly). Hmm, yes I see. The simplest solution to your problem is probably to use the simple form of incremental output, i.e., your code looks like it presents the entire view after each interaction, except that you have inserted updating-output nodes in strategic places so that the system will not modify output where it is not needed. This method allows you to present the view differently according to the focus, while still getting the advantage of not *really* presenting the entire thing each time. > > It appends to the end of the current output record, but that is fact > > is important only to the display order. The records are conceptually > > drawn from bottom to top according to this order. But you can create > > hierarchies of output records and presentations by opening a new > > output records. One way of doing that is to use > > with-output-as-presentation. > > I think it would solve my problem, but I haven't figured out, how to > accomplish that in code. I know how to instantiate output records and > insert them into the tree (using add-output-record), but I don't know > how to attach presentations to them. You don't attach presentations to output records. A presentation *is* an output record (a subclass of it). Take care, -- 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 o.finnendahl at inm.mh-freiburg.de Tue Dec 21 20:08:56 2010 From: o.finnendahl at inm.mh-freiburg.de (Orm Finnendahl) Date: Tue, 21 Dec 2010 21:08:56 +0100 Subject: [mcclim-devel] mouse wheel gesture? Message-ID: <20101221200856.GB27378@varese> Hi, thanks to your help, the first prototype of the apps behaviour is surfacing and clim's mechanisms are getting less and less obscure. I couldn't find documentation, whether mouse wheel movement is implemented as gesture in mcclim. In my app this would be very useful, but I could imagine, clim was invented long before mousewheels appeared. On a related topic I tried to define a keystroke to invoke a command if the mouse is over a presentation. This didn't seem to work directly (via define gesture-name and define-presentation-to-command-translator). I resorted to defining a global variable in the application frame to hold a highlighted presentation (or nil if nothing is highlighted) and use this as reference for a command invoked by a keystroke. To me this seems to be rather a workaround than a solution. In case I'm missing something I'd be grateful for comments. Nice holidays to all of you, Orm From rm at tuxteam.de Tue Dec 21 21:56:10 2010 From: rm at tuxteam.de (rm at tuxteam.de) Date: Tue, 21 Dec 2010 22:56:10 +0100 Subject: [mcclim-devel] mouse wheel gesture? In-Reply-To: <20101221200856.GB27378@varese> References: <20101221200856.GB27378@varese> Message-ID: <20101221215609.GC29826@seid-online.de> On Tue, Dec 21, 2010 at 09:08:56PM +0100, Orm Finnendahl wrote: > Hi, > > thanks to your help, the first prototype of the apps behaviour is > surfacing and clim's mechanisms are getting less and less obscure. > > I couldn't find documentation, whether mouse wheel movement is > implemented as gesture in mcclim. In my app this would be very useful, > but I could imagine, clim was invented long before mousewheels > appeared. Oh dear, no. There where wheel back in the old days. Mighty wheels of oak and iron, but wheels nevertheless :-) >From 'stream-input.lisp' in function 'realize-gesture-spec': .... (let ((real-device-name (case device-name (:left +pointer-left-button+) (:middle +pointer-middle-button+) (:right +pointer-right-button+) (:wheel-up +pointer-wheel-up+) (:wheel-down +pointer-wheel-down+) (t (error "~S is not a known button" device-name))))) ... Cheers and happy christmas RalfD > On a related topic I tried to define a keystroke to invoke a command > if the mouse is over a presentation. This didn't seem to work directly > (via define gesture-name and > define-presentation-to-command-translator). I resorted to defining a > global variable in the application frame to hold a highlighted > presentation (or nil if nothing is highlighted) and use this as > reference for a command invoked by a keystroke. To me this seems to be > rather a workaround than a solution. In case I'm missing something I'd > be grateful for comments. > > Nice holidays to all of you, > Orm > > _______________________________________________ > mcclim-devel mailing list > mcclim-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel From o.finnendahl at inm.mh-freiburg.de Wed Dec 22 10:24:25 2010 From: o.finnendahl at inm.mh-freiburg.de (Orm Finnendahl) Date: Wed, 22 Dec 2010 11:24:25 +0100 Subject: [mcclim-devel] mouse wheel gesture? In-Reply-To: <20101221215609.GC29826@seid-online.de> References: <20101221200856.GB27378@varese> <20101221215609.GC29826@seid-online.de> Message-ID: <20101222102425.GA30775@varese> hmm, can't make it work with the mouse wheel. This works: (define-gesture-name :up :pointer-button-press :middle) This doesn't work: (define-gesture-name :up :pointer-button-press :wheel-up) I also tried ":pointer-button" in place of "pointer-button-press". Is there any way to find out, whether sbcl/mcclim is getting the event at all and what it gets translated into? The mouse wheel works in other applications. -- Orm Am Tuesday, den 21. December 2010 um 22:56:10 Uhr (+0100) schrieb rm at tuxteam.de: > .... > (let ((real-device-name > (case device-name > (:left +pointer-left-button+) > (:middle +pointer-middle-button+) > (:right +pointer-right-button+) > (:wheel-up +pointer-wheel-up+) > (:wheel-down +pointer-wheel-down+) > (t (error "~S is not a known button" device-name))))) From rm at tuxteam.de Wed Dec 22 23:25:17 2010 From: rm at tuxteam.de (rm at tuxteam.de) Date: Thu, 23 Dec 2010 00:25:17 +0100 Subject: [mcclim-devel] mouse wheel gesture? In-Reply-To: <20101222102425.GA30775@varese> References: <20101221200856.GB27378@varese> <20101221215609.GC29826@seid-online.de> <20101222102425.GA30775@varese> Message-ID: <20101222232517.GA28628@seid-online.de> On Wed, Dec 22, 2010 at 11:24:25AM +0100, Orm Finnendahl wrote: > hmm, can't make it work with the mouse wheel. > > This works: > > (define-gesture-name :up :pointer-button-press :middle) > > This doesn't work: > > (define-gesture-name :up :pointer-button-press :wheel-up) > > I also tried ":pointer-button" in place of "pointer-button-press". Hmm, sorry, no wheel mouse here, so I can't test. But shouldn't that be (define-gesture-name :up :pointer-button-press (:wheel-up)) > Is there any way to find out, whether sbcl/mcclim is getting the event > at all and what it gets translated into? The mouse wheel works in > other applications. Well, the wheel buttons are used in panes.lisp (for scrolling), so maybe you could just test scrolling with the mouse wheel. Thinking of it: maybe your application pane inherits from mouse-wheel-scroll-mixin and somehow the scroll event gets eaten by that class' dispatch-event ... Cheers, RalfD BTW, send me your newest version, I can test with scroll-wheel tomorrow. > -- > Orm > > Am Tuesday, den 21. December 2010 um 22:56:10 Uhr (+0100) schrieb rm at tuxteam.de: > > .... > > (let ((real-device-name > > (case device-name > > (:left +pointer-left-button+) > > (:middle +pointer-middle-button+) > > (:right +pointer-right-button+) > > (:wheel-up +pointer-wheel-up+) > > (:wheel-down +pointer-wheel-down+) > > (t (error "~S is not a known button" device-name))))) > > _______________________________________________ > mcclim-devel mailing list > mcclim-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel From frank.goenninger at consequor.de Mon Dec 27 10:36:24 2010 From: frank.goenninger at consequor.de (=?iso-8859-1?Q?Frank_G=F6nninger?=) Date: Mon, 27 Dec 2010 11:36:24 +0100 Subject: [mcclim-devel] CLX backend or OpenGL backend with ClozureCL on OS X (also posted on c.l.l) Message-ID: <59DD52A0-420F-42CD-9090-69098963A2F8@consequor.de> Hi all: Being completely new to McCLIM and Clozure CL I tried running the sample apps from McCLIM doc's chapter 3. All fine with the Gtk Cairo backend, but no chance with the CLX or OpenGL backends. CLX itself works fine. Using Quicklisp I loaded the required packages: ? (ql:quickload "clx") To load "clx": Load 1 ASDF system: clx ; Loading "clx" ("clx") ? (ql:quickload "spatial-trees") To load "spatial-trees": Load 1 ASDF system: spatial-trees ; Loading "spatial-trees" ("spatial-trees") ? (ql:quickload "clim") To load "clim": Load 1 ASDF system: clim ; Loading "clim" .... ("clim") ;;; OK, so far. Now let's define CLX as the backend... ? (setq clim:*default-server-path* '(:clx)) (:CLX) ;;; Following the McCLIM's Chapter 3 "The First Application" I ;;; tried the sample app: ? (app::app-main) > Error: NIL is not of type (OR SYMBOL FUNCTION), and can't be FUNCALLed or APPLYed > While executing: CLIM:FIND-PORT, in process Listener(6). > Type cmd-. to abort, cmd-\ for a list of available restarts. > Type :? for other options. ;;; Hmpf ?!? Ok, CLX seems to be the problem. Backtrace shows: 1 > :b *(161D78B8) : 0 (FIND-PORT :SERVER-PATH (:CLX)) 265 (161D7930) : 1 (FIND-FRAME-MANAGER) 509 (161D7968) : 2 (FUNCALL #'#<#> #) 405 (161D7A40) : 3 (%%STANDARD-COMBINED-METHOD-DCODE (# #) 46378838) 693 (161D7AC0) : 4 (CALL-CHECK-REGS APP:APP-MAIN) 221 (161D7AF8) : 5 (TOPLEVEL-EVAL (APP:APP-MAIN) NIL) 701 (161D7B98) : 6 (READ-LOOP :INPUT-STREAM # :OUTPUT-STREAM # :BREAK-LEVEL 0 :PROMPT-FUNCTION #) 2269 (161D7DF0) : 7 (TOPLEVEL-LOOP) 101 (161D7E18) : 8 (FUNCALL #'#<(:INTERNAL CCL::MAKE-MCL-LISTENER-PROCESS)>) 741 (161D7EB8) : 9 (RUN-PROCESS-INITIAL-FORM # (#)) 677 (161D7F48) : 10 (FUNCALL #'#<(:INTERNAL (CCL::%PROCESS-PRESET-INTERNAL (PROCESS)))> # (#)) 389 (161D7F98) : 11 (FUNCALL #'#<(:INTERNAL CCL::THREAD-MAKE-STARTUP-FUNCTION)>) 301 1 > I'd have to dig deeper but maybe there's someone on here you already can point in the right direction ?!? THX! Best, Frank From rm at tuxteam.de Mon Dec 27 11:44:54 2010 From: rm at tuxteam.de (rm at tuxteam.de) Date: Mon, 27 Dec 2010 12:44:54 +0100 Subject: [mcclim-devel] CLX backend or OpenGL backend with ClozureCL on OS X (also posted on c.l.l) In-Reply-To: <59DD52A0-420F-42CD-9090-69098963A2F8@consequor.de> References: <59DD52A0-420F-42CD-9090-69098963A2F8@consequor.de> Message-ID: <20101227114454.GA2013@seid-online.de> On Mon, Dec 27, 2010 at 11:36:24AM +0100, Frank G?nninger wrote: > Hi all: > > Being completely new to McCLIM and Clozure CL I tried running the sample apps from McCLIM doc's chapter 3. All fine with the Gtk Cairo backend, but no chance with the CLX or OpenGL backends. CLX itself works fine. > > Using Quicklisp I loaded the required packages: > > ? (ql:quickload "clx") > To load "clx": > Load 1 ASDF system: > clx > ; Loading "clx" > > ("clx") > ? (ql:quickload "spatial-trees") > To load "spatial-trees": > Load 1 ASDF system: > spatial-trees > ; Loading "spatial-trees" > > ("spatial-trees") > ? (ql:quickload "clim") > To load "clim": > Load 1 ASDF system: > clim > ; Loading "clim" > .... > ("clim") Why do you perform such a selective load? So far I had better luck just doing a: (ql:quickload "mcclim") > ;;; OK, so far. Now let's define CLX as the backend... > > ? (setq clim:*default-server-path* '(:clx)) > > (:CLX) Without (ql:quickload "clim-clx") this won't work. CLX by itself only provides the API to communicate with a X server, the X backend is defined inclim-cxl. HTH Ralf Mattes > ;;; Following the McCLIM's Chapter 3 "The First Application" I > ;;; tried the sample app: > > ? (app::app-main) > > > Error: NIL is not of type (OR SYMBOL FUNCTION), and can't be FUNCALLed or APPLYed > > While executing: CLIM:FIND-PORT, in process Listener(6). > > Type cmd-. to abort, cmd-\ for a list of available restarts. > > Type :? for other options. > > ;;; Hmpf ?!? Ok, CLX seems to be the problem. Backtrace shows: > > 1 > :b > *(161D78B8) : 0 (FIND-PORT :SERVER-PATH (:CLX)) 265 > (161D7930) : 1 (FIND-FRAME-MANAGER) 509 > (161D7968) : 2 (FUNCALL #'#<#> #) 405 > (161D7A40) : 3 (%%STANDARD-COMBINED-METHOD-DCODE (# #) 46378838) 693 > (161D7AC0) : 4 (CALL-CHECK-REGS APP:APP-MAIN) 221 > (161D7AF8) : 5 (TOPLEVEL-EVAL (APP:APP-MAIN) NIL) 701 > (161D7B98) : 6 (READ-LOOP :INPUT-STREAM # :OUTPUT-STREAM # :BREAK-LEVEL 0 :PROMPT-FUNCTION #) 2269 > (161D7DF0) : 7 (TOPLEVEL-LOOP) 101 > (161D7E18) : 8 (FUNCALL #'#<(:INTERNAL CCL::MAKE-MCL-LISTENER-PROCESS)>) 741 > (161D7EB8) : 9 (RUN-PROCESS-INITIAL-FORM # (#)) 677 > (161D7F48) : 10 (FUNCALL #'#<(:INTERNAL (CCL::%PROCESS-PRESET-INTERNAL (PROCESS)))> # (#)) 389 > (161D7F98) : 11 (FUNCALL #'#<(:INTERNAL CCL::THREAD-MAKE-STARTUP-FUNCTION)>) 301 > 1 > > > I'd have to dig deeper but maybe there's someone on here you already can point in the right direction ?!? > > THX! > > Best, > Frank > > > > _______________________________________________ > mcclim-devel mailing list > mcclim-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel From frank.goenninger at consequor.de Mon Dec 27 11:40:13 2010 From: frank.goenninger at consequor.de (=?iso-8859-1?Q?Frank_G=F6nninger?=) Date: Mon, 27 Dec 2010 12:40:13 +0100 Subject: [mcclim-devel] CLX backend or OpenGL backend with ClozureCL on OS X (also posted on c.l.l) In-Reply-To: <20101227114454.GA2013@seid-online.de> References: <59DD52A0-420F-42CD-9090-69098963A2F8@consequor.de> <20101227114454.GA2013@seid-online.de> Message-ID: <67C50DC8-8D5A-4FB1-80A0-0153EF6ACD66@consequor.de> Am 27.12.2010 um 12:44 schrieb : > On Mon, Dec 27, 2010 at 11:36:24AM +0100, Frank G?nninger wrote: >> Hi all: >> >> Being completely new to McCLIM and Clozure CL I tried running the sample apps from McCLIM doc's chapter 3. All fine with the Gtk Cairo backend, but no chance with the CLX or OpenGL backends. CLX itself works fine. >> >> Using Quicklisp I loaded the required packages: >> >> ? (ql:quickload "clx") >> To load "clx": >> Load 1 ASDF system: >> clx >> ; Loading "clx" >> >> ("clx") >> ? (ql:quickload "spatial-trees") >> To load "spatial-trees": >> Load 1 ASDF system: >> spatial-trees >> ; Loading "spatial-trees" >> >> ("spatial-trees") >> ? (ql:quickload "clim") >> To load "clim": >> Load 1 ASDF system: >> clim >> ; Loading "clim" >> .... >> ("clim") > > Why do you perform such a selective load? So far I had better luck just > doing a: > > (ql:quickload "mcclim") Well, yes, no, because the docs told me to do so ... >> ;;; OK, so far. Now let's define CLX as the backend... >> >> ? (setq clim:*default-server-path* '(:clx)) >> >> (:CLX) > > Without (ql:quickload "clim-clx") this won't work. CLX by itself only > provides the API to communicate with a X server, the X backend is > defined inclim-cxl. > > > HTH Ralf Mattes It did! Thanks a bunch! Frank From james.ashley at gmail.com Mon Dec 27 14:59:40 2010 From: james.ashley at gmail.com (James Ashley) Date: Mon, 27 Dec 2010 08:59:40 -0600 Subject: [mcclim-devel] CLX backend or OpenGL backend with ClozureCL on OS X (also posted on c.l.l) In-Reply-To: <20101227114454.GA2013@seid-online.de> References: <59DD52A0-420F-42CD-9090-69098963A2F8@consequor.de> <20101227114454.GA2013@seid-online.de> Message-ID: On Mon, Dec 27, 2010 at 5:44 AM, wrote: > On Mon, Dec 27, 2010 at 11:36:24AM +0100, Frank G?nninger wrote: >> Hi all: >> Using Quicklisp I loaded the required packages: >> > > Why do you perform such a selective load? So far I had better luck just > doing a: > > ?(ql:quickload "mcclim") > > >> ;;; OK, so far. Now let's define CLX as the backend... >> >> ? (setq clim:*default-server-path* '(:clx)) >> >> (:CLX) > > Without (ql:quickload "clim-clx") this won't work. CLX by itself only > provides the API to communicate with a X server, the X backend is > defined inclim-cxl. So is this a bug in the ASD (not specifying some required package), a limitation of ASDF (can't specify that package x depends on variable y), or just a matter of understanding the tools (load the package you want, don't mess around with the dependencies)? Where's the best place to document this so it doesn't bite someone else in the future? (cliki seems like the most obvious to me, but what do I know?) Respectfully, James > HTH Ralf Mattes > >> ;;; Following the McCLIM's Chapter 3 "The First Application" I >> ;;; tried the sample app: >> >> ? ?(app::app-main) >> >> > Error: NIL is not of type (OR SYMBOL FUNCTION), and can't be FUNCALLed or APPLYed >> > While executing: CLIM:FIND-PORT, in process Listener(6). >> > Type cmd-. to abort, cmd-\ for a list of available restarts. >> > Type :? for other options. >> >> ;;; Hmpf ?!? Ok, CLX seems to be the problem. Backtrace shows: >> >> 1 > :b >> *(161D78B8) : 0 (FIND-PORT :SERVER-PATH (:CLX)) 265 >> ?(161D7930) : 1 (FIND-FRAME-MANAGER) 509 >> ?(161D7968) : 2 (FUNCALL #'#<#> #) 405 >> ?(161D7A40) : 3 (%%STANDARD-COMBINED-METHOD-DCODE (# #) 46378838) 693 >> ?(161D7AC0) : 4 (CALL-CHECK-REGS APP:APP-MAIN) 221 > >> ?(161D7AF8) : 5 (TOPLEVEL-EVAL (APP:APP-MAIN) NIL) 701 >> ?(161D7B98) : 6 (READ-LOOP :INPUT-STREAM # :OUTPUT-STREAM # :BREAK-LEVEL 0 :PROMPT-FUNCTION #) 2269 >> ?(161D7DF0) : 7 (TOPLEVEL-LOOP) 101 >> ?(161D7E18) : 8 (FUNCALL #'#<(:INTERNAL CCL::MAKE-MCL-LISTENER-PROCESS)>) 741 >> ?(161D7EB8) : 9 (RUN-PROCESS-INITIAL-FORM # (#)) 677 >> ?(161D7F48) : 10 (FUNCALL #'#<(:INTERNAL (CCL::%PROCESS-PRESET-INTERNAL (PROCESS)))> # (#)) 389 >> ?(161D7F98) : 11 (FUNCALL #'#<(:INTERNAL CCL::THREAD-MAKE-STARTUP-FUNCTION)>) 301 >> 1 > >> >> I'd have to dig deeper but maybe there's someone on here you already can point in the right direction ?!? >> >> THX! >> >> Best, >> ? Frank >> >> >> >> _______________________________________________ >> 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 rpgoldman at sift.info Mon Dec 27 15:07:48 2010 From: rpgoldman at sift.info (Robert Goldman) Date: Mon, 27 Dec 2010 09:07:48 -0600 Subject: [mcclim-devel] CLX backend or OpenGL backend with ClozureCL on OS X (also posted on c.l.l) In-Reply-To: References: <59DD52A0-420F-42CD-9090-69098963A2F8@consequor.de> <20101227114454.GA2013@seid-online.de> Message-ID: <4D18ABC4.3040503@sift.info> On 12/27/10 Dec 27 -8:59 AM, James Ashley wrote: > On Mon, Dec 27, 2010 at 5:44 AM, wrote: >> On Mon, Dec 27, 2010 at 11:36:24AM +0100, Frank G?nninger wrote: >>> Hi all: >>> Using Quicklisp I loaded the required packages: >>> >> >> Why do you perform such a selective load? So far I had better luck just >> doing a: >> >> (ql:quickload "mcclim") >> >> >>> ;;; OK, so far. Now let's define CLX as the backend... >>> >>> ? (setq clim:*default-server-path* '(:clx)) >>> >>> (:CLX) >> >> Without (ql:quickload "clim-clx") this won't work. CLX by itself only >> provides the API to communicate with a X server, the X backend is >> defined inclim-cxl. > > So is this a bug in the ASD (not specifying some required package), a > limitation of ASDF (can't specify that package x depends on variable > y), or just a matter of understanding the tools (load the package you > want, don't mess around with the dependencies)? > > Where's the best place to document this so it doesn't bite someone > else in the future? > > (cliki seems like the most obvious to me, but what do I know?) It's rarely done, but it is possible to pass initargs to ASDF load system. So, with a recent asdf (which doesn't require use of OOS), you could do something like (asdf:load-system :mcclim :backend :clx) ...if the mcclim maintainers would like to support that, probably using an :around method on asdf:operate. One could even support either defaulting or forcing the user to specify a backend. The latter might help this periodic confusion of novices. Best, r From rm at tuxteam.de Mon Dec 27 15:47:36 2010 From: rm at tuxteam.de (rm at tuxteam.de) Date: Mon, 27 Dec 2010 16:47:36 +0100 Subject: [mcclim-devel] CLX backend or OpenGL backend with ClozureCL on OS X (also posted on c.l.l) In-Reply-To: References: <59DD52A0-420F-42CD-9090-69098963A2F8@consequor.de> <20101227114454.GA2013@seid-online.de> Message-ID: <20101227154736.GA3021@seid-online.de> On Mon, Dec 27, 2010 at 08:59:40AM -0600, James Ashley wrote: > On Mon, Dec 27, 2010 at 5:44 AM, wrote: > > On Mon, Dec 27, 2010 at 11:36:24AM +0100, Frank G?nninger wrote: > >> Hi all: > >> Using Quicklisp I loaded the required packages: > >> > > > > Why do you perform such a selective load? So far I had better luck just > > doing a: > > > > ?(ql:quickload "mcclim") > > > > > >> ;;; OK, so far. Now let's define CLX as the backend... > >> > >> ? (setq clim:*default-server-path* '(:clx)) > >> > >> (:CLX) > > > > Without (ql:quickload "clim-clx") this won't work. CLX by itself only > > provides the API to communicate with a X server, the X backend is > > defined inclim-cxl. > > So is this a bug in the ASD (not specifying some required package), a > limitation of ASDF (can't specify that package x depends on variable > y), or just a matter of understanding the tools (load the package you > want, don't mess around with the dependencies)? I'd say it's a missunderstanding: CLIM is an abstract user interface API that can (and does) run on different backends (X/Gtk/Genera/Windows/MAc Toolbox ...). Clim for shure does need _one_ backend loaded to be operable, but how to express this in ASDF? Maybe (find-port ...) should throw an error for an unloaded backend? Looking at mcclim's code for find-port, blindly funcalling the return value of (get (first server-path) :server-path-parser) looks like an error to me. > Where's the best place to document this so it doesn't bite someone > else in the future? > > (cliki seems like the most obvious to me, but what do I know?) McClim's Wiki? Cheers, RalfD > Respectfully, > James > > > > HTH Ralf Mattes > > > >> ;;; Following the McCLIM's Chapter 3 "The First Application" I > >> ;;; tried the sample app: > >> > >> ? ?(app::app-main) > >> > >> > Error: NIL is not of type (OR SYMBOL FUNCTION), and can't be FUNCALLed or APPLYed > >> > While executing: CLIM:FIND-PORT, in process Listener(6). > >> > Type cmd-. to abort, cmd-\ for a list of available restarts. > >> > Type :? for other options. > >> > >> ;;; Hmpf ?!? Ok, CLX seems to be the problem. Backtrace shows: > >> > >> 1 > :b > >> *(161D78B8) : 0 (FIND-PORT :SERVER-PATH (:CLX)) 265 > >> ?(161D7930) : 1 (FIND-FRAME-MANAGER) 509 > >> ?(161D7968) : 2 (FUNCALL #'#<#> #) 405 > >> ?(161D7A40) : 3 (%%STANDARD-COMBINED-METHOD-DCODE (# #) 46378838) 693 > >> ?(161D7AC0) : 4 (CALL-CHECK-REGS APP:APP-MAIN) 221 > > > >> ?(161D7AF8) : 5 (TOPLEVEL-EVAL (APP:APP-MAIN) NIL) 701 > >> ?(161D7B98) : 6 (READ-LOOP :INPUT-STREAM # :OUTPUT-STREAM # :BREAK-LEVEL 0 :PROMPT-FUNCTION #) 2269 > >> ?(161D7DF0) : 7 (TOPLEVEL-LOOP) 101 > >> ?(161D7E18) : 8 (FUNCALL #'#<(:INTERNAL CCL::MAKE-MCL-LISTENER-PROCESS)>) 741 > >> ?(161D7EB8) : 9 (RUN-PROCESS-INITIAL-FORM # (#)) 677 > >> ?(161D7F48) : 10 (FUNCALL #'#<(:INTERNAL (CCL::%PROCESS-PRESET-INTERNAL (PROCESS)))> # (#)) 389 > >> ?(161D7F98) : 11 (FUNCALL #'#<(:INTERNAL CCL::THREAD-MAKE-STARTUP-FUNCTION)>) 301 > >> 1 > > >> > >> I'd have to dig deeper but maybe there's someone on here you already can point in the right direction ?!? > >> > >> THX! > >> > >> Best, > >> ? Frank > >> > >> > >> > >> _______________________________________________ > >> 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 > > > > _______________________________________________ > mcclim-devel mailing list > mcclim-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel From frank.goenninger at consequor.de Mon Dec 27 15:45:04 2010 From: frank.goenninger at consequor.de (=?iso-8859-1?Q?Frank_G=F6nninger?=) Date: Mon, 27 Dec 2010 16:45:04 +0100 Subject: [mcclim-devel] CLX backend or OpenGL backend with ClozureCL on OS X (also posted on c.l.l) In-Reply-To: <20101227154736.GA3021@seid-online.de> References: <59DD52A0-420F-42CD-9090-69098963A2F8@consequor.de> <20101227114454.GA2013@seid-online.de> <20101227154736.GA3021@seid-online.de> Message-ID: Am 27.12.2010 um 16:47 schrieb : > I'd say it's a missunderstanding: CLIM is an abstract user interface API > that can (and does) run on different backends (X/Gtk/Genera/Windows/MAc > Toolbox ...). I think I got that clear after reading the intro material to CLIM. It wasn't obvious to me that after loading CLX and defining CLX as the backend I still missed a package: "CLIM-CLX". > Clim for shure does need _one_ backend loaded to be > operable, but how to express this in ASDF? No need to IMO. > Maybe (find-port ...) > should throw an error for an unloaded backend? Yes! An exception stating "You specified CLX as the backend for CLIM. The necessary package, "CLIM-CLX", has not been loaded." would help really. Similar ones for the other backends, too, of course ;-) > Looking at mcclim's code for find-port, blindly funcalling the return > value of (get (first server-path) :server-path-parser) looks like an > error to me. Yep. > >> Where's the best place to document this so it doesn't bite someone >> else in the future? >> >> (cliki seems like the most obvious to me, but what do I know?) > > McClim's Wiki? Yep! Because that's where I started out my CLIM odyssey. Thanks again! Best wishes Frank From rm at mh-freiburg.de Mon Dec 27 18:24:28 2010 From: rm at mh-freiburg.de (Ralf Mattes) Date: Mon, 27 Dec 2010 18:24:28 +0000 (UTC) Subject: [mcclim-devel] mouse wheel gesture? References: <20101221200856.GB27378@varese> <20101221215609.GC29826@seid-online.de> <20101222102425.GA30775@varese> Message-ID: On Wed, 22 Dec 2010 11:24:25 +0100, Orm Finnendahl wrote: Hi Orm, just a quick follow-up .... > hmm, can't make it work with the mouse wheel. > > This works: > > (define-gesture-name :up :pointer-button-press :middle) > > This doesn't work: > > (define-gesture-name :up :pointer-button-press :wheel-up) It does work. Unfortunately you place your pane inside of (scrolling ...) - and the scoller-pane seems to swallow scroll-wheel events. Leave out the (scrolling ...) arround your pane in the layout definition and your pane receives scroll events (there's a bug in your presentation-to- command definition, but that's another problem). Cheers, RalfD From rm at mh-freiburg.de Mon Dec 27 20:26:03 2010 From: rm at mh-freiburg.de (Ralf Mattes) Date: Mon, 27 Dec 2010 20:26:03 +0000 (UTC) Subject: [mcclim-devel] CLX backend or OpenGL backend with ClozureCL on OS X (also posted on c.l.l) References: <59DD52A0-420F-42CD-9090-69098963A2F8@consequor.de> <20101227114454.GA2013@seid-online.de> <20101227154736.GA3021@seid-online.de> Message-ID: On Mon, 27 Dec 2010 16:45:04 +0100, Frank G?nninger wrote: > Am 27.12.2010 um 16:47 schrieb : > >> I'd say it's a missunderstanding: CLIM is an abstract user interface >> API that can (and does) run on different backends >> (X/Gtk/Genera/Windows/MAc Toolbox ...). > > I think I got that clear after reading the intro material to CLIM. It > wasn't obvious to me that after loading CLX and defining CLX as the > backend I still missed a package: "CLIM-CLX". Well - to be fair, iff you had started your odysee by asdf-ing :mcclim instead of just :clim that would've pulled in :clim-looks which pulls in :clim-clx ... >> Clim for shure does need _one_ backend loaded to be operable, but how >> to express this in ASDF? > > No need to IMO. > >> Maybe (find-port ...) >> should throw an error for an unloaded backend? > > Yes! > > An exception stating "You specified CLX as the backend for CLIM. The > necessary package, "CLIM-CLX", has not been loaded." would help really. > Similar ones for the other backends, too, of course ;-) I've just written up a small patch that does that (without information on what to load - in theory it's possible to load backends mcclim doesn't know off). But I really think the whole function is kind of unelegant. (setq server-path (funcall (get (first server-path) :server-path-parser) server-path)) what is this? An entry in a perl obscurity contest? And a lot of semantic mud afterwards ... comparing keyword lists with #'equal for shure doesn't work. Hmmm-where to put patches ? Cheers, RalfD >> Looking at mcclim's code for find-port, blindly funcalling the return >> value of (get (first server-path) :server-path-parser) looks like an >> error to me. > > Yep. > > >>> Where's the best place to document this so it doesn't bite someone >>> else in the future? >>> >>> (cliki seems like the most obvious to me, but what do I know?) >> >> McClim's Wiki? > > Yep! Because that's where I started out my CLIM odyssey. > > Thanks again! > > Best wishes > > Frank From ahefner at gmail.com Wed Dec 29 10:21:27 2010 From: ahefner at gmail.com (Andy Hefner) Date: Wed, 29 Dec 2010 17:21:27 +0700 Subject: [mcclim-devel] mouse wheel gesture? In-Reply-To: <20101222232517.GA28628@seid-online.de> References: <20101221200856.GB27378@varese> <20101221215609.GC29826@seid-online.de> <20101222102425.GA30775@varese> <20101222232517.GA28628@seid-online.de> Message-ID: On Thu, Dec 23, 2010 at 6:25 AM, wrote: > Well, the wheel buttons are used in panes.lisp (for scrolling), so maybe > you could just test scrolling with the mouse wheel. Thinking of it: > maybe your application pane inherits from mouse-wheel-scroll-mixin and somehow the > scroll event gets eaten by that class' dispatch-event ... That's correct. In McCLIM, the superclasses of application-pane are clim-stream-pane, cut-and-paste-mixin, and mouse-wheel-scroll-mixin. McCLIM arranges the classes with the expectation that most users want mouse wheel scrolling (and other features not explicitly mentioned by the spec), so the wheel scrolling mixin was incorporated by application-pane and interactor-pane, allowing users with unusual needs to instead inherit from clim-stream-pane. In retrospect, I should also have included an initarg in each such mixin to disable the feature. I can't guarantee there isn't some other reason why using a wheel button as a gesture might fail (having never tried it myself), but bypassing the wheel scrolling code is necessary.