From clinton at unknownlamer.org Tue May 6 19:25:52 2008 From: clinton at unknownlamer.org (Clinton Ebadi) Date: Tue, 06 May 2008 15:25:52 -0400 Subject: [mcclim-devel] Small patch for pixie look sliders Message-ID: <87skwvfd4v.fsf@unknownlamer.org> Greetings, When testing a small program I noticed that the value-changed callbacks in pixie look sliders were not being called. I compared the handle-event methods for the concrete gadget and pixie looks, and I think the attached patch is the correct fix (and just copied from (handle-event )). -------------- next part -------------- A non-text attachment was scrubbed... Name: pixie-slider-fix.patch Type: text/x-diff Size: 859 bytes Desc: pixie look slider fix URL: -------------- next part -------------- -- Jessie: i thought your beard took the oxygen from the air and made it breathable for you From clinton at unknownlamer.org Wed May 7 22:15:17 2008 From: clinton at unknownlamer.org (Clinton Ebadi) Date: Wed, 07 May 2008 18:15:17 -0400 Subject: [mcclim-devel] Gadget based accepting-values Message-ID: <87skwtep6y.fsf@unknownlamer.org> Greetings, Attached is a patch, accepting-values-gadgets-1, that makes accepting-values capable of working of with gadget based views. The (probably) uncontroversal part is exporting the CLIM 2.2 (from the Franz user guide) gadget views and the related constants. I added view-gadget-initargs support to gadget-view so gadgets can be created properly. The code merely stashes all the provided initargs into a slot and does no sanity checking. Should this somehow verify that the initargs are valid for the related gadget class? If so, what would be the cleanest way? I also caught the lack of a +check-box-view+ and added it. To the frame-manager protocol class I added the CLIM 2.2 frame-manager-dialog-view method which (for now) defaults to a textual rather than gadget based view. I noticed the XXX comment attached so I am unsure if this is an OK place to add it. accepting-values-stream now returns the frame manager dialog view as its stream-default-view. The Franz user guide says that this ought to be setfable; to which class should I add the slot and accessor? To accepting-values itself I moved the final cleanup of the input editor records into a generic, finally-finalize-query-record, so that accept-present-default methods that don't contain a text editing field can actually work. There are a few quick hackish methods for accepting from a text-field-view/gadget-dialog-view (the assumption being that they contain an input editing record so just calling them with +textual-dialog-view+ will work). I also reworked the accept-present-default for text-field-view to always call the textual-dialog-view method even if the width is not set. Also attached is avg.lisp which is a work in progress I'd like someone a bit more knowledgeable about CLIM to look at which implements gadget based accepting-values methods as per the Franz user guide. This is loosely based upon the public domain code found in [1]. If it looks ok I can split it up into the appropriate files in McCLIM and submit a patch. It seems to work well enough, but I am unsure if I have implemented things well. The most suspect bit is line 225 where I set the cache-test of the updating-output-record to return t always. I was having problems with a new gadget being created every time the value changed. gui.lisp contains a small test frame for testing whether the gadgets actually work. [1] http://osdir.com/ml/lisp.mcclim.devel/2006-04/msg00069.html -------------- next part -------------- A non-text attachment was scrubbed... Name: accept-values-gadgets-1.patch Type: text/x-diff Size: 10946 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: avg.lisp Type: application/octet-stream Size: 12311 bytes Desc: accepting values gadgets URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: gui.lisp Type: application/octet-stream Size: 2267 bytes Desc: test program URL: -------------- next part -------------- -- Jessie: but today i was a nerd Jessie: i even read slashdot. From athas at sigkill.dk Fri May 9 21:39:06 2008 From: athas at sigkill.dk (Troels Henriksen) Date: Fri, 09 May 2008 23:39:06 +0200 Subject: [mcclim-devel] Gadget based accepting-values In-Reply-To: <87skwtep6y.fsf@unknownlamer.org> (Clinton Ebadi's message of "Wed, 07 May 2008 18:15:17 -0400") References: <87skwtep6y.fsf@unknownlamer.org> Message-ID: <87y76jjgxx.fsf@lambda.athas.dyndns.dk> Clinton Ebadi writes: > Greetings, Sorry for the late reply, I didn't have the time to properly check your patch until just now. > Attached is a patch, accepting-values-gadgets-1, that makes > accepting-values capable of working of with gadget based views. The > (probably) uncontroversal part is exporting the CLIM 2.2 (from the > Franz user guide) gadget views and the related constants. This patch is great! I've wanted this functionality in McCLIM for quite a while and it's great fun to play with. > I added view-gadget-initargs support to gadget-view so gadgets can be > created properly. The code merely stashes all the provided initargs > into a slot and does no sanity checking. Should this somehow verify > that the initargs are valid for the related gadget class? If so, what > would be the cleanest way? Is this slot used anywhere in your code? I cannot find any uses, and I'd cautiously prefer letting specific gadget-view subclasses define initargs as appropriate for the gadget they support. > To the frame-manager protocol class I added the CLIM 2.2 > frame-manager-dialog-view method which (for now) defaults to a > textual rather than gadget based view. I noticed the XXX comment > attached so I am unsure if this is an OK place to add it. This looks like the right thing. Implementing CLIM 2.2 functionality is always a good thing, and there's nothing we can do about putting slot definitions in protocol-classes.lisp at the moment. > accepting-values-stream now returns the frame manager dialog view as > its stream-default-view. The Franz user guide says that this ought to > be setfable; to which class should I add the slot and accessor? Probably to the accepting-values-stream itself. > To accepting-values itself I moved the final cleanup of the input > editor records into a generic, finally-finalize-query-record, so that > accept-present-default methods that don't contain a text editing field > can actually work. This is necessary, yes. Accepting-values is a bit of a hack, because I don't think CLIM actually specifies enough behaviour for it to be user-extensible... This issue might also stem from the fact that McCLIM uses an input-editing-stream to implement the "default" dialog input fields. I've been told that classic CLIM uses text-field gadgets, which may arguably be a better solution in general. > There are a few quick hackish methods for accepting from a > text-field-view/gadget-dialog-view (the assumption being that they > contain an input editing record so just calling them with > +textual-dialog-view+ will work). I also reworked the > accept-present-default for text-field-view to always call the > textual-dialog-view method even if the width is not set. I don't fully understand what's going on here... which purpose does the gadget-dialog-view class serve? What kind of view is it? Generally your patch seems to do the right thing. I'm not knowledgeable enough about CLIM dialog issues to fully judge its merits, but it looks good to me. > Also attached is avg.lisp which is a work in progress I'd like someone > a bit more knowledgeable about CLIM to look at which implements gadget > based accepting-values methods as per the Franz user guide. This is > loosely based upon the public domain code found in [1]. If it looks ok > I can split it up into the appropriate files in McCLIM and submit a > patch. It seems to work well enough, but I am unsure if I have > implemented things well. The most suspect bit is line 225 where I set > the cache-test of the updating-output-record to return t always. I was > having problems with a new gadget being created every time the value > changed. There is one thing here I take issue with, though it may mostly reveal my inexperience with dialogs: you create a bunch of new, internal presentation generic functions. This makes it essentially impossible for user-defined gadgets to be used in views. Wouldn't it be better to use the normal accept-by-gadget-view methods in dialogs (I know they don't fully work yet, yes)? I'm not much in favor of devising new, internal protocols until we are completely sure that the existing CLIM facilities are insufficient. > gui.lisp contains a small test frame for testing whether the gadgets > actually work. This program, and gadget views, do show some powerful CLIM qualities. I love how easy (relatively speaking...) it is to take gadgets out of their normal environment and stuff them into a command prompt setting. -- \ Troels /\ Henriksen From clinton at unknownlamer.org Sat May 10 18:34:27 2008 From: clinton at unknownlamer.org (Clinton Ebadi) Date: Sat, 10 May 2008 14:34:27 -0400 Subject: [mcclim-devel] Gadget based accepting-values In-Reply-To: <87y76jjgxx.fsf@lambda.athas.dyndns.dk> (Troels Henriksen's message of "Fri\, 09 May 2008 23\:39\:06 +0200") References: <87skwtep6y.fsf@unknownlamer.org> <87y76jjgxx.fsf@lambda.athas.dyndns.dk> Message-ID: <87lk2i80uk.fsf@unknownlamer.org> Troels Henriksen writes: > Clinton Ebadi writes: > >> Greetings, > > Sorry for the late reply, I didn't have the time to properly check > your patch until just now. > >> Attached is a patch, accepting-values-gadgets-1, that makes >> accepting-values capable of working of with gadget based views. The >> (probably) uncontroversal part is exporting the CLIM 2.2 (from the >> Franz user guide) gadget views and the related constants. > > This patch is great! I've wanted this functionality in McCLIM for > quite a while and it's great fun to play with. > >> I added view-gadget-initargs support to gadget-view so gadgets can be >> created properly. The code merely stashes all the provided initargs >> into a slot and does no sanity checking. Should this somehow verify >> that the initargs are valid for the related gadget class? If so, what >> would be the cleanest way? > > Is this slot used anywhere in your code? I cannot find any uses, and > I'd cautiously prefer letting specific gadget-view subclasses define > initargs as appropriate for the gadget they support. Yes, it is used in make-gadget-for-view to pass any user specified initargs to the gadget created for the view. This was just a quick make-it-work thing. I think LispWorks CLIM has a similar method (at least a comment in the original pavp.lisp made it seem so; I have no idea since I have no access to any proprietary implementations). >> accepting-values-stream now returns the frame manager dialog view as >> its stream-default-view. The Franz user guide says that this ought to >> be setfable; to which class should I add the slot and accessor? > > Probably to the accepting-values-stream itself. On page 149 of the Franz user guide it seems to say that stream-default-view should be setfable on every stream, and that on accepting-values streams it should be frame-manager-dialog-view by default. >> To accepting-values itself I moved the final cleanup of the input >> editor records into a generic, finally-finalize-query-record, so that >> accept-present-default methods that don't contain a text editing field >> can actually work. > > This is necessary, yes. Accepting-values is a bit of a hack, because I > don't think CLIM actually specifies enough behaviour for it to be > user-extensible... > > This issue might also stem from the fact that McCLIM uses an > input-editing-stream to implement the "default" dialog input > fields. I've been told that classic CLIM uses text-field gadgets, > which may arguably be a better solution in general. I'll implement text-field based text fields in the next revision of avg.lisp rather than falling back to textual-dialog-view. I've also been building a planner page with a list of the unimplemented features of accepting-values and I intend to implement the ones that I can. I have :exit-boxes implemented and a first stab at accept-value-command-button. >> There are a few quick hackish methods for accepting from a >> text-field-view/gadget-dialog-view (the assumption being that they >> contain an input editing record so just calling them with >> +textual-dialog-view+ will work). I also reworked the >> accept-present-default for text-field-view to always call the >> textual-dialog-view method even if the width is not set. > > I don't fully understand what's going on here... which purpose does > the gadget-dialog-view class serve? What kind of view is it? The gadget-dialog-view class is the default for gadget based dialog streams, and resolves to sane default views for basic types. See page 150 of the Franz UG. > Generally your patch seems to do the right thing. I'm not > knowledgeable enough about CLIM dialog issues to fully judge its > merits, but it looks good to me. > >> Also attached is avg.lisp which is a work in progress I'd like someone >> a bit more knowledgeable about CLIM to look at which implements gadget >> based accepting-values methods as per the Franz user guide. This is >> loosely based upon the public domain code found in [1]. If it looks ok >> I can split it up into the appropriate files in McCLIM and submit a >> patch. It seems to work well enough, but I am unsure if I have >> implemented things well. The most suspect bit is line 225 where I set >> the cache-test of the updating-output-record to return t always. I was >> having problems with a new gadget being created every time the value >> changed. > > There is one thing here I take issue with, though it may mostly reveal > my inexperience with dialogs: you create a bunch of new, internal > presentation generic functions. This makes it essentially impossible > for user-defined gadgets to be used in views. Wouldn't it be better to > use the normal accept-by-gadget-view methods in dialogs (I know they > don't fully work yet, yes)? I'm not much in favor of devising new, > internal protocols until we are completely sure that the existing CLIM > facilities are insufficient. Could you point me toward these accept-by-gadget-view methods? I couldn't find anything with a similar name in the clim-internals package or the spec or the franz user guide; I'm fairly new to CLIM (I wrote this so I could use presentations and still have option-panes and such in my first CLIM program) so I'm not sure where everything is yet. I'm not sure if the CLIM spec specifies enough for a user to add his own gadget views except when built upon the ones provided by the implementation. It would be nice if there were though, or, failing that, compatibility with other CLIM implementation's internal protocols for this. As McCLIM is the only CLIM I have access to I require some guidance here. -- Jessie: but today i was a nerd Jessie: i even read slashdot. From athas at sigkill.dk Sat May 10 21:27:06 2008 From: athas at sigkill.dk (Troels Henriksen) Date: Sat, 10 May 2008 23:27:06 +0200 Subject: [mcclim-devel] Gadget based accepting-values In-Reply-To: <87lk2i80uk.fsf@unknownlamer.org> (Clinton Ebadi's message of "Sat, 10 May 2008 14:34:27 -0400") References: <87skwtep6y.fsf@unknownlamer.org> <87y76jjgxx.fsf@lambda.athas.dyndns.dk> <87lk2i80uk.fsf@unknownlamer.org> Message-ID: <87lk2hkfyt.fsf@lambda.athas.dyndns.dk> Clinton Ebadi writes: > Yes, it is used in make-gadget-for-view to pass any user specified > initargs to the gadget created for the view. This was just a quick > make-it-work thing. I think LispWorks CLIM has a similar method (at > least a comment in the original pavp.lisp made it seem so; I have no > idea since I have no access to any proprietary implementations). Oh, so you don't see any problem with letting such initargs be up to the specific gadget view? That would also have another benefit, namely the ability of the view to easily filter the permitted initargs. It is possible that not all features of a gadget may be permitted when it is used in a dialog. > On page 149 of the Franz user guide it seems to say that > stream-default-view should be setfable on every stream, and that on > accepting-values streams it should be frame-manager-dialog-view by > default. It should still be defined for each specific stream class, not in a superclass, since each specific stream implementation may want to implement it in a different way. FWIW, the standard-extended-output-stream implements it as just a slot with an accessor. > I'll implement text-field based text fields in the next revision of > avg.lisp rather than falling back to textual-dialog-view. Do you think this should be the default? Do you think it should even be possible to use input-editing streams in dialogs? > I've also been building a planner page with a list of the > unimplemented features of accepting-values and I intend to implement > the ones that I can. I have :exit-boxes implemented and a first stab > at accept-value-command-button. It would be good if you could put it on http://mcclim.cliki.net, so that others can see what is missing (and possibly pitch in). > The gadget-dialog-view class is the default for gadget based dialog > streams, and resolves to sane default views for basic types. See page > 150 of the Franz UG. Most of the dialog gadget-views in the current implementation seem to inherit from gadget-view, not gadget-dialog-view, though. Should this thus be fixed? > Could you point me toward these accept-by-gadget-view methods? I > couldn't find anything with a similar name in the clim-internals > package or the spec or the franz user guide; I'm fairly new to CLIM (I > wrote this so I could use presentations and still have option-panes > and such in my first CLIM program) so I'm not sure where everything is > yet. They aren't in McCLIM itself yet, partly because no-one is sure that everything is in place to support them. I have an example, though, that does work for my test cases: (define-presentation-method accept ((type subset-completion) stream (view list-pane-view) &key) (with-look-and-feel-realization ((frame-manager *application-frame*) *application-frame*) (block body (multiple-value-bind (list-pane list-record) (with-output-as-gadget (stream) (make-pane 'list-pane :items sequence :mode :nonexclusive)) (multiple-value-bind (button-pane button-record) (with-output-as-gadget (stream) (make-pane 'push-button :label "Done" :activate-callback #'(lambda (button) (declare (ignore button)) (return-from body (gadget-value list-pane))))) (declare (ignore button-pane)) (unwind-protect (loop (read-gesture :stream stream)) (delete-output-record list-record (output-record-parent list-record)) (delete-output-record button-record (output-record-parent button-record)))))))) You will notice that: 1) It is a bit horrible. 2) It isn't really possible to automatically embed this in a dialog, the way we can currently do with input-editing streams. Perhaps it will always be necessary to have a specialised protocol for dialog-gadget-views (perhaps that is even the purpose of that class?). In that case, I think we should simplify your protocol and export it from CLIM-EXTENSIONS - or even better, find some existing CLIM facility that enables this. > I'm not sure if the CLIM spec specifies enough for a user to add his > own gadget views except when built upon the ones provided by the > implementation. It would be nice if there were though, or, failing > that, compatibility with other CLIM implementation's internal > protocols for this. As McCLIM is the only CLIM I have access to I > require some guidance here. I don't have access to anything but McCLIM either. I would not be surprised to hear that commercial CLIM implementations do not have the extensibility I would like to see in McCLIM. They often differ from how I would imagine a good CLIM implementation to work. :-) -- \ Troels /\ Henriksen From clinton at unknownlamer.org Sat May 10 23:15:39 2008 From: clinton at unknownlamer.org (Clinton Ebadi) Date: Sat, 10 May 2008 19:15:39 -0400 Subject: [mcclim-devel] Gadget based accepting-values In-Reply-To: <87lk2hkfyt.fsf@lambda.athas.dyndns.dk> (Troels Henriksen's message of "Sat\, 10 May 2008 23\:27\:06 +0200") References: <87skwtep6y.fsf@unknownlamer.org> <87y76jjgxx.fsf@lambda.athas.dyndns.dk> <87lk2i80uk.fsf@unknownlamer.org> <87lk2hkfyt.fsf@lambda.athas.dyndns.dk> Message-ID: <877ie192ec.fsf@unknownlamer.org> Troels Henriksen writes: > Clinton Ebadi writes: > >> Yes, it is used in make-gadget-for-view to pass any user specified >> initargs to the gadget created for the view. This was just a quick >> make-it-work thing. I think LispWorks CLIM has a similar method (at >> least a comment in the original pavp.lisp made it seem so; I have no >> idea since I have no access to any proprietary implementations). > > Oh, so you don't see any problem with letting such initargs be up to > the specific gadget view? That would also have another benefit, namely > the ability of the view to easily filter the permitted initargs. It is > possible that not all features of a gadget may be permitted when it is > used in a dialog. The Franz userguide (p. 148) says that gadget views are intended to take all of the options of the related gadget. It doesn't make much sense to allow initargs related to setting the value through though, but is harmless (at least for the predefined views) since it would be overridden anyway. The only problem then is how to implement it. If the view has slots for each option it is a bit of a pain to assemble the initarg list for the gadget. With my quick implementation subclasses could specialize view-gadget-initargs to remove any unsupported options. >> On page 149 of the Franz user guide it seems to say that >> stream-default-view should be setfable on every stream, and that on >> accepting-values streams it should be frame-manager-dialog-view by >> default. > > It should still be defined for each specific stream class, not in a > superclass, since each specific stream implementation may want to > implement it in a different way. FWIW, the > standard-extended-output-stream implements it as just a slot with an > accessor. Ah ok. I didn't notice that there was a slot for it in standard-extended-output-stream (I just saw the method on accepting-values-stream and figured there was no slot for it). >> I'll implement text-field based text fields in the next revision of >> avg.lisp rather than falling back to textual-dialog-view. > > Do you think this should be the default? Do you think it should even > be possible to use input-editing streams in dialogs? For textually oriented dialogs using an input editing stream seems to make sense. Are there streams in CLIM that cannot have gadgets on them? For gadget based views using text-field/text-editor is the saner choice and I'm implementing that now (trying to figure out how to call accept at the right time). >> I've also been building a planner page with a list of the >> unimplemented features of accepting-values and I intend to implement >> the ones that I can. I have :exit-boxes implemented and a first stab >> at accept-value-command-button. > > It would be good if you could put it on http://mcclim.cliki.net, so > that others can see what is missing (and possibly pitch in). Will do. >> The gadget-dialog-view class is the default for gadget based dialog >> streams, and resolves to sane default views for basic types. See page >> 150 of the Franz UG. > > Most of the dialog gadget-views in the current implementation seem to > inherit from gadget-view, not gadget-dialog-view, though. Should this > thus be fixed? I am fairly certain that the individual gadget views are supposed to inherit from gadget-view; gadget-dialog-view is like textual-dialog-view in that it represents the view for the entire dialog. Perhaps someone has access to Allegro or LispWorks CLIM and could check the class heirarchy? I can see why they might be derived from gadget-dialog-view instead >> Could you point me toward these accept-by-gadget-view methods? I >> couldn't find anything with a similar name in the clim-internals >> package or the spec or the franz user guide; I'm fairly new to CLIM (I >> wrote this so I could use presentations and still have option-panes >> and such in my first CLIM program) so I'm not sure where everything is >> yet. > > They aren't in McCLIM itself yet, partly because no-one is sure that > everything is in place to support them. I have an example, though, > that does work for my test cases: > ... > > You will notice that: > > 1) It is a bit horrible. > > 2) It isn't really possible to automatically embed this in a dialog, > the way we can currently do with input-editing streams. Perhaps it > will always be necessary to have a specialised protocol for > dialog-gadget-views (perhaps that is even the purpose of that > class?). In that case, I think we should simplify your protocol and > export it from CLIM-EXTENSIONS - or even better, find some existing > CLIM facility that enables this. The Franz userguide says that accept on a gadget-view outside of a dialog is not intended to work. This makes sense to me because of the mismatch between synchronous accept and asychronous gadgets; inside of a dialog the entire dialog blocks allowing the desired behavior to be achieved. In any case you can always call accepting-values with just a single accept and then it handles blocking until :exit is clicked generically. The big issue I see is that accept-present-default is called with the encapsulated stream of accepting-values-stream rather than the a-v-stream itself. This prevents user defined gadgets views from working without accessing some internals (the *accepting-values-stream*) or using a manual :value-changed-callback and nastiness of throwing presentations around (and still then using the internal com-change-query). Is there any reason for this other than using input editing streams? I tried a quick experiment with just passing the a-v-stream but it failed in a few places. I got it to at least get as far as displaying when I merged the a-v-record and a-v-stream types, but it blew up after displaying the first prompt. The spec makes it seem that an encapsulating stream should be transparant to most code (lack of knowledge of CLIM here...). If the accepting-values-stream itself were passed to accept-present-default then creating a new gadget based accept would be much cleaner: (let ((top-level-stream stream)) (updating-output (...) (with-output-as-gadget (...) (make-pane ... :client top-level-stream ...)))) With all of the arcane magic hidden in the value-changed-callback specialized on accepting-values-stream. There would still be some uncleanliness owing to the lack of specification about how this should work, but it's better than not being able to do it at all without relying on internal methods. OTOH I don't know if this would be portable anyway (still, using specified bits of CLIM is always nicer). I'll work on simplifying the internal protocol now. button-labels could just be done as a function typecased on (check-box radio-box) / (option-pane list-pane) as it is really just a convenience function for generating them. encode/decode-gadget-view are also only really used for check/radio boxes because they receive/return toggle-buttons instead of the values contained within. This could be fixed by subclassing them and adding :around methods to the needed methods to do conversion automatically. Likewise for sliders and coercing the result from a rational into a float or integer when needed. Does this sound like a good idea? I'm not quite sure how to eliminate gadget-initargs-for-view, view-gadget-initargs, or make-gadget-for-view without creating a lot of duplicated code. If the a-v-stream stuff can be resolved so that users could create custom gadget views then the same things can be accomplished by hand for the user views anyway. They also seem like reasonable things to put into clim-extensions. I've seen list posts mentioning CLIM 2.5 before. Which implementation does this correspond to? If there is a manual for it online perhaps it has more to say about this. -- ntk is currently using "telnet fyodor 25" to send email From pw at snoopy.mv.com Sun May 11 13:08:13 2008 From: pw at snoopy.mv.com (Paul Werkowski) Date: Sun, 11 May 2008 09:08:13 -0400 Subject: [mcclim-devel] Gadget based accepting-values In-Reply-To: <877ie192ec.fsf@unknownlamer.org> References: <87skwtep6y.fsf@unknownlamer.org> <87y76jjgxx.fsf@lambda.athas.dyndns.dk> <87lk2i80uk.fsf@unknownlamer.org> <87lk2hkfyt.fsf@lambda.athas.dyndns.dk> <877ie192ec.fsf@unknownlamer.org> Message-ID: <4826EFBD.9080201@snoopy.mv.com> Clinton Ebadi wrote: > I am fairly certain that the individual gadget views are supposed to > inherit from gadget-view; gadget-dialog-view is like > textual-dialog-view in that it represents the view for the entire > dialog. Perhaps someone has access to Allegro or LispWorks CLIM and > could check the class heirarchy? I can see why they might be derived > from gadget-dialog-view instead > In Lispworks CLIM, which seems to match the CLIM 2.2 spec (although you can't tell that from the documentation) standard-object clim:view clim:textual-view clim:gadget-view clim:gadget-menu-view clim:gadget-dialog-view clim:internals::actual-gadget-view clim:check-box-view, etc clim:pointer-documentation-view clim:textual-dialog-view clim:textual-menu-view Paul From chris_melen at yahoo.com Mon May 12 18:01:56 2008 From: chris_melen at yahoo.com (christopher melen) Date: Mon, 12 May 2008 19:01:56 +0100 (BST) Subject: [mcclim-devel] cl-jpeg dependency with ASDF-install (bug?) Message-ID: <881101.16658.qm@web54306.mail.re2.yahoo.com> When I try to ASDF-install McClim (on Mac OS X) it complains that it can't install a dependency, cl-jpeg. This library appears to be no longer available. __________________________________________________________ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html From ch-mcclim at bobobeach.com Mon May 12 18:12:51 2008 From: ch-mcclim at bobobeach.com (Cyrus Harmon) Date: Mon, 12 May 2008 11:12:51 -0700 Subject: [mcclim-devel] cl-jpeg dependency with ASDF-install (bug?) In-Reply-To: <881101.16658.qm@web54306.mail.re2.yahoo.com> References: <881101.16658.qm@web54306.mail.re2.yahoo.com> Message-ID: It is available, but it is currently not asdf-install-installable. I recommend installing manually from the CVS repository. Cyrus On May 12, 2008, at 11:01 AM, christopher melen wrote: > When I try to ASDF-install McClim (on Mac OS X) it > complains that it can't install a dependency, cl-jpeg. > This library appears to be no longer available. > > > __________________________________________________________ > Sent from Yahoo! Mail. > A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html > _______________________________________________ > mcclim-devel mailing list > mcclim-devel at common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel From athas at sigkill.dk Mon May 12 18:21:10 2008 From: athas at sigkill.dk (Troels Henriksen) Date: Mon, 12 May 2008 20:21:10 +0200 Subject: [mcclim-devel] Gadget based accepting-values In-Reply-To: <877ie192ec.fsf@unknownlamer.org> (Clinton Ebadi's message of "Sat, 10 May 2008 19:15:39 -0400") References: <87skwtep6y.fsf@unknownlamer.org> <87y76jjgxx.fsf@lambda.athas.dyndns.dk> <87lk2i80uk.fsf@unknownlamer.org> <87lk2hkfyt.fsf@lambda.athas.dyndns.dk> <877ie192ec.fsf@unknownlamer.org> Message-ID: <874p93pend.fsf@lambda.athas.dyndns.dk> Clinton Ebadi writes: > For textually oriented dialogs using an input editing stream seems to > make sense. Are there streams in CLIM that cannot have gadgets on > them? None that can have input-editing streams on them, anyway. > For gadget based views using text-field/text-editor is the saner > choice and I'm implementing that now (trying to figure out how to call > accept at the right time). But what about the default view, when nothing else is specified? With the input-editing stream, you get completion, which is nice. Can this be replicated with gadgets, I wonder? > I am fairly certain that the individual gadget views are supposed to > inherit from gadget-view; gadget-dialog-view is like > textual-dialog-view in that it represents the view for the entire > dialog. Perhaps someone has access to Allegro or LispWorks CLIM and > could check the class heirarchy? I can see why they might be derived > from gadget-dialog-view instead Oh yeah, it seems I was confused (who'd have thought?). > The Franz userguide says that accept on a gadget-view outside of a > dialog is not intended to work. This makes sense to me because of the > mismatch between synchronous accept and asychronous gadgets; inside of > a dialog the entire dialog blocks allowing the desired behavior to be > achieved. The Franz documentation does indeed say that, but I have seen screenshots from other CLIM implementations where it is clearly supported. And as you can see from my example, it's possible to get it to work. It's not a big issue to actually define a bunch of presentation methods for gadget views outside of dialogs, though, I'm willing to postpone that to a later date. > [technical issues] I'm not familiar enough with dialogs to provide advice on this, so I'll defer to your recommendations. > I've seen list posts mentioning CLIM 2.5 before. Which implementation > does this correspond to? If there is a manual for it online perhaps it > has more to say about this. I have never heard of CLIM 2.5 before. I have, however, heard of CLIM 2.1, which seems to be LispWorks CLIM. -- \ Troels /\ Henriksen From clinton at unknownlamer.org Tue May 13 13:54:33 2008 From: clinton at unknownlamer.org (Clinton Ebadi) Date: Tue, 13 May 2008 09:54:33 -0400 Subject: [mcclim-devel] Gadget based accepting-values In-Reply-To: <874p93pend.fsf@lambda.athas.dyndns.dk> (Troels Henriksen's message of "Mon\, 12 May 2008 20\:21\:10 +0200") References: <87skwtep6y.fsf@unknownlamer.org> <87y76jjgxx.fsf@lambda.athas.dyndns.dk> <87lk2i80uk.fsf@unknownlamer.org> <87lk2hkfyt.fsf@lambda.athas.dyndns.dk> <877ie192ec.fsf@unknownlamer.org> <874p93pend.fsf@lambda.athas.dyndns.dk> Message-ID: <87tzh271ie.fsf@unknownlamer.org> Troels Henriksen writes: > The Franz documentation does indeed say that, but I have seen > screenshots from other CLIM implementations where it is clearly > supported. And as you can see from my example, it's possible to get it > to work. > > It's not a big issue to actually define a bunch of presentation > methods for gadget views outside of dialogs, though, I'm willing to > postpone that to a later date. I could see this working with an :around method on accept-present-default for normal gadget-view outside of a dialog. I may try to implement this later, but I do want to get back to the program I was writing first (my initial itch has nearly been scratched, but polishing little bits of mcclim is fun). I've attached a new patch that sets up the framework for getting gadget based dialogs working, and also adds initial support for setting the :exit-boxes of an accepting-values stream. I also have a function for displaying them nicely on a gadget based stream (which I'll send in with the patch to add the rest of the gadget based dialog code): (defmethod display-exit-boxes (frame stream (view gadget-dialog-view)) (updating-output (stream :unique-id 'buttons :cache-value t) (with-look-and-feel-realization ((frame-manager frame) frame) (fresh-line stream) (with-output-as-gadget (stream) (horizontally () (make-pane 'push-button :label (second (assoc :exit (exit-boxes *accepting-values-stream*))) :activate-callback (lambda (g) (declare (ignore g)) (com-query-exit))) (make-pane 'push-button :label (second (assoc :abort (exit-boxes *accepting-values-stream*))) :activate-callback (lambda (g) (declare (ignore g)) (com-query-abort))))) (terpri stream)))) I think the patch is good enough to merge into cvs. I'm finishing up the last few issues with the gadget dialog views now, and should have a set of fairly clean working patches in a few days. -------------- next part -------------- A non-text attachment was scrubbed... Name: accept-values-gadgets-2.patch Type: text/x-diff Size: 12650 bytes Desc: not available URL: -------------- next part -------------- -- Jessie: i thought your beard took the oxygen from the air and made it breathable for you From clinton at unknownlamer.org Tue May 13 17:38:05 2008 From: clinton at unknownlamer.org (Clinton Ebadi) Date: Tue, 13 May 2008 13:38:05 -0400 Subject: [mcclim-devel] Gadget based accepting-values In-Reply-To: <87tzh271ie.fsf@unknownlamer.org> (Clinton Ebadi's message of "Tue\, 13 May 2008 09\:54\:33 -0400") References: <87skwtep6y.fsf@unknownlamer.org> <87y76jjgxx.fsf@lambda.athas.dyndns.dk> <87lk2i80uk.fsf@unknownlamer.org> <87lk2hkfyt.fsf@lambda.athas.dyndns.dk> <877ie192ec.fsf@unknownlamer.org> <874p93pend.fsf@lambda.athas.dyndns.dk> <87tzh271ie.fsf@unknownlamer.org> Message-ID: <87lk2e6r5u.fsf@unknownlamer.org> Clinton Ebadi writes: > I've attached a new patch that sets up the framework for getting > gadget based dialogs working, and also adds initial support for > setting the :exit-boxes of an accepting-values stream. I also have a > function for displaying them nicely on a gadget based stream (which > I'll send in with the patch to add the rest of the gadget based dialog > code): Whoops, I accidentally reverted the finally-finalize-query-record bit. Attached is a fixed patch. -------------- next part -------------- A non-text attachment was scrubbed... Name: accept-values-gadgets-2a.patch Type: text/x-diff Size: 13528 bytes Desc: not available URL: -------------- next part -------------- -- ntk is currently using "telnet fyodor 25" to send email From clinton at unknownlamer.org Tue May 13 17:44:01 2008 From: clinton at unknownlamer.org (Clinton Ebadi) Date: Tue, 13 May 2008 13:44:01 -0400 Subject: [mcclim-devel] Gadget based accepting-values In-Reply-To: <87tzh271ie.fsf@unknownlamer.org> (Clinton Ebadi's message of "Tue\, 13 May 2008 09\:54\:33 -0400") References: <87skwtep6y.fsf@unknownlamer.org> <87y76jjgxx.fsf@lambda.athas.dyndns.dk> <87lk2i80uk.fsf@unknownlamer.org> <87lk2hkfyt.fsf@lambda.athas.dyndns.dk> <877ie192ec.fsf@unknownlamer.org> <874p93pend.fsf@lambda.athas.dyndns.dk> <87tzh271ie.fsf@unknownlamer.org> Message-ID: <87ej866qvy.fsf@unknownlamer.org> And of course I forgot to change gadget-dialog-view to gadget-view in the superclass list of text-editor-view too, but on second thought it's probably worthwhile to hold off committing my patch if anyone intended to until I finish a few more infrastructure updates. I realized why passing the accepting-values-stream directly to accept-present-default did not work: mcclim encapsulated streams don't implement the incremental redisplay protocol depsite being required to. I'm fixing that and passing accepting-values-stream directly to accept-present-default. It is really required to allow library users to use gadget views for accepting anything other than primitive types. -- ntk is currently using "telnet fyodor 25" to send email From clinton at unknownlamer.org Tue May 13 19:06:56 2008 From: clinton at unknownlamer.org (Clinton Ebadi) Date: Tue, 13 May 2008 15:06:56 -0400 Subject: [mcclim-devel] Gadget based accepting-values In-Reply-To: <874p93pend.fsf@lambda.athas.dyndns.dk> (Troels Henriksen's message of "Mon\, 12 May 2008 20\:21\:10 +0200") References: <87skwtep6y.fsf@unknownlamer.org> <87y76jjgxx.fsf@lambda.athas.dyndns.dk> <87lk2i80uk.fsf@unknownlamer.org> <87lk2hkfyt.fsf@lambda.athas.dyndns.dk> <877ie192ec.fsf@unknownlamer.org> <874p93pend.fsf@lambda.athas.dyndns.dk> Message-ID: <877idy6n1r.fsf@unknownlamer.org> Troels Henriksen writes: > It's not a big issue to actually define a bunch of presentation > methods for gadget views outside of dialogs, though, I'm willing to > postpone that to a later date. > >> [technical issues] > > I'm not familiar enough with dialogs to provide advice on this, so > I'll defer to your recommendations. Ok, I have now attached a third revision of the patch to add the infrastructure needed to support gadget based accepting-values dialogs. The big change is that encapsulating streams now support the incremental redisplay protocol, and so stream-accept on an accepting-values-stream can now pass the encapsulating stream to accept-present-default. This removes a bit of the ugliness from the accept-present-default methods for displaying gadgets in general. I'm still trying to figure out how to make nested calls to accept work (e.g. for a user defined accept-present-default that accepts a few primitive types) without resorting to nested accepting-values calls. I've also attached a newer avg.lisp that should be fully working if a bit in need of cleanup. Now supported are text-field and text-editor gadgets. -------------- next part -------------- A non-text attachment was scrubbed... Name: accept-values-gadgets-3.patch Type: text/x-diff Size: 14855 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: avg.lisp Type: application/octet-stream Size: 16021 bytes Desc: not available URL: -------------- next part -------------- -- thehurdguy: LOL you'll end up being like that urban myth thehurdguy: the guy that thinks he's orange juice thehurdguy: I'll be like "dude, I know a lisp programmer who did so much acid, he thinks he's an empty list..." From athas at sigkill.dk Tue May 13 19:55:00 2008 From: athas at sigkill.dk (Troels Henriksen) Date: Tue, 13 May 2008 21:55:00 +0200 Subject: [mcclim-devel] Gadget based accepting-values In-Reply-To: <87tzh271ie.fsf@unknownlamer.org> (Clinton Ebadi's message of "Tue, 13 May 2008 09:54:33 -0400") References: <87skwtep6y.fsf@unknownlamer.org> <87y76jjgxx.fsf@lambda.athas.dyndns.dk> <87lk2i80uk.fsf@unknownlamer.org> <87lk2hkfyt.fsf@lambda.athas.dyndns.dk> <877ie192ec.fsf@unknownlamer.org> <874p93pend.fsf@lambda.athas.dyndns.dk> <87tzh271ie.fsf@unknownlamer.org> Message-ID: <87zlquou7f.fsf@lambda.athas.dyndns.dk> Clinton Ebadi writes: > I think the patch is good enough to merge into cvs. I'm finishing up > the last few issues with the gadget dialog views now, and should have > a set of fairly clean working patches in a few days. Excellent! I think that, once this is in, we should freeze and make a release quickly, this is actually pretty useful and significant stuff. -- \ Troels /\ Henriksen From athas at sigkill.dk Tue May 13 20:29:32 2008 From: athas at sigkill.dk (Troels Henriksen) Date: Tue, 13 May 2008 22:29:32 +0200 Subject: [mcclim-devel] cl-jpeg dependency with ASDF-install (bug?) In-Reply-To: <881101.16658.qm@web54306.mail.re2.yahoo.com> (christopher melen's message of "Mon, 12 May 2008 19:01:56 +0100 (BST)") References: <881101.16658.qm@web54306.mail.re2.yahoo.com> Message-ID: <87hcd2oslv.fsf@lambda.athas.dyndns.dk> christopher melen writes: > When I try to ASDF-install McClim (on Mac OS X) it > complains that it can't install a dependency, cl-jpeg. > This library appears to be no longer available. I just created, signed and uploaded a CL-JPEG package accessible to ASDF-Install. It should work now. -- \ Troels /\ Henriksen From clinton at unknownlamer.org Tue May 13 23:26:19 2008 From: clinton at unknownlamer.org (Clinton Ebadi) Date: Tue, 13 May 2008 19:26:19 -0400 Subject: [mcclim-devel] Gadget based accepting-values In-Reply-To: <877idy6n1r.fsf@unknownlamer.org> (Clinton Ebadi's message of "Tue\, 13 May 2008 15\:06\:56 -0400") References: <87skwtep6y.fsf@unknownlamer.org> <87y76jjgxx.fsf@lambda.athas.dyndns.dk> <87lk2i80uk.fsf@unknownlamer.org> <87lk2hkfyt.fsf@lambda.athas.dyndns.dk> <877ie192ec.fsf@unknownlamer.org> <874p93pend.fsf@lambda.athas.dyndns.dk> <877idy6n1r.fsf@unknownlamer.org> Message-ID: <87skwl6b1g.fsf@unknownlamer.org> Clinton Ebadi writes: > Ok, I have now attached a third revision of the patch to add the > infrastructure needed to support gadget based accepting-values > dialogs. The big change is that encapsulating streams now support the > incremental redisplay protocol, and so stream-accept on an > accepting-values-stream can now pass the encapsulating stream to > accept-present-default. This removes a bit of the ugliness from the > accept-present-default methods for displaying gadgets in general. Bah, I should have tested the encapsulating stream stuff with something a bit fancier than the address book and my demo. Drei is very unhappy with being passed an encapsulating stream so I have to add proxy methods for panes and stream panes (not required by the spec, but since a pane is a sheet is a stream ...). -- * jeffcovey becomes too groggy to read the directions and becomes the year's first nasal spray overdose fatality. From chris_melen at yahoo.com Sat May 17 16:26:26 2008 From: chris_melen at yahoo.com (christopher melen) Date: Sat, 17 May 2008 17:26:26 +0100 (BST) Subject: [mcclim-devel] McClim up and running Message-ID: <355984.82140.qm@web54301.mail.re2.yahoo.com> OK so I have McClim up and running on my Mac (PPC with OS X 10.4.9). I've tried it with two Lisps so far, OpenMCL (now Clozure CL) and SBCL. Some observations - 1. SBCL works best. I had some problems with the listener under OpenMCL, especially when I tried to change the path (complained that it was 'not of type LIST'). 2. I have to run it with Apple's X11 - which is not a problem for me, as I use it frequently, but I was wondering if anyone's got it running without it. I had to set the DISPLAY environment variable in my .bash_profile to 127.0.0.1:0.0. So I have to run it from the terminal or an xterm, not from Emacs Slime (my preferred set-up). 3. When an app starts (for instance, the listener, or Gsharp) it takes a while to 'come alive'. Menus aren't usable for about a minute. After that it's OK, though, and I can restart an app (in the same Lisp session) without issue. I think I've only encountered this problem with SBCL. 4. I have also tried to get McClim running on my Windows box. I can compile it for Clisp (native Cygwin version, haven't tried the Win32 port), but when I try and run the Listener or any of the demos it just hangs (even with Cygwin's X11 running). I have also tried using the Win32 port of SBCL, but for some reason CLX won't compile on that. Might give ACL a go, if I can get ASDF to work properly with it. 4. I am hoping to use McClim to build the gui for my current project. I am keen to use it because of the fact that it's Lisp all the way through, unlike other Lisp-based gui kits (Ltk, cells-gtk, lispbuilder, for example) which, while perhaps slicker, feel a bit superficial (just wrappers for Tcl/Tk, Gtk, etc.). I have been tempted to fork out for ACL or LispWorks, but then there are licensing issues when it comes to redistributing my application. So I really want to stick with McClim. Any thoughts/comments much appreciated. Thanks, Chris __________________________________________________________ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html From athas at sigkill.dk Sat May 17 17:07:52 2008 From: athas at sigkill.dk (Troels Henriksen) Date: Sat, 17 May 2008 19:07:52 +0200 Subject: [mcclim-devel] McClim up and running In-Reply-To: <355984.82140.qm@web54301.mail.re2.yahoo.com> (christopher melen's message of "Sat, 17 May 2008 17:26:26 +0100 (BST)") References: <355984.82140.qm@web54301.mail.re2.yahoo.com> Message-ID: <878wy8svtj.fsf@lambda.athas.dyndns.dk> christopher melen writes: > 1. SBCL works best. I had some problems with the listener under > OpenMCL, especially when I tried to change the path (complained that > it was 'not of type LIST'). It's no surprise that SBCL works best - it's what most McCLIM hackers use. Also, it has good performance and implements CLOS well, which is important to McCLIM. Clozure CL is also supposed to be good, so I'd be interested in hearing the specifics of the error you got (backtrace?). > 2. I have to run it with Apple's X11 - which is not a problem for > me, as I use it frequently, but I was wondering if anyone's got it > running without it. I had to set the DISPLAY environment variable in > my .bash_profile to 127.0.0.1:0.0. So I have to run it from the > terminal or an xterm, not from Emacs Slime (my preferred set-up). You can set the environment variable for Emacs (M-x setenv) if you want, but anyway, McCLIM is theoretically able to run under Clozure CL/OpenMCL with the Beagle backend, which uses Cocoa. It's not as complete as the CLX backend, though. I hear Apples X11 server is odd in some ways, which can affect McCLIM, but I do not know the specifics. > 3. When an app starts (for instance, the listener, or Gsharp) it > takes a while to 'come alive'. Menus aren't usable for about a > minute. After that it's OK, though, and I can restart an app (in the > same Lisp session) without issue. I think I've only encountered this > problem with SBCL. It is normal for McCLIM apps to be slightly sluggish at first, because the CLOS caches need to be filled the first time generic functions are called. Successive invocations of the program should start up faster. A pause of an entire minute is highly unusual, however. Which version of SBCL is that? > 4. I have also tried to get McClim running on my > Windows box. I can compile it for Clisp (native Cygwin > version, haven't tried the Win32 port), but when I try > and run the Listener or any of the demos it just hangs > (even with Cygwin's X11 running). I have also tried > using the Win32 port of SBCL, but for some reason CLX > won't compile on that. Might give ACL a go, if I can > get ASDF to work properly with it. How does it hang? Does it take up all available CPU time or block? McCLIM works on CLISP on Unix, so the implementation itself should not be a problem. > 4. I am hoping to use McClim to build the gui for my current > project. I am keen to use it because of the fact that it's Lisp all > the way through, unlike other Lisp-based gui kits (Ltk, cells-gtk, > lispbuilder, for example) which, while perhaps slicker, feel a bit > superficial (just wrappers for Tcl/Tk, Gtk, etc.). I have been > tempted to fork out for ACL or LispWorks, but then there are > licensing issues when it comes to redistributing my application. So > I really want to stick with McClim. That's also one of the reasons I like McCLIM so much. You can use McCLIM to create GUIs that are somewhat similar to "normal" GUIs if you want, but you should realise that it will likely not be a "pretty" GUI unless you implement your own drawing routines for gadgets and panes. The current appearance of the McCLIM CLX backend is not a policy decision, though, so if you can come up with something prettier (the implementation of which should be relatively easy) you're very welcome. -- \ Troels /\ Henriksen From rudi at constantly.at Sat May 17 17:25:37 2008 From: rudi at constantly.at (Rudi Schlatte) Date: Sat, 17 May 2008 19:25:37 +0200 Subject: [mcclim-devel] McClim up and running In-Reply-To: <878wy8svtj.fsf@lambda.athas.dyndns.dk> References: <355984.82140.qm@web54301.mail.re2.yahoo.com> <878wy8svtj.fsf@lambda.athas.dyndns.dk> Message-ID: <7638D7B8-2B80-49F9-AFEF-890CD43192C9@constantly.at> On 17.05.2008, at 19:07, Troels Henriksen wrote: > christopher melen writes: >> >> 2. I have to run it with Apple's X11 - which is not a problem for >> me, as I use it frequently, but I was wondering if anyone's got it >> running without it. I had to set the DISPLAY environment variable in >> my .bash_profile to 127.0.0.1:0.0. So I have to run it from the >> terminal or an xterm, not from Emacs Slime (my preferred set-up). > > You can set the environment variable for Emacs (M-x setenv) if you > want, but anyway, McCLIM is theoretically able to run under Clozure > CL/OpenMCL with the Beagle backend, which uses Cocoa. It's not as > complete as the CLX backend, though. For "not as complete", read "will crash if you look at it funny"; the beagle backend needs lots of tender loving care by someone who knows cocoa. If you want to see it in action anyway, (push :clim-beagle *features*) before loading mcclim, then load clim-examples, call (clim- demo::demodemo) and enjoy the pretty Aqua-ish buttons. You can also get a clim-listener window or start the Climacs editor; just don't expect anything to not crash. > I hear Apples X11 server is odd in some ways, which can affect McCLIM, > but I do not know the specifics. http://paste.lisp.org/display/60199 has a patch that teaches clx/sbcl the appropriate X11-on-Leopard-autostartish magic so you don't need to set DISPLAY. I don't know of any other problems with Apple's X11 server. Cheers, Rudi -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2419 bytes Desc: not available URL: From mikemac at mikemac.com Sat May 17 18:00:12 2008 From: mikemac at mikemac.com (Mike McDonald) Date: Sat, 17 May 2008 11:00:12 -0700 Subject: [mcclim-devel] McClim up and running In-Reply-To: Your message of "Sat, 17 May 2008 19:25:37 +0200." <7638D7B8-2B80-49F9-AFEF-890CD43192C9@constantly.at> Message-ID: <200805171800.m4HI0Cp25014@saturn.mikemac.com> >I don't know of any other problems with Apple's X11 >server. Oh, there's LOTS of problems with the 10.5 version. In my opinion, it was a MAJOR step backwards from the 10.4 release. But none of them have anything to do with lisp or McCLIm though. Mike McDonald mikemac at mikemac.com From chris_melen at yahoo.com Sat May 17 22:58:22 2008 From: chris_melen at yahoo.com (christopher melen) Date: Sat, 17 May 2008 23:58:22 +0100 (BST) Subject: [mcclim-devel] McClim up and running Message-ID: <230592.36381.qm@web54302.mail.re2.yahoo.com> > It's no surprise that SBCL works best - it's what most McCLIM hackers > use. Also, it has good performance and implements CLOS well, which is > important to McCLIM. Clozure CL is also supposed to be good, so I'd be > interested in hearing the specifics of the error you got (backtrace?). With Clozure CL the only command that works in the listener's Filesystem menu is 'Up Directory'; everything else gives me this - Error: value PATHNAME is not of the expected type LIST. While executing: CCL::FRAME-SUPPLIED-ARGS, in process repl-thread. > You can set the environment variable for Emacs (M-x setenv)... I'd tried that, but it still errored, asking if I wanted to use the local unix display. > It is normal for McCLIM apps to be slightly sluggish at first, because > the CLOS caches need to be filled the first time generic functions are > called. Successive invocations of the program should start up > faster. A pause of an entire minute is highly unusual, however. Which > version of SBCL is that? When I run it with Clozure CL there's no delay at all. Only with SBCL. I'm running version 1.0.2. > How does it hang? Does it take up all available CPU time or block? > McCLIM works on CLISP on Unix, so the implementation itself should > not be a problem. Yes, CPU on the Windows machine is 100% at that point. I'll have a go on my laptop, which runs Vista, see if that's any better. Thanks, Chris __________________________________________________________ Sent from Yahoo! Mail. A Smarter Email http://uk.docs.yahoo.com/nowyoucan.html From rpgoldman at sift.info Sun May 18 03:07:18 2008 From: rpgoldman at sift.info (Robert Goldman) Date: Sat, 17 May 2008 22:07:18 -0500 Subject: [mcclim-devel] McClim up and running In-Reply-To: <7638D7B8-2B80-49F9-AFEF-890CD43192C9@constantly.at> References: <355984.82140.qm@web54301.mail.re2.yahoo.com> <878wy8svtj.fsf@lambda.athas.dyndns.dk> <7638D7B8-2B80-49F9-AFEF-890CD43192C9@constantly.at> Message-ID: <482F9D66.2080401@sift.info> Rudi Schlatte wrote: > > On 17.05.2008, at 19:07, Troels Henriksen wrote: > >> christopher melen writes: >>> >>> 2. I have to run it with Apple's X11 - which is not a problem for >>> me, as I use it frequently, but I was wondering if anyone's got it >>> running without it. I had to set the DISPLAY environment variable in >>> my .bash_profile to 127.0.0.1:0.0. So I have to run it from the >>> terminal or an xterm, not from Emacs Slime (my preferred set-up). >> >> You can set the environment variable for Emacs (M-x setenv) if you >> want, but anyway, McCLIM is theoretically able to run under Clozure >> CL/OpenMCL with the Beagle backend, which uses Cocoa. It's not as >> complete as the CLX backend, though. > > For "not as complete", read "will crash if you look at it funny"; the > beagle backend needs lots of tender loving care by someone who knows > cocoa. If you want to see it in action anyway, (push :clim-beagle > *features*) before loading mcclim, then load clim-examples, call > (clim-demo::demodemo) and enjoy the pretty Aqua-ish buttons. You can > also get a clim-listener window or start the Climacs editor; just don't > expect anything to not crash. > >> I hear Apples X11 server is odd in some ways, which can affect McCLIM, >> but I do not know the specifics. > > http://paste.lisp.org/display/60199 has a patch that teaches clx/sbcl > the appropriate X11-on-Leopard-autostartish magic so you don't need to > set DISPLAY. I don't know of any other problems with Apple's X11 server. > Mikel Bancroft has a version of CLX (forked from Xophe's, I believe) with some hacks I came up with to make it play nicely with the autostart magic. Reassuringly, I believe that once I kludged something together that worked, he improved it considerably... I believe you can get this version from darcs get http://opensource.franz.com/clx/ Note, I haven't tested the latest version yet... Robert From Scott at sympoiesis.com Thu May 22 19:21:40 2008 From: Scott at sympoiesis.com (Scott L. Burson) Date: Thu, 22 May 2008 15:21:40 -0400 Subject: [mcclim-devel] "Recent news" typo Message-ID: <20080522152140.wtm2v07wg0s0c8gk@webmail.sympoiesis.com> Hi, On http://common-lisp.net/project/mcclim/, under "Recent News", the recent "St. George's Day" release is shown as having occurred in 2007 rather than 2008. -- Scott From asf at boinkor.net Sat May 24 17:57:43 2008 From: asf at boinkor.net (Andreas Fuchs) Date: Sat, 24 May 2008 19:57:43 +0200 Subject: [mcclim-devel] "Recent news" typo In-Reply-To: <20080522152140.wtm2v07wg0s0c8gk@webmail.sympoiesis.com> References: <20080522152140.wtm2v07wg0s0c8gk@webmail.sympoiesis.com> Message-ID: <6536F742-71FB-40CB-9803-0E7DF8B8CA09@boinkor.net> On May 22, 2008, at 21:21, Scott L. Burson wrote: > On http://common-lisp.net/project/mcclim/, under "Recent News", the > recent "St. George's Day" release is shown as having occurred in > 2007 rather than 2008. Heh, does it show that I was using copy&paste? Should be fixed now. Thanks a lot for reporting this! The next release this year should not have this problem ((-: Cheers, -- Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs