From smustudent1 at yahoo.com Wed Nov 2 01:53:35 2005 From: smustudent1 at yahoo.com (C Y) Date: Tue, 1 Nov 2005 17:53:35 -0800 (PST) Subject: [mcclim-devel] Status? Message-ID: <20051102015335.28309.qmail@web31711.mail.mud.yahoo.com> List has been a tad quiet lately - is anything going on at the moment? I've seen a few comments here and there about R-trees but the list has been alarmingly quiet. So I'll make some noise :-). (BTY, nevermind my spec license question - presumably since it's being distributed with McCLIM it's at least LGPL compatible, which is good enough.) I have a question about Backends, or rather what it takes to make one. Is there any kind of template somewhere in the spec, a "Provide all of these graphical abilities and IO routines and you have a valid Backend" kind of document? The Beagle backend, as near as I can tell, loads clx and then provides Cocoa parts in a gradual shift from clx to Cocoa, but it's not clear to me how a developer knows what to implement and what it needs. The clx backend, presumably the most complete one, is a bit intimidating. The keyboard IO stuff is a bit scary (I suppose that really is a hard topic but only the graphical toolkit people ever run into it). Also, if one wants to provide higher level interfacing, for example create an McCLIM menu gadget and tie that directly to GTK's menu API instead of lower level McCLIM gadgets, how would one go about that? I'm sort of curious if McCLIM+lambdagtk could make a reasonably modern looking CLIM, and GTK provides high level functionality which would be nice to use, but I'm a bit at sea as to how to approch this from an McCLIM backend perspective. My instinct is to go top down, tying high level functionality in the spec to high level toolkit functionality and working down to lower level objects, but obviously the clx backend only interfaces to the outside world through the clx communication bridge, and has to implement everything else it needs on top of that. Beagle is presumably working at a somewhat higher level since it's getting some Aqua look and feel working but I haven't really understood how that's being handled yet. Can somebody recommend a "McCLIM backends for dummies" guide? Some place in the spec perhaps? I'll keep digging but I though maybe someone could put me out of my misery and point me in the best direction to head. Cheers, CY __________________________________ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs From amoroso at mclink.it Wed Nov 2 09:34:42 2005 From: amoroso at mclink.it (Paolo Amoroso) Date: Wed, 02 Nov 2005 10:34:42 +0100 Subject: [mcclim-devel] Status? References: <20051102015335.28309.qmail@web31711.mail.mud.yahoo.com> Message-ID: <87oe53z93h.fsf@plato.moon.paoloamoroso.it> C Y writes: > List has been a tad quiet lately - is anything going on at the moment? These days work on McCLIM tends to be concentrated in occasional bursts, but it does happen. To keep up to date with the latest and greatest, you may for example subscribe to the mcclim-cvs mailing list, or check my blog (see signature). > I have a question about Backends, or rather what it takes to make one. > Is there any kind of template somewhere in the spec, a "Provide all of > these graphical abilities and IO routines and you have a valid Backend" > kind of document? The Beagle backend, as near as I can tell, loads clx I'm afraid nothing similar exists. But there is a little known experimental backend, not included in McCLIM's source tree, you may not be aware of. It's the Cairo backend by Gilbert Baumann: http://bauhh.dyndns.org:8000/mcclim/cairo/ Here you can find source code and screen shots. This material may provide additional insight on how a McCLIM backend can be implemented. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From duncan at robotcat.demon.co.uk Wed Nov 2 19:04:53 2005 From: duncan at robotcat.demon.co.uk (Duncan Rose) Date: Wed, 2 Nov 2005 19:04:53 +0000 Subject: [mcclim-devel] Status? In-Reply-To: <20051102015335.28309.qmail@web31711.mail.mud.yahoo.com> Message-ID: <8D1C93AE-4BD3-11DA-ADCC-000A9577B8A2@robotcat.demon.co.uk> On Wednesday, November 2, 2005, at 01:53 am, C Y wrote: > List has been a tad quiet lately - is anything going on at the moment? > I've seen a few comments here and there about R-trees but the list has > been alarmingly quiet. So I'll make some noise :-). > > (BTY, nevermind my spec license question - presumably since it's being > distributed with McCLIM it's at least LGPL compatible, which is good > enough.) > > I have a question about Backends, or rather what it takes to make one. > Is there any kind of template somewhere in the spec, a "Provide all of > these graphical abilities and IO routines and you have a valid Backend" > kind of document? There's no such document as far as I am aware. But basically the back end is responsible for optionally implementing any methods that specialize on frame manager, frame, medium and mirror + the lower level event handling. When I wrote Beagle I copied the methods from the CLX back end and tried to write Cocoa equivalents. The last time I made any changes to Beagle I was really hitting a wall I think because of this approach though (Cocoa /= CLX) so ymmv following this path. > The Beagle backend, as near as I can tell, loads clx > and then provides Cocoa parts in a gradual shift from clx to Cocoa, but > it's not clear to me how a developer knows what to implement and what > it needs. The clx backend, presumably the most complete one, is a bit > intimidating. The keyboard IO stuff is a bit scary (I suppose that > really is a hard topic but only the graphical toolkit people ever run > into it). There shouldn't be any CLX dependency if you're running Beagle; the back ends are totally divorced. The developer generally finds out what's missing when he (I would say s/he but I think there aren't any females working on McCLIM currently ;-) tries to execute some application that dies horribly. > Also, if one wants to provide higher level interfacing, for > example create an McCLIM menu gadget and tie that directly to GTK's > menu API instead of lower level McCLIM gadgets, how would one go about > that? > You want to read the chapters on windowing (6-9?) and the ones on panes and gadgets (23, 24?). Chapter numbers in this mail are non authoritative, but the contents page in the spec. should make them obvious... > I'm sort of curious if McCLIM+lambdagtk could make a reasonably modern > looking CLIM, and GTK provides high level functionality which would be > nice to use, but I'm a bit at sea as to how to approch this from an > McCLIM backend perspective. My instinct is to go top down, tying high > level functionality in the spec to high level toolkit functionality and > working down to lower level objects, but obviously the clx backend only > interfaces to the outside world through the clx communication bridge, > and has to implement everything else it needs on top of that. Beagle > is presumably working at a somewhat higher level since it's getting > some Aqua look and feel working but I haven't really understood how > that's being handled yet. CLIM is specified in terms of 'logical windowing ops' (for want of a better term); the back-ends provide methods that define these in terms of actual window toolkit calls. Beagle doesn't act at a higher level than CLX, at least not as far as CLIM is concerned. The Beagle code is actually higher level than the CLX code I think, but that's because the Cocoa API is defined in OO terms and at a higher level of abstraction than the CLX API. I'm not convinced that a more abstract API is better however in this case; it seems Cocoa and CLIM want to do be responsible for many of the same things, and forcing one or the other to work differently to the respective design is an annoyance (this seems to be particularly bad with respect to event handling and drawing text). > Can somebody recommend a "McCLIM backends > for dummies" guide? Some place in the spec perhaps? I'll keep digging > but I though maybe someone could put me out of my misery and point me > in the best direction to head. The code is the best documentation.... -Duncan > > Cheers, > CY > > > > __________________________________ > Start your day with Yahoo! - Make it your home page! > http://www.yahoo.com/r/hs > _______________________________________________ > mcclim-devel mailing list > mcclim-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel > From smustudent1 at yahoo.com Wed Nov 2 19:45:37 2005 From: smustudent1 at yahoo.com (C Y) Date: Wed, 2 Nov 2005 11:45:37 -0800 (PST) Subject: [mcclim-devel] Status? In-Reply-To: <8D1C93AE-4BD3-11DA-ADCC-000A9577B8A2@robotcat.demon.co.uk> Message-ID: <20051102194537.49821.qmail@web31713.mail.mud.yahoo.com> --- Duncan Rose wrote: > > On Wednesday, November 2, 2005, at 01:53 am, C Y wrote: > > > I have a question about Backends, or rather what it takes to make > > one. Is there any kind of template somewhere in the spec, > > a "Provide all of these graphical abilities and IO routines and > > you have a valid Backend" kind of document? > > There's no such document as far as I am aware. But basically the > back end is responsible for optionally implementing any methods that > specialize on frame manager, frame, medium and mirror + the lower > level event handling. OK. So whatever isn't handled by calls to external routines is implemented in the Lisp backend in terms of lower level routines? > When I wrote Beagle I copied the methods from the CLX back end and > tried to write Cocoa equivalents. The last time I made any changes to > Beagle I was really hitting a wall I think because of this approach > though (Cocoa /= CLX) so ymmv following this path. I was sort of hoping to "start clean" but that might be an exercise in folly. > > The Beagle backend, as near as I can tell, loads clx > > and then provides Cocoa parts in a gradual shift from clx to > > Cocoa, but it's not clear to me how a developer knows what to > > implement and what it needs. The clx backend, presumably the most > > complete one, is a bit intimidating. The keyboard IO stuff is a > > bit scary (I suppose that really is a hard topic but only the > > graphical toolkit people ever run into it). > > There shouldn't be any CLX dependency if you're running Beagle; the > back ends are totally divorced. OK. > The developer generally finds out what's missing when he (I would > say s/he but I think there aren't any females working on McCLIM > currently ;-) tries to execute some application that dies horribly. Ah, the fun way :-). > > Also, if one wants to provide higher level interfacing, for > > example create an McCLIM menu gadget and tie that directly to GTK's > > menu API instead of lower level McCLIM gadgets, how would one go > > about that? > > You want to read the chapters on windowing (6-9?) and the ones on > panes and gadgets (23, 24?). Chapter numbers in this mail are non > authoritative, but the contents page in the spec. should make them > obvious... Sounds good. > CLIM is specified in terms of 'logical windowing ops' (for want of a > better term); the back-ends provide methods that define these in > terms of actual window toolkit calls. Beagle doesn't act at a higher > level than CLX, at least not as far as CLIM is concerned. The Beagle > code is actually higher level than the CLX code I think, but that's > because the Cocoa API is defined in OO terms and at a higher level > of abstraction than the CLX API. Ah, OK. (Looks like SLIME+xref is going to be a useful tool here...) > I'm not convinced that a more abstract API is better however in this > case; it seems Cocoa and CLIM want to do be responsible for many of > the same things, and forcing one or the other to work differently to > the respective design is an annoyance (this seems to be particularly > bad with respect to event handling and drawing text). Hmm. Knowing Apple, I take it CLIM is more general than Cocoa wants to allow? I remember you mentioning that, I'll have to go back and reread those emails. > > Can somebody recommend a "McCLIM backends for dummies" guide? > > Some place in the spec perhaps? I'll keep digging but I though > > maybe someone could put me out of my misery and point me > > in the best direction to head. > > The code is the best documentation.... I was afraid of that... oh, well. Time to kick back and do some recreation spec reading... Thanks much! CY __________________________________ Yahoo! FareChase: Search multiple travel sites in one click. http://farechase.yahoo.com From idurand at labri.fr Mon Nov 7 15:01:47 2005 From: idurand at labri.fr (Irene DURAND) Date: Mon, 07 Nov 2005 16:01:47 +0100 Subject: [mcclim-devel] SBCL SLOW Message-ID: <436F6C5B.8030207@labri.fr> Hello, I have a problem with McCLIM and SBCL. The following McCLIM application (which uses threads through make-process) runs fine with both CMUCL-18e and OpenMCL but desesperatingly slow with SBCL 0.9.5. Each call to the command "Process" returns almost instantly with OpenMCl and CMUCL but takes at least 5 seconds with SBCL. Did anyone notice a problem using threads with SBCL? Thanks for you help, Ir?ne ;;;---------------------------------------------------------------------- (defpackage #:TEST (:use :clim :clim-extensions :clim-lisp)) (in-package test) (defvar *output-stream* nil) (let ((*n* 0)) (defun pause () (incf *n*) (dotimes (i 100000000) (1+ 1)) (format *standard-output* "f ~A done~%" *n*) )) (make-command-table 'file-command-table :errorp nil :menu '( ("Process" :command com-process) ("Quit" :command com-quit))) (define-application-frame test () () (:panes (interactor-pane :interactor) (result-pane (make-pane 'clim-stream-pane :name 'result-pane)) (quit :push-button :label "Quit" :activate-callback #'(lambda (x) (declare (ignore x)) (com-quit)))) (:layouts (default (vertically () quit interactor-pane result-pane)))) (defun run-test (name) (loop for port in climi::*all-ports* do (destroy-port port)) (setq climi::*all-ports* nil) (let* ((frame (make-application-frame name))) (run-frame-top-level frame))) (defun start () (run-test 'test) 0) (defmethod default-frame-top-level :before ((frame application-frame) &key (command-parser 'command-line-command-parser) (command-unparser 'command-line-command-unparser) (partial-command-parser 'command-line-read-remaining-arguments-for-partial-command) (prompt "command: ")) (declare (ignore command-parser)) (declare (ignore command-unparser)) (declare (ignore partial-command-parser)) (declare (ignore prompt)) (setf *output-stream* (climi::find-pane-named *application-frame* 'result-pane))) (define-test-command (com-process :name t) () (clim-sys::make-process (lambda () (let ((*standard-output* *output-stream*)) (pause))) :name "name" )) (define-test-command (com-quit :name t) () (frame-exit *application-frame*)) From csr21 at cam.ac.uk Mon Nov 7 16:09:34 2005 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Mon, 07 Nov 2005 16:09:34 +0000 Subject: [mcclim-devel] SBCL SLOW In-Reply-To: <436F6C5B.8030207@labri.fr> (Irene DURAND's message of "Mon, 07 Nov 2005 16:01:47 +0100") References: <436F6C5B.8030207@labri.fr> Message-ID: Irene DURAND writes: > The following McCLIM application (which uses threads through make-process) > runs fine with both CMUCL-18e and OpenMCL but > desesperatingly slow with SBCL 0.9.5. > > Each call to the command "Process" returns almost instantly with OpenMCl > and CMUCL > but takes at least 5 seconds with SBCL. > > Did anyone notice a problem using threads with SBCL? I haven't noticed anything like a five-second latency in thread startup. > (let ((*n* 0)) > (defun pause () > (incf *n*) > (dotimes (i 100000000) > (1+ 1)) > (format *standard-output* "f ~A done~%" *n*) > )) Under normal operation, the loop in this function would be optimized away. Do you have anything in your personal or site-wide sbcl initialization files, such as a global proclamation of a high debug setting? Or any other package which performs such a global proclamation? I tried your test, and each call to Process finished essentially instantaneously. A screenshot is available at . Putting a call to TIME around the call to (PAUSE) in COM-PROCESS gives output of the form Evaluation took: 0.125 seconds of real time 0.121982 seconds of user run time 0.001 seconds of system run time 0 page faults and 286,448 bytes consed. which is perhaps a little high, but not completely ridiculous for graphical output. Cheers, Christophe From m.retzlaff at gmx.net Tue Nov 22 23:12:41 2005 From: m.retzlaff at gmx.net (Max-Gerd Retzlaff) Date: Wed, 23 Nov 2005 00:12:41 +0100 Subject: [mcclim-devel] Conditional Commands (And Sheets) Extension Message-ID: <20051122231241.GA31266@mgr.home> Hello, I have written an extensions for McCLIM. See below for the documentation file starting with a short description of its purpose. The source code contains an complete example, the complete code is currently available at: http://bl0rg.net/~mgr/flux/conditional-commands_v2_20051122.tar.bz2 (or http://bl0rg.net/~mgr/flux/conditional-commands_v2_20051122/ ) But I'm going to commit it to the McCLIM CVS repository soon; I think the directory mcclim/Extensions/conditional-commands will be suitable. Comments are welcome. -- zipp -- -------------------------------------------------------------------------- Title: Conditional Commands (And Sheets) Extension Created: 2005/11/22 Author: Max-Gerd Retzlaff , http://bl0rg.net/~mgr -------------------------------------------------------------------------- (c) copyright 2005 by Max-Gerd Retzlaff This extensions tries to add simple and elegant methods to specify dependencies among commands and between commands and sheets of a (Mc)CLIM application. Imagine an audio player: The play commands should only be enabled if a audio file is loaded; the same is true for the push-buttons that trigger these commands and probably for a slider that might represent the current position in the audio file. It may also be nice if only the possible commands and gadgets (in general: sheets) will be enabled if you restart the GUI of such a programme (restart only the GUI not the whole programme). The extensions uses the term conditional command for commands that enable or disable commands and/or sheets, and the term conditional application frame for an application frame in whose context conditional commands are invoked. It is stored which commands and sheets got disabled during a run of a conditional application frame; when you exit the application frame and run the top level of a newly created instance of the application frame the previous state will be re-established. This implies that only one instance of a conditional application frame can be running at given time! You can define conditional command by using the macro DEFINE-CONDITIONAL-COMMAND, that is very similar to the CLIM macro DEFINE-COMMAND: The only change is that ENTITIY-ENABLEDNESS-CHANGE is inserted as the new second parameter ENTITY-ENABLEDNESS-CHANGE has to be a list that matches the parameter list: (application-frame &key enable-commands disable-commands enable-sheets disable-sheets evaluate-this) For example: (define-conditional-command (com-bar :name t :menu t :command-table cruft-command-table) (conditional-commands-example :enable-commands (com-baz) :disable-commands (com-bar) :enable-sheets (thud) :disable-sheets (grunt)) () (format t "~%bar called")) Note that the elements of the arguments to :ENABLE-COMMANDS and :DISABLE-COMMANDS can not only be names of commands but also names of command-tables; in the latter case all comamnds of the command table will be enabled (or disabled). With EVALUATE-THIS you can specify a form that will be evaluated when the "entity enabledness change" happens, for conditional commands this is immediately after the body of the command has been executed. Initially all conditional commands and all sheets that might be disabled by them are enabled. To specify which commands and sheets should initially be disabled when the top level of the application frame is run (CLIM:RUN-FRAME-TOP-LEVEL) there is another macro: DEFINE-CONDITIONAL-APPLICATION-FRAME. It is very similar to CLIM:DEFINE-APPLICATION-FRAME, only ENTITY-ENABLEDNESS-CHANGE is inserted as the new third parameter. In this case ENTITY-ENABLEDNESS-CHANGE has to be a list that matches the parameter list: (&key enable-commands disable-commands enable-sheets disable-sheets evaluate-this) For example: (define-conditional-application-frame conditional-commands-example () (:disable-commands (com-bar com-baz) :disable-sheets (thud grunt) :evaluate-this (incf *incarnation-number*)) () (:command-table ...) (:panes ...) ...) This "entity enabledness change" happens in a :BEFORE method of CLIM:RUN-FRAME-TOP-LEVEL that dispatches on the just defined conditional application frame. It might be less confusing to define all "entity enabledness changes" in one place, therefore it is also possible to define an "entit :enable-commands '(com-bar) :disable-commands '(com-baz) :enable-sheets '(grunt) :disable-sheets '(thud)) The argument to ADD-ENTITY-ENABLEDNESS-CHANGE has to be a list that matches the parameter list: (command application-frame &key enable-commands disable-commands enable-sheets disable-sheets evaluate-this) To define the "entity enabledness change" of a conditional application frame seperately the first argument to ADD-ENTITY-ENABLEDNESS-CHANGE has to be the string concatenation of the name of the conditional application frame and the string "-start". In these cases the second argument for DEFINE-CONDITIONAL-COMMAND and DEFINE-CONDITIONAL-APPLICATION-FRAME might be the empty list. (Note: You still have to use DEFINE-CONDITIONAL-COMMAND and DEFINE-CONDITIONAL-APPLICATION-FRAME and not CLIM:DEFINE-COMMAND and DEFINE-APPLICATION-FRAME.) (Be sure to have a look at the contents of the file conditional-commands-example.lisp for the full code of the example.) -- zapp -- -- Max-Gerd Retzlaff For your amusement: life, n.: Learning about people the hard way -- by being one. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From m.retzlaff at gmx.net Thu Nov 24 21:58:31 2005 From: m.retzlaff at gmx.net (Max-Gerd Retzlaff) Date: Thu, 24 Nov 2005 22:58:31 +0100 Subject: [mcclim-devel] Conditional Commands (And Sheets) Extension In-Reply-To: <20051122231241.GA31266@mgr.home> References: <20051122231241.GA31266@mgr.home> Message-ID: <20051124215831.GA13544@mgr.home> Hello On Wed, Nov 23, 2005 at 12:12:41AM +0100, Max-Gerd Retzlaff wrote: > But I'm going to commit it to the McCLIM CVS repository soon; I think > the directory mcclim/Extensions/conditional-commands will be suitable. As you might have noticed this is done now. Bye, Max (PS: This is also finally the first lisp-related entry in my tiny weblog: http://blogs.bl0rg.net/mgr/display/18 Sorry, only about one third of the articles is written in English.) -- Max-Gerd Retzlaff For your amusement: Think of it! With VLSI we can pack 100 ENIACs in 1 sq. cm.! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From thomas at spacecentre.se Tue Nov 29 23:40:52 2005 From: thomas at spacecentre.se (Thomas Persson) Date: Wed, 30 Nov 2005 00:40:52 +0100 Subject: [mcclim-devel] text-field problem Message-ID: <87ek4z9g57.fsf@spacecentre.se> Hi After a cvs update tonight I noticed that the text-field gadget gets initialized with a width of 0, if you don't supply a ":value", resulting in a grey box as seen here: http://www.spacecentre.se/thomas/text-field.png My last update was probably a month ago. More details here: http://paste.lisp.org/display/14131#2 /Thomas From clemens at endorphin.org Wed Nov 30 17:18:56 2005 From: clemens at endorphin.org (Clemens Fruhwirth) Date: Wed, 30 Nov 2005 18:18:56 +0100 Subject: [mcclim-devel] destroy-port to close connection to broken pipes Message-ID: <20051130171702.CE2D03C22F@irulan.endorphin.org> clim:destroy-port does not succeed in closing an already closed connection because a stream error is signaled. This might happen after xkilling an application (the X server terminates the connection) or network problems. Using :abort t for xlib:close-display cuts the connection and there will be no buffer flushing. My purposed patch is attached. Note: SBCL users should put (sb-sys:ignore-interrupt sb-unix:sigpipe) into their .sbclrc. This is necessary because the first attempt to write to a broken pipe will result in a SIGPIPE, which must be ignored. Another catchable error (stream-error) is signaled none the less. Imho sigpipe will becomes ignored per default as discussed on sbcl-devel recently. -- Fruhwirth Clemens - http://clemens.endorphin.org for robots: sp4mtrap at endorphin.org -------------- next part -------------- Index: Backends/CLX/port.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/Backends/CLX/port.lisp,v retrieving revision 1.114 diff -u -r1.114 port.lisp --- Backends/CLX/port.lisp 28 Nov 2005 14:21:45 -0000 1.114 +++ Backends/CLX/port.lisp 30 Nov 2005 09:46:04 -0000 @@ -536,7 +536,8 @@ (xlib:unmap-window (sheet-direct-mirror mirror)) ) (defmethod destroy-port :before ((port clx-port)) - (xlib:close-display (clx-port-display port))) + (handler-case (xlib:close-display (clx-port-display port)) + (stream-error) () (xlib:close-display (clx-port-display port) :abort t))) (defmethod port-motion-hints ((port clx-port) (sheet mirrored-sheet-mixin)) (let ((event-mask (xlib:window-event-mask (sheet-direct-mirror sheet))))