mcclim-devel

mcclim-devel@common-lisp.net

820 discussions

[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

[mcclim-devel] another question
by Žiga Lenarčič 05 Nov '09

05 Nov '09

Hi! Here's my previos email I sent as a non-member: ---------------- Hi McCLIM developers! I have a few questions, in no particular order: * I've started 'theming' McCLIM to give it a more modern look (a darker look).. I've started with /Looks/pixie.lisp and went from there. Is pixie.lisp an example of 'correct' skinning process - effectively creating new classes with overridden methods for various things or is it better to just redefine the handle-redraw methods of original gadgets and be done with it? Pixie has a problem for instance - mouse wheel scrolling doesn't work, because it reimplements scrolling logic implemented in gadgets.lisp or somewhere else. Wouldn't it be more correct to use the 'default' logic and only redefine handle-repaint methods, if change in functionality isn't needed? * what is the correct way to add my own widgets? I assume I should look at gadgets.lisp and start from there. Are new widgets welcome in the main McCLIM source tree or is McCLIM closely following some CLIM specification and doesn't want to go beyond that? * I'm using CLX backend and default/freetype/truetype font renedering. I've noticed that with default X11 font rendering, the usual textstyle (sans-serif, roman) is much more readable at size :small, than :normal. For antialiased fonts, :normal works great. Perhaps the default fontsize should be :small (or mcclim's clx default font render should just interpret :normal as :small) - clim- examples applications would look nicer out of the box and I wouldn't need to write cases in my app (if ''freetype'' :normal :small) to make stuff look nice. I think this has been mentioned before.. * right now McCLIMs 'textfield' is vastly different from text fields in other toolkits. I think we could conform better if the caret was just a line (not a block), if the caret blinked properly, if there was caret positioning via mouse click and if there was selection possible. I don't know how other McCLIM users feel about this - but if I added these features, would they be added to McCLIM? Would it be better to add a new 'gadget' for this 'modern' text field stuff? Regards, Ziga ----------------- I have another question: * What's the state of unicode support with McCLIM. I guess this is backend specific, since SBCL supports unicode strings very nicely. I use McCLIM on Mac OS X and non ASCII keys don't produce anything in McCLIM. Perhaps this is a problem with Mac OS X's X11 server? I've looked into 'freetype' font rendering and (I think) it assumes that char-code is < 256. Is there any unicode support in McCLIM? Regards, Ziga

3 3

← Newer
1
...
13
14
15
16
17
18
19
...
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