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

[mcclim-devel] Scrollbar/text-editor-bug in McCLIM?
by Troels Henriksen 05 Mar '06

05 Mar '06

Observe the behavior of this simple application: (define-application-frame buggy-editor () () (:panes (text-edit :text-editor) (interactor :interactor :scroll-bars nil)) (:layouts (default (vertically () (scrolling (:scroll-bars t) text-edit) (scrolling (:scroll-bars t) interactor))))) If a line wider than the pane is written to the text-editor pane, it will correctly update the scroll-bars and the pane size to allow one to navigate through the entire line. This does not happen when more lines are inserted than it is possible to display in the pane, though: in that case, the horizontal scrollbars will not be adjusted, thus rendering it impossible to see the surplus lines. Is this behavior a bug in my application or in McCLIM? -- \ Troels "Athas" Henriksen /\ sigkill.dk - KILL -9

1 0

[mcclim-devel] [patch] make goatee search & execute frame commands by gesture
by Andreas Fuchs 26 Feb '06

26 Feb '06

Hi all, as it is now, goatee doesn't search for commands by keystroke gesture in the application frame's command table. This means that any command-invoking keystrokes that are entered when goatee is active will be ignored. This seems to affect all applications that have an interactor pane, like beirc. So, here's a patch that makes goatee search for & execute the command in the current application frame, if there is one. I'm not sure if this is the right thing to do, but it allows us to use keystroke accelerators in beirc commands, so I'd like it to go in, after goatee-literate people (hi, tim!) have OKed it. Here's the patch (sorry for the big hunk; the upper part is what I changed; the lower part is emacs cl-indent playing games): Cheers, -- Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs

1 1

[mcclim-devel] Spiffy code sought for elegant pop-up dialog!
by Peter Braroe 22 Feb '06

22 Feb '06

Hello all! As I have understood, it seems that :own-window t for accepting-values or NOTIFY-USER is not available yet in McCLIM. I really have my heart set on using a pop-up windows to manage prefs etc. but it seems non-trivial... What I want to do is: 1 Create a child window 2A Populate with text-fields, checkboxes, and buttons (like gadet-test) 2B Add "Save" button and method that returns/stores the values selected 3 Move focus to child, put original window in background 4 Destroy child window, refocus on original window It certainly seems possible looking at the Clim spec, but when I google it seems that I can't find much about it or examples. Sooo i am wondering if there is a reason for this... So if anyone has a nice example* of how to do this that would be a dream, and if not the next best thing would be if someone had a clear understanding of how it should be donwe. And if not some vauge ideas on how to get started, and where to look would be excellent! Thanks all! /Peter (*Even just a "About" pop-up example would be loveley!)

5 7

[mcclim-devel] Error while compiling PostScript backend
by Paolo Amoroso 19 Feb '06

19 Feb '06

I have tried building from scratch the latest McCLIM CVS sources with CMUCL Snapshot 2005-11 (19C) under Linux, and compilation stops with the error: [...] ; /home/paolo/src/dev/mcclim/Goatee/presentation-history.x86f written. ; Compilation finished in 0:00:00. ; Loading #P"/home/paolo/src/dev/mcclim/Goatee/presentation-history.x86f". ; Loading #P"/home/paolo/src/dev/mcclim/Backends/PostScript/sheet.x86f". Execution of a form compiled with errors: (DEFMETHOD SHEET-DIRECT-MIRROR ((SHEET POSTSCRIPT-STREAM)) (POSTSCRIPT-STREAM-FILE-STREAM SHEET)) [Condition of type KERNEL:SIMPLE-PROGRAM-ERROR] Restarts: 0: [CONTINUE] Return NIL from load of #P"/home/paolo/src/dev/mcclim/Backends/PostScript/sheet.x86f". 1: [RETRY ] Retry performing #<ASDF:LOAD-OP NIL {5837C315}> on #<ASDF:CL-SOURCE-FILE "sheet" {5837C145}>. 2: [ACCEPT ] Continue, treating #<ASDF:LOAD-OP NIL {5837C315}> on #<ASDF:CL-SOURCE-FILE "sheet" {5837C145}> as having been successful. 3: [ABORT ] Return to Top-Level. Debug (type H for help) (C::DO-CALL #<Code Object "Top-Level Form" {580C4017}> 78 79 4 ...) Source: Error finding source: Error in function DEBUG::GET-FILE-TOP-LEVEL-FORM: Source file no longer exists: target:code/byte-interp.lisp. 0] Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log

2 2

[mcclim-devel] mcclim.org domain: still active?
by Paolo Amoroso 18 Feb '06

18 Feb '06

If I try to connect to: http://www.mcclim.org I get a server not found error. Is the mcclim.org domain still active? Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log

1 0

[mcclim-devel] Writing single-line strings to clim-stream-panes
by Troels Henriksen 17 Feb '06

17 Feb '06

Assume an instance of a standard clim-stream-pane with a width and height of 0 respectively (though the issue concerns panes of all sizes). If one prints a string *with* linebreaks to this pane, it will properly resize itself to accommodate the text. If the string does *not* include linebreaks, however, the pane will not be resized (and thus, not be visible by the user). I consider this a bug. A possible solution, and the one I have followed due to my lack of insight into McCLIM internals, is to modify `seos-write-string' in stream-output.lisp to call `change-space-requirements' on the pane with a :min-height parameter of the height of the string being printed. This does ensure that the pane is never too small to accommodate the string, but it is certainly an ugly hack. Does anyone else have a better solution? -- \ Troels "Athas" Henriksen /\ sigkill.dk/blog (Danish)

4 6

[mcclim-devel] Threading and Waiting
by John Connors 14 Feb '06

14 Feb '06

While looking for the 'right' way to get a SCBL thread to wait for a specified condition as part of an attempt to update port from the CLOCC, I came across this gem in the McCLIM sources. (declaim (inline yield)) (defun yield () (declare (optimize speed (safety 0))) (sb-alien:alien-funcall (sb-alien:extern-alien "sched_yield" (function sb-alien:int))) (values)) (defun process-wait (reason predicate) (let ((old-state (process-whostate *current-process*))) (unwind-protect (progn (setf old-state (process-whostate *current-process*) (process-whostate *current-process*) reason) (loop (let ((it (funcall predicate))) (when it (return it))) ;(sleep .01) (yield))) (setf (process-whostate *current-process*) old-state)))) Now this will work, but my understanding is when calling sched_yeild, a thread gets completely expired and put at the back of the scheduling queue. What was/is wrong with sleep?

2 1

[mcclim-devel] Guided Tour of CLIM
by Clemens Fruhwirth 09 Feb '06

09 Feb '06

Here is my draft of an update to CLIM tutorial. http://clemens.endorphin.org/A%20Guided%20Tour%20of%20CLIM%202006-draft.pdf I plan to put it into the mcclim repository under Doc/, so others can enhance it if desired. I will probably post an other update myself, as I originally planned to write more (incremental updates, accepting- values and a spreadsheet examples are missing). But I rather felt like it's better to release it early than never. Feedback is appreciated. -- Fruhwirth Clemens - http://clemens.endorphin.org for robots: sp4mtrap(a)endorphin.org

5 6

[mcclim-devel] Class precedence error with sheet.lisp and cmucl
by Raymond Toy 09 Feb '06

09 Feb '06

While compiling mcclim from a cvs checkout of 2006-02-08 using the latest cmucl snapshot, I get an error when compiling Backend/Postscript/sheet.lisp. The error message is Error in function PCL::CPL-ERROR: While computing the class precedence list of the class named POSTSCRIPT-STREAM: The class named CLIM-INTERNALS::UPDATING-OUTPUT-STREAM-MIXIN is a forward referenced class. The class named CLIM-INTERNALS::UPDATING-OUTPUT-STREAM-MIXIN is a direct superclass of the class named POSTSCRIPT-STREAM.. [Condition of type SIMPLE-ERROR] I guess this might be a bug in cmucl's PCL. Ray

1 0

Re: [mcclim-devel] incremental redisplay slowness and local patches
by pw＠snoopy.mv.com 09 Feb '06

09 Feb '06

> > This, however, uses a scary clim-internals internal symbol. That's > fine up to a point, but it would be better from our point of view if > there were a way of doing this in a documented way; is there a > spec-blessed way of having a custom incremental-redisplay method > called? Alternatively, can climi::window-stream be documented and > exported? Any other ideas? I have not tried this myself, but there is the :record-type keyword to updating-output where you can supply your own class of output-record. Then redisplay-output-record on what that returns should do what you want. No? Paul

2 1