From pdm at zamazal.org Mon Jan 2 08:56:40 2006 From: pdm at zamazal.org (Milan Zamazal) Date: Mon, 02 Jan 2006 09:56:40 +0100 Subject: [mcclim-devel] Re: Command and non-ASCII problems References: <87psnfqw1o.fsf@sigkill.dk> <87k6dms684.fsf@sigkill.dk> Message-ID: <87lkxzros7.fsf@blackbird.zamazal.org> >>>>> "TH" == Troels Henriksen writes: TH> I've hacked a few things up in CLX that allows me TH> to read Danish special characters from the keyboard. This was TH> mostly about redefing `translate-default' and modifying TH> *keysym->character-map* in CLX itself (as I said, a hack). It TH> works in pure CLX-applications, but for some reason, not in TH> McCLIM. Look for "non-ASCII" in the mailing list archive, June 2005. I've found a working Q&D way to input and display Czech characters in McCLIM using a Unicode font. Regards, Milan Zamazal -- http://www.zamazal.org From athas at sigkill.dk Mon Jan 2 10:53:35 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Mon, 02 Jan 2006 11:53:35 +0100 Subject: [mcclim-devel] Re: Command and non-ASCII problems In-Reply-To: <87lkxzros7.fsf@blackbird.zamazal.org> (Milan Zamazal's message of "Mon, 02 Jan 2006 09:56:40 +0100") References: <87psnfqw1o.fsf@sigkill.dk> <87k6dms684.fsf@sigkill.dk> <87lkxzros7.fsf@blackbird.zamazal.org> Message-ID: <87y81y7vgg.fsf@sigkill.dk> Milan Zamazal writes: > Look for "non-ASCII" in the mailing list archive, June 2005. I've found > a working Q&D way to input and display Czech characters in McCLIM using > a Unicode font. Thank you. Based on your post, I was able to write some functions that solve the problem in a very simple way: (defun fix-character (character keysym) "Setup character to work in CLX and McCLIM." (xlib::define-keysym character keysym) (goatee::add-gesture-command-to-table character 'goatee::insert-character goatee::*simple-area-gesture-table*)) (defun fix-danish-input () (fix-character #\? 230) (fix-character #\? 198) (fix-character #\? 248) (fix-character #\? 216) (fix-character #\? 229) (fix-character #\? 197)) I also had to replace clim-clx::translate with the Unicode-capable translation function from Climacs. I think this fix should be mentioned somewhere, since non-ASCII input is likely to be important to many people. Also, could this method be used as a general solution, or is it still a hack (apart from the low number of supported characters, of course)? -- \ Troels "Athas" Henriksen /\ sigkill.dk/blog (Danish) From clemens at endorphin.org Mon Jan 2 21:47:50 2006 From: clemens at endorphin.org (Clemens Fruhwirth) Date: Mon, 02 Jan 2006 22:47:50 +0100 Subject: [mcclim-devel] repaint-sheet, +everywhere+ and output recording Message-ID: <20060102215037.29E083CB8B@irulan.endorphin.org> (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 at endorphin.org -------------- next part -------------- Index: recording.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/recording.lisp,v retrieving revision 1.120 diff -u -r1.120 recording.lisp --- recording.lisp 1 Dec 2005 11:10:55 -0000 1.120 +++ recording.lisp 2 Jan 2006 21:41:45 -0000 @@ -2235,9 +2235,17 @@ ;;; to explicit repaint requests from the user, not exposes from X ;;; FIXME: Use DRAW-DESIGN*, that is fix DRAW-DESIGN*. +;;; %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. + (defun %handle-repaint (stream region) - (when (output-recording-stream-p stream) - (let ((region (bounding-rectangle region))) + (when (and (output-recording-stream-p stream) + (not (region-equal region +nowhere+))) + (let ((region (if (region-equal region +everywhere+) + (when (sheetp stream) + (sheet-region stream)) + (bounding-rectangle region)))) (with-bounding-rectangle* (x1 y1 x2 y2) region (with-output-recording-options (stream :record nil) (draw-rectangle* stream x1 y1 x2 y2 :filled T :ink +background-ink+))) From clemens at endorphin.org Wed Jan 4 20:08:48 2006 From: clemens at endorphin.org (Clemens Fruhwirth) Date: Wed, 04 Jan 2006 21:08:48 +0100 Subject: [mcclim-devel] space requirements :min-:max options Message-ID: <20060104201151.7A9E73CB8B@irulan.endorphin.org> 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 at endorphin.org From pdm at zamazal.org Sat Jan 7 19:01:25 2006 From: pdm at zamazal.org (Milan Zamazal) Date: Sat, 07 Jan 2006 20:01:25 +0100 Subject: [mcclim-devel] Re: Command and non-ASCII problems References: <87psnfqw1o.fsf@sigkill.dk> <87k6dms684.fsf@sigkill.dk> <87lkxzros7.fsf@blackbird.zamazal.org> <87y81y7vgg.fsf@sigkill.dk> Message-ID: <87d5j3ooai.fsf@blackbird.zamazal.org> >>>>> "TH" == Troels Henriksen writes: TH> I think this fix should be mentioned somewhere, since non-ASCII TH> input is likely to be important to many people. Perhaps it could be added to McCLIM Cliki? TH> Also, could this method be used as a general solution, or is it TH> still a hack (apart from the low number of supported characters, TH> of course)? I'm not competent to answer this question. But I'd like to assure McCLIM developers that any partially working solution is definitely much better than not to be able to use non-ASCII characters at all. Lack of very basic i18n support in McCLIM was one of the main reasons why I had to cowardly switch from McCLIM to GNOME Guile in one of my projects. :-| Regards, Milan Zamazal -- http://www.zamazal.org From amoroso at mclink.it Sun Jan 8 10:40:27 2006 From: amoroso at mclink.it (Paolo Amoroso) Date: Sun, 08 Jan 2006 11:40:27 +0100 Subject: [mcclim-devel] Re: Command and non-ASCII problems In-Reply-To: <87d5j3ooai.fsf@blackbird.zamazal.org> (Milan Zamazal's message of "Sat, 07 Jan 2006 20:01:25 +0100") References: <87psnfqw1o.fsf@sigkill.dk> <87k6dms684.fsf@sigkill.dk> <87lkxzros7.fsf@blackbird.zamazal.org> <87y81y7vgg.fsf@sigkill.dk> <87d5j3ooai.fsf@blackbird.zamazal.org> Message-ID: <87irsvm290.fsf@plato.moon.paoloamoroso.it> Milan Zamazal writes: >>>>>> "TH" == Troels Henriksen writes: > > TH> I think this fix should be mentioned somewhere, since non-ASCII > TH> input is likely to be important to many people. > > Perhaps it could be added to McCLIM Cliki? It's here: http://mcclim.cliki.net/Tip Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From clemens at endorphin.org Sun Jan 8 15:51:25 2006 From: clemens at endorphin.org (Clemens Fruhwirth) Date: Sun, 08 Jan 2006 16:51:25 +0100 Subject: [mcclim-devel] accepting-values: prompts not clickable, no redraw, improper output recording? In-Reply-To: <20051205092039.634A33C248@irulan.endorphin.org> References: <20051205092039.634A33C248@irulan.endorphin.org> Message-ID: <20060108155414.B84253CB8B@irulan.endorphin.org> Clemens Fruhwirth wrote: > The attached test case does produce strange results for accepting-values > calls. After a fair amount of source reading: Not a bug. Paolo, thanks for adding it to http://mcclim.cliki.net/Bug. I removed it. The follownig code is not a valid test case. See below. > (accepting-values (input-stream) > (accept 'string :prompt "A string" :stream input-stream ) > (terpri input-stream) > (accept 'integer :prompt "An integer" :stream input-stream ) > (terpri input-stream) > (accept 'integer :prompt "An integer" :stream input-stream )))) >From the CLIM spec, 6th paragraph in the description of accepting-values in Chapter 26: "Inside of accepting-values, programmers should supply the :query-identifier argument to each call to accept. If :query-identifier is not explicitly supplied, the prompt for that call to accept is used as the query identifier. Thus, if :query-identifier is not supplied, programmers must ensure that all of the prompts are different. If there is more than one call to accept with the same query identifier, the behavior of accepting-values is unspecified." -- Fruhwirth Clemens - http://clemens.endorphin.org for robots: sp4mtrap at endorphin.org From clemens at endorphin.org Mon Jan 9 10:14:26 2006 From: clemens at endorphin.org (Clemens Fruhwirth) Date: Mon, 09 Jan 2006 11:14:26 +0100 Subject: [mcclim-devel] accepting-values: prompts not clickable, no redraw, improper output recording? In-Reply-To: <20060108155414.B84253CB8B@irulan.endorphin.org> References: <20051205092039.634A33C248@irulan.endorphin.org> <20060108155414.B84253CB8B@irulan.endorphin.org> Message-ID: <20060109101722.DAEA43CB8B@irulan.endorphin.org> Clemens Fruhwirth wrote: > Clemens Fruhwirth wrote: > > > The attached test case does produce strange results for accepting-values > > calls. > > After a fair amount of source reading: Not a bug. I changed my feelings regarding this issue. As even McCLIM makes incorrect use of its own facilities, I decided that it's better that accepting-values gives at least an annoying warning if it detects an incorrect usage pattern. This is easy to do, see the serial-checking patch below. Regarding McCLIM's own incorrect use of accepting-values, see commands-accepting-values-fix.diff. The partial command parser must generate :query-identifier for all accept statements, because it does not generate unique prompts. This is bug becomes visible when using (define-foobar-command (com-foobar :menu t :name t) ((x 'integer) (y 'integer)) ()) When the command is invoked via menu or via a partial command, the two integer arguments cause two identical prompts, namely "Enter an integer". The problem with this is that accepting-values uses :prompt when :query-identifier is missing, and as the command parser hasn't supplied unique prompts, the query-identifiers are non-unique too. Non-unique query-identifiers in accepting-values cause strange screen corruption. I really don't like that and when this happens to a new user - as it happend to me - the user has little clue where to start searching for a remedy and might even be tempted not to search at all because this looks like a toolkit bug. So, we better spend some time on checking usage patterns. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dialog-sanity-check.lisp URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: commands-accepting-value-use-fix.lisp URL: From athas at sigkill.dk Tue Jan 17 15:47:03 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Tue, 17 Jan 2006 16:47:03 +0100 Subject: [mcclim-devel] Support for :insert-default in `accept' Message-ID: <87hd823lhk.fsf@sigkill.dk> 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? -------------- next part -------------- A non-text attachment was scrubbed... Name: presentation-defs.lisp.patch Type: text/x-patch Size: 2782 bytes Desc: not available URL: -------------- next part -------------- -- \ Troels "Athas" Henriksen /\ sigkill.dk/blog (Danish) From clemens at endorphin.org Thu Jan 19 16:06:21 2006 From: clemens at endorphin.org (Clemens Fruhwirth) Date: Thu, 19 Jan 2006 17:06:21 +0100 Subject: [mcclim-devel] spec-compliant CLIM impossible on single-threaded systems? Message-ID: <20060119161038.A0BF93CBC8@irulan.endorphin.org> 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_Converting_a_Subset_of_Common_Lisp_to_CPS.html ) 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 at endorphin.org From ahefner at gmail.com Thu Jan 19 19:48:18 2006 From: ahefner at gmail.com (Andy Hefner) Date: Thu, 19 Jan 2006 14:48:18 -0500 Subject: [mcclim-devel] spec-compliant CLIM impossible on single-threaded systems? In-Reply-To: <20060119161038.A0BF93CBC8@irulan.endorphin.org> References: <20060119161038.A0BF93CBC8@irulan.endorphin.org> Message-ID: <31ffd3c40601191148y3bb80f9bn530f18804746b236@mail.gmail.com> Isn't the lesson here to not read from streams inside event handlers? I don't understand why one would do this. From athas at sigkill.dk Thu Jan 19 22:09:25 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Thu, 19 Jan 2006 23:09:25 +0100 Subject: [mcclim-devel] Keyboard shortcuts for the debugger (patch) Message-ID: <878xtbyine.fsf@sigkill.dk> 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) -------------- next part -------------- A non-text attachment was scrubbed... Name: clim-debugger.lisp.patch Type: text/x-patch Size: 7246 bytes Desc: not available URL: From clemens at endorphin.org Fri Jan 20 10:48:26 2006 From: clemens at endorphin.org (Clemens Fruhwirth) Date: Fri, 20 Jan 2006 11:48:26 +0100 Subject: [mcclim-devel] spec-compliant CLIM impossible on single-threaded systems? In-Reply-To: <31ffd3c40601191148y3bb80f9bn530f18804746b236@mail.gmail.com> References: <20060119161038.A0BF93CBC8@irulan.endorphin.org> <31ffd3c40601191148y3bb80f9bn530f18804746b236@mail.gmail.com> Message-ID: <20060120105246.58F633CBC8@irulan.endorphin.org> Andy Hefner wrote: > Isn't the lesson here to not read from streams inside event handlers? In a single-thread system, it does make any difference if it's an event handler or command or something else. And if you think stream-read are too low level anyway, simply think of two accepting-values forms. The second will instantly cause trouble for the first. From ortmage at gmx.net Sun Jan 22 05:07:07 2006 From: ortmage at gmx.net (Scott Williams) Date: Sat, 21 Jan 2006 22:07:07 -0700 Subject: [mcclim-devel] clisp build issues Message-ID: <43D312FB.7020907@gmx.net> 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 #: 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 #: # 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 From ortmage at gmx.net Sun Jan 22 19:03:22 2006 From: ortmage at gmx.net (Scott Williams) Date: Sun, 22 Jan 2006 12:03:22 -0700 Subject: [mcclim-devel] clisp build issues In-Reply-To: <43D312FB.7020907@gmx.net> References: <43D312FB.7020907@gmx.net> Message-ID: <43D3D6FA.6080709@gmx.net> This error appears to be related to :unicode in *features*. When :unicode is set, (setf xlib:gcontext-font) is never called on the gcontext returned from medium-gcontext. I can stuff font into the gcontext and continue the drawing operation, but error is quickly triggered again. I traced xlib:create-gcontext and found that a new context is created. I don't really have any idea what I'm doing, but I thought I might get things to continue if i modified medium-gcontext to always call gcontext-font: (setf (xlib:gcontext-font gc) (xlib:open-font (first xlib::*displays*) "fixed")) This allows the demo to continue without further errors, but nothing really very interesting appears in the demo window except a narrow black box at the top, with a wide white box beneath it. At this point I really don't have any idea what's wrong. Can anyone help me or show me where to start looking? -- Scott Scott Williams wrote: >[4]> (clim-demo::calculator) >*** - XLIB:DRAW-GLYPHS: NIL is not of type XLIB:FONT >The following restarts are available: >ABORT :R1 ABORT > > From csr21 at cam.ac.uk Sun Jan 22 20:05:17 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Sun, 22 Jan 2006 20:05:17 +0000 Subject: [mcclim-devel] clisp build issues In-Reply-To: <43D3D6FA.6080709@gmx.net> (Scott Williams's message of "Sun, 22 Jan 2006 12:03:22 -0700") References: <43D312FB.7020907@gmx.net> <43D3D6FA.6080709@gmx.net> Message-ID: Scott Williams writes: > At this point I really > don't have any idea what's wrong. Can anyone help me or show me where to > start looking? I believe that the stuff in mcclim protected by #+unicode was written for a never-released experimental branch of CMUCL, and never generalized to work for other lisps displaying that feature. Try either removing all code protected by it, or removing :unicode from your clisp's *features* before compiling mcclim. Cheers, Christophe From ortmage at gmx.net Sun Jan 22 21:49:39 2006 From: ortmage at gmx.net (Scott Williams) Date: Sun, 22 Jan 2006 14:49:39 -0700 Subject: [mcclim-devel] clisp build issues In-Reply-To: <87bqy4klc9.wl%asf@boinkor.net> References: <43D312FB.7020907@gmx.net> <43D3D6FA.6080709@gmx.net> <87bqy4klc9.wl%asf@boinkor.net> Message-ID: <43D3FDF3.5050407@gmx.net> Thanks Andreas, those changes allow me to load mcclim with less pain :o) With the patch below, I can load mcclim and run the calculator demo with this command: clisp -K full -q -x "(export 'xlib::set-selection-owner 'xlib) (asdf:operate 'asdf:load-op :mcclim) (asdf:operate 'asdf:load-op :clim-examples) (clim-demo::calculator)" I don't get any obvious errors (lots of compiler warnings and style warnings, which I can supply if it would help), but the resulting demo window still doesn't look like much is happening (I attached an image of the window in case that helps). FWIW, there's no CPU activity, so I don't suspect it's doing anything at all. Any idea what's going on? -- Scott -------------- next part -------------- A non-text attachment was scrubbed... Name: clisp-asdf.patch Type: text/x-patch Size: 1893 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: calculator-demo.png Type: image/png Size: 698 bytes Desc: not available URL: From asf at boinkor.net Sun Jan 22 21:24:06 2006 From: asf at boinkor.net (Andreas Fuchs) Date: Sun, 22 Jan 2006 22:24:06 +0100 Subject: [mcclim-devel] clisp build issues In-Reply-To: References: <43D312FB.7020907@gmx.net> <43D3D6FA.6080709@gmx.net> Message-ID: <87bqy4klc9.wl%asf@boinkor.net> Today, Christophe Rhodes wrote: > Scott Williams writes: > >> At this point I really don't have any idea what's wrong. Can anyone >> help me or show me where to start looking? > > I believe that the stuff in mcclim protected by #+unicode was > written for a never-released experimental branch of CMUCL, and never > generalized to work for other lisps displaying that feature. Try > either removing all code protected by it, or removing :unicode from > your clisp's *features* before compiling mcclim. FWIW, I just committed a change that removes these blocks and compiles the #-unicode blocks unconditionally, as I had announced (wow) 6 months ago. The resulting mcclim builds and runs beirc, so it shouldn't be too broken, either (: Hope this improves Scott's situation. Thanks for finally making me do this, -- Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs From root at common-lisp.net Mon Jan 23 08:15:30 2006 From: root at common-lisp.net (root) Date: Mon, 23 Jan 2006 02:15:30 -0600 (CST) Subject: [mcclim-devel] Auto-nag: mcclim link verifier failed Message-ID: <20060123081530.C2F101E1AD@common-lisp.net> 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 at common-lisp.net Thanks! From athas at sigkill.dk Mon Jan 23 16:47:18 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Mon, 23 Jan 2006 17:47:18 +0100 Subject: [mcclim-devel] Attempt to make (accept 'expression) more interaction-friendly. Message-ID: <87mzhmvqll.fsf@sigkill.dk> 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) -------------- next part -------------- A non-text attachment was scrubbed... Name: builtin-commands.lisp.patch Type: text/x-patch Size: 2963 bytes Desc: not available URL: From m.retzlaff at gmx.net Tue Jan 24 04:16:29 2006 From: m.retzlaff at gmx.net (Max-Gerd Retzlaff) Date: Tue, 24 Jan 2006 05:16:29 +0100 Subject: [mcclim-devel] DEFINE-APPLCATION-STARTER and a modified Clim Launcher Message-ID: <20060124041628.GA7959@mgr.home> Hello, this is a proposal for a new extension to McCLIM consisting of two parts: A general macro to produce application starter functions for McCLIM applications Most Clim application have a starter functions that just makes the application frame and afterwards runs its toplevel: (defun start () (run-frame-top-level (make-application-frame 'my-foo))) So far, so simple. But now we want a shortcut to start the toplevel in a newly created process, so we have: (defun start (&key (new-process nil)) (flet ((run () (run-frame-top-level (make-application-frame 'my-foo)))) (if new-process (clim-sys:make-process #'run :name "foo tool") (run)))) What else? Perhaps a default window width and height? A keyword parameter for the process name? . . . It has started with the first version, then someone has written the second one, that was copied by others. Further extended... Well, it has become quite convenient, and so you can find mutations of the code in the Clim Listener, Clouseau (the inspector), the Clim Launcher, Climacs, and probably others. For a strange reason all of the authors never created a simple macro for it but have copied the code literally and changed it appropriately. How unlispy! So I changed this, by making one as part of the LED Cube Modeller[1]. It basically creates the code of the second example. You can also specify a default width and height for the application frame, as well as the default process name. Then there is also the option :COMPLAIN-ABOUT-EXISTING-PROCESS; set it to T when defining the starter (the default is nil) and the generated starter function will, previously to do anything else, search for an existing process and ask what it should do about it (I wanted this behaviour for the Cube Modeller's toolbox window). In addition to this you can also specify the frame manager if you want to try out the pixie/clx-look. The new macro can be used as a drop-in replacement for e.g. the existing climacs-gui:climacs: (climi::define-application-starter climacs :function-name climacs :default-width 900 :default-height 400) For the Clim Launcher it is: (climi::define-application-starter launcher :function-name start :default-process-name "CLIM Launcher" :announce-to-clim-launcher nil) For the Clim Listener it could be: (climi::define-application-starter listener :function-name run-listener :default-width 760 :default-height 550) but there is a tiny problem with this right now that can be fixed with a small change to the Listener (more on this in a seperate mail). And finally to illustrate :COMPLAIN-ABOUT-EXISTING-PROCESS: (climi::define-application-starter toolbox :function-name start-toolbox :default-process-name "cube-modeller toolbox" :complain-about-existing-process t) For further review the expanded version of the Climacs example is attached to this mail. Still simple, but nice nevertheless as this is a quite general application starter macro, and you all know the advantage of using a macro instead of duplicating code. Clim Launcher Together with the Launcher by Dwight Holman there is an additional benefit: The macro can announce the created starter to it. So that if you use it to define the function that fires up your GUI it will automatically displayed in the Clim Launcher. As this is quite nice, I seperated my modefied version of the Clim Launcher from Clim Desktop and merged it with the DEFINE-APPLICATION-STARTER code. I propose to commit this as a new extension to the McCLIM repository itself. It's not really much code (172 lines altogether), and the barrier to use the macro should be as low as possible. If you don't want the generated function to be announced to the Launcher you can specify :ANNOUNCE-TO-CLIM-LAUNCHER as nil. The Launcher itself should not be listed for example. Or you want to use the function only internally and have your application started via another function. In this case you can announce this function manually via (add-application "Beirc" #'beirc:beirc), for example. (This is also possible if you don't want to use the macro at all, of course.) Current status The current version is work in progress. (What else?) The Clim Launcher still depends on :clim-listener, :beirc, and :closure. If we agree to merge this code with McCLIM these dependencies should be removed, and the Listener, Beirc, Climacs, etc. should instead depend on :clim-launcher (and use DEFINE-APPLICATION-STARTER or CLIM-LAUNCHER:ADD-APPLICATION). The dependency to :climacs is already removed, you might want to evaluate the above example in the package denoted by "CLIMACS-GUI" and be impressed by the fact that a "button" will automatically manifest itself in the next turn of the Launcher's command loop. Now a direct question: The macro DEFINE-APPLICATION-STARTER currently resides in the file clim-utilities.lisp together with the two functions FIND-PROCESS-WITH-NAME and DESTROY-PROCESS-WITH-NAME that it needs. These will be created in the package "CLIM-INTERNALS", which is not very nice, but on the other hand: The two functions are generally useful to interact with the threads that McCLIM provides in a portable way. (Perhaps we want them to be exported by the package "CLIM-SYS"?) And in order to use DEFINE-APPLICATION-STARTER it would be more nice to just use it as if it were part of the CLIM specification. But do we want it in the package "CLIM"? It is not part of the specification... Or should it just be in and exported by "CLIM-LAUCNHER", and everybody should :USE that package? What do you think? I'm indecisive.. Source code and a screen shot The current version of the source codeis attached to this mail. It is also in my public flux directory http://matroid.org/flux/ as clim-launcher-20060124-01.tar.bzip2 (or newer). The extracted archive is here: http://matroid.org/flux/clim-launcher/ Here is a recent screenshot of some clim applications, including Closure, Beirc, the Listener and the Launcher, Climacs, and the LED Cube Modeller (including the File Selector): http://matroid.org/flux/CLIM-Desktop-20060124-1.png (780 kB) Entertainment The first name of the macro hasn't been very nice: MAKE-RUN-GUI-DEFUN. So there has been a discussion[2] about it in #lisp. Proposals have been: DEFINE-APPLICATION-ENTRY, DEFINE-APPLICATION, DEFINE-APPLICATION-ENTRY-POINT, DEFINE-APPLICATION-ENTRY-FUNCTION, DEFINE-APPLICATION-STARTER-FUNCTION, EFINE-APPLICATION-STARTER, DEFINE-CLICKY-CLICK-THING, EFINE-APPLICATION-FIRESTARTER, DEFINE-APPLICATION-IGNITION, EFINE-DO-IT-TO-IT-FUNCTION, DEFINE-GUI-FIRE-UP-THINGIE, DEFINE-HEY-HO-LETS-GO, DEFINE-APPLICATION-INVOKER, DEFINE-APPLICATOR, DEFINE-APPLICATION-ANTI-TERMINATOR, DEFINE-APPLICATION-RUNNER, DEFINE-APPLICATION-INITIATOR, IVE-ME-AN-INITIATIR-FOR-MY-MIGHTY-GUI, AND DEFINE-APPLICATION-TOPLEVEL. Well, although I really like DEFINE-CLICKY-CLICK-THING and DEFINE-HEY-HO-LETS-GO, I hope you are okay with DEFINE-APPLICATION-STARTER. (Or is DEFINE-APPLICATION-RUNNER really better? :) ) Comments and thoughts are welcome, of course. Bye, Max Links: 1) http://blog.matroid.org/display/25 2) IRC context for the bored: http://meme.b9.com/cview.html?utime=3346791413&channel=lisp&start=3346787818&end=3346795018#utime_requested PS: So many words for such a simple thing.. Hrm.. -- Max-Gerd Retzlaff http://blog.matroid.org For your amusement: "The sixties were good to you, weren't they?" -- George Carlin -------------- next part -------------- A non-text attachment was scrubbed... Name: clim-launcher-20060124-01.tar.bzip2 Type: application/octet-stream Size: 2325 bytes Desc: not available URL: -------------- next part -------------- (in-package :climacs-gui) ;;; This: (climi::define-application-starter climacs :function-name climacs :default-width 900 :default-height 400) ;;; gives: (MULTIPLE-VALUE-PROG1 (DEFUN CLIMACS (&KEY CLIM-INTERNALS::NEW-PROCESS (CLIM-SYS:PROCESS-NAME "Climacs") (CLIM-INTERNALS::WIDTH 900) (CLIM-INTERNALS::HEIGHT 400) CLIM-INTERNALS::FRAME-MANAGER-NAME CLIM-INTERNALS::FORCE-RESTART (CLIM-INTERNALS::DEBUGGER (FUNCTION CLIM-DEBUGGER:DEBUGGER))) (WHEN (CLIM-INTERNALS::FIND-PROCESS-WITH-NAME CLIM-SYS:PROCESS-NAME) (IF CLIM-INTERNALS::FORCE-RESTART (CLIM-INTERNALS::DESTROY-PROCESS-WITH-NAME CLIM-SYS:PROCESS-NAME) (WHEN NIL (RESTART-CASE (ERROR "There seems to be a running instance of the climacs process.") (CLIM-INTERNALS::|destroy-process| NIL :REPORT "Destroy old climacs process and make a new one." (CLIM-INTERNALS::DESTROY-PROCESS-WITH-NAME CLIM-SYS:PROCESS-NAME)) (CLIM-INTERNALS::|don't-care| NIL :REPORT "Just run the gui again and don't care about the running process." NIL) (CLIM-INTERNALS::|do-nothing| NIL :REPORT "Just return without doing anything more." (RETURN-FROM CLIMACS)))))) (LET ((CLIM-INTERNALS::FRAME (IF CLIM-INTERNALS::FRAME-MANAGER-NAME (MAKE-APPLICATION-FRAME 'CLIMACS :WIDTH CLIM-INTERNALS::WIDTH :HEIGHT CLIM-INTERNALS::HEIGHT :FRAME-MANAGER (MAKE-INSTANCE CLIM-INTERNALS::FRAME-MANAGER-NAME :PORT (FIND-PORT))) (MAKE-APPLICATION-FRAME 'CLIMACS :WIDTH CLIM-INTERNALS::WIDTH :HEIGHT CLIM-INTERNALS::HEIGHT))) (*DEBUGGER-HOOK* CLIM-INTERNALS::DEBUGGER)) (FLET ((CLIM-INTERNALS::RUN () (RUN-FRAME-TOP-LEVEL CLIM-INTERNALS::FRAME))) (IF CLIM-INTERNALS::NEW-PROCESS (CLIM-SYS:MAKE-PROCESS (LAMBDA () (CLIM-INTERNALS::RUN) (CLIM-INTERNALS::DESTROY-PROCESS-WITH-NAME CLIM-SYS:PROCESS-NAME)) :NAME CLIM-SYS:PROCESS-NAME) (CLIM-INTERNALS::RUN))) CLIM-INTERNALS::FRAME)) (WHEN (AND T (FIND-PACKAGE :CLIM-LAUNCHER) (FBOUNDP (INTERN "ADD-APPLICATION" :CLIM-LAUNCHER))) (FUNCALL (INTERN "ADD-APPLICATION" :CLIM-LAUNCHER) "Climacs" (LAMBDA () (FUNCALL #'CLIMACS :NEW-PROCESS T))))) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From athas at sigkill.dk Tue Jan 24 15:03:00 2006 From: athas at sigkill.dk (Troels Henriksen) Date: Tue, 24 Jan 2006 16:03:00 +0100 Subject: [mcclim-devel] DEFINE-APPLCATION-STARTER and a modified Clim Launcher In-Reply-To: <20060124041628.GA7959@mgr.home> (Max-Gerd Retzlaff's message of "Tue, 24 Jan 2006 05:16:29 +0100") References: <20060124041628.GA7959@mgr.home> Message-ID: <87zmllwtwb.fsf@sigkill.dk> Generally, I think your idea is very cool. A standardized way to start applications (apart from `run-frame-toplevel') would be highly useful. I do, however, have a request: Max-Gerd Retzlaff writes: > Clim Launcher > > Together with the Launcher by Dwight Holman there is an additional > benefit: The macro can announce the created starter to it. So that > if you use it to define the function that fires up your GUI it will > automatically displayed in the Clim Launcher. This functionality should not be wired to a specific launcher program. Instead, McCLIM should maintain an *application-entry-points* alist that maps application names to functions. Thereby, any CLIM-application will be able to retrieve a list of the programs available. This would also open for the possibility of creating alternative launcher programs. -- \ Troels "Athas" Henriksen /\ sigkill.dk/blog (Danish) From m.retzlaff at gmx.net Wed Jan 25 03:00:26 2006 From: m.retzlaff at gmx.net (Max-Gerd Retzlaff) Date: Wed, 25 Jan 2006 04:00:26 +0100 Subject: [mcclim-devel] New version, based on ideas by Timonthy Moore (Has been: DEFINE-APPLCATION-STARTER and a modified Clim Launcher) In-Reply-To: <20060124041628.GA7959@mgr.home> References: <20060124041628.GA7959@mgr.home> Message-ID: <20060125030025.GA16230@mgr.home> Hi, I have not much time to write right now but there is a new version and I want to inform you about it so that you do not spend thought on things that are already changed. I've had a discussion with Timothy Moore in #lisp. His idea has been: mgr: I mean that launch-application could be a generic function that does what the code generated by your macro does, with all the flexibility that implies. Not that I care very much, but these days I tend to think about protocols before I think about macros. (The discussion is logged, here is a direct link: http://meme.b9.com/cview.html?channel=lisp&utime=3347129927#utime_requested ) Afterwards I have rewritten the stuff in clim-utilities.lisp; please, have a look at the file in the attached archive or at: http://matroid.org/flux/clim-launcher/clim-utilities.lisp (The archive i is also in my public flux directory http://matroid.org/flux/ as clim-launcher-20060125-01.tar.bzip2 (or newer).) Now there is the generic function LAUNCH-APPLICATION, the most generic method of it consists basically of the code the previous version of the DEFINE-APPLICATION-STARTER macro has generated, only more general. You can know just execute (climi::launch-application 'climacs-gui:climacs :new-process t) to start Climacs, without the need to define a custom starter function. In this case you have to announce your application manually with something like: (clim-launcher:add-application "Climacs" ;; (See [1].) (lambda () (climacs-gui::climacs :new-process t))) To create a custum starter function nevertheless, DEFINE-APPLICATION-STARTER does still exist, although it has been changed to use LAUNCH-APPLICATION. (It will still announce the application by default, of course.) Using a generic method has the huge benefit that the starter can now be modified for each application frame. Think of Beirc, which wants to make a separate thread for the IRC connection on its start-up. Another example is Clouseau that needs an object to inspect as an argument. We can now modify LAUNCH-APPLICATION and put the argument :object into the (also new) ARGUMENTS-FOR-APPLICATION-FRAME-CREATION argument for the generic LAUNCH-APPLICATION method: -- zipp -- ;;; Clouseau example (in-package :clouseau) (climi::define-application-starter inspector :function-name inspector) (in-package :climi) (defmethod launch-application :around ((application-frame-name (eql 'clouseau::inspector)) &rest rest &key arguments-for-application-frame-creation &allow-other-keys) "This method will put the :OBJECT argument into :ARGUMENTS-FOR-APPLICATION-FRAME-CREATION" (let ((object (getf rest :object))) (when object (setf (getf arguments-for-application-frame-creation :obj) object ;; ensure that its in the list: (getf rest :arguments-for-application-frame-creation) arguments-for-application-frame-creation))) ;; call the real thing (apply #'call-next-method application-frame-name rest)) -- zapp -- We can now start Clouseau with (climi::launch-application 'clouseau:inspector :new-process t :object 'dudel) or via the custom generated function (clouseau:inspector :object 'tada :new-process t) Comments are welcome. Bye, Max 1) The name ADD-APPLICATION should be renamed as well. I like ANNOUNCE-APPLICATION, but how will DELETE-APPLICATION then be called? Perhaps we should take REGISTER-APPLICATION and DEREGISTER-APPLICATION, although I prefer "announce".. -- Max-Gerd Retzlaff http://blog.matroid.org For your amusement: Once is happenstance, Twice is coincidence, Three times is enemy action. -- Auric Goldfinger -------------- next part -------------- A non-text attachment was scrubbed... Name: clim-launcher-20060125-01.tar.bzip2 Type: application/octet-stream Size: 2866 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From m.retzlaff at gmx.net Wed Jan 25 03:18:06 2006 From: m.retzlaff at gmx.net (Max-Gerd Retzlaff) Date: Wed, 25 Jan 2006 04:18:06 +0100 Subject: [mcclim-devel] DEFINE-APPLCATION-STARTER and a modified Clim Launcher In-Reply-To: <87zmllwtwb.fsf@sigkill.dk> References: <20060124041628.GA7959@mgr.home> <87zmllwtwb.fsf@sigkill.dk> Message-ID: <20060125031806.GB16230@mgr.home> Hello On Tue, Jan 24, 2006 at 04:03:00PM +0100, Troels Henriksen wrote: > Generally, I think your idea is very cool. A standardized way to start > applications (apart from `run-frame-toplevel') would be highly > useful. Thank you. > I do, however, have a request: > > Max-Gerd Retzlaff writes: > > > Clim Launcher > > > > Together with the Launcher by Dwight Holman there is an additional > > benefit: The macro can announce the created starter to it. So that > > if you use it to define the function that fires up your GUI it will > > automatically displayed in the Clim Launcher. > > This functionality should not be wired to a specific launcher > program. Instead, McCLIM should maintain an *application-entry-points* > alist that maps application names to functions. Thereby, any > CLIM-application will be able to retrieve a list of the programs > available. This would also open for the possibility of creating > alternative launcher programs. This is perfectly possible. Think of CLIM-LAUNCHER as just what you want + a simplistic standard GUI. The list of applications ist called clim-launcher::*applications* (though it is not an association list right now but a list of application objects (this is part of what Dwight has written)), and the interface function to add and delete applications are currently named ADD-APPLICATION and DELETE-APPLICATION (see the footnote in my other, just sent mail about the names). I've just seperated both parts: The "backend" has right now got 39 lines of code, and the current GUI consists of 45 lines. To separate the parts is a good idea, and I have just done that in my private directory. Though I would like to have this very simple GUI interface included directly into McCLIM. This doesn't mean that there cannot be another shiny, flashing "launch bar" that is available via a separate package. Bye, Max -- Max-Gerd Retzlaff http://blog.matroid.org For your amusement: If you want to know what god thinks of money, just look at the people he gave it to. -- Dorthy Parker -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From clemens at endorphin.org Wed Jan 25 22:59:41 2006 From: clemens at endorphin.org (Clemens Fruhwirth) Date: Wed, 25 Jan 2006 23:59:41 +0100 Subject: [mcclim-devel] Guided Tour of CLIM Message-ID: <20060125230444.89F163CBC9@irulan.endorphin.org> 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 at endorphin.org From frido at q-software-solutions.de Thu Jan 26 07:51:52 2006 From: frido at q-software-solutions.de (Friedrich Dominicus) Date: Thu, 26 Jan 2006 08:51:52 +0100 Subject: [mcclim-devel] I guess what I want is not the clim way In-Reply-To: <20060125031806.GB16230@mgr.home> (Max-Gerd Retzlaff's message of "Wed, 25 Jan 2006 04:18:06 +0100") References: <20060124041628.GA7959@mgr.home> <87zmllwtwb.fsf@sigkill.dk> <20060125031806.GB16230@mgr.home> Message-ID: <87u0brmnon.fsf_-_@flarge.here> I'm trying to get a bit familiar with clim. I wonder about the user interface. The usual way in "normal" applications to get extra user inpt is via Dialog boxes. Now as I understand this is not the clim way it seems you use a interactor pane for it. I just wonder if I have overlooked something which may allow a more "dialog" oriented way.. Thanks Friedrich From clemens at endorphin.org Thu Jan 26 11:15:53 2006 From: clemens at endorphin.org (Clemens Fruhwirth) Date: Thu, 26 Jan 2006 12:15:53 +0100 Subject: [mcclim-devel] I guess what I want is not the clim way In-Reply-To: <87u0brmnon.fsf_-_@flarge.here> References: <20060124041628.GA7959@mgr.home> <87zmllwtwb.fsf@sigkill.dk> <20060125031806.GB16230@mgr.home> <87u0brmnon.fsf_-_@flarge.here> Message-ID: <20060126112100.E4CA03CBC9@irulan.endorphin.org> Friedrich Dominicus wrote: > I'm trying to get a bit familiar with clim. I wonder about the user > interface. The usual way in "normal" applications to get extra user > inpt is via Dialog boxes. Now as I understand this is not the clim > way it seems you use a interactor pane for it. I just wonder if I have > overlooked something which may allow a more "dialog" oriented way.. Just wrap your accept calls in (accepting-values (stream :own-window t) ...) Then a dialog window will pop up. -- Fruhwirth Clemens - http://clemens.endorphin.org for robots: sp4mtrap at endorphin.org From melevy at freemail.hu Fri Jan 27 08:44:49 2006 From: melevy at freemail.hu (=?ISO-8859-2?Q?M=E9sz=E1ros_Levente?=) Date: Fri, 27 Jan 2006 09:44:49 +0100 (CET) Subject: [mcclim-devel] CLIM on the WEB Message-ID: Hi, I don't know much about CLIM internals, so my theoretical question might be weird. Is it possible to render a CLIM application on current web browsers using JavaScript, XHTML and AJAX? I do not mean that is it possible right now (I wish it would be, but it certainly isn't) but conceptually? The idea comes from a requirement of being able to use light weight (actually it means already installed) clients through firewalls, etc. AFAICT some of CLIM code (event dispatch, some of event handling) would have to be (possibly automatically transformed and) run on the client side using JavaScript. Clearly a completely new backend would be needed (and I think some kind of continuation would be necessary on the server side). Maybe it's just not worth the effort... Any comments? Levy ________________________________________________________________ P?nz?gyi szolg?ltat?s ?s hitelig?nyl?s interneten kereszt?l a nap 24 ?r?j?ban. www.klikkbank.hu From luismbo at gmail.com Fri Jan 27 00:39:26 2006 From: luismbo at gmail.com (=?utf-8?Q?Lu=C3=ADs?= Oliveira) Date: Fri, 27 Jan 2006 00:39:26 +0000 Subject: [mcclim-devel] Re: Guided Tour of CLIM References: <20060125230444.89F163CBC9@irulan.endorphin.org> Message-ID: Clemens Fruhwirth writes: > http://clemens.endorphin.org/A%20Guided%20Tour%20of%20CLIM%202006-draft.pdf > > Feedback is appreciated. Hello, I'm going through the tutorial, and being very much clim-illiterate here are my few comments that I wrote down while doing so: - The tutorial is pretty cool. The introduction addresses what CLIM is good for, and how it relates to "normal" GUI toolkits, the terminology, etc... Very enlightening. - There's a typo in page 2: "(...) equally to the _build-in_ gadget types." - Mentioning the CLIM-USER package (where we can try the examples) might be a good idea. - I'd suggest restructuring the code in way that doesn't generate warnings about undefined functions. Eg: I was confused about why my McCLIM didn't seem to have this update-draw-pane function used in the draw-frame commands. - The draw-frame example doesn't work for me (SBCL 0.9.8 and McCLIM HEAD, CLX backend). I get an error saying: "The function (SETF RECTANGLE-EDGES*) is undefined." Hmm, and I get this same error with the file-browser example. - Another typo: in figure 7, "The second _color_ (...)". - I'd love to see figure 7's code in action. However, count-package-symbols isn't defined anywhere. (Ah, and in fig. 7 it actually reads _count-package-symbols-package_). Sure, it is trivial to implement, but still. :-) - Is the source code for the examples available somewhere? That'd be useful. Hope this helps in some say, -- Lu?s Oliveira luismbo (@) gmail (.) com Equipa Portuguesa do Translation Project http://www.iro.umontreal.ca/translation/registry.cgi?team=pt From ortmage at gmx.net Fri Jan 27 14:41:06 2006 From: ortmage at gmx.net (Scott Williams) Date: Fri, 27 Jan 2006 07:41:06 -0700 Subject: [mcclim-devel] Re: Guided Tour of CLIM In-Reply-To: References: <20060125230444.89F163CBC9@irulan.endorphin.org> Message-ID: <43DA3102.8030400@gmx.net> I'm also reading it, but haven't gotten all the way through it yet Lu?s Oliveira wrote: >Clemens Fruhwirth writes: > > >>http://clemens.endorphin.org/A%20Guided%20Tour%20of%20CLIM%202006-draft.pdf >> >>Feedback is appreciated. >> >> > >Hello, > >I'm going through the tutorial, and being very much clim-illiterate here >are my few comments that I wrote down while doing so: > > - The tutorial is pretty cool. The introduction addresses what CLIM is > good for, and how it relates to "normal" GUI toolkits, the > terminology, etc... Very enlightening. > > - There's a typo in page 2: "(...) equally to the _build-in_ gadget > types." > > - Mentioning the CLIM-USER package (where we can try the examples) > might be a good idea. > > - I'd suggest restructuring the code in way that doesn't generate > warnings about undefined functions. Eg: I was confused about why my > McCLIM didn't seem to have this update-draw-pane function used in > the draw-frame commands. > > - The draw-frame example doesn't work for me (SBCL 0.9.8 and McCLIM > HEAD, CLX backend). I get an error saying: > "The function (SETF RECTANGLE-EDGES*) is undefined." > Hmm, and I get this same error with the file-browser example. > > - Another typo: in figure 7, "The second _color_ (...)". > > - I'd love to see figure 7's code in action. However, > count-package-symbols isn't defined anywhere. (Ah, and in > fig. 7 it actually reads _count-package-symbols-package_). Sure, > it is trivial to implement, but still. :-) > > - Is the source code for the examples available somewhere? That'd be > useful. > >Hope this helps in some say, > > > From frido at q-software-solutions.de Fri Jan 27 15:59:29 2006 From: frido at q-software-solutions.de (Friedrich Dominicus) Date: Fri, 27 Jan 2006 16:59:29 +0100 Subject: [mcclim-devel] I guess what I want is not the clim way In-Reply-To: <20060126112100.E4CA03CBC9@irulan.endorphin.org> (Clemens Fruhwirth's message of "Thu, 26 Jan 2006 12:15:53 +0100") References: <20060124041628.GA7959@mgr.home> <87zmllwtwb.fsf@sigkill.dk> <20060125031806.GB16230@mgr.home> <87u0brmnon.fsf_-_@flarge.here> <20060126112100.E4CA03CBC9@irulan.endorphin.org> Message-ID: <874q3p8xwe.fsf@flarge.here> Oh, well it's that simply. Thanks I'll try it. Regards Friedrich From frido at q-software-solutions.de Fri Jan 27 16:35:28 2006 From: frido at q-software-solutions.de (Friedrich Dominicus) Date: Fri, 27 Jan 2006 17:35:28 +0100 Subject: [mcclim-devel] CLIM on the WEB In-Reply-To: (ISO's message of "Fri, 27 Jan 2006 09:44:49 +0100 (CET)") References: Message-ID: <87lkx17hnz.fsf@flarge.here> "=?ISO-8859-2?Q?M=E9sz=E1ros_Levente?=" writes: > Hi, > > I don't know much about CLIM internals, so my theoretical question > might be weird. > > Is it possible to render a CLIM application on current web browsers > using JavaScript, XHTML and AJAX? I do not mean that is it possible > right now (I wish it would be, but it certainly isn't) but > conceptually? Yes theoratically in practical Arthur Lemmens and (a bit me) have worke on making the present/accept Model available for Web pages. We do not use JavaScript we do no use any scripting all the stuff is done on the server side from within common lisp an example on how it looks: #| * Date example This example shows how to define a new presentation type that corresponds to multiple HTML gadgets. * Running the example: - Compile and load this buffer - Start a listener and do: CL-USER 1 > (in-package :wps.date) WPS.DATE 2 > (run) - Start a web-browser and enter the URL http://localhost:8000/date - When you're getting bored, stop the listener: WPS.DATE 3> (stop-running) |# (defpackage wps.date (:use :clim-lisp :clim :wps :lml2 :araneida) (:shadowing-import-from :lml2 #:html-stream #:html) #+lispworks ;; In Lispworks, CLIM-LISP::WRITE-SEQUENCE is not exported so we need ;; to import it explicitly. (:import-from :common-lisp #:write-sequence)) (in-package :wps.date) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;; Application ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; (defclass date-application (wps-application araneida:handler) ((title :accessor title :initform "WPS Date Example")) (:default-initargs :name "date")) (defmethod handle-wps-get-request ((handler date-application) stream request) ;; This is the wps entry point for dealing with HTTP GET requests ;; (POST requests are normally handled automatically by wps). ;; Here you look at request and the state of your app and decide what you're ;; going to do. For this example, we keep it simple and just show ;; the ask-for-date page. (declare (ignore request)) (ask-for-date stream)) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;; Defining the presentation type ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; (defconstant +months+ '(("January" 31) ("February" 28) ("March" 31) ("April" 30) ("May" 31) ("June" 30) ("July" 31) ("August" 31) ("September" 30) ("October" 31) ("November" 30) ("December" 31))) (defun ask-for-date (stream) (html-stream stream (:html (:head (:title "WPS Date")) (:body (html (:h1 (:princ-safe (title *wps-application*)))) (let (date) (with-continuation (k stream) (web-accepting-values (stream :continuation k :align-prompts :left) (setq date (accept 'date :stream stream :prompt "Date" :query-identifier 'date))) ;; Input accepted (html-stream stream (:html (:head (:title "WPS Date (response)")) (:body (:p (:princ-safe (format nil "You entered ~A" (present-to-string date 'date))))))))))))) (clim:define-presentation-type date () :options ((separator #\-))) (define-presentation-method accept ((type date) (stream wps-stream) view &key (default (get-universal-time)) query-identifier query-input-error-p &allow-other-keys) (when query-input-error-p (html-stream (encapsulating-stream-stream stream) (:p (:princ-safe "You entered an impossible date. Please try again.")))) (multiple-value-bind (sec min hr day month year) (decode-universal-time default) (declare (ignore sec min hr)) (multiple-value-bind (year year-type year-changed-p) (accept `(completion ,(loop for y from 1990 to 2020 collect y)) :stream stream :prompt "Year" :default year :query-identifier (format nil "~A.year" (html-query-identifier query-identifier))) (declare (ignore year-type)) (multiple-value-bind (month month-type month-changed-p) (accept `(member-alist ,(loop for name in (mapcar #'first +months+) for number from 1 collect (list name number))) :stream stream :prompt "Month" :default month :query-identifier (format nil "~A.month" (html-query-identifier query-identifier))) (declare (ignore month-type)) (multiple-value-bind (day day-type day-changed-p) (accept `(completion ,(loop for i from 1 to 31 collect i)) :stream stream :prompt "Day" :default day :query-identifier (format nil "~A.day" (html-query-identifier query-identifier))) (declare (ignore day-type)) (cond ((and year-changed-p month-changed-p day-changed-p) ;; Do a simple minded date check. (let ((max-nr-days (second (elt +months+ (1- month))))) (if (> day max-nr-days) (error 'wps-error :message "Wrong number of days for month.") (encode-universal-time 0 0 0 day month year)))) (t default))))))) ;; Define a PRESENT method for textual-views. (define-presentation-method present (universal-time (type date) stream (view textual-view) &key) ;; Print the date part of a universal-time. ;; Note how we can refer to the presentation-type option (separator) ;; without 'introducing' it explicitly. (multiple-value-bind (second minute hour day month year) (decode-universal-time universal-time) (declare (ignore second minute hour)) (format stream "~4,'0D~A~2,'0D~A~2,'0D" year separator month separator day))) ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;;; Araneida-specific setup ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; (defparameter *listener* (make-instance 'araneida:threaded-http-listener :port 8000)) (defun run (&key (application (make-instance 'date-application)) (host "localhost") (port 8000)) (araneida:install-handler (araneida:http-listener-handler *listener*) application (format nil "http://~A:~D/~A" host port (wps-application-name application)) nil) ;; For easier debugging. You may not want this for a production app. (setq araneida::*handler-timeout* 600) ;; (araneida:start-listening *listener*)) (defun stop-running () (araneida:stop-listening *listener*)) Regards Friedrich From m.retzlaff at gmx.net Fri Jan 27 16:10:55 2006 From: m.retzlaff at gmx.net (Max-Gerd Retzlaff) Date: Fri, 27 Jan 2006 17:10:55 +0100 Subject: [mcclim-devel] CLIM on the WEB In-Reply-To: References: Message-ID: <20060127161055.GB8184@mgr.home> Hi On Fri, Jan 27, 2006 at 09:44:49AM +0100, M?sz?ros Levente wrote: > Is it possible to render a CLIM application on current web browsers > using JavaScript, XHTML and AJAX? I do not mean that is it possible > right now (I wish it would be, but it certainly isn't) but conceptually? There is a "software tool for retrofiting graphical user interfaces developed for CLIM (the Common Lisp Interface Manager), to run dynamically through the World Wide Web." It has been made in around 1995, so it doesn't use fancy stuff like AJAX but HTML + GIFs with image maps/active regions. See http://www.ai.sri.com/~pkarp/clim-www/tool.html for more details. There is also a paper with the title "Adapting CLIM Applications for Use on the World Wide Web" that is available on that page. The application they have "retrofitted" with this tool is still online: http://ecocyc.org/server.html Bye, Max -- Max-Gerd Retzlaff http://blog.matroid.org For your amusement: There's no such thing as an original sin. -- Elvis Costello -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From amoroso at mclink.it Fri Jan 27 16:37:02 2006 From: amoroso at mclink.it (Paolo Amoroso) Date: Fri, 27 Jan 2006 17:37:02 +0100 Subject: [mcclim-devel] CLIM on the WEB In-Reply-To: <20060127161055.GB8184@mgr.home> (Max-Gerd Retzlaff's message of "Fri, 27 Jan 2006 17:10:55 +0100") References: <20060127161055.GB8184@mgr.home> Message-ID: <8764o5d3v5.fsf@plato.moon.paoloamoroso.it> Max-Gerd Retzlaff writes: > There is a "software tool for retrofiting graphical user interfaces > developed for CLIM (the Common Lisp Interface Manager), to run > dynamically through the World Wide Web." It has been made in around > 1995, so it doesn't use fancy stuff like AJAX but HTML + GIFs with > image maps/active regions. See http://www.ai.sri.com/~pkarp/clim-www/tool.html That's the one I meant in my post, thanks. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log From mikemac at mikemac.com Fri Jan 27 16:06:05 2006 From: mikemac at mikemac.com (Mike McDonald) Date: Fri, 27 Jan 2006 09:06:05 -0700 Subject: [mcclim-devel] CLIM on the WEB In-Reply-To: Your message of "Fri, 27 Jan 2006 09:44:49 +0100." Message-ID: <200601271606.k0RG65r08101@saturn.mikemac.com> >To: mcclim-devel at common-lisp.net >Date: Fri, 27 Jan 2006 09:44:49 +0100 (CET) >From: =?ISO-8859-2?Q?M=E9sz=E1ros_Levente?= > >Hi, > >I don't know much about CLIM internals, so my theoretical question >might be weird. > >Is it possible to render a CLIM application on current web browsers >using JavaScript, XHTML and AJAX? I do not mean that is it possible >right now (I wish it would be, but it certainly isn't) but conceptually? Xerox PARC did this ten years ago with CLIM. There used to be a paper on their site describing what they did. Mike McDonald mikemac at mikemac.com From csr21 at cam.ac.uk Mon Jan 30 12:13:33 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Mon, 30 Jan 2006 12:13:33 +0000 Subject: [mcclim-devel] Guided Tour of CLIM In-Reply-To: <20060125230444.89F163CBC9@irulan.endorphin.org> (Clemens Fruhwirth's message of "Wed, 25 Jan 2006 23:59:41 +0100") References: <20060125230444.89F163CBC9@irulan.endorphin.org> Message-ID: Clemens Fruhwirth writes: > 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. I've read it through, and from this first pass have a list of small typos, stylistic changes and the like that I'd like to suggest. I would have sent a diff with the changes, but unfortunately the current source is one-line-per-paragraph, which would make the diff extremely noisy and unclear. Would it be possible to insert line breaks in the source? The thing I would most like to see in terms of the document as a whole, I think, is a changebar (somewhat like in the second edition of CLtL) indicating the changed material, so that the reader can see what is essentially unchanged from the 1990 version. Cheers, Christophe From csr21 at cam.ac.uk Tue Jan 31 13:35:06 2006 From: csr21 at cam.ac.uk (Christophe Rhodes) Date: Tue, 31 Jan 2006 13:35:06 +0000 Subject: [mcclim-devel] Guided Tour of CLIM In-Reply-To: (Christophe Rhodes's message of "Mon, 30 Jan 2006 12:13:33 +0000") References: <20060125230444.89F163CBC9@irulan.endorphin.org> Message-ID: Christophe Rhodes writes: > Clemens Fruhwirth writes: > >> Here is my draft of an update to CLIM tutorial. > I've read it through, and from this first pass have a list of small > typos, stylistic changes and the like that I'd like to suggest. I > would have sent a diff with the changes, but unfortunately the current > source is one-line-per-paragraph, which would make the diff extremely > noisy and unclear. Would it be possible to insert line breaks in the > source? Find attached a diff against the linebroken version in Doc/Guided-Tour. These changes are suggestions -- where I've picked up on something, it may be that you can think of a better way to express it than I have. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: guided-tour.diff URL: -------------- next part -------------- Cheers, Christophe