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

[mcclim-devel] text with negative x-offsets
by Christophe Rhodes 14 Aug '05

14 Aug '05

[ to the real mcclim-devel address, this time ] Hi, Find attached a preliminary patch to deal with the fact that, in general, glyphs from fonts are not constrained to draw only to the right of the cursor position. This patch does not correct any of the assumptions about horizontal left-to-right rendering or single-line rendering. However, it attempts to cater for all cases which are currently functional, for the CLX backend (both with ordinary X fonts and with the experimental Freetype bindings). It is probably fairly tricky to trigger problems without this patch using the ordinary X fonts, but using the Bitstream Vera family of fonts in climacs for a little while tends to degrade the display as incremental-redisplay fails to erase the entirety of glyphs (because the bounding rectangle is wrong). It works by introducing a new internal function, TEXT-BOUNDING-RECTANGLE*, which is somewhat analogous to TEXT-SIZE and STREAM-STRING-WIDTH, only capable of dealing with non-zero offsets. TEXT-BOUNDING-RECTANGLE* returns the coordinates of a bounding rectangle that would bound the output of DRAW-TEXT* at position 0 0 and with :ALIGN-X and ALIGN-Y taking their default values. It is entirely possible that I have miscalculated some of the other cases in DEF-GRECORDING DRAW-TEXT: caveat user. With this patch, I was no longer able to trigger disastrous redraw effects on simple climacs editing operations; previously, entering " ___" on a line, putting point at the start of the line and then hitting the space bar a few times would leave a trail of pixels as the output records for almost all the text would move (on my display here, with my freetype options, the #\_ character has an active pixel at -1). The real test case for this is the tablature editor, which is using a font designed such that the centres of characters are at (0,0); unfortunately, I'm not in a position to run it right now, but with luck we'll be able to test this tomorrow (and extend this work to the Postscript backend: maintainers of other backends should chime in at this point to indicate whether this solution is acceptable and implementable :-). Cheers, Christophe

2 4

[mcclim-devel] bug in incremental redisplay with OUTPUT-RECORD-HASH
by Taylor Campbell 12 Aug '05

12 Aug '05

When redrawing a Climacs screen, either by hitting C-l or just moving the screen around, I consistently got an error about OUTPUT-RECORD-HASH having no applicable methods for STANDARD-BOUNDING-RECTANGLE. After a little analysis of incremental-redisplay.lisp, it looks like the first method of OUTPUT-RECORD-HASH defined in incremental-redisplay.lisp should be specialized on STANDARD-RECTANGLE, or at the very least STANDARD-BOUNDING-RECTANGLE, instead of BASIC-OUTPUT-RECORD, because it will at some point get a STANDARD-BOUNDING-RECORD that is not also a BASIC-OUTPUT-RECORD: The OLD-BOUNDS slot of UPDATING-OUTPUT-RECORD-MIXIN has an initform of a call to MAKE-BOUNDING-RECTANGLE, which returns an instance of STANDARD-BOUNDING-RECTANGLE. COMPUTE-DIFFERENCE-SET (which is where the error was signalled when Climacs borked) collects the values of OLD-BOUNDS slots into a list and then puts elements of that list as keys into a table, using OUTPUT-RECORD-HASH to convert them into keys. Unless the OLD-BOUNDS slot is meant to be a BASIC-OUTPUT-RECORD instance more specifically than a STANDARD-BOUNDING-RECORD, the method isn't specific enough to handle this. (The COORDINATES slot is defined in the STANDARD-RECTANGLE class, which is why I suggested it as the least specific possible class to specialize the OUTPUT-RECORD-HASH method on, which just returns the value of that slot.) I'm no McCLIM expert, so the solution of specializing the method differently may be the wrong thing, and the right thing may be to fix the value of the OLD-BOUNDS slot, but changing the specializer seems to work here, and I don't have any specific suggestions on fixing it the other way (changing the value of the OLD-BOUNDS slot). Can anyone else comment on this fix or, if it is the right thing, commit it? (I'm told that it's Tim Moore's code.)

1 0

[mcclim-devel] two fixes for graph formatting
by rpgoldman＠real-time.com 12 Aug '05

12 Aug '05

Previously format-graph-from-roots would crash if given a :duplicate-test argument that wasn't one of the equality predicates accepted by make-hash-table. Previously format-graph-from-roots would crash if asked to format a :dag. This is fixed. Sorta. I'm not bragging about the dag layout method --- it really needs a nice layering, but doesn't have one yet. But I hope it's better than crashing! Note that it will /still/ crash if asked to format a general :digraph. When I was testing this, I discovered that FORMAT-GRAPH-FROM-ROOT, the singleton wrapper, wasn't exported from the CLIM package. Since it's required by the spec, I added the export, and committed package.lisp. My first commit. Hope I haven't gaffed anything! Seems like the clim-listener still works, and that's really my only test case... Cheers, R

2 1

[mcclim-devel] Broken links to mcclim-devel message archive
by Paolo Amoroso 12 Aug '05

12 Aug '05

It looks like links established in the past to messages in the mcclim-devel mailing list are now broken. Any changes to the list archive? McCLIM users maintain a wiki-based bug list at: http://mcclim.cliki.net/Bug Each entry has links to relevant messages in mcclim-devel. But such links are now essentially lost. I also have many such links in my blog, where I periodically report about McCLIM development. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log

2 7

[mcclim-devel] bug list on mcclim cliki
by rpgoldman＠real-time.com 12 Aug '05

12 Aug '05

Alas, while the links to the mail archive no longer dangle, they don't work, either. I was looking at some of the links in the bug list, and they are garbled and point to the wrong thing. E.g., the link for "Graph nodes are incorrectly placed when scale factor <> 1" now points to this email: [mcclim-devel] Copying text to clipboard loops displaying messages to Konsole Paolo Amoroso amoroso at mclink.it Tue Mar 22 17:11:24 CET 2005 * Previous message: [mcclim-devel] Copying text to clipboard loops displaying messages to Konsole * Next message: [mcclim-devel] more beagle stuff * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] Christophe Rhodes <csr21 at cam.ac.uk> writes: > Right. Reading around the web indicates that Klipper is not > completely alone in its strategy of polling the selection owner for > the timestamp of its selection ownership to see if anything has > changed. > > I've therefore committed more-or-less what I sent, along with > something which disables logging these events to the console. I hope > that I haven't broken anything in the process. Text paste seems to be working fine with Klipper now. Paolo

1 0

[mcclim-devel] question about CLIM listener and FORMAT-GRAPH-FROM-ROOTS
by rpgoldman＠real-time.com 11 Aug '05

11 Aug '05

I found that the clim-listener calls format-graph-from-roots with :tree as the graph type, but :merge-duplicates=t. The spec sorta ambiguously suggests that these aren't compatible. Is there any reason why you did this? Of course, it's possible that this was because formerly there was no layout method for :dag or :digraph, and :merge-duplicates=t would force the choice of one of those methods.... But I had thought about sending a warning if one made this choice, and turning off :merge-duplicates in that case. So I would like to make sure this wouldn't be a problem. Would you mind having to change to :tree and :merge-duplicates=nil? Best, R

2 1

[mcclim-devel] patch for CLIM-LISTENER on Allegro
by Robert P. Goldman 10 Aug '05

10 Aug '05

I was just looking over the clim-listener to see how the wholine worked, and in passing found that its recipe for getting a user id doesn't work on Allegro. Here's a quick patch. As an aside, I couldn't find anything that would provide a description of mem usage that would fit the one-liner in here for other lisps. All I could find was ROOM, which seemed to give too much information.... Finally, is there any reason we shouldn't all set ;; Set this to true if you want the listener to bind *debug-io* to the ;; listener window. (defparameter *listener-use-debug-io* #+hefner t #-hefner nil) to T instead of NIL? For me, at least on Allegro, the utility of the system is vitiated by having it lock up and dump the debug output into my emacs window. But perhaps there's a downside to this that I don't know about.... Best, R Index: listener.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/Apps/Listener/listener.lisp,v retrieving revision 1.21 diff -u -F^(def -r1.21 listener.lisp --- listener.lisp 11 Jan 2005 05:26:26 -0000 1.21 +++ listener.lisp 10 Aug 2005 21:56:46 -0000 @@ -72,7 +72,8 @@ (defun generate-wholine-contents (frame (declare (ignore frame)) (let* ((*standard-output* pane) (username (or #+cmu (cdr (assoc :user ext:*environment-list*)) - #-cmu (getenv "USER") + #+allegro (sys:getenv "USER") + #-(or allegro cmu) (getenv "USER") "luser")) ; sorry.. (sitename (machine-instance)) (memusage #+cmu (lisp::dynamic-usage)

1 0

Re: [mcclim-devel] pathname and accept
by rpgoldman＠real-time.com 10 Aug '05

10 Aug '05

Sorry. Let me be more clear (or at least more specific). I have an application that is an MDP (Markov Decision Problem) solver. I have a command that loads a file with an MDP description in it. So I want to ACCEPT a pathname that corresponds to an existing MDP description file. So I want ACCEPT to reject any pathname that doesn't (at least) correspond to a file that really exists. It's a bit of a nuisance, when I use the current UI (which doesn't enforce file existence), to type in a filename, find out that I mistyped, and then have to start over. I would prefer to have ACCEPT help me out by rejecting my input and allowing me to revise it. Does that help? The best test example I could find was the following: (in-package :CLIM-USER) ;;; this stuff doesn't work as well as I would like, unfortunately. [2005/08/10:rpg] (define-presentation-type extant-pathname () :inherit-from 'pathname) (define-presentation-method presentation-typep (object (type extant-pathname)) (and (presentation-typep object 'pathname) (probe-file object))) (define-presentation-method accept ((type extant-pathname) stream view &rest args &key) (let ((raw-value (call-next-method))) (when (probe-file raw-value) (return-from accept (values raw-value 'extant-pathname))) (format stream "~&No directory entry for ~A ~%" raw-value) (apply #'accept type :stream stream :view view args))) But when I try to do this, and type in a pathname that does not correspond to an extant file, it seems to return some odd default. McCLIM correctly rejects the bad value, and prints my format string, but instead of giving me a chance to enter a good value, it just returns the current working directory! (I'd show the results, but I tested in the clim-listener, whence I cannot cut-and-paste :-/). I'm hoping that I've just done something dopey here, and that's why this doesn't work. [BTW, I was poking around at the CLIMACS code base to see if I could pull out a completing-pathname type, but I thought I would see if I could get the existence constraint to work first...]

1 0

[mcclim-devel] pathname and accept
by rpgoldman＠real-time.com 10 Aug '05

10 Aug '05

[Apologies if this is a dumb question...] AFAICT there's no way for me to try to ACCEPT a pathname that is constrained to refer to a file that already exists. Is this true? I could imagine trying to create a new presentation subtype of pathname that would meet this constraint. But doesn't it seem that it would have been reasonable to make a pathname a compound type that would allow for constraints? Also, I have been looking at the Allegro CLIM UG and the CLIM 2 spec, and I have not been able to determine what sort of guarantees ACCEPT provides. When it reads one of my previously-existing pathnames, for example, will it be obligated to run presentation-typep at some point to check that the filename is actually previously-extant? Or is it allowed to just hope that the user has typed in a string that refers to a previously-existing filename, instead of the name of his grandmother's dog? I don't know exactly how to test this, but my rudimentary tests with trace seem to indicate that ACCEPT isn't doing any verification. Is that right? If so, and I want to enforce this constraint, should I be making an :around method for accept that will check the constraint and either return if it's satisfied, or invoke call-next-method if it's violated? I would have thought that there would have been some protocol for bad input (e.g., raise a particular exceptionq), but my cursory examination of the spec doesn't reveal any such. Thanks, Robert

3 5

[mcclim-devel] question about error message
by rpgoldman＠real-time.com 09 Aug '05

09 Aug '05

I run my mcclim application in a separate process under Allegro CL 6.2. Periodically I get the following kind of oddity appearing in my main REPL window (not one of the McCLIM windows): #<GOATEE::BUFFER-BOUNDS-ERROR @ #x7209b98a> #<GOATEE::BUFFER-BOUNDS-ERROR @ #x7209c582> #<GOATEE::BUFFER-BOUNDS-ERROR @ #x7209d05a> Any idea what this might mean? Am I worried? R

1 0