mcclim-devel November 2005

mcclim-devel@common-lisp.net

8 participants
8 discussions

[mcclim-devel] question about curves and formatting graphs
by rpgoldman＠real-time.com 10 Apr '06

10 Apr '06

If one wanted to draw curvy lines in McCLIM, is there any way of doing this? I had assumed, foolish me, that this could be done using Bezier curves, but now I see that those were an Allegro extension to the standard, and not part of CLIM 2.0.... I'm not much of a graphics person, and don't understand X very well, so I was wondering --- is there anything about X itself that makes drawing curved lines particularly difficult? Also, has anyone been thinking about the possibility of dynamic graphs? I.e., graphs where one might want to enter leaves? Or the possibility of having a fixed graph where a user might move the nodes around to make the graph more readable. CLIM doesn't have any sort of "smart link" object that would support this, does it? Thanks, Robert

4 11

[mcclim-devel] [patch] fix apparent typos
by tim＠tenkan.org 30 Dec '05

30 Dec '05

In my travels through the looking-pane, I bumped into these: -- -Tim

2 1

[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] 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

mcclim-devel November 2005