mcclim-devel

mcclim-devel@common-lisp.net

820 discussions

[mcclim-devel] Attempt to make (accept 'expression) more interaction-friendly.
by Troels Henriksen 23 Jan '06

23 Jan '06

First a disclaimer: I'm not at all sure what consequences the patch included with this post has on other parts of McCLIM, so it probably shoulnd't be used without an experienced McCLIM'er taking a look at it. It is a solution to a problem that has annoyed me, and I haven't detected any malfunctions in other parts of McCLIM, so perhaps it's safe... In existing McCLIM, if you type a single "(" (without the quotes) at the McCLIM-Listener, you will instantly end up in the debugger with a reader-error due to unbalanced parantheses. This struck me as unnecessarily harsh, especially since the input entered at the Listener will be gone when the debugger is exited. The patch specializes the `accept' method for objects of type `expression' for streams of type `input-editing-stream' to ignore reader errors and let the user continue typing. If the entered input is still malformed when the user presses RETURN, it will be handled in a SLIME-style way, that is, a newline will be inserted and the expression will remain editable (and fixable). I have used the patch for the last week or so and have experienced no problems, but I could imagine that such a relatively crude modification to an important McCLIM-function could have some unexpected side-effects. Use at own risk. :-) -- \ Troels "Athas" Henriksen /\ sigkill.dk/blog (Danish)

1 0

[mcclim-devel] Auto-nag: mcclim link verifier failed
by root＠common-lisp.net 23 Jan '06

23 Jan '06

You are being nagged on because your project's name showed up in the nightly Checkbot run. Checkbot checks for broken links etc. This probably means that you are either pointing to a broken link or that someone is pointing to a broken link on your site. Or something else, it check's a bunch of stuff. Update your webpages or you shall be nagged again next week. To find out what's wrong with your webpages, please consult: http://common-lisp.net/checkbot/checkbot-common-lisp.net.html Any questions? You can reach the author of this cronjob at clo-devel(a)common-lisp.net Thanks!

1 0

[mcclim-devel] clisp build issues
by Scott Williams 22 Jan '06

22 Jan '06

Starting with CVS mcclim: clisp -K full -x "(asdf:operate 'asdf:load-source-op :mcclim)" .....[snip]..... *** - MAKE-PATHNAME: illegal :NAME argument "Experimental/menu-choose" This seems to be related to ASDF. If I modify mcclim.asd by removing the slash in the filenames: - (:file "Experimental/menu-choose" ..... + (:file "Experimental.menu-choose" ....... - (:file "Goatee/presentation-history" ...... + (:file "Goatee.presentation-history" ...... - (:file "Looks/pixie" ...... + (:file "Looks.pixie" ...... I have no idea what the kosher way to fix this is. Any ideas? I can get all the way to: *** - READ from #<INPUT BUFFERED FILE-STREAM CHARACTER #P"/home/scottw/.asdf/site/mcclim/Backends/CLX/port.lisp" @1048>: there is no package with name "EXTERNAL-FORMAT" where mcclim wants external-format::ascii-code-to-font-index which is defined medium.lisp. However, mcclim.asd says medium.lisp depends on port.lisp. I'm not quite sure what the right way to resolve this is? In the mean time, in the debugger, I can create the package and the function: Break 1 CLIM-CLX[8]> (make-package "EXTERNAL-FORMAT") Break 1 CLIM-CLX[8]> (defun ascii-code-to-font-index (code) (values code (<= #x00 code #x7f))) Break 1 CLIM-CLX[8]> (export 'ascii-code-to-font-index 'external-format) and redoing the read operation with the redo restart. This allows the loading to continue to *** - READ from #<INPUT BUFFERED FILE-STREAM CHARACTER #P"/home/scottw/.asdf/site/mcclim/Backends/CLX/port.lisp" @1394>: #<PACKAGE XLIB> has no external symbol with name "SET-SELECTION-OWNER" which is a clisp packaging error i fixed by exporting (export 'xlib::set-selection-owner 'xlib) and redoing the read (I'll pass this on to the clisp maintainers). Then the loading of mcclim is complete! Moving on to the examples. (asdf:operate 'asdf:load-source-op :clim-examples) completes successfully. But the first example: [4]> (clim-demo::calculator) *** - XLIB:DRAW-GLYPHS: NIL is not of type XLIB:FONT The following restarts are available: ABORT :R1 ABORT Break 1 [5]> :w EVAL frame for form (XLIB:DRAW-GLYPHS CLIM-CLX::MIRROR CLIM-CLX::GC CLIM-CLX::X CLIM-CLX::Y STRING :START CLIM-CLX::START :END CLIM-CLX::END :SIZE 16 :TRANSLATE #'CLIM-CLX::TRANSLATE) The stack trace is long, but the last recognizable function I can see is (CLIM:MEDIUM-DRAW-TEXT* CLIM:MEDIUM STRING CLIM:POINT-X CLIM:POINT-Y CLIM-INTERNALS::START CLIM-INTERNALS::END CLIM-INTERNALS::ALIGN-X CLIM-INTERNALS::ALIGN-Y CLIM-INTERNALS::TOWARD-X CLIM-INTERNALS::TOWARD-Y CLIM-INTERNALS::TRANSFORM-GLYPHS) Ok, this is where I'm stuck. I don't know much about mcclim, where should I start hunting down this "nil" being passed to xlib:draw-glyphs? I'd be happy to provide more detail where needed. -- Scott

3 4

[mcclim-devel] spec-compliant CLIM impossible on single-threaded systems?
by Clemens Fruhwirth 20 Jan '06

20 Jan '06

Assume you have two stream panes in a single-thread CLIM implementation (that is *multiprocessing-p* -> nil). By some means you trigger stream-read-char on the first pane. As there is no character available stream-read-char will block and start a subsequent event processing loop, checking if there is a character arriving on its pane. But there won't come any character. In the meanwhile the event processing loop running inside of stream-read-char causes via some other handle-event that a second stream-read-char is started. Again causing an event loop. Problem #1: The event loop of the second stream-read-char does not know anything about the loop condition of the first event loop. Problem #2: Problem #1 can be curred by making some "global" state of event conditions. However, It can't do anything about even if it would know when the first stream-read is supposed to terminate. Because to return to the first event loop, it would have to stop blocking, but it's not allowed to do that. There is no way stream 1 can process its character before stream 2 got its (and further assuming that the code calling stream-read-char exits). Conclusion: CLIM can not be implemented on a single-thread system as it is specified. Continuations a solution? Rather not. event-read would to be specified as a macro that takes a body argument used in a closure. For instance, (event-read (event sheet) (process-event event)) But there is nothing like that in the CLIM spec. So we either support stream reading cleanly or we forbid synchronous event processing at all. We can't have both. Not with this CLIM spec. (Remark: UCW got it right. A former version of UCW uses continuations to fix the problem of "proper problem encoding". Our brain does not think in terms of events. We don't envision problem solutions in terms of state machines. We envison solutions as linear flow. See: http://common-lisp.net/project/ucw/docs/html/rest/rest.html - An interesting thing about UCW is also that it doesn't require deep nesting of sexps as it uses (actually has used) a code walker to transform code into CPS. It can be found here http://common-lisp.net/project/bese/docs/arnesi/html/Automatically_Converti… ) I actually wanted to write about the fact that McCLIM does not have per-pane event queues. But before I can have a look at this topic, I rather discuss how CLIM events should be handled at all. If we are actually going to change something in this area, I would also like to define: Who is allowed to read an event and when? What are the priorities if there are more than one event consumers? How is event consumption of event-read related to handle-event; Is handle-event the default event-processing mechanism by the default event-reader, so that handle-event is a fallback if there are no other event-readers (than the default)? See stream-read-char, stream-read-char-no-hang, handle-non-stream-event in stream-input.lisp, standalone-event-loop in panes.lisp, simple-event-loop in frames.lisp for more. -- Fruhwirth Clemens - http://clemens.endorphin.org for robots: sp4mtrap(a)endorphin.org

2 2

[mcclim-devel] Keyboard shortcuts for the debugger (patch)
by Troels Henriksen 19 Jan '06

19 Jan '06

I have added SLIME-style keyboard shortcuts to the McCLIM debugger (Apps/Debugger/clim-debugger.lisp), as well as a pointer-documentation pane. These changes may be generally useful, so a patch is attached to this post. -- \ Troels "Athas" Henriksen /\ sigkill.dk/blog (Danish)

1 0

[mcclim-devel] Support for :insert-default in `accept'
by Troels Henriksen 17 Jan '06

17 Jan '06

I have tried to implement support for the :insert-default option for the `accept'-function. in McCLIM. Attached to this post is a patch for presentation-defs.lisp that seems to work for the test cases I have tried (mostly some other hacks on Climacs). Could someone with more (Mc)CLIM-fu than me tell me whether or not it is acceptable? -- \ Troels "Athas" Henriksen /\ sigkill.dk/blog (Danish)

1 0

[mcclim-devel] accepting-values: prompts not clickable, no redraw, improper output recording?
by Clemens Fruhwirth 09 Jan '06

09 Jan '06

The attached test case does produce strange results for accepting-values calls. In the test case you will find 2 commands. The first one causes an implicit accepting values to be generated when you click on the menu button (or type "Implicit AV<ret>" in the interactor pane). In my CVS checkout (about 12 hours old), the Implicit AV command presents three prompts, of that only the last one accepts input. Notice, when damaging the draw area only the last one is repainted, even though not shown first. Explicit AV also generates three prompts, of that the first and the last accepts input. Both are redrawn upon X damage. I also put up a video of this behaviour in case it is not reproducable for you. They are at http://clemens.endorphin.org/strange-clim-artefacts/ (Most of them are MPEG4 provided with four different flavors of fourcc. The last is in Motion JPEG, but quite huge. I won't give an off-topic explaination here of what caused the problems seen by those participating in the IRC discussion of this bug, but when you're interested http://itdp.fh-biergarten.de/~itdp/html/mplayer-users/2005-03/msg00069.html ) Regards, -- Fruhwirth Clemens - http://clemens.endorphin.org for robots: sp4mtrap(a)endorphin.org

1 2

[mcclim-devel] Command and non-ASCII problems
by Troels Henriksen 08 Jan '06

08 Jan '06

Hi, I'm trying to learn CLIM, through McCLIM, from the ground up, but I'm having a slight problem with commands. The following example program shows the issue: (in-package :clim-user) (define-application-frame example-editor () () (:menu-bar menubar-command-table) (:panes (text-edit :text-editor)) (:layouts (default text-edit))) (define-example-editor-command com-quit () (frame-exit *application-frame*)) (make-command-table 'file-command-table :errorp nil :menu '(("Quit" :command com-quit))) (make-command-table 'menubar-command-table :errorp nil :menu '(("File" :menu file-command-table))) The "Quit" menu option shows up just fine, but nothing happens when I click it. Why is this? Furthermore, non-ASCII-input (the Danish special characters Æ, Ø and Å, for example) does not show up in the text-editor pane. I assume that McCLIM lacks support for this. Where would I want to look, if I am to hack up some support for this? -- \ Troels "Athas" Henriksen /\ sigkill.dk/blog (Danish)

5 7

[mcclim-devel] space requirements :min-:max options
by Clemens Fruhwirth 04 Jan '06

04 Jan '06

According to the CLIM spec 29.3.1 Layout Pane Options: "If either of the :max-height or :min-height options is not supplied, it defaults to the value of the :height option." However in panes.lisp, I see: ;; NOTE: The defaulting for :min-foo and :max-foo is different from MAKE-SPACE-REQUIREMENT. ;; MAKE-SPACE-REQUIREMENT has kind of &key foo (min-foo 0) (max-foo +fill+) ;; While user space requirements has &key foo (min-foo foo) (max-foo foo). ;; I as a user would pretty much expect the same behavior, therefore I'll take the ;; following route: ;; When the :foo option is given, I'll let MAKE-SPACE-REQUIREMENT decide. May I urge you to change revert that change. The :height and :width initargs loss their usefulness this way. Also it's a bit counter-intutive. Look at (define-application-frame only-red () () (:pane (vertically () (make-pane 'application-pane :background +red+ :min-height 100) +fill+ (make-pane 'application-pane :background +blue+ :height 100)))) Wouldn't you expect to see two panes, one blue with height 100 and a red one at least 100 pixel high? The reason for this query is that I have troubles explaining the readers of my CLIM tutorial why McCLIM violates the spec and why :height as well as :width are mostly useless at the moment. See panes.lisp "merge-one-option" (Line 549) and the commented code ;; (setf user-max-foo (or user-max-foo user-foo) ;; user-min-foo (or user-min-foo user-foo)) Thanks, -- Fruhwirth Clemens - http://clemens.endorphin.org for robots: sp4mtrap(a)endorphin.org

1 0

[mcclim-devel] repaint-sheet, +everywhere+ and output recording
by Clemens Fruhwirth 02 Jan '06

02 Jan '06

(repaint-sheet instance-inheriting-from-output-recording-stream +everywhere+) does not work. The reason is %handle-repaint in recording.lisp. It rewrites region to a bounding-rectangle regardless the type of the region. Hence, %handle-repaint needs to check whether region is region-equal to +nowhere+ or +everywhere+, the only unbounded region types that do not participate in the bounding rectangle protocol. Please comment on my patch, because I personally don't like it. It seems a bit ackward to make explicit checks for these two regions, probably there are better solutions. If you need something to reproduce the bug, try http://paste.lisp.org/display/15284#3 - uncomment standard-output-recording-stream from the long list of superclasses that imitate those of application-pane to reproduce the error. -- Fruhwirth Clemens - http://clemens.endorphin.org for robots: sp4mtrap(a)endorphin.org

1 0

← Newer
1
...
51
52
53
54
55
56
57
...
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