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

[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 for possbility sorting
by rpgoldman＠real-time.com 07 Apr '06

07 Apr '06

In BEIRC, one can end up with an enormously long list of candidate possibilities for completing a command, because IRC has so many commands. The possibilities are not ordered at all, so the list is pretty much useless. The following patch to input-editing would fix this problem by sorting the set of possibilities alphabetically. I realize that this may not be optimal, because it's a "one size fits all" solution. OTOH, it's clearly better than just getting an arbitrarily permuted list, so I suggest that it be adopted. I have commit privs, but have mostly used them for documentation and Allegro-specific compatibility fixes, so I'd love some validation (or reasoned rejection) before committing. Thanks all, R P.S. It occurs to me that we could avoid pointlessly sorting length 1 lists by dumping the call to sort inside the VALUES call in the ELSE branch of the final if of complete-from-generator-possibilies. But that shouldn't change the question of whether this is a good idea or not... --- input-editing.lisp 10 Mar 2006 21:58:13 -0000 1.49 +++ input-editing.lisp 7 Apr 2006 19:00:18 -0000 @@ -781,6 +781,9 @@ (defun complete-from-generator-possibili (incf nmatches) (push (cons str obj) possibilities)))) (funcall generator initial-string #'suggester) + ;; attempting to get the list of candidates sorted [2006/04/07:rpg] + (setf possibilities + (sort possibilities #'string-lessp :key #'car)) (if (and (eql nmatches 1) (string-equal initial-string (caar possibilities))) (values (caar possibilities)

2 3

[mcclim-devel] scroll
by Irene DURAND 07 Apr '06

07 Apr '06

Hello, With the latest version of mcclim, my application Autowrite has a problem that wasn't there before. When I scroll up a scrolling pane the top of the pane is empty and I cannot see anymore what was at the top of the pane. -- Irène DURAND http://dept-info.labri.u-bordeaux.fr/~idurand

1 1

[mcclim-devel] issues (bug?) with with-tab-layout in beirc
by rpgoldman＠real-time.com 04 Apr '06

04 Apr '06

I was trying to debug a space requirement issue in beirc, so I wanted to grab hold of its tab-layout-pane (which is named 'query). Oddly, I find that (get-frame-pane <frame> 'query) returns nil. I managed to use a back door to find the pane, and it *does* have a name: BEIRC(31): (slot-value tab-pane 'climi::name) QUERY It was defined as follows: (:layouts (default (vertically () (with-tab-layout ('receiver-pane :name 'query) ("*Not Connected*" server 'receiver-pane)) ;; (68 io) ;; no drop-shadow prompt (make-pane 'clim-extensions:box-adjuster-gadget) io (20 pointer-doc) (20 ;<-- Sigh! Bitrot! status-bar)))) The with-tab-layout does have the :name option, and it invokes make-pane. AFAICT, make-pane should stuff *application-frame* into an arglist and invoke make-pane-1, which should stash this pane away in the named-panes slot of the *application-frame*. But this is evidently not happening (or, I suppose, that slot could be overwritten). Alternatively, I suppose that *application-frame* might be unbound at the time this with-tab-layout gets evaluated? I'm pretty sure that this is a bug, and that the tab-layout pane IS intended to be exposed to get-frame-pane. But I'm not sure how to fix it, myself. Thanks, R

4 6

[mcclim-devel] define-presentation-type
by Christophe Rhodes 02 Apr '06

02 Apr '06

Hi, I think I just got bitten by the (specified) restriction that one can't inherit-from OR presentation types in define-presentation-type. It would have saved me some time if McCLIM had detected my erroneous code earlier -- is that possible? Cheers, Christophe

2 1

[mcclim-devel] eps bug
by David Lewis 01 Apr '06

01 Apr '06

Hi, If this was me, I apologise now, but somehow eps output from invoke-with-output-to-postscript-stream now always gives a bounding box with 0 width. This should fix it: --- Backends/PostScript/sheet.lisp 7 Mar 2006 15:43:44 -0000 1.13 +++ Backends/PostScript/sheet.lisp 30 Mar 2006 13:12:10 -0000 @@ -74,11 +74,11 @@ ((:eps) (let ((record (stream-output-history stream))) (multiple-value-bind (lx ly ux uy) (bounding-rectangle* record) - (setf translate-x (- (ceiling lx)) + (setf translate-x (- (floor lx)) translate-y (ceiling uy)) (format file-stream "%%BoundingBox: ~A ~A ~A ~A~%" 0 0 - (+ translate-x (floor lx)) + (+ translate-x (ceiling ux)) (- translate-y (floor ly)))))) (t (multiple-value-bind (width height)

2 1