- mcclim-devel - mailman3.common-lisp.net

[mcclim-devel] [patch] minor goatee improvements (arrow keys!)
by Andreas Fuchs 07 Dec '05

07 Dec '05

Hi all, I have here a patch to make arrow keys and the Home and End keys in a goatee input buffer DTRT. I'm not entirely sure if the patch to lookup-gesture-command is doing the right thing, so I'd like a CLIM gesture specialist to at least glance over it before I commit it. (: Here's the patch: Have fun, -- Andreas Fuchs, <asf(a)boinkor.net>, asf(a)jabber.at, antifuchs

1 1

[mcclim-devel] Interactor pane, hollow cursor?
by Andy Hefner 06 Dec '05

06 Dec '05

Why does the text cursor within interactor panes now appear hollow, as though you were not typing to the interactor?

4 4

[mcclim-devel] Weird gray regions bug in Clouseau
by Peter Scott 05 Dec '05

05 Dec '05

When I open Clouseau and expand what I'm inspecting so that it goes off the screen, I see gray regions if I scroll to the right or down. Here's a screenshot: http://www.ece.iastate.edu/~pjscott/inspector-bug.png I got that just by doing (clouseau:inspector *features*) and scrolling to the right. The same problem occurs at the bottom if I inspect something too long to properly display. If I scroll down in the previous window: http://www.ece.iastate.edu/~pjscott/inspector-bug2.png This is annoying, and I don't know enough about the internal workings of McCLIM to know where to start fixing it. I think it might be related to this code: (defmethod redisplay-frame-pane :after ((frame inspector) (pane application-pane) &key force-p) (declare (ignore force-p)) (change-space-requirements pane :height (bounding-rectangle-height (stream-output-history pane)))) ...but I'm not sure, and I don't want to just randomly munge code and hope that I accidentally fix the problem. --Peter

4 5

[mcclim-devel] text-field problem
by Thomas Persson 03 Dec '05

03 Dec '05

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

2 1

[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 28 Oct '05

28 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