From evgeny.zubok at tochka.ru Fri Jan 8 16:14:55 2010 From: evgeny.zubok at tochka.ru (Evgeny M. Zubok) Date: Fri, 08 Jan 2010 19:14:55 +0300 Subject: [mcclim-devel] [PATCH] Reimplementaion of drag-output-record, dragging-output Message-ID: <87vdfcd14w.fsf@tochka.ru> 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: drag-output-record.patch Type: text/x-diff Size: 19355 bytes Desc: not available URL: From evgeny.zubok at tochka.ru Sun Jan 10 23:36:15 2010 From: evgeny.zubok at tochka.ru (Evgeny M. Zubok) Date: Mon, 11 Jan 2010 02:36:15 +0300 Subject: [mcclim-devel] [PATCH] Make CLX loadable for CLISP Message-ID: <87vdf9a5xs.fsf@tochka.ru> 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. -------------- next part -------------- A non-text attachment was scrubbed... Name: load-clim-clx-for-clisp.patch Type: text/x-diff Size: 2231 bytes Desc: not available URL: From busserpeter at gmail.com Sun Jan 24 19:38:46 2010 From: busserpeter at gmail.com (Peter Busser) Date: Sun, 24 Jan 2010 20:38:46 +0100 Subject: [mcclim-devel] Is McCLIM being maintained? Message-ID: <3693571d1001241138l2795c047maec46831c8dc5179@mail.gmail.com> 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. From csr21 at cantab.net Sun Jan 24 20:16:16 2010 From: csr21 at cantab.net (Christophe Rhodes) Date: Sun, 24 Jan 2010 20:16:16 +0000 Subject: [mcclim-devel] Is McCLIM being maintained? In-Reply-To: <3693571d1001241138l2795c047maec46831c8dc5179@mail.gmail.com> (Peter Busser's message of "Sun, 24 Jan 2010 20:38:46 +0100") References: <3693571d1001241138l2795c047maec46831c8dc5179@mail.gmail.com> Message-ID: <87ockjz2b3.fsf@cantab.net> Peter Busser writes: > 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. Without knowing what your suggestions are, it's difficult to say whether anyone would be able and/or motivated to or not -- but I think it's fair to say that we (for whatever "we" that is) are shorter of time than we are of things to do to improve things. If a mailing list post feels too ephemeral for your writing, you could consider filing bugs at launchpad , where at least the reports would be archived for when time and effort becomes available. Cheers, Christophe From strandh at labri.fr Sun Jan 24 20:46:33 2010 From: strandh at labri.fr (Robert Strandh) Date: Sun, 24 Jan 2010 21:46:33 +0100 Subject: [mcclim-devel] Is McCLIM being maintained? In-Reply-To: <3693571d1001241138l2795c047maec46831c8dc5179@mail.gmail.com> References: <3693571d1001241138l2795c047maec46831c8dc5179@mail.gmail.com> Message-ID: <19292.45481.713817.531874@cleo.labri.fr> Hello, Peter Busser writes: > > 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. Oh, please send them over. We'll see what we can do. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. ---------------------------------------------------------------------