mcclim-devel

mcclim-devel@common-lisp.net

820 discussions

[mcclim-devel] trying to clean up incremental-redisplay.lisp
by Robert Strandh 18 Aug '05

18 Aug '05

Hello, I am trying to clean up in incremental-redisplay.lisp. Here is what I suggest for now. If someone has objections, let me know: * get rid of *enable-updating-output*. It is initialized to t in incremental-redisplay.lisp and used there as well as in frames.lisp, but it is never set or bound. I suppose it was meant to be some kind of debugging tool, * get rid of redisplay-add-output-record and redisplay-delete-output-record which are never called, * get rid of clear-moved-record which is never called. What do you think? -- 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. ---------------------------------------------------------------------

2 2

[mcclim-devel] some patches: accepting-values and partial-commands
by Max-Gerd Retzlaff 18 Aug '05

18 Aug '05

Hi, I've found some problems in McClim yesterday and written some patches (for three of the four problems). Regards, Max-Gerd Retzlaff ======================================================================== - The example in section 10.2.1 of the clim spec v2.2: (define-editor-command (com-save-file :menu t :keystroke (:s :control)) () ...) is either an error and :keystroke (#\s :control) was meant, or it suggests that it should be possible to first define a keystroke :s like for example: (define-gesture-name :s :keyboard (#\s)) and add modifiers later. The latter does not work in McClim; modifiers that are only specified in the :keystroke argument to a define-command are simply ignored. Patch: - none - ======================================================================== - accepting-dialog should behave as if the argument align-prompts had the value :right if it is specified as T (clim spec v2.2, 13.3); only the values nil, :left, :right, and t are possible. Patch to dialog.lisp: -- zipp -- @@ -167,7 +183,10 @@ (frame-class 'accept-values)) (declare (ignore own-window exit-boxes modify-initial-query resize-frame label scroll-bars x-position y-position - width height frame-class)) + width height frame-class)) + (when (and align-prompts ;; t means the same as :right + (not (eq align-prompts :left))) + (setf align-prompts :right)) (multiple-value-bind (cx cy) (stream-cursor-position stream) (let* ((*accepting-values-stream* (make-instance 'accepting-values-stream -- zapp -- ======================================================================== - accepting-values for partial-commands The generated accepting-values shouldn't allow to be exited (via "OK") as long as decent values (i.e. matching the specified presentation type) are supplied for the required arguments of the command. Note: This is a personal taste, I haven't found anything in the clim-spec that requires such a behaviour. Proposed patch (a hack): Apply the following patch to commands.lisp: -- zipp -- --- commands.lisp.~1.53.~ 2005-06-28 06:32:46.000000000 +0200 +++ commands.lisp 2005-08-18 02:05:11.975682512 +0200 @@ -746,6 +746,7 @@ ;; We don't need fresh gensyms of these variables for each accept form. (with-gensyms (value ptype changedp) `(defun ,name (,command-table ,stream ,partial-command) + (do ((still-missing nil t)) (nil) (destructuring-bind (,command-name ,@original-args) ,partial-command (let ((,command-line-name (command-line-name-for-command @@ -755,7 +756,7 @@ ,@(mapcar #'list required-arg-names original-args)) (accepting-values (,stream) (format ,stream - "You are being prompted for arguments to ~S~%" + "You are being prompted for arguments to ~S~%~%" ,command-line-name) ,@(loop for var in required-arg-names @@ -767,9 +768,16 @@ (declare (ignore ,ptype)) (terpri ,stream) (when ,changedp - (setq ,var ,value)))))) - (list ,command-name ,@required-arg-names)))))))) - + (setq ,var ,value))))) + (when still-missing + (format ,stream + "~&Please supply all arguments."))) + (setf ,partial-command (list ,command-name ,@required-arg-names)) + (unless (partial-command-p ,partial-command) + (return ,partial-command)))))))))) ;;; XXX What do to about :acceptably? Probably need to wait for Goatee "buffer ;;; streams" so we can insert an accept-result-extent in the buffer for -- zapp -- ======================================================================== - exit-boxes of accepting-values; 13.3 of the clim spec v2.2 says: -- zipp -- exit-boxes [...] The default behavior is as though you specified the following: '((:exit "OK") (:abort "Cancel")) -- zapp -- The default behavior of McClim correspondends to '((:exit "Exit") (:abort "Abort")) at the moment. Patch: Replace the strings "Exit" and "Abort" in #'display-exit-boxes of dialog.lisp by "Exit" and "Abort", respectively. Patch to dialog.lisp: -- zipp -- --- dialog.lisp.~1.19.~ 2005-02-27 21:52:49.000000000 +0100 +++ dialog.lisp 2005-08-17 08:43:20.000000000 +0200 @@ -224,11 +243,11 @@ (fresh-line stream) (with-output-as-presentation (stream nil 'exit-button) - (format stream "Exit")) + (format stream "OK")) (write-char #\space stream) (with-output-as-presentation (stream nil 'abort-button) - (format stream "Abort")) + (format stream "Cancel")) (terpri stream))) (defmethod stream-accept ((stream accepting-values-stream) type -- zapp -- ======================================================================== -- Max-Gerd Retzlaff <m.retzlaff(a)gmx.net> For your amusement: The human brain is a wonderful thing. It starts working the moment you are born, and never stops until you stand up to speak in public. -- Sir George Jessel

2 1

[mcclim-devel] A new example application for CLIM (town-example.lisp)
by Max-Gerd Retzlaff 18 Aug '05

18 Aug '05

And again.. I had quite a productive day regarding clim programming yesterday; one of the outcomes is the following example for CLIM programming. It tries to demonstrate the following topics: custom view classes, different present presentation methods for different views, completion for accept presentation methods, accepting-values dialogues, presentation to command translators, partial commands in menus, automatically generated menus, and keystroke gestures for commands. At the same time I tried to make the application as simple as possible. As in: Not doing fancy stuff to make the application less senseless (as an application) or more visually appealing. You'll find a screenshot at: http://bl0rg.net/~mgr/flux/town-example.png The code is located at http://bl0rg.net/~mgr/flux/town-example.lisp and also attached to this email. Any comments and proposals for changes are welcome! Did I do something that would better have been done in a different way? Then, please, enlighten me! I currently think about expanding it to a real tutorial with some explanations. But I don't know whether I'll have the time to do it. Regards, Max -- Max-Gerd Retzlaff <m.retzlaff(a)gmx.net> For your amusement: aphorism, n.: A concise, clever statement. afterism, n.: A concise, clever statement you don't think of until too late. -- James Alexander Thom

1 0

[mcclim-devel] tow more patches
by Max-Gerd Retzlaff 18 Aug '05

18 Aug '05

Hi, here are two additional patches. Bye, Max ======================================================================== - :own-window of accepting-values is not implemented I've made a patch based on clim:open-window-stream. Consider it to be a quick and *dirty* hack. Look at the sleep.. -- zipp -- --- dialog.lisp.~1.19.~ 2005-02-27 21:52:49.000000000 +0100 +++ dialog.lisp 2005-08-18 03:21:37.284609600 +0200 @@ -136,6 +136,30 @@ (defvar *accepting-values-stream* nil) +(defmacro with-stream-in-own-window ((&optional (stream '*query-io*) + &rest further-streams) + &rest body) + `(let* ((,stream (open-window-stream)) + ,@(mapcar (lambda (a-stream) + (list a-stream stream)) + further-streams)) + (sleep 0.1) ;; hackhack.. some delay to "ensure" that the window-stream ist opened + (unwind-protect + (progn + ,@body) + (close ,stream)))) + (defmacro accepting-values ((&optional (stream t) &rest args @@ -144,17 +168,22 @@ align-prompts label scroll-bars x-position y-position width height command-table frame-class) &body body) - (declare (ignorable own-window exit-boxes initially-select-query-identifier + (declare (ignorable exit-boxes initially-select-query-identifier modify-initial-query resynchronize-every-pass resize-frame align-prompts label scroll-bars x-position y-position width height command-table frame-class)) (setq stream (stream-designator-symbol stream '*standard-input*)) (with-gensyms (accepting-values-continuation) + (let ((return-form `(flet ((,accepting-values-continuation (,stream) ,@body)) (invoke-accepting-values ,stream #',accepting-values-continuation - ,@args)))) + ,@args)) + )) + (if own-window + `(with-stream-in-own-window (,stream *standard-input* *standard-output*) ,return-form) + return-form)))) (defun invoke-accepting-values (stream body -- zapp -- ======================================================================== - A patch to open-window-stream to be able to do modify the display-function of the created window-stream afterwards, as in: (let ((stream (open-window-stream))) (setf (slot-value stream 'climi::display-function) (lambda (frame pane) (declare (ignore frame)) (write-string "foo" pane))) stream) and not having to explicitly call (redisplay-frame-panes (pane-frame *) :force-p t) after changing the display function. The standalone-event-loop for open-window-stream is quite Spartan. The default-frame-top-level includes a call to redisplay-frame-panes with force (only for the first time) before calling simple-event-loop as well. I conclude that calling redisplay-frame-panes in open-window-stream is the right thing to do. By the way, standard-event-loop is complete copy of simple-event-loop aside from two lines of code to handle FRAME-EXIT. Not very nice. Patch to panes.lisp - zipp - --- panes.lisp.~1.153.~ 2005-06-24 01:12:42.000000000 +0200 +++ panes.lisp 2005-08-18 03:48:55.298593624 +0200 @@ -2591,6 +2596,8 @@ #+clim-mp (unless input-buffer (clim-sys:make-process (lambda () (let ((*application-frame* frame)) + (redisplay-frame-panes frame :force-p t) (standalone-event-loop))))) (slot-value frame 'stream))) - zapp - ======================================================================== -- Max-Gerd Retzlaff <m.retzlaff(a)gmx.net> For your amusement: My brother sent me a postcard the other day with this big satellite photo of the entire earth on it. On the back it said: "Wish you were here". -- Steven Wright

1 0

[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 16 Aug '05

16 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

← Newer
1
...
58
59
60
61
62
63
64
...
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