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

[mcclim-devel] frames with multiple layouts
by rpgoldman＠real-time.com 17 Aug '05

17 Aug '05

I've used multiple layouts to give me a kind of modal UI. It seemed easier to have multiple, simple diplay functions instead of a single complex one. All well and good, but now I find that when I change layouts, the size of the frame changes. This is annoyingly distracting, especially since it happens in an odd way: 1. go to layout 1. 2. Maximize the window. 3. Go to layout 2. Window shrinks. 4. Return to layout 1. Window has shrinky size of layout 2. Is there some relatively easy way to make CLIM assign the frame a size that is the MAX of all of the sizes of the individual layouts? Thanks, R

1 0

[mcclim-devel] minor bug in CLIM-LISTENER or in FORMAT-GRAPH-FROM-ROOTS
by rpgoldman＠real-time.com 16 Aug '05

16 Aug '05

Often, I find when graphing classes in the CLIM-LISTENER, that I will run off the window size. The reason is that neither the class-grapher, which invokes format-graph-from-roots, nor format-graph-from-roots, calls change-space-requirement on its stream. I'm not at all sure what's the proper fix. It seems to me that Format-graph-from-roots should call change-space-requirements, because I can't imagine a case where one wouldn't want to after drawing a graph. But I recall raising this issue on #lisp one day, and having people argue that they preferred NOT to have anything automatically call change-space-requirements, that this should be left to the programmer, in the interests of efficiency, so that that programmer could bundle up a large number of window writes before updating the space requirements. So, what's the consensus of the group? Where should this be fixed? Robert

1 0

[mcclim-devel] another incremental redisplay problem
by Robert Strandh 15 Aug '05

15 Aug '05

Hello, Incremental redisplay uses objects of type output-record to determine what to redisplay. Output records are subclasses of bounding-rectangle. But bounding-rectangle is not a subclass of region, so one cannot use region-intersects-region-p to check whether two output records overlap. But this is in fact the case in the current incremental redisplay code. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. ---------------------------------------------------------------------

1 0

[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