mcclim-devel

mcclim-devel@common-lisp.net

820 discussions

[mcclim-devel] McCLIM 0.9.4 released!
by McCLIM developers 14 Jan '07

14 Jan '07

The McCLIM developers are happy to release version 0.9.4 of McCLIM, code-named "Orthodox New Year". This release was tested and found to work on the following implementations: This release includes some great improvements, from a new editor substrate ("DREI") to many cool new features in the Gtkairo backend, and many compatibility enhancements and extensions to the core of McCLIM. Note that due to the radical changes introduced by the new editor substrate, some bugs may surface in day-to-day use. Refer to the section "Known Bugs" in the included release notes for details. When testing this release, we found that it works on the following implementations: * SBCL * OpenMCL * CLISP * Allegro Common Lisp 8.0 in ANSI Mode For compatibility with other implementations, please see the attached release notes. Get the tarball at <http://common-lisp.net/project/mcclim/downloads/mcclim-0.9.4.tar.gz> or install McCLIM via asdf-install. We are looking forward to your comments and bug reports. Please send them to mcclim-devel at common-lisp.net. The list of currently known bugs can be found at <http://mcclim.cliki.net/Bug>. Have fun using McCLIM, The McCLIM developers. RELEASE NOTES FOR McCLIM 0.9.4, "Orthodox New Year": Compatibility ============= This release was tested and found to work on the following implementations: * SBCL * OpenMCL * CLISP * Allegro Common Lisp 8.0 in ANSI Mode In our tests, this release of McCLIM did not work on the following implementations: * CMUCL (at the time of this release, the released CMUCL has a bug that prevents successful loading of McCLIM; CMUCL 19d + patch 1 and the 2006-12 snapshot or later contain a fix for this problem) Also, McCLIM currently does not support lisps with case-sensitive readers (ACL "modern mode" and lower-case SCL). Known Bugs ========== Due to the radical changes introduced by the new editor substrate, some bugs may surface in day-to-day use. We would very much like to hear about them on mcclim-devel(a)common-lisp.net. As a work-around, you can enable the old input substrate by using (setf climi::*use-goatee* t) on the REPL when clim is loaded. The following bugs are known to exist: * McCLIM freetype can interact poorly with Drei under some circumstances * Drei does not handle most reader macros well * Sometimes, the ENTER key is not very responsive when editing forms with Drei * Calling stream-input-buffer is still buggy. Changes in mcclim-0.9.4 "Orthodox New Year" relative to 0.9.3: ============================================================== >From the NEWS file: * cleanup: removed the obsolete system.lisp file. * backend improvements: Gtkairo ** Double buffering is now supported (fixes disappearing widgets on Windows). ** X errors no longer terminate the lisp process. ** Some bugfixes, including CMUCL support and better key event handling. ** Native implementation of context menus, list panes, label panes, and option panes. ** Draw text using Pango. (Bug fix: Fixed-width font supported on Windows now. Multiple lines of output in TEXT-SIZE supported now. TEXT-STYLE-FIXED-WIDTH-P works correctly now.) * Improvement: Added new editor substrate ("Drei"). * Improvement: Improved the pathname presentation methods considerably. * specification compliance: DELETE-GESTURE-NAME function now implemented. * specification compliance: PRESENTATION-TYPE-SPECIFIER-P presentaion function now implemented. * specification compliance: DISPLAY-COMMAND-TABLE-MENU function now implemented. * specification compliance: DISPLAY-COMMAND-MENU function now implemented. * specification compliance: POINTER-PLACE-RUBBER-BAND-LINE* function now implemented. * specification compliance: POINTER-INPUT-RECTANGLE* function now implemented. * specification compliance: POINTER-INPUT-RECTANGLE function now implemented. * Improvement: Added font listing support, see section "Fonts and Extended Text Styles" in the manual. * Improvement: Added support for bezier splines (Robert Strandh). To be documented. * better PRESENTATION-SUBTYPEP (more likely to give the right answer on some-of and all-of presentation types) * Improvement: M-n/M-p gestures for navigating presentation histories.

1 0

[mcclim-devel] mcclim 0.9.4 freeze trivia
by Kilian Sprotte 14 Jan '07

14 Jan '07

Hi, my concerns are centered around mcclim.asd for the moment... I just wanted to let you know that the current (defsystem :drei-mcclim ...) form is unREADable for openmcl. This is due to (mcclim.system::dep-on-swank) returning (or), which it does not seem to like in this context. The other thing is that asdf-binary-locations seems to have a problem with (:file "Extensions/rgb-image"), but that's probably a bug over there... Greetings, Kilian

3 3

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

← Newer
1
...
32
33
34
35
36
37
38
...
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