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

[mcclim-devel] clim-gtkairo problems
by Cyrus Harmon 16 Jun '10

16 Jun '10

I've been having trouble trying to get the clim-gtkairo backend working of late. The main application I'm working on throws an error, only with the gtkairo backend, but I don't have a nice simple test case for it yet. In the course of trying to generate such testcase, I figured I'd try the demodemo and see how it works with clim-gtkairo. Unfortunately, it seems to have some problems. The most obvious problem is that the initial demodemo window is completely blank until one drags the mouse over all of the buttons. With the clx backend, everything is fine. Anyone else seeing this? thanks, Cyrus

1 1

[mcclim-devel] Is McCLIM being maintained?
by Peter Busser 24 Jan '10

24 Jan '10

Hi, Is McCLIM being maintained? I have a few suggestions for improvement. But if no one is able to add it, then I would rather not waste my time writing it down. Groetjes, Peter.

3 2

[mcclim-devel] [PATCH] Make CLX loadable for CLISP
by Evgeny M. Zubok 10 Jan '10

10 Jan '10

Recently, someone in this mailing-list pointed to the problem that CLX was not loaded during McCLIM compilation process in CLISP. Indeed, :clim-clx loading for was disabled for CLISP. I fix it. CLISP has it's own two implementations of CLX -- new-clx and mit-clx. Their presence can be enabled or disabled with CLISP configure script's options --with-module=clx/new-clx or --with-module=clx/mit-clx. First, we verify availability of :xlib package. If :xlib doesn't exist, then we load CLX from ASDF. Otherwise, some heuristic applied to detect what implementation provided with CLISP: if the symbol `set-selection-owner' is not declared as exported, we have implementation (new-clx, I suppose) that currently cannot be used as McCLIM backend. In this case, we unlock :xlib and try to replace it with CLX from ASDF. I tried mit-clx (predecessor of telent-clx) as McCLIM's backend two years ago, and it worked. But, AFAIR, I read (I don't remember where) that something (and I don't remember what) would not work with this implementation and also that the implementation hasn't being updated for a long time. I think the right decision is to leave it as possible backend for a while and don't replace it with telent CLX from ASDF.

1 0

[mcclim-devel] [PATCH] Reimplementaion of drag-output-record, dragging-output
by Evgeny M. Zubok 08 Jan '10

08 Jan '10

Hello, I've reimplemented `drag-output-record' and `dragging-output' to be more closer to specification. Unfortunately, the behaviour of these functions is underspecified and quite unclear in many places. I've attempted to implement all keys and window repaint event (the latter was marked as unresolved issue). I've used CLIM 2.0 (Symbolics/Xerox/Apple etc.), LW's CLIM 2.0 and Franz' CLIM 2.2.2 specifications as references. Also I played with CLIM implementation from Allegro CL with lesstif backend instead Motif. The drag-output-record is something buggy there, but acceptable to analyze some features. This patch does the following:: * Implements :repaint (as I understand it's meaning). * Supports :multiple-window. However, my understanding the meaning of this key and, hence, implementation could be incorrect. * :erase key works as described in specification: by default erase-output-record is used. * Supports window-repaint-event. In effect, if user's :feedback is provided and window-repaint-event has been queued (for instance, when user scrolled down/up stream while dragging), the feedback first is erased, then handle-repaint is called and, finally, the feedback is drawn again at the same place. * Reimplements dragging-output macro without introducing unspecified key :erase-final. * Slightly corrected draggable-graph example from clim-examples. I hope that I will write more featured example... later. Note, there is bug somewhere in stream-pointer-position. Something wrong with sheet-native-transformation for the stream. The effect of this bug is that the record capture works as expected only on first page inside scroller. On other pages the record is selected with wrong initial position.

1 0

[mcclim-devel] How stream-pointer-position should work?
by Evgeny M. Zubok 27 Dec '09

27 Dec '09

Hello, If I call stream-pointer-position on the stream without scroller, it returns an expected position. However, when the stream has a scroller, the function returns the position inside viewport regardless position of scrollbars, i. e. from upper left corner of viewport, not from the stream's origin. I have played with map-sheet-position-to-child and map-sheet-position-to-parent but faced with the different behaviour of these functions, which depends on how scrolling declared inside define-application-frame. To be more presise, it depends on internal structure of application-pane with scroller: in McCLIM it has also border-pane as a parent (why?). I think, the programmer shouldn't keep in mind such implementation details. So, what is the right behavior of stream-pointer-position if the stream has a scroller? Shouldn't it return the real coordinates on stream as pointer events do? Specification says: stream-pointer-position [Generic Function] Arguments: stream &key pointer Summary: Returns the current position of the pointing device pointer for the extended input stream stream as two values, the x and y positions in the stream's drawing surface coordinate system. If pointer is not supplied, it defaults to the stream-primary-pointer of the stream.

1 1

[mcclim-devel] [Patch] not unquoted variable in with-output-as-presentation
by Stas Boukarev 16 Dec '09

16 Dec '09

Patch attached. -- With Best Regards, Stas.

1 0

[mcclim-devel] drawing of RGB-IMAGE-DESIGN
by Marcus Eskilsson 14 Dec '09

14 Dec '09

Hello thar, list! I have started a lil' work here on some McCLIM based software and I have run into a bit of an issue. I'm trying to have a pane with a display-function that displays me an image I load from a PNM, and this fails for me. Basically I have (excuse the indentation. thunderbird mail client etc.) (defmethod pane-display (frame stream) (draw-design (find-pane-named frame 'foo-pane) (climi::make-rgb-image-design (image::read-image-file "foo.pnm")))) result is this There is no applicable method for the generic function #<STANDARD-GENERIC-FUNCTION CLIM-INTERNALS::IMAGE-WIDTH (1)> when called with arguments (#2A((12693671 12303027 12697025 12960710 13093066 13618384 14210776 14343390 14606308 14738150 ...) (11902865 11706271 12433848 12633281 13683403 13947084 13947345 14080471 14670557 14606822 ...) (11118502 11445149 11973554 12759733 13222341 13487563 13683408 13882839 14606045 14738146 ...) (8945292 11970725 12169393 12365746 13091006 13422029 13882580 14276825 14606041 14540249 ...) (10723750 11710384 11973812 12564921 13355469 13881037 14472140 14342101 14538968 14605792 ...) (11908536 12499904 13486538 13486792 13552588 13947345 14473680 14736857 14473433 14538717 ...) (12828606 13090233 13421257 13420744 13486791 13749708 14209746 14342105 14671069 14868192 ...) (13024958 13420748 13551822 13422023 13749963 13618378 14144469 14734804 14473432 14998751 ...) (12962251 13422543 13618382 13552330 13422538 13421261 13949651 14473688 14538969 14473432 ...) (13488855 12899034 13030102 13293012 13095121 13292756 13488336 13357008 13684694 14079703 ...) ...)). [Condition of type SIMPLE-ERROR] Backtrace: 0: ((SB-PCL::FAST-METHOD NO-APPLICABLE-METHOD (T)) #<unavailable argument> #<unavailable argument> #<STANDARD-GENERIC-FUNCTION CLIM-INTERNALS::IMAGE-WIDTH (1)>)[:EXTERNAL] 1: ((SB-PCL::FAST-METHOD INITIALIZE-INSTANCE :AFTER (CLIM-INTERNALS::DRAW-IMAGE-DESIGN-OUTPUT-RECORD)) ..)[:EXTERNAL] 2: ((LAMBDA (SB-PCL::|.P0.| SB-PCL::|.P1.| SB-PCL::|.P2.| SB-PCL::|.P3.|)) #<unavailable argument> #<unavailable argument> #<unavailable argument> #<unavailable argument>) 3: ((LABELS #:G5221) #<CLIM-CLX::CLX-MEDIUM {1003B139A1}>) 4: ((SB-PCL::FAST-METHOD CLIM-INTERNALS::MEDIUM-DRAW-IMAGE-DESIGN* :AROUND (OUTPUT-RECORDING-STREAM T T T)) ..) 5: ((SB-PCL::FAST-METHOD CLIM-INTERNALS::DO-GRAPHICS-WITH-OPTIONS-INTERNAL (MEDIUM T T)) ..)[:EXTERNAL] 6: ((SB-PCL::FAST-METHOD CLIM-INTERNALS::DO-GRAPHICS-WITH-OPTIONS (SHEET T)) ..)[:EXTERNAL] 7: ((SB-PCL::FAST-METHOD DRAW-DESIGN (T CLIM-INTERNALS::RGB-IMAGE-DESIGN)) ..)[:EXTERNAL] I'm unaware if this is actually a bug or I just should stay the hell away from these functions and make the pnm loader behave with MAKE-PATTERN-FROM-BITMAP-FILE.

2 1

[mcclim-devel] A few questions about dragging functions
by Evgeny M. Zubok 07 Dec '09

07 Dec '09

I'm reimplementing the drag-output-record, dragging-output to be more closer to CLIM specification. This work is almost done. However, a behaviour of drag-output-record is underspecified in some places. My questions are about `feedback' argument of drag-output-record. The following is what the CLIM specification says about feedback function and that's all what we have: ------------------------------------------------------------------------ `feedback' allows the programmer to identify a "feedback" function of seven arguments: the output record, the stream, the initial x and y position of the pointer, the current x and y position of the pointer, and a drawing argument (either :erase or :draw). It has dynamic extent. The default is nil, meaning that the feedback behavior will be for the output record to track the pointer. (The feedback argument is used when the programmer desires more complex feedback behavior, such as drawing a "rubber band" line as the user moves the mouse.) Note that if feedback is supplied, erase is ignored. ------------------------------------------------------------------------ My current solution. Notes: (i) the numbers with star means that the action is performed by user in the `feedback' function; (ii) (INITIAL-X INITIAL-Y) is the pointer coordinate when the user initially clicks the button on the desired record; (iii) (X-OLD Y-OLD) is remembered previous pointer coordinate. The user calls drag-output-record. In drag-output-record: 1* Call (feedback RECORD STREAM INITIAL-X INITIAL-Y INITIAL-X INITIAL-Y :DRAW) 2. Set X-OLD := INITIAL-X; Y-OLD := INITIAL-Y 3. User moves the pointer. Now X Y is a new pointer position. 4* Call (feedback RECORD STREAM INITIAL-X INITIAL-Y X-OLD Y-OLD :ERASE). Erase previous feedback effect and output record. 5. Change output-record-position of the RECORD to a new location. 6* Call (feedback RECORD STREAM INITIAL-X INITIAL-Y X Y :DRAW) where the user draws the record at it's new position and draws feedback effect. Note, that RECORD already has the new coordinates in output-record-position. 7. X-OLD := X; Y-OLD := Y 8. Repeat from 4 ... 9. User clicks a pointer button 10* Call (feedback RECORD STREAM INITIAL-X INITIAL-Y X Y :ERASE). Erase last feedback effect and the output record. 11. Replay the output record without feedback effect at it's final position. 12. Exit --- Qusetion about my solution. =========================== Q: Where the dragged output record should be erased and redrawn (i. e. replayed) when the `feedback' is supplied: in the `feedback' function by user or inside the drag-output-record function? My solution: I've delegated the erasing and redrawing the dragged record to the user. The situation with erasing is more clear. CLIM specification states that if `feedback' argument is supplied, the `erase' argument is ignored. As far as user already had the possibility to provide the `erase' argument with custom function (`erase-output-record' by default), then this possibility only migrates to the :ERASE part of `feedback' function. A situation with `feedback :DRAW' is unclear. The redrawing of dragged output record can be accomplished either (i) in the drag-output-record before `feedback :DRAW' or (ii) by user in `feedback :DRAW', manually replaying the record and the desired feedback effect. In other words, there are two algorithms, which are almost equivalent in the sense of visible effect, but not equivalent with respect to the user. (I) My current solution. Erasing/redrawing of output record and feedback effect is accompishing by user. 1. Call `feedback :ERASE' where user erases the dragged output record and additional feedback effect from their previous position (with possible replaying). 2. Change output-record-position to a new position inside drag-output-record. 3. Call 'feedback :DRAW' where user draws the dragged output record and then the additional feedback effect at the new position. (II) Alternative solution. The output record is redrawing in the drag-output-record. 1. Call `feedback :ERASE' where user erases the dragged output record and additional feedback effect from previous position (with possible replaying). 2. Change output-record-position to a new position inside drag-output-record 3. Draw the dragged output record at it's new position inside the drag-output-record by replaying required region that contains the output record. 4. Call 'feedback :DRAW' where user draws only the additional feedback effect. What to prefer? The former provides more flexibility to control output record appearence as it's dragged. For example, I could implement dragging that is snapped to a grid by erasing/redrawing output record and additional feedback effect only when the pointer occures in the next grid cell area. This is not possible with (II), bacause we cannot control the redrawing of output record. How it was implemented in original CLIM? Does anyone have any legacy code or examples that use the drag-output-record with `feedback'? --- Q: When the `feedback' is called with :DRAW, does the RECORD already have a new position on STREAM, i. e. the coordinates where it will be drawn? My solution: See item 5. I'm changing output-record-position in the drag-output-record just before calling `feedback :DRAW'. Only the original CLIM implementation could clear how this was implemented. --- Q: Am I right when passing the X-OLD Y-OLD to the `feedback :ERASE'? My solution: If we are using the current pointer coordinates to draw feedback effect in `feedback :DRAW' (for example, to draw line with flipping ink from 0,0 to current pointer location), then to erase this feedback effect in subsequent :ERASE the previous pointer coordinates are required, not the current. However, CLIM spec says, that only current pointer coordinates are passed to feedback :ERASE/:DRAW. Alternative solution: user somewhere remembers coordinates that are passed to `feedback :DRAW' and use them when it's required to erase previous feedback.

1 0

[mcclim-devel] How to use McCLIM on SnowLeopard with SBCL ?
by 十亀眞怜 22 Nov '09

22 Nov '09

Hello, I try to use McCLIM on Mac OSX SnowLeopard with latest version SBCL. I finished install mcclim and try to test program. (require 'clim-examples) (clim-demo::demodemo) Then I got Error like this: debugger invoked on a SB-BSD-SOCKETS:HOST-NOT-FOUND-ERROR: Name service error in "getaddrinfo": 8 (nodename nor servname provided, or not known) Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level. (SB-BSD-SOCKETS::ADDRINFO-ERROR "getaddrinfo" 8) But I can't figure out why this error happen. Does anyone can solve this probrem? Pleas help me. Many Thanks.-------------------------------------- GyaO! - Anime, Dramas, Movies, and Music videos [FREE] http://pr.mail.yahoo.co.jp/gyao/

1 0

[mcclim-devel] faster clim-clx:pixel-translator
by Nikodemus Siivola 14 Nov '09

14 Nov '09

One of the reasons IMAGE-TO-XIMAGE is slow is that pixel translators are _really_ slow. Attached patch fixes this bit. (On SBCL at least -- presumably elsewhere as well.) Cheers, -- Nikodemus

1 0