mcclim-devel

mcclim-devel@common-lisp.net

820 discussions

[mcclim-devel] destroy-port to close connection to broken pipes
by Clemens Fruhwirth 30 Nov '05

30 Nov '05

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(a)endorphin.org

1 0

[mcclim-devel] Conditional Commands (And Sheets) Extension
by Max-Gerd Retzlaff 24 Nov '05

24 Nov '05

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 <m.retzlaff(a)gmx.net>, 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 <m.retzlaff(a)gmx.net> For your amusement: life, n.: Learning about people the hard way -- by being one.

1 1

[mcclim-devel] SBCL SLOW
by Irene DURAND 07 Nov '05

07 Nov '05

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*))

2 1

[mcclim-devel] Status?
by C Y 02 Nov '05

02 Nov '05

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

3 3

[mcclim-devel] Spec license?
by C Y 29 Oct '05

29 Oct '05

As long as I'm looking into this in other projects, I might as well ask here - what are the copyright/license terms of the CLIM spec? Cheers, CY __________________________________ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs

1 0

[mcclim-devel] (statusp cocoa-port)
by James Crippen 23 Oct '05

23 Oct '05

What's the current status on the Cocoa backend for McCLIM? I have an all Mac environment now, and I'd like to hack on Climacs a bit. But I'd rather have it running in Cocoa than in X. Is the Cocoa port working, for some suitable value of working? Or is it basically dead? If the latter, what needs to be done to ressurect it? Thanks, James

5 6

[mcclim-devel] Resizing windows
by David Lewis 21 Oct '05

21 Oct '05

Hi, Working with Christophe Rhodes on a lute tablature editor under Climacs, I'm using one basic climacs window and a graphical window created with open-window-stream: http://common-lisp.net/project/climacs/tabcode.png Because of the need to resize the graphical display as the text changes, I've put an allocate-space command into our redisplay routine. That seems to work, but resizing the window manually (with the mouse) seems to resize the stream rather than (as I expected it to) the viewport. Is that expected behaviour? Should I be approaching the problem differently? Thanks, David Lewis P.S. A side issue to this is that the scroll-bars seem not to refresh automatically. Should I be running a command to do that or is this a bug/feature?

1 0

[mcclim-devel] a patch for mcclim/Lisp-Dep/mp-acl.lisp
by Max-Gerd Retzlaff 13 Oct '05

13 Oct '05

Hello, what do you think about this patch for mcclim/Lisp-Dep/mp-acl.lisp? Index: mp-acl.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/Lisp-Dep/mp-acl.lisp,v retrieving revision 1.5 diff -a -u -r1.5 mp-acl.lisp --- mp-acl.lisp 10 Mar 2004 12:03:45 -0000 1.5 +++ mp-acl.lisp 13 Oct 2005 15:25:07 -0000 @@ -30,8 +30,24 @@ (eval-when (:load-toplevel :compile-toplevel :execute) (pushnew :clim-mp *features*)) +#+nil (defun make-process (function &key name) (mp:process-run-function name function)) + +;; In ACL each process has its own dynamic enviroment, +;; therefore a special binding doesn't affect the global binding of +;; the variable and the new process doesn't see that special binding. +;; In other words: +;; (let ((*debugger-hook* #'clim-debugger:debugger)) +;; (clim-listener::run-listener :new-process t)) +;; does not work, if *debugger-hook* is not explicitly bound to +;; the current special binding for the new process. +;; mgr, 20050706 +(defun make-process (function &key name) + (mp:process-run-function `(:name ,name + :initial-bindings ((*debugger-hook* . ,*debugger-hook*) + ,@excl:*cl-default-special-bindings*)) + function)) (defun destroy-process (process) (mp:process-kill process)) Regards, Max -- Max-Gerd Retzlaff <m.retzlaff(a)gmx.net> For your amusement: You're currently going through a difficult transition period called "Life."

1 0

[mcclim-devel] Is anyone using McCLIM with :unicode on *features*?
by Andreas Fuchs 09 Oct '05

09 Oct '05

Hi all, short story: I wonder if anyone is using McCLIM on CLX with the :unicode feature. Please test with: (cl:member :unicode cl:*features*) and report non-NIL results to this list. Thank you! long story: while trying to refactor the CLX backend's medium implementation, I found a lot of #+unicode statements in Backends/CLX/medium.lisp. From the comments, it looks like they shouldn't even be there: ; Yes, the following is a nasty hack. ; It's just a proof of concept, I'll try not to commit it :] ; If it does get committed, it shouldn't affect anyone much... These definitions don't *seem* to me like they are used by anyone, so I'd like to nuke them in favour of definitions that have a chance of working with mcclim-freetype's idea of text-style properties without requiring an ugly hack (like the method redefinitions that mcclim-freetype currently employs). So, again, please test if you're using McCLIM with the feature :unicode. Run (cl:member :unicode cl:*features*) and report non-NIL results to this list. I may be breaking your McCLIM soon, and we don't want that to happen without a good reason (-: Thanks, -- Andreas Fuchs, <asf(a)boinkor.net>, asf(a)jabber.at, antifuchs

2 1

[mcclim-devel] Re: [climacs-devel] Small patch to commands.lisp
by Christophe Rhodes 30 Sep '05

30 Sep '05

John Q Splittist <splittist(a)yahoo.com> writes: > Christophe Rhodes wrote: > >> I wonder if it would be possible to add a test case for the failure >> you've seen in the Tests/ directory? > > I'm not sure whether this fits the bill, but here is an attempt. > Corrections, suggestions etc. welcome. I guess three weeks is an adequate timescale for corrections and suggestions for a one-line patch with tests, so I've merged your patch and test file (adding a completely untested extra test). Thanks. Cheers, Christophe

1 0

← Newer
1
...
54
55
56
57
58
59
60
...
82
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

mcclim-devel