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

[mcclim-devel] #+unicode makes McCLIM not compile, #-unicode makes gadget-test-kr.lisp not compile.
by Dirk Gerrits 29 Jun '05

29 Jun '05

As the title says, if I don't have :unicode in *features*, then Examples/gadget-test-kr.lisp won't compile. It calls make-text-style with 4 arguments in several places, when make-text-style only takes 3 arguments. Having discovered that make-text-style /does/ take 4 arguments with #+unicode, I tried to recompile McCLIM after (push :unicode *features*). (:sb-unicode was already in *features*) This didn't work either: compilation aborted because of fatal error: READ failure in COMPILE-FILE: READER-ERROR at 43712 (line 1046, column 88) on #<SB-SYS:FD-STREAM for "file \"/home/dirk/lisp/mcclim/Backends/CLX/port.lisp\"" {1000F83EA1}>: package "EXTERNAL-FORMAT" not found Unicode support isn't important for me, but I was trying out the Examples/*.lisp and came across this, so I just thought I'd let you know. Kind regards, Dirk Gerrits

3 5

[mcclim-devel] FONT-ERROR in puzzle demo.
by Dirk Gerrits 28 Jun '05

28 Jun '05

When I try to start the puzzle demo through the Demodemo application, I'm dropped in the debugger with the following error: FONT-ERROR in current request Code 47.0 [QueryFont] ID #x2C00188 [Condition of type XLIB:FONT-ERROR] Is this a problem on my end? I'm using McCLIM CVS with SBCL 0.9.1 on an AMD64. Kind regards, Dirk Gerrits

3 4

[mcclim-devel] opacity / translucency
by nik gaffney 27 Jun '05

27 Jun '05

hello, after some basic experimentation with setting the 'opacity' of various inks, and attempting to compose-in/compose-over, im unable to find an obvious way to blend freshly drawn pixels (eg. using draw-line*) over previously drawn pixels. is it at all possible using the x11 (or potentially the beagle) backend to draw transparent/translucent objects in mcclim panes? the clim reference suggests it should be, . .. if such blending is not currently supported, could anyone suggest a method to simulate it? (a partially flipping +flipping-ink+ ??) thanks, nik

2 1

[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