From csr21 at cam.ac.uk Wed May 10 13:06:13 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Wed, 10 May 2006 14:06:13 +0100 Subject: [gsharp-devel] ESA changes Message-ID: Hi, I made some changes to the esa ("emacs-style application") module in climacs this morning. The main point of it all was to allow commands to take arguments through the regular clim mechanisms, rather than prompting for their arguments themselves. For most uses, this is a relatively invisible change, but it does allow for some potentially interesting functionality. For instance, it's fairly easy to write a hook in the clim listener to make .gsh files clickable, and to make them load into an already-running gsharp: see for a non-interactive demo. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: frob.lisp URL: -------------- next part -------------- Cheers, Christophe From csr21 at cam.ac.uk Fri May 12 16:58:57 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Fri, 12 May 2006 17:58:57 +0100 Subject: [gsharp-devel] Re: [mcclim-devel] scrollbars and :command-loop In-Reply-To: <31ffd3c40605111632t76bb705dofacfc045926f2a56@mail.gmail.com> (Andy Hefner's message of "Thu, 11 May 2006 19:32:38 -0400") References: <31ffd3c40605111632t76bb705dofacfc045926f2a56@mail.gmail.com> Message-ID: [added gsharp-devel, since that's where this patch would end up...] "Andy Hefner" writes: > I struggled with this a while ago and concluded that incremental > redisplay is probably the intended solution. While Andy said this in this forum, he did provide a hint in another... on IRC, he said Xof: have you considered solving your scrolling problem by setting :display-time nil and calling your display function yourself from the top-level loop and using (clear-output-record (stream-output-history foo)) rather than window-clear? And so I tried it, and the attached patch is the result. I don't know if it's climily correct, and it might suffer a bit from suboptimality when loading in new files, but apart from that it does what I think I want it to. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: scrolling.diff URL: -------------- next part -------------- So this patch does two things: one, after doing what drawing to the score pane needs to be done, the :height space requirement is changed to whatever it needs to be; two, window-clear calls are intercepted and implemented following Andy's suggestion. Comments? Cheers, Christophe From csr21 at cam.ac.uk Wed May 24 10:02:59 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Wed, 24 May 2006 11:02:59 +0100 Subject: [gsharp-devel] clipping regions, replay, handle-repaint Message-ID: Hi, I think that CLIM underspecifies how clipping regions (and text-styles and line-styles) are handled for output records. For REPLAY-OUTPUT-RECORD, it says "The current user transformation, line style, text style, ink, and clipping region of stream are all ignored during the replay operation. Instead, these are gotten from the output record." which is good, but unfortunately it doesn't specify /how/ they are gotten, which means that implementing one's own output record class is tricky. Why does this matter? In gsharp, we implement sloped beams with our own kind of output record; as of this morning, I taught that output record, and the replay-output-record methods, about the medium clipping region, so that sloped short beams (as in ) survive repainting; previously the output record had no record of the clipping region, and so a repaint would cause the entire width, rather than just the short segment, to be drawn. So this now works acceptably. However, we implement horizontal beams with an ordinary rectangle, and short ones with an ordinary rectangle and clipping region. Before a repaint, this works fine: see . However, obscuring and uncovering the window, triggering a repaint, results in . This happens because the replay-output-record methods for the clim internal graphics things (such as rectangles) set the medium clipping region while they're replaying, but don't set it back; they simply rely on a method on replay. In fact, in McCLIM itself as distributed the set-medium-graphics-state :after method on gs-clip-mixin is essentially disabled, though I'm not entirely sure why; gsharp re-enables it, presumably in an attempt to get some of this working, but disabling it again simply means that replaying horizontal beams (i.e. rectangles) which have been clipped ignores the previous clipping region. What is one to do? Well, I think with the standard as it is there's no way of writing output record classes. However, the case of changing ink can be handled in the spec, as CLIM specifies a function displayed-output-record-ink; using that, dealing with the ink looks like (defmethod replay-output-record :around ((record displayed-output-record) stream ...) (let ((medium (sheet-medium stream))) (with-drawing-options (medium :ink (displayed-output-record-ink record)) (call-next-method)))) and this will work, given that all displayed-output-record objects obey the displayed-output-record protocol. If we were to extend the protocol to require displayed-output-record-clipping-region, displayed-output-record-text-style and displayed-output-record-line-style, then I think this would cover the difficult cases, most of the set-medium-graphics-state methods could go away, and gsharp could have horizontal short beams. Comments? Cheers, Christophe From csr21 at cam.ac.uk Sun May 28 17:54:06 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Sun, 28 May 2006 18:54:06 +0100 Subject: [gsharp-devel] Re: [mcclim-devel] clipping regions, replay, handle-repaint In-Reply-To: (Christophe Rhodes's message of "Wed, 24 May 2006 11:02:59 +0100") References: Message-ID: Christophe Rhodes writes: > Comments? Here's an implementation of a more minimal, less invasive change. SET-MEDIUM-GRAPHICS-STATE goes away and is replaced by :AROUND methods on REPLAY-OUTPUT-RECORD the various graphics state mixin types, which use WITH-DRAWING-OPTIONS to bind dynamically the various bits of graphics state that they need. The uses of SET-MEDIUM-GRAPHICS-STATE in incremental-redisplay then boil down to setting the stream cursor position; the uses of MEDIUM-GRAPHICS-STATE there actually should just retrieve the cursor position, but I haven't altered that in the source. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: output-records.diff URL: -------------- next part -------------- Then GSharp, which specializes DISPLAYED-OUTPUT-RECORD (a specified class, unlike STANDARD-DISPLAYED-OUTPUT-RECORD, where all of these changes have been occurring) can itself remember the bits of medium state it needs (ink and clipping-region), and then the effect of the graphics state of each output record is dynamically contained to its own replay, and not any other records'. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: score-pane.diff URL: -------------- next part -------------- And all this lets me put up screenshots like . I have tested a couple of other applications with this (the Address Book still works!) and nothing seems terribly amiss. I'd like a sanity check, though, and maybe consideration of whether having analogues to displayed-output-record-ink would make sense. (I think it would, and in fact I think that with this change the various bits of graphics state /are/ attached to the output record). Cheers, Christophe From csr21 at cam.ac.uk Wed May 31 15:42:23 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Wed, 31 May 2006 16:42:23 +0100 Subject: [gsharp-devel] bezier curves and postscript Message-ID: Hi, Robert's committed his work recently to implement glyphs as bezier curves (and also his X11 rasterizer for these objects). The huge advantage of this scheme is the ability to draw these things to backends other than X11; I attach a proof-of-concept for the postscript backend, which does not work for translated-regions but produces from the commented form at the bottom. (I think this is cool). -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: bez.lisp URL: -------------- next part -------------- Cheers, Christophe