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

[mcclim-devel] An easy question?
by Friedrich Dominicus 01 Feb '06

01 Feb '06

I'm trying to understand a bit more of clim. Now I'm stuck. How do I write an accept method which an be used in subset-completion? e.g I have the class (defclass t1 () ((val :initarg :val... (sval :initarge ...)))) Now I want to present a list of things to the user he/she can choose from something like (accept `(subset-completion ,(list (make-instance 't1 :val... (make-instance 't1 :val ....)))) I got a somewhat working solution with present-to-string but what I really want is something like this | | "(val t1 , (sval " .... for the first object | | "(val t1) .... for the second object etc. I'm sure there is something for that .... Help would be very appriciated. Regards Friedrich

1 0

[mcclim-devel] CLIM on the WEB
by Mészáros Levente 27 Jan '06

27 Jan '06

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

5 4

[mcclim-devel] DEFINE-APPLCATION-STARTER and a modified Clim Launcher
by Max-Gerd Retzlaff 27 Jan '06

27 Jan '06

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=334678781… PS: So many words for such a simple thing.. Hrm.. -- Max-Gerd Retzlaff <m.retzlaff(a)gmx.net> http://blog.matroid.org For your amusement: "The sixties were good to you, weren't they?" -- George Carlin

4 6

[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