cells-devel

cells-devel@common-lisp.net

567 discussions

[cells-devel] Emailing: MouseClick.lisp
by Kenny Tilton 21 Feb '04

21 Feb '04

Just in case... kenny -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application ;; -*- mode: Lisp; Syntax: Common-Lisp; Package: cello; -*- ;;; ;;; Copyright © 2004 by Kenneth William Tilton. ;;; ;;; Permission is hereby granted, free of charge, to any person obtaining a copy ;;; of this software and associated documentation files (the "Software"), to deal ;;; in the Software without restriction, including without limitation the rights ;;; to use, copy, modify, merge, publish, distribute, sublicense, and/or sell ;;; copies of the Software, and to permit persons to whom the Software is furnished ;;; to do so, subject to the following conditions: ;;; ;;; The above copyright notice and this permission notice shall be included in ;;; all copies or substantial portions of the Software. ;;; ;;; THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR ;;; IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, ;;; FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE ;;; AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER ;;; LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING ;;; FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS ;;; IN THE SOFTWARE. (in-package :cello) (defmodel Mouse () ((leftb :initarg :leftb :initform (cv :up) :accessor leftb) (middleb :initarg :middleb :initform (cv :up) :accessor middleb) (rightb :initarg :rightb :initform (cv :up) :accessor rightb))) (defmodel MouseClick (Model Perishable) ((clickwindow :cell nil :initarg :clickwindow :initform nil :reader clickwindow) (osEvent :cell nil :initarg :oSEvent :reader osEvent) (clickee :cell nil :initarg :clickee :reader clickee) (clickeePXY :reader clickeePXY :cell nil :initarg :clickeePXY) (clickCompleted :reader clickCompleted :initform (c? (when (typep (clickwindow self) 'Window) ;; <- acl used to turn windows into (mouseUpEvt (clickwindow self))))) ;; closed-stream instances (clickOver :reader clickOver :initform (c? (when (typep (clickwindow self) 'Window) (unless (^clickCompleted) (when (mouse-over-p (clickee self)) (mousePos (clickwindow self))))))) (inDrag :reader inDrag :initform (c? (when (typep (clickwindow self) 'Window) (unless (^clickCompleted) (when (mouse-over-p (clickee self)) (mousePos (clickwindow self))))))) (clicked :reader clicked :initform (c? (trc nil "clicked?> typeof clickw" (clickwindow self) (type-of (clickwindow self))) (when (typep (clickwindow self) 'Window) (trc nil "clicked?> asking clickcompleted") (bWhen (up (^clickCompleted)) (trc nil "clicked?> asking point-in-box" (evtWhere up) (clickee self) (without-c-dependency (screenbox (clickee self)))) (when (point-in-box (evtWhere up) ;; more precise than mPos (without-c-dependency ;; moving GUI elements? chya (screenbox (clickee self)))) (cons (clickee self) up)))))) ) (:default-initargs :expiration (c? (mouseUpEvt (clickWindow self))))) (defmethod initialize-instance :after ((self MouseClick) &key) (when (typep (clickee self) 'Focus) (unless (control-key-down (evtButtons (osEvent self))) ;; lame debugging enabler; make better (focus-navigate (focus (clickWindow self)) (clickee self)))) (bwhen (ctxt (clickee self)) (do-mouseclick ctxt (clickWindow self) (osEvent self))) (to-be self) ;; unnecessary? 2301kt just moved this from after next line (trc nil "echo click set self clickee" (clickee self)) (bwhen (ctxt (clickee self)) ;; /// looks wrong with do-mouseclick above and now this (set-mouseclick ctxt self)) ) (defmethod do-mouseclick (other w evt) (declare (ignorable other w evt))) (defmethod set-mouseclick (other click) (declare (ignorable other click))) (defmethod set-doubleclick? (other click) (declare (ignorable other click))) (defmethod not-to-be :around ((self MouseClick)) (when (typep (clickWindow self) 'Window) ;; /// why worry about this? (trc nil "echo click clearing self from clickee" (clickee self)) (set-mouseclick (clickee self) nil) ;; do this first? ;; (trc "echo click not-to-be-ing self from clickee" self) (call-next-method) (set-doubleClick? (clickWindow self) self) ;; from Win32 days )) (def-c-echo clicked () (when (and new-value (clickwindow self)) (trc nil "echo clicked calling control-do-action" self new-value) (Control-do-action (car new-value) (cdr new-value)))) ;---------------------------------------- (def-c-echo clickOver () (ctl-handle-over (clickee self) self new-value)) (defmethod ctl-handle-over (self clickStart overInfo) (declare (ignore self clickStart overInfo))) ;;; (defmethod ctl-handle-over :before ((self control) clickStart overInfo) ;;; (declare (ignore clickStart)) ;;; (setf (hilited self) overInfo)) ;; treat as flag: only issue is nil or not ;-----------------------------------------

1 0

[cells-devel] Portacello
by Kenny Tilton 21 Feb '04

21 Feb '04

1. If we make any progess on porting Cello off win32 I will apply for a separate Cello project here on common-lisp.net. In the meantime, non-Cellists might want to switch to digest mode since I would like (for a week?) to use this list for porting traffic so everyone sees it. I will be a porter (and OSX LispworksTrial) myself, and three others have requested and been sent zips. Speaking of which... 2. Doh! Non-win32 users will need to build .SOs for everything including FTGL. I completely forgot that I had written a few C routines so Lisp could deal with FTGL, which is C++. The source for that will follow as soon as I find it. :) 3. I have started on an effort to carve Cello up cleanly so one can build with just the GLUT and OpenGL and pull in FTGL and ImageMagick as optional add-ons. If any porter would prefer an approach in which they tackle one hurdle at a time, they might want to wait until this afternoon when I hope to get the thing carved up. 4. I will also set things up so a build can be done with the absolute minimum of OpenGL FFI bindings. Part of what is going on here and in #3 is to shrink Cello enough that it will run on the trial version of Lispworks and maybe someday ACL (I think after Cells gets hacked in ways I have planned.) 5. GLUT is a big issue. For one, any GLUT means callbacks from C into Lisp, set up by Lisp calling the GLUT library to identify the callbacks and then give control to Glut. That means the cmucl/sbcl crowd needs recent work on cmucl and sbcl to add that capability. I believe there are two such patches, one by Thomas. Hopefully you all can deal with the cmucl/sbcl lists to work out that issue. Second, Freeglut has me worried. It hogs the CPU insanely on win32. soon enough I'll go see why and work out a fix, but this is not confidence-inspiring. nor is the bug report I sent in going completely ignored. :) well, at least we have the source. But the reason we use FG instead of Mark Kilgard's original is that that closes down the Lisp IDE when you close any glut window. Not good. There are two fixes. One is to set an option (see notes below) /not/ to exit to the OS when a window closes. That is how the existing code works because FG was not working (strike three?) when I used the alternative: do not give control to glut by calling glutMainLoop, just periodically call glutCheckLoop (some glut hacks) or (glutMainLoopEvent (I think)) in Freeglut. I see the Aqua glut (my target) on OS X has a glutCheckLoop, and hopefully theirs works, so if you are doing an OS X port I recommend (a) the Aqua glut (not the X11 Glut) and glutCheckLoop. The source has some old polling code commented out--look for glutMainLoopEvent in window.lisp. 6. OK, here are the notes I have sent out before: I thought of a couple of things, and will merge them in with the other notes so as to have everything in one place. btw, tomorrow I plan to rip out as much as possible so as to get this thing running again under Lispworks trial, then see if I can do a port to OS X myself. Install notes: - email Qs at first sign of trouble, don't wait till you are stuck. Even if it turns out in the end to be some typo, i would rather err on that side than have you banging your head for hours on something I could sort out quickly - to build: if you are on win32 using ACL just use the Cloucell.lpr project. everyone else can use ASDF with some aggravation: find "build.lisp" in the cello directory. That shows the order in which things are to be loaded, and you get to tweak the directory lists to correspond to where you ended up installing. (there are hardcoded paths in the source as well you'll need to hunt down and amend.) Now for the aggravation: my defsystems are derived from the LPRs I use under Allegro. That project manager is smart enough to load things in order whether or not dependencies are made explicit. Not ASDF. So an incremental build will often fail because ASDF first compiles any changed file, at which point only explicit dependencies will have been loaded. I have a 3ghz laptop, so I just change the force-load parameter to t if I get an error I recognize to be related to all this. - once you have a clean build, the test function is: (starter) - you need some dynamic load libraries (win32 dlls I use are included) and to change the paths hardcoded into the app. I use "/dev/lib" and I have already been warned that /dev is a system directory on Unix. The runtime libraries you will need are: GL (OpenGL, that is) Freeglut or any Glut that accepts the option to exit on window close. In window.lisp, function glutw-create, look for: (glut-set-option GLUT_ACTION_ON_WINDOW_CLOSE GLUT_ACTION_GLUTMAINLOOP_RETURNS) You might have to change that if your glut works diff. FTGL -- should be painless; the developer is an OS X guy ImageMagick (possibly GraphicsMagick would be compatible) The source you will need to get is UFFI (tho I could send it to you if necessary). an ASDF.lisp is included. To build using ASDF, oen build.lisp in the cello subdirectory and evaluate forms in the order shown. Note that they will have to be adjusted to yyour directory structure. kenny

2 1

[cells-devel] PortaCello 1.0
by Kenny Tilton 20 Feb '04

20 Feb '04

I just sent a notice to a few folks I remembered were interested in seeing if they could get the Cello mess running under something besides (and win32 (or acl lw)). If I forgot anyone just yell and I will get you onto my list of candidate porters. Gotta break now to work on Lisp+Music for tonights meeting. cheers, kenny -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application

1 0

[Fwd: Re: [cells-devel] Cells/ASDF: Telling the lisp env that cells is loaded...]
by Kenny Tilton 16 Feb '04

16 Feb '04

Frank Goenninger wrote: >Hey, no prob. The following lines are now part of my cells.asd file (at >the end of the file): > >(defmethod asdf:perform ((o load-op) (c (eql (find-system :cells)))) > (pushnew "CELLS" *modules*) > (pushnew :cells *features*)) > Done, as well as a parallel entry in Cello.asd. Thx, kenny -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application

1 0

[cells-devel] Cells/ASDF: Telling the lisp env that cells is loaded...
by Frank Goenninger 16 Feb '04

16 Feb '04

Hi all on the list, hi Kenny, after playing now with cells for a while I wonder what you guys think of adding something like the following to a cells load file: (I put it into cells.asd) ---- (defmethod asdf:perform ((o load-op) (c (eql (find-system :cells)))) (pushnew :cells *features*)) ---- Objective was to "tell" other packages/functionality that cells is loaded into the image/system. Any comments? Thx for feedback. Regards, Frank

3 8

[cells-devel] Cello screen shots
by Kenny Tilton 13 Feb '04

13 Feb '04

http://www.tilton-technology.com/cellophane.html Still just ACL/win32 for now, with Lispworks having a couple of problems (which look easy) and progress reported on an SBCL/OSX/X11 port. I will clean things up and make a zip available to anyone brave enough to dive in at the deep end, in a day or three. kt -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application

1 0

[cells-devel] The "No CVS" Rule :)
by Kenny Tilton 16 Dec '03

16 Dec '03

Just to be clear, the "No CVS" rule relates to avoiding the bleeding edge, not anything to with CVS per se, yes? Or is it that the CVS stuff is not packaged as thoughtfully to build right out of the box? I ask because it has occurred to me that CVS neatly solves the problem of my jumping around between win32 and Linux: if I pull source down onto my Linux box and hack it to make it work over there, then I just commit and do an update on my win32 box and make sure everything still works there. If not, another iteration and all should be OK, off to OS X to conquer another platform. Sound right? kt -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application

2 3

[cells-devel] Oops on FFX files
by Kenny Tilton 16 Dec '03

16 Dec '03

In case anyone notices and is concerned, I am at this point just playing around with cvs trying to get clear how to live with it, and have uploaded a few source files as part of my experimentation. But the few files (in an FFX subdirectory) still have to be modified to show the open license, which I will do shortly. kt -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application

1 0

[cells-devel] Freeglut configure on Debian Linux
by Kenny Tilton 16 Dec '03

16 Dec '03

OK, I decided to try Cello/Linux first since I have actually used CMUCL and Emacs on this box successfully in the past. Managed with the usual amount of grief to CVS down the Freeglut sources into /usr/local/freeglut/freeglut (their fault, not mine). Tried what I thought was the way to go: ./configure ...with the directory containing configure.in as my working directory. Shell yells no such command. So I try: autoconf ...and get: root@xkenny:~# cd /usr/local/freeglut/freeglut root@xkenny:/usr/local/freeglut/freeglut# autoconf configure.in:4: error: possibly undefined macro: AM_INIT_AUTOMAKE If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.in:5: error: possibly undefined macro: AM_CONFIG_HEADER configure.in:11: error: possibly undefined macro: AC_LIBTOOL_DLOPEN configure.in:12: error: possibly undefined macro: AM_PROG_LIBTOOL configure.in:35: error: possibly undefined macro: AC_CHECK_LIBM I understand the Freeglut stuff is pretty tight, and someone here built Freeglut successfully, so... what am I doing wrong? In case it is not clear, I am clueless on Linux, so plz err on the side of more specifity with any advice. I'll keep digging, but I thought I would send up a flare before running out for pizza. kt

2 3

[cells-devel] Is it Cello yet? Nope...
by Kenny Tilton 12 Dec '03

12 Dec '03

Silly me. I had heard that the Big Three (*nix, Mac OS, and win32) all supported native fonts for OpenGL via xgl, agl, and wgl libraries. Well... Bad luck. The one I tried first happened to be wgl, which supports both bitmapped and outline of any installed font on the system. Not so with agl, just bitmap and not just any font. It offers a nice list of pre-defined fonts, but to do this right we need unrestricted font access. I am looking at FreeType next. kt -- http://tilton-technology.com Why Lisp? http://alu.cliki.net/RtL%20Highlight%20Film Your Project Here! http://alu.cliki.net/Industry%20Application

2 2

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

cells-devel