mcclim-devel

mcclim-devel@common-lisp.net

820 discussions

[mcclim-devel] with-output-as-gadget, again
by Max-Gerd Retzlaff 26 Aug '05

26 Aug '05

Hello, I've tried to get with-output-as-gadget working but I was not successful. The problem being that I have not understood recording and several further parts of CLIM, yet. In this mail I want to present my observation about the problem, in the hope that someone with more experience and knowledge might see a solution. I would really like to have it working for a file selector that I need for several projects. Christophe reported the problem already in July: http://common-lisp.net/pipermail/mcclim-devel/2005-July/004100.html You might want to read that mail first. Basically the panes of the whole gadget are only adopted to the stream's sheet (stream being the stream that is given as an argument to the call of WITH-OUTPUT-AS-GADGET) when the output-record of the sheet is replayed (or what is the right term?). The adoption happens via note-output-record-got-sheet method calls that are made when output-records about "parent/child-relationships" are processed; there is specialization on (record gadget-output-record) for that method, in which the adoption takes place. The problem is that the output methods of the clx-backend (window-clear-area (called from window-clear), medium-draw-text* (called from write-string), .. ) try to access the native-transformation (and later native-region) of the gadget's panes quite early, and that does not work if the panes are not yet adopted. Either the adoption has to happen earlier, or the clx output method have to be delayed via output-records as well. I suspect that the clx backend needs an general overhaul to make it be (more) "output-recording aware". But perhaps a single, deliberately inserted line would work a miracle.. Consider Christophe's example: (clim:with-output-as-gadget (*standard-output*) (clim:with-look-and-feel-realization ((clim:frame-manager clim:*application-frame*) clim:*application-frame*) (clim:labelling (:label "Hello") (clim:make-pane 'clim:text-field :activate-callback (lambda (g) (princ (clim:gadget-value g))))))) The flow to the error NO-APPLICABLE-METHOD on sheet-native-transformation when called with an argument of NIL is: In WITH-OUTPUT-AS-GADGET a instance of 'GADGET-OUTPUT-TYPE is created (with the evaluated body of the call as its :child argument). There is a initialize-instance :after method for instances of this class, in which ALLOCATE-SPACE for the child (the label-pane) is called. ALLOCATE-SPACE calls MOVE-SHEET for the first child of the label-pane (the text-field-pane). MOVE-SHEET SETFs the SHEET-TRANSFORMATION of the text-field-pane. There is a method (setf sheet-transformation) :after (transformation (sheet basic-sheet)). It calls (note-sheet-transformation-changed sheet), which calls UPDATE-MIRROR-GEOMETRY. Inside UPDATE-MIRROR-GEOMETRY (sheet-native-transformation (sheet-parent sheet)) is called, but as the sheet is not adopted yet, that gives nil and sheet-native-transformation is not defined for nil. => NO-APPLICABLE-METHOD on sheet-native-transformation when called with an argument of NIL It is quite the same for simpler examples where the WRITE-STRING is called with a pane of the gadget as output stream. There it is: WRITE-STRING -> %WRITE-STRING -> .. -> MEDIUM-DRAW-TEXT* -> (sheet-native-transformation (medium-sheet medium)) Inside sheet-native-transformation the same function is called again for the sheet-parent. As the sheet is not adopted yet, that gives nil and sheet-native-transformation is not defined for nil. Naively, I tried something like: (let ((my-stream (find-pane-named *application-frame* 'clim-listener::interactor))) (replay (STREAM-CURRENT-OUTPUT-RECORD my-stream) my-stream)) right after WITH-OUTPUT-AS-GADGET and before the WRITE-STRING, in the hope that this would force recorded adoption records to take place earlier. Is this completely wrong, should it have been replay-output-record instead? Well, it would only be an ugly workaround at it doesn't help against the problems with labelling and scrolling. I could confirm my assumption that the delayed adoption is the problem as with neatly placed calls to SHEET-ADOPT-CHILD and SHEET-DISOWN-CHILD I got my file-selector kind of running (only the first ACCEPTING-VALUES iteration draws correctly and there is no scrolling for the embedded pane: http://bl0rg.net/~mgr/flux/file-selector-dialog.png (In the end it should become a accept method for pathname presentations in gadget-dialog-view.) There are additional problem when the stream for WITH-OUTPUT-AS-GADGET is an ACCEPTING-VALUES-STREAM: When attempting to read the slot's value (slot-value), the slot CLIM-INTERNALS::HEIGHT is missing from the object #<CLIM-INTERNALS::ACCEPTING-VALUES-STREAM {92BF441}>. [Condition of type SIMPLE-ERROR] It would be especially nice to get this running as well.. Regards, Max -- Max-Gerd Retzlaff <m.retzlaff(a)gmx.net> For your amusement: I don't make the rules, Gil, I only play the game. -- Cash McCall

1 0

[mcclim-devel] Re: [mcclim-cvs] CVS update: mcclim/dialog.lisp
by Max-Gerd Retzlaff 26 Aug '05

26 Aug '05

Hello On Fri, Aug 26, 2005 at 01:50:21PM +0200, Paolo Amoroso wrote: > mretzlaff(a)common-lisp.net (Max-Gerd Retzlaff) writes: > > > Modified Files: > > dialog.lisp > > Log Message: > > (climi::frame-event-queue *application-frame*) as argument :INPUT-BUFFER > > to the call of OPEN-WINDOW-STREAM in WITH-STREAM-IN-OWN-WINDOW (was not > > specified previously). > > I still don't get separate windows in dialogs of town-example.lisp > that have :own-window t. The accepting-values dialogs still appear in > the interactor. I use the latest McCLIM CVS sources. Did you change the call TO ACCEPTING-VALUES in the macro ACCEPTING-VALUES-WITH-STYLE-AND-TITLE (and a recompile of the whole file)? ACCEPTING-VALUES-WITH-STYLE-AND-TITLE is only used for the *output* of the commands COM-SHOW-TOWN-INFO and COM-GET-DISTANCE. And that did not work for you? I just grabbed a fresh cvs checkout and it worked for me. If you want the accepting-values dialogs of the partial-command-parser (i.e. if you click in the menu on "Show Town Info" or "Get Distance") to appear in a new window, you have to change the :own-window argument of that call. It is burried in MAKE-PARTIAL-PARSER-FUN in mcclim/commands.lisp, try this patch: -- zipp -- --- commands.lisp_old 2005-08-26 15:06:27.370372680 +0200 +++ commands.lisp 2005-08-26 15:06:29.218091784 +0200 @@ -755,7 +755,7 @@ ,command-table :errorp nil)) ,@(mapcar #'list required-arg-names original-args)) - (accepting-values (,stream) + (accepting-values (,stream :own-window t) (format ,stream "You are being prompted for arguments to ~S~%~%" ,command-line-name) -- zapp -- There seems to be no simple way to just change the default for a single application frame. The right way seems to be to modify the application-frame's top-level with something like (:top-level (default-frame-top-level :partial-command-parser ..) in one's DEFINE-APPLICATION-FRAME. But that seems to be a lot of work as the default, COMMAND-LINE-READ-REMAINING-ARGUMENTS-FOR-PARTIAL-COMMAND, calls the partial-command-parsers that are created via mentioned MAKE-PARTIAL-PARSER-FUN when the commands of the application are defined (DEFINE-..-COMMAND -> DEFINE-COMMAND -> %DEFINE-COMMAND).. Bye, Max -- Max-Gerd Retzlaff <m.retzlaff(a)gmx.net> For your amusement: Scientists will study your brain to learn more about your distant cousin, Man.

2 2

[mcclim-devel] Re: [mcclim-cvs] CVS update: mcclim/dialog.lisp
by Andy Hefner 26 Aug '05

26 Aug '05

On 8/25/05, Max-Gerd Retzlaff <mretzlaff(a)common-lisp.net> wrote: > (Broken because OPEN-WINDOW-STREAM doesn't really work yet. I think > there has to be a (redisplay-frame-panes frame) or something like that > in its event-loop (that is the function STANDALONE-EVENT-LOOP).) Why do you think that?

3 4

[mcclim-devel] One char patch to presentation-defs
by David Murray 25 Aug '05

25 Aug '05

[resent to the correct address - I hope...] I was wondering why the :highlight option to :single-box wasn't working as I thought it should. Turns out there was a wee typo. Patch attached. JQS Index: presentation-defs.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/presentation-defs.lisp,v retrieving revision 1.44 diff -u -r1.44 presentation-defs.lisp --- presentation-defs.lisp 22 Jun 2005 09:49:15 -0000 1.44 +++ presentation-defs.lisp 25 Jul 2005 13:05:48 -0000 @@ -993,7 +993,7 @@ (multiple-value-bind (min-x min-y max-x max-y) (output-record-hit-detection-rectangle* record) (if (and (<= min-x x max-x) (<= min-y y max-y)) - (if (or (null single-box) (eq single-box :higlighting)) + (if (or (null single-box) (eq single-box :highlighting)) (funcall-presentation-generic-function presentation-refined-position-test (presentation-type record) record x y)

10 34

[mcclim-devel] CLIM-LISTENER and the MOP
by Robert P. Goldman 23 Aug '05

23 Aug '05

Recently, I was playing with the CLIM-LISTENER (thanks to Paolo's suggestion that it would provide good exercise for the graph-rendering code), and found that it often crashed under Allegro CL, with MOP errors. I'm no MOP authority, so I dropped a line to Franz to ask them why this was happening. Steve Haflich kindly filled me in on why, and offered some comments on the use of the MOP to interrogate the class hierarchy in the CLIM listener. With his permission, here's some of what he said: From: rpgoldman(a)sift.info I have been trying to use a portable class browser for class hierarchies with ACL 6.2, and have been getting frequent errors like this: CL-USER(8): (aclmop:class-slots (find-class 'clim::application-frame)) Error: Class #<STANDARD-CLASS CLIM:APPLICATION-FRAME> is not yet finalized. [condition type: PROGRAM-ERROR] Restart actions (select using :continue): 0: Return to Top Level (an "abort" restart). 1: Abort entirely from this process. [1] CL-USER(9): [note: this is with the open McCLIM clim implementation, not ACL CLIM.] I'm confused by this error, since it seems to contradict the documentation I have, which states: "Class finalization is the process of computing the information a class inherits from its superclasses and preparing to actually allocate instances of the class. ... To support forward-referenced superclasses, and to account for the fact that not all classes are actually instantiated, class finalization is not done as part of the initialization of the class metaobject. Instead, finalization is done as a separate protocol, invoked by calling the generic function finalize-inheritance. The exact point at which finalize-inheritance is called depends on the class of the class metaobject; for standard-class it is called sometime after all the classes superclasses are defined, but no later than when the first instance of the class is allocated (by allocate-instance)." But I have an instance of this class that the MOP seems to be telling me is not finalized: GRAPH-MDP(77): (class-of *frame*) #<STANDARD-CLASS TAEMS-MDP-APP> GRAPH-MDP(78): (aclmop:class-direct-superclasses (class-of *frame*)) (#<STANDARD-CLASS STANDARD-APPLICATION-FRAME>) (aclmop:class-direct-superclasses (first (aclmop:class-direct-superclasses (class-of *frame*)))) (#<STANDARD-CLASS APPLICATION-FRAME> #<STANDARD-CLASS CLIM-INTERNALS::PRESENTATION-HISTORY-MIXIN>) Based on the above, shouldn't APPLICATION-FRAME have been finalized? Or is it not finalized because it doesn't have any DIRECT instances? SMH> Your suggested analysis is correct: A class is only required to be SMH> finalized when it is directly instantiated. (See the term "direct SMH> instance" in the ANS Glossary.) There is no need to finialize SMH> superclasses. In fact, there is good reason not to do so, even beyond SMH> the fact that it is a waste of time and storage: SMH> If one has a collection of mixin classes, sometimes the oeration of SMH> one mixin might depend on functionality, perhaps a method, provided by SMH> a different mixin. If one instantiates a class that doesn't have a SMH> complete set of these interrelated mixins, an error can be signalled SMH> at execution time. It is sometime done that a mixin will implement SMH> checking for other necessary classes and/or method. It can do this in SMH> various ways, such as by defining :after methods on SMH> finalize-inheritance. The idea is that it is much better to signal SMH> error for some inconsistency earlier rather than later. Steve went on to directly comment on the class browsing in CLIM-LISTENER: SMH> .... We agreed in the last round that a class does not _have_ a SMH> class-slots property until it is finalized, and not all classes are SMH> always finalized. Further, it's even worse, because some classes SMH> cannot even be finalized. As I suggested before, a mixin class might SMH> have code to guarantee it is not finalized (or instantiated) unless SMH> certain conditions are met. And of course finalization is impossible SMH> if a class' superclasses include a forward-reference-class. SMH> So ideas like trying to force all classes to be finalized or to SMH> trigger class finalization when inspected probably aren't good ones. SMH> I don't know if it is possible for you to suggest McCLIM be fixed SMH> (which would be best) or whether you have to try to patch this locally SMH> in your copy. But you might investigate what the McCLIM inspector SMH> itself does in the situation that a class still has forward SMH> references. SMH> class-slots is defined to return a list of SMH> effective-slot-definition-objects, which cannot exist until SMH> finalization. Depending on the needs of the browser, it is SMH> straightforward to write a class walker that computes a partial list SMH> of known slots by walking the portions of the superclass tree that are SMH> defined (i.e. stopping on forward-reference-classes). But that would SMH> compute a set of direct-slot-definition-objects (possibly multiple SMH> dsd's per slot) instead of esd's, so the browser would need to be SMH> modified to accept this. As I said, I'm no expert on the MOP, or the internals of the CLIM-LISTENER, so I'm not sure how feasible/desirable such a rewrite would be. For that matter, I'm not sure why the CLIM-LISTENER works on CMUCL and SBCL... I'd be willing to rally round to help fix this if anyone wants to take charge, especially to conduct tests on ACL 6.2 and 7.0. But I'm not qualified to be more than a foot-soldier in that effort.... Cheers, R

1 0

[mcclim-devel] A mcclim app which could possibly be used as a demo
by David Christiansen 20 Aug '05

20 Aug '05

Hello, For my AI class at the University of Idaho, I wrote a program that will play Connect 4 against you. I used McCLIM, and just tested it against the CVS version. It demonstrates drawing, presentation-to- command translators, and a few other things. I've also commented it a great deal, as Lisp was not the first language of the TA who graded my work. The file is attached to this email, in case you'd like to use it as example code for McCLIM. I'm fairly new to Lisp, so parts may be sub-optimal. If they are, please let me know and I'll improve them. -David Christiansen

2 1

[mcclim-devel] mcclim-0.9.1:system.lisp
by Mike McDonald 19 Aug '05

19 Aug '05

Something looks a bit fishy. (pushnew :clim *features*) (pushnew :mcclim *features*) +;;; I really didn't have good luck with this on Allegro, because +;;; Allegro's CL-USER package uses it's EXCL stuff, which has its own +;;; DEFSYSTEM. [2004/12/21:rpg] +;;;#+mk-defsystem (use-package "MK") (defmacro clim-defsystem ((module &key depends-on) &rest components) `(progn #+mk-defsystem Mike McDonald mikemac(a)mikemac.com

4 4

[mcclim-devel] tar file of nightly "sources"
by Mike McDonald 19 Aug '05

19 Aug '05

Quoting the web page: Releases A compressed tar file of the sources is made nightly. Except it's not the sources. It's the whole CVS repository! Mike McDonald mikemac(a)mikemac.com

1 0

[mcclim-devel] question about abort and accept
by rpgoldman＠real-time.com 19 Aug '05

19 Aug '05

IIUC, the abort gesture is defined to be control-C. (define-gesture-name :abort :keyboard (#\c :control)) So, I was surprised to find when I had mistyped an argument, and pressed control-c, it did not abort the interaction. Is this a bug? I rooted around in the code, and I'm afraid I wasn't sufficiently savvy to guess where the abort gesture should be trapped. I would have guessed, though, that unless it was trapped, it would toss an error. So is there something wrong about accept in an interactor window that is keeping abort from being signalled? thanks, r

1 0

[mcclim-devel] problem with the webarchive of this mailinglist
by Max-Gerd Retzlaff 18 Aug '05

18 Aug '05

Hi, who maintains the web archive? Have a look at: http://common-lisp.net/pipermail/mcclim-devel/2005-August/004217.html What's the problem? Bye, Max -- Max-Gerd Retzlaff <m.retzlaff(a)gmx.net> For your amusement: Text processing has made it possible to right-justify any idea, even one which cannot be justified on any other grounds. -- J. Finnegan, USC.

3 2

← Newer
1
...
57
58
59
60
61
62
63
...
82
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

mcclim-devel