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

[mcclim-devel] Non-ASCII character input in McCLIM using SBCL
by Milan Zamazal 20 Jun '05

20 Jun '05

Finally I've found a way how to force McCLIM to partially accept non-ASCII input when used with SBCL. For each of the non-ASCII CHARACTERs to be input by the key CODE the following actions must be done: (xlib:define-keysym CHARACTER (xlib:keysym CODE)) (in-package :goatee) (add-gesture-command-to-table CHARACTER 'insert-character *simple-area-gesture-table*) It is not a perfect solution, because dead keys are ignored. Milan Zamazal -- It's amazing how much better you feel once you've given up hope. (unknown source)

1 0

[mcclim-devel] Displaying non-ASCII characters in McCLIM using SBCL
by Milan Zamazal 20 Jun '05

20 Jun '05

The following patch makes McCLIM/CLX to display accented characters with SBCL 0.9.1.1. This is only a raw proof-of-concept patch, not a patch to be actually applied. Additionally, I tested it only with ISO 8859-2 characters. Could somebody of the McCLIM experts look at it and make the necessary changes in McCLIM/CLX, please? Thanks. Input of non-ASCII characters still doesn't work. Milan Zamazal -- real programmer? don't get me started. if you need to hide your pathetic excuse for a carreer behind super-macho languages like C, C++, and/or Perl instead of writing clean, maintainable, efficient code, you aren't much of a real programmer in my view. -- Erik Naggum in comp.emacs

1 0

[mcclim-devel] incremental redisplay optimization(?)
by Christophe Rhodes 17 Jun '05

17 Jun '05

Hi, The new(ish) code for optimizing incremental redisplay by replaying move-overlapping and erase-overlapping records all at once is actually a huge pessimization for many disconnected records: I think that region-union is a precise operation, so the asymptotic complexity of the union operation is O(n^2), and I think the complexity of the replay is O(n^3). Specifically, for my tablature editor, an operation which causes most records to be redraw takes 200 seconds with the current code, with most time (about 77%) being spent in BANDS-OP. The attached fixes the performance problem by being a little less precise. Is it right? Cheers, Christophe

2 1

[mcclim-devel] pointer protocol class / standard-pointer
by Christophe Rhodes 16 Jun '05

16 Jun '05

Hi, At present, it's only possible to have one backend loaded at once, because STANDARD-POINTER is defined per-backend. This can't be right, can it? On the other hand, the attached is my 'solution' (for the CLX backend; I haven't tried fiddling with Beagle, but this also works for my in-development Null backend), and I'm not wild about it. Still. Any opinions? Cheers, Christophe

3 5

[mcclim-devel] Fwd: [clisp-list] Lisp and Win32 GUIs
by C Y 16 Jun '05

16 Jun '05

Would the following be relevant to a Win32 backend for McCLIM? Cheers, CY --- Berlin Brown <berlin.brown(a)gmail.com> wrote: > From: Berlin Brown <berlin.brown(a)gmail.com> > To: clisp-list(a)lists.sourceforge.net > Subject: [clisp-list] Lisp and Win32 GUIs > Date: Thu, 16 Jun 2005 12:38:43 -0400 > > If quit working on a Win32 GUI library, actually it just simply > connects the API to lisp through FFI, nothing too complicated. > Anyway, if anybody wants to continue the project or have any > questions > on how they can create their own system you may ask me. I didn't get > too far with the Win32 widget creation set, but it is more code than > zero. > > You can find out more about the project here. I used open tools for > compiling on Windows so you don't need to purchase anything. > > http://www.newspiritcompany.com/retroevolution/widget_toolkit/widget.htm > > Latest source release. > > http://www.newspiritcompany.com/src/Widget-0.1.b57-050505-0802.zip > > Berlin Brown > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration > Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click > _______________________________________________ > clisp-list mailing list > clisp-list(a)lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/clisp-list > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

1 0

[mcclim-devel] [patch] bug in map-over-command-table-keystrokes?
by Daniel Barlow 15 Jun '05

15 Jun '05

I noticed this while trying to persuade climacs to give me a list of keybindings: (map-over-command-table-keystrokes (lambda (name key item) (format t "~A ~A ~A~%" name key item)) 'CLIMACS-GUI::GLOBAL-CLIMACS-TABLE) => debugger invoked on a UNBOUND-SLOT in thread 11974: The slot CLIM-INTERNALS::MENU-NAME is unbound in the object #<MENU-ITEM keystroke (- META) {9794829}>. According to the specification 27.4, "function must be a function of three arguments, the menu name (which will be nil if there is none), the keystroke accelerator, and the command menu item". I don't know if the fix below is the Right Thing, but it does the trick for me. Index: commands.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/commands.lisp,v retrieving revision 1.51 diff -u -r1.51 commands.lisp --- commands.lisp 24 Jan 2005 09:36:00 -0000 1.51 +++ commands.lisp 15 Jun 2005 17:57:40 -0000 @@ -474,7 +474,8 @@ (loop for gesture in keystroke-accelerators for item in keystroke-items do (funcall function - (command-menu-item-name item) + (and (slot-boundp item 'menu-name) + (command-menu-item-name item)) gesture item))))) -- Daniel Barlow // daniel.barlow(a)uk.clara.net // ext 3233 world domination and a whole lot of money to spend

1 0

Fwd: [mcclim-devel] Re: Beagle backend requirements?
by Duncan Rose 10 Jun '05

10 Jun '05

Begin forwarded message: > From: Duncan Rose <duncan(a)robotcat.demon.co.uk> > Date: Fri Jun 10, 2005 12:16:53 am Europe/London > To: mcclim-devel(a)common-lisp.net > Cc: Brian Mastenbrook <chandler(a)unmutual.info>, Rainer Joswig > <joswig(a)lisp.de> > Subject: Re: [mcclim-devel] Re: Beagle backend requirements? > > > Further to this, I can report no problems observed on 10.2 running > with OpenMCL 0.14.3 (from the 'distributions' link on Clozure.com, not > bleeding edge from CVS or whatever) so I suspect this may be a problem > that's specific to Tiger. > > Sorry not to be more helpful, but I don't have access to a box running > 10.4 :-( > > -Duncan > > > On Monday, June 6, 2005, at 12:06 am, Duncan Rose wrote: > >> >> Oops, didn't notice this was posted to the list as well... this is >> how I responded to Brian's chandler address: >> >> On Thursday, June 2, 2005, at 01:45 am, Brian Mastenbrook wrote: >> >>> Hi Duncan, >>> >>> What version of OpenMCL is required for running the Beagle backend? >>> Right now current CVS won't run on 0.14.3 with an error about ObjC >>> ARRAY. >>> >>> Should I get bleeding edge or current 0.14 CVS? >>> >> >> I'm currently using the outdated 0.14.1-p1 version, on 10.2 >> >> I've heard from Rainer Joswig that Beagle doesn't compile under the >> latest OpenMCL (but no more than that it fails 'with a type error'; >> presumably the same thing you're seeing); there's still quite a lot >> of discussion on the OpenMCL list regarding problems with the ObjC >> bridge under the latest OpenMCL versions (and I'm pretty sure Jaguar >> is not intended to be supported any longer by later OpenMCL versions) >> so I haven't done an upgrade (I'm seriously considering forking out >> for a new iBook though, at which point I will be upgrading ;-). >> >> Could you send me the actual error report? At the moment I'm guessing >> from your description that the problem is likely to be in >> %COCOA-IMAGE-FROM-PATTERN in OUTPUT;MEDIUM.LISP however I don't >> believe any ObjC arrays are used directly by the code (I'm classing C >> arrays (char * etc) and ObjC (NSArray) arrays differently, although >> perhaps I shouldn't in the context of this issue). >> >> -Duncan >> >>> Thanks! >>> >>> >>> -- >>> Brian Mastenbrook >>> http://www.iscblog.info/ >>> http://www.cs.indiana.edu/~bmastenb/ >>> >> >> _______________________________________________ >> mcclim-devel mailing list >> mcclim-devel(a)common-lisp.net >> http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel >> >

1 0

[mcclim-devel] May/June 2005 messages missing from mcclim-devel archive
by Paolo Amoroso 10 Jun '05

10 Jun '05

It looks like the archive of the mcclim-devel mailing list: http://common-lisp.net/pipermail/mcclim-devel/ is missing all May 2005 messages and part of the June ones. Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log

3 2

[mcclim-devel] Beagle backend requirements?
by Brian Mastenbrook 09 Jun '05

09 Jun '05

Hi Duncan, What version of OpenMCL is required for running the Beagle backend? Right now current CVS won't run on 0.14.3 with an error about ObjC ARRAY. Should I get bleeding edge or current 0.14 CVS? Thanks! -- Brian Mastenbrook http://www.iscblog.info/ http://www.cs.indiana.edu/~bmastenb/

2 2

[mcclim-devel] Freetype for SBCL
by Brian Mastenbrook 09 Jun '05

09 Jun '05

Hello, Since I'm under the impression that code in the Experimental directory is, well, experimental, I've committed a version of the experimental freetype bindings which works on SBCL. I've optimized away the %SAP-ALIEN problems, and the end product is reasonably usable. It's a bit laggy until the glyph cache warms up, but after that it's just fine. Here's a gratuitous screenshot: http://www.unmutual.info/images/slidemacs-big.png I'm pretty sure that this doesn't work on CMUCL anymore, as CMUCL has slightly different names (DEF-ALIEN-TYPE and -ROUTINE), but a little macrology should restore CMUCL workingness if anybody's interested in giving it a try. In order to use this under SBCL, you must use the .asd file, as there's a little ASDF muckery in there to work around the fact that compiling the freetype-ffi file currently stuffs up in SBCL. After the rest of the code finishes compiling, you should see a message about setting mcclim-freetype:*freetype-font-path* - set this to a directory containing the Bitstream Vera fonts, and don't forget the final / on the pathname or else merge-pathnames is not going to be happy. Comments and patches welcome, especially from CMUCL users. -- Brian Mastenbrook "God made the natural numbers; http://www.iscblog.info/ all else is the work of man." chandler(a)unmutual.info -- Leopold Kroneker

3 2