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

[mcclim-devel] question about curves and formatting graphs
by rpgoldman＠real-time.com 10 Apr '06

10 Apr '06

If one wanted to draw curvy lines in McCLIM, is there any way of doing this? I had assumed, foolish me, that this could be done using Bezier curves, but now I see that those were an Allegro extension to the standard, and not part of CLIM 2.0.... I'm not much of a graphics person, and don't understand X very well, so I was wondering --- is there anything about X itself that makes drawing curved lines particularly difficult? Also, has anyone been thinking about the possibility of dynamic graphs? I.e., graphs where one might want to enter leaves? Or the possibility of having a fixed graph where a user might move the nodes around to make the graph more readable. CLIM doesn't have any sort of "smart link" object that would support this, does it? Thanks, Robert

4 11

[mcclim-devel] incremental redisplay and with-first-quadrant-coordinates
by Christophe Rhodes 02 Jul '05

02 Jul '05

Hi, The attached file defines two application frames which differ essentially only in their use of with-first-quadrant-coordinates. In the one (BAR) without with-first-quadrant-coordinates, incremental redisplay behaves as I expect; in the other (FOO) with, strange things happen. I believe this is connected with output record moving; if I change state-matches-stream-p in incremental-redisplay to query both X and Y coordinates of the stream cursor, the display of both applications is as I expect. Cheers, Christophe

1 0

[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