mcclim-devel January 2007

mcclim-devel@common-lisp.net

17 participants
29 discussions

Re: [mcclim-devel] mcclim 0.9.4 freeze
by Troels Henriksen 13 Jan '07

13 Jan '07

> Hi there, > > reliable sources tell me that it's time for another release. The next > holiday is jan 14th, the Orthodox New Year, and I'd like to release > 0.9.4 on this day. "McCLIM 0.9.4 Orthodox New Year"? > This mail marks the start of the freeze period. Please test as > aggressively as you can, and keep changes to the core of mcclim to a > minimum (of course, documentation improvements are always welcome). It may be necessary to turn Drei off by default, as there are still some somewhat-serious problems: * Reader macros are poorly handled by the Lisp syntax, leading to possible Listener breakage. * Delimiter gestures do not work properly for some reason (rtoy has been affected by this). * Sometimes, Lisp syntax is not properly enabled when the input buffer is changed via the presentation history or similar. * Sometimes, Drei will move its output record when stuff is inserted. I *suspect* this is not the same bug as the one triggered by Closure. Apart from that, great! There's been quite a bunch of changes over the last months, so it's a good time to do a release I think.

3 3

[mcclim-devel] mcclim 0.9.4 freeze
by Andreas Fuchs 11 Jan '07

11 Jan '07

Hi there, reliable sources tell me that it's time for another release. The next holiday is jan 14th, the Orthodox New Year, and I'd like to release 0.9.4 on this day. This mail marks the start of the freeze period. Please test as aggressively as you can, and keep changes to the core of mcclim to a minimum (of course, documentation improvements are always welcome). Cheers, -- Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs

2 1

[mcclim-devel] T presentation-type
by Christophe Rhodes 10 Jan '07

10 Jan '07

Hi, While I'm on the bug reporting bandwagon, doing (clim:accept t) at the listener errors from NO-APPLICABLE-METHOD: There is no applicable method for the generic function #<STANDARD-GENERIC-FUNCTION CLIM-INTERNALS::DESCRIPTION (3)> when called with arguments (#<BUILT-IN-CLASS SYMBOL>). This is probably because of the magical nature of T. Cheers, Christophe

3 2

[mcclim-devel] Drei(?) problems
by Christophe Rhodes 09 Jan '07

09 Jan '07

Hi, In the listener, if I do (defun foo (x) x) and then (clim:accept 'symbol), then wave my mouse around, I get an error from the CLIM-LISTENER:SYMBOL-TO-CLASS-NAME translator, saying that "symbol" isn't a valid argument to find-class. This comes about because of what I believe are two Drei bugs. One is that the unknown-symbol shouldn't inherit from symbol, as the presentation object is not in fact a symbol (and so presentation methods expecting it to be will lose). The other is that FORM-TO-OBJECT methods on token (symbolish?) lexemes seem not to return enough values to satisfy the DISPLAY-PARSE-TREE method on TOKEN-MIXIN, which means that every token gets presented as an unknown-symbol, with the presentation object being the unparsed string. I don't really know what the UNKNOWN-SYMBOL presentation type is for, but maybe it should inherit from STRING instead of SYMBOL? Cheers, Christophe

1 0

[mcclim-devel] presentation-subtypep
by Robert Goldman 09 Jan '07

09 Jan '07

With Xof's help, I have butchered the definition of presentation-subtypep in McCLIM to hand AND types --- previously it only handled OR. Here is a draft new defun (apologies is wrapper gonks it) and, for those who prefer, I will attach (unless I forget again) a patch file: (defun presentation-subtypep (type maybe-supertype) (when (equal type maybe-supertype) (return-from presentation-subtypep (values t t))) (with-presentation-type-decoded (super-name super-parameters) maybe-supertype (when (eq super-name 'or) (loop for or-type in super-parameters when (presentation-subtypep type or-type) do (return-from presentation-subtypep (values t t)) finally (return-from presentation-subtypep (values nil t)))) (when (eq super-name 'satisfies) (return-from presentation-subtypep (values nil nil))) (with-presentation-type-decoded (sub-name sub-parameters) type (when (eq sub-name 'and) (loop for and-type in sub-parameters with subtypep and knownp with answer-knownp = t do (multiple-value-setq (subtypep knownp) (presentation-subtypep and-type maybe-supertype)) if subtypep do (return-from presentation-subtypep (values t t)) else ; track whether we know the answer do (setf answer-knownp (and answer-knownp knownp)) finally (return-from presentation-subtypep (values nil answer-knownp))))) (map-over-presentation-type-supertypes #'(lambda (name massaged) (when (eq name super-name) (return-from presentation-subtypep (funcall-presentation-generic-function presentation-subtypep massaged maybe-supertype)))) type)) (values nil t))

2 1

[mcclim-devel] file-browser demo program
by Robert Goldman 09 Jan '07

09 Jan '07

I have committed a working, but undesirable version of the demo. This one fixes some bugs that weren't really CLIM bugs, per se, but were either incorrect, or at least unportable, treatments of CL pathnames. A remaining problem is that the file-browser would try to edit (really list) directories on any pathname, not just directory pathnames. My attempt to fix this originally relied (I think correctly), on the use of a presentation type of (and pathname (satisfies cl-fad:directory-pathname-p)). Unfortunately, and and satisfies presentation types don't work properly in McCLIM. For now, I have also committed this alternative version for reference as file-browser.lisp-type-abbrev. It could become the real version when the presentation types are fully fixed. Sorry to leave things like this, but I will probably be unable to work on McCLIM again for a week or so, so thought it would be best to leave things at least *better*, if not fully fixed. Cheers, R

1 0

[mcclim-devel] modified clim Spec latex
by Robert Goldman 08 Jan '07

08 Jan '07

I have modified the clim spec to load its images through includegraphics rather than through epsfig, making it equally usable through pdflatex and latex. In pdflatex, I additionally tweaked it to generate hyperlinks, making it easier to read the document online. Anyone have any objections to my committing these changes? Best, Robert

1 1

[mcclim-devel] RGBA image drawing
by David Lichteblau 07 Jan '07

07 Jan '07

Hi, McCLIM CVS now has experimental support for 32 bit RGBA images, based on Closure's AIMAGE code. Both API and implementation are up for discussion, and I would be glad to receive feedback. One API issue is that Closure draws aimages to CLX pixmaps, and keeps a cache of these pixmaps. To keep this cache functional, I decided to put medium-specific data into the design instances used to draw images. Normally designs are not bound to a particular medium, and existing code for indexed-pattern does not expose its caching to the user. Perhaps a better implementation strategy could be used for both rgb-image-design and indexed-pattern? More serious perhaps is the current implementation's limitation to true color visuals. Closure itself had sophisticated support for all kinds of X11 visuals, including dithering algorithms. The routines used there are similar to the code found in CLIM-CLX's indexed-pattern implementation. Basically, code suitable for the current colormap is compiled at runtime into a function that maps abstract colors and x/y coordinates to X11 colors. (This code can be found in closure/src/renderer/x11.lisp) Perhaps someone who understand the indexed-pattern drawing routines knows what the right approach to this is. Should x11.lisp be moved into McCLIM? Can it be merged with the code that Backends/CLX/medium.lisp already has? Thanks, David

1 0

Re: [mcclim-devel] file-browser example application
by Robert Goldman 07 Jan '07

07 Jan '07

Robert Goldman wrote: > Troels Henriksen wrote: >> Robert Goldman <rpgoldman(a)real-time.com> writes: >> >>> I made a stab at it, but no, it didn't seem to work. I am attaching two >>> different versions of the file-browser: one that works, using a new >>> presentation-type, dir-pathname, and one that tries to do the job with >>> (and pathname (satisfies cl-fad:directory-pathname-p)), that doesn't >>> work. >> It seems that the `and' type doesn't work at all. Try doing (present 2 >> 'integer) and then (accept '(and integer)) - the previous output will >> not be selectable. >> > Hm.... > > At least in presentation-defs.lisp, there is no accept presentation > method for AND. Is this the culprit? > > By analogy, I tried whacking together the following definition for > presentation-defs: > (define-presentation-method accept ((type and) > (stream input-editing-stream) > (view textual-view) > &key) > (let ((scan-begin (stream-scan-pointer stream)) > success > value) > (dolist (and-type types) > (setf (stream-scan-pointer stream) scan-begin) > (multiple-value-setq (success value) > (block try-accept > (handler-case (values t (accept and-type > :stream stream > :view view > :prompt nil)) > (parse-error () (return-from try-accept nil))))) > (unless success (simple-parse-error "Input type is not of type ~S" > types))) > value)) > > But then I get an error that SATISFIES is an unknown presentation type. > I suspect that this is because it's not a primary presentation type, so > I need to use presentation-typep here instead of a recursive accept... > > Best, > R > OK, the following works to let me enter values of type (and pathname (satisfies cl-fad:directory-pathname-p)) to the command prompt. But I still don't get the ability to mouse-select the directory list entries for the presentation-to-command-translator. (define-presentation-method accept ((type and) (stream input-editing-stream) (view textual-view) &key) (let* ((subtype (first types)) (value (accept subtype :stream stream :view view :prompt nil))) (unless (presentation-typep value type) (simple-parse-error "Input type is not of type ~S" type)) value)) BTW, the command prompt is pretty uninformative: Edit Directory (and) : Is this where an abbreviation and description would be helpful? Cheers, R

1 0

[mcclim-devel] file-browser example application
by Robert Goldman 07 Jan '07

07 Jan '07

The guided-tour has a test application that's a file-browser. I wanted to try to figure out how to read pathnames in an application I'm writing, so I tried to fire up the file-browser. Unfortunately, it didn't work, mostly because it made assumptions about the way that CL pathnames work that didn't map onto either SBCL or ACL, the two applications on which I tried it. I am attaching a patch which makes it work (if the patch about pathname presentations, that I sent earlier today, is also present). I am inclined to commit this, since (a) it's just part of an article, so can't be on anyone's critical path and (b) it seems like a Bad Thing to have a tutorial out there featuring exemplars that don't work. The downside is that CL pathnames are so intractable that the only good way I found to make this work was to use CL-FAD. Dependencies on libraries seems generally like a bad thing in a small tutorial like this, but importing enough code to make it work w/o the library would probably obscure the tutorial intent even worse. BTW, I think a more elegant solution might be made that would use satisfies to define the dir-pathname presentation-type more declaratively. But I couldn't figure out how to do it... best, Robert

3 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

mcclim-devel January 2007