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

[mcclim-devel] clim-extensions.lisp
by John Connors 20 Apr '06

20 Apr '06

I note that clim-extensions.lisp isn't in the clim-clx asdf defsystem form despite being defined in that package; is there a reason for this? -- +--------------------------------------------------------+ |Cyborg Animation Programmer | johnc(a)yagc.ndo.co.uk| |http://badbyteblues.blogspot.com -----------------------| +--------------------------------------------------------+

1 2

[mcclim-devel] accept-values-pane
by Paul Werkowski 19 Apr '06

19 Apr '06

For those interested, I have a mostly portable version of accept-values-pane running on lispworks CLIM and today I have it semi-working on McCLIM. Here is the patch file I load to supply missing parts of McCLIM. It would be cool if someone could add this functionality to the code base. I plan to post my code in a few days once I figure out how to handle radio-box. The spec and McCLIM have radio-box :choices and :current-selection as toggle-button objects. CLIM makes things a bit easier so I want to make a wrapper around the button-object constraint. What's really missing in McCLIM are list-pane and option-pane gadgets. Another thing. CLIM puts with-look-and-feel-realization in the expansion of with-output-to-gadget. It would be good if McCLIM did as well. I don't think the spec forbids that. Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ;;; -*- Package: clim-internals -*- (in-package :clim-internals) ;;; Add missing view classes and +xxx-view+ objects. (macrolet ((frob (name) (let ((sym (intern (string name) :clim-internals)) (par (intern (concatenate 'string "+" (string name) "+") :clim-internals))) `(progn (defclass ,sym (clim:gadget-view)()) (import '(,sym ,par) :clim) (export '(,sym ,par) :clim) (defparameter ,par (make-instance ',sym)))))) (frob toggle-button-view) (frob push-button-view) (frob radio-box-view) (frob check-box-view) (frob slider-view) ;(frob text-field-view) (frob text-editor-view) (frob list-pane-view) (frob option-pane-view) ) (import '(name-key value-key test documentation-key) :clim) (export '(name-key value-key test documentation-key) :clim) (defun accept-present-default (type stream view default default-supplied-p present-p query-identifier) (funcall-presentation-generic-function accept-present-default type stream view default default-supplied-p present-p query-identifier)) (defmethod pane-frame ((pane standard-encapsulating-stream)) (pane-frame (encapsulating-stream-stream pane))) (defmethod invoke-with-sheet-medium-bound (continuation (medium null) (sheet standard-encapsulating-stream)) (invoke-with-sheet-medium-bound continuation medium (encapsulating-stream-stream sheet)))

2 1

[mcclim-devel] spatial-trees
by Christophe Rhodes 19 Apr '06

19 Apr '06

Hi, I've uploaded a new version of spatial-trees to cclan, with two fixes: * conditionalize (on #+slow :-) the code checking that all the coordinates are in the right order in MAKE-RECTANGLE * make spatial-tree-viz a static-file, so that if a user installs spatial-trees systemwide and then someone else installs clim, you don't get write errors. Cheers, Christophe

1 0

[mcclim-devel] fonts, bounding-rectangles on beagle
by Christophe Rhodes 19 Apr '06

19 Apr '06

Hi all, JWZ's blog might be of interest for those wondering about implementing TEXT-BOUNDING-RECTANGLE* on beagle: it looks like he has exactly the same problem at <http://jwz.livejournal.com/628853.html>. (Something similar might be needed for the gtk and/or cairo backends, who knows?) Cheers, Christophe

1 0

[mcclim-devel] bug: with-presentation-type-xxx
by pw＠snoopy.mv.com 18 Apr '06

18 Apr '06

In LispWorks CLIM CLIM-USER> (with-presentation-type-parameters (completion '(completion (a b c))) value-key) CLIM-USER> IDENTITY In McCLIM, an error The variable VALUE-KEY is unbound. With-presentation-type-parameters and with-presentation-type-options are afflicted this way. Paul

1 0

[mcclim-devel] Severe performance regression with latest CVS sources?
by Paolo Amoroso 16 Apr '06

16 Apr '06

When I update my working copy of McCLIM's CVS sources, I do a quick test to check that things still work fine. I run the CLIM Listener and evaluate a form that draws a monster graph: (time (clim-listener::com-show-class-subclasses t)) Until a few weeks ago, I got run times under 1 s (I seem to remember about 0.7-0.8 s) with CMUCL under Slackware Linux 10.0. With the latest McCLIM CVS sources and CMUCL Snapshot 2006-02 (19C), I now get times over 15 s, no matter whether I initialize multiprocessing with (mp::startup-idle-and-top-level-loops) or not. Can anybody confirm this? Paolo -- Lisp Propulsion Laboratory log - http://www.paoloamoroso.it/log

5 18

[mcclim-devel] radio-box gadget
by pw＠snoopy.mv.com 13 Apr '06

13 Apr '06

FYI Seems that CLIM (lispworks at least) implements the :name-key and :value-key options (found in the documentation for list-pane and option-pane) for radio-box and check-box as well. This either an undocumented extension or an omission from the spec. Having that available aids handling presentation-types like member-alist and subset-alist. With these types, the gadget gets a :choices list like ((:a . 1)(:b 2)) and wants to show check-boxes with names A and B. Selecting one/some of these results in a gadget value that is made up from the :choices list. For radio-box the gadget-value might be (:a . 1) while the check-box form would yield ((:a . 1)). The way the spec is written, those conversions have to be done outside the gadget itself. Does anyone know if other CLIM implementations do this too? Should McCLIM? Paul

1 0

Re: [mcclim-devel] accept-values-pane and views
by pw＠snoopy.mv.com 11 Apr '06

11 Apr '06

> I don't quite understand. Do you have an implementation of accept values > panes that you'd like to share, or you're using it in CLIM and would > like to use it in McCLIM too? This is an important project that Well, I've been using accept-values-pane and accepting-values :own-window t in CLIM for a few years now (never used interactor at all) and got to wondering what the magic was. So I played around a bit and found that accept-values-pane was very simple to implement with most of the hair in converting to/from completion ptypes. I think that is mostly solved now as well. Now that with-output-as-gadget has a chance of working in McCLIM, this mostly portable code could be messaged into a McCLIM accept-values-pane. McCLIM's accepting-values mechanism was not up to handling with-output-as-gadget when I last checked in December. I can send you what I have if you are interested. It may be of some help. > As for view object values, there is code in classic CLIM to pass on the > "init args" passed to a view object as extra arguments to make-pane; it > is probably worthwhile to do that in McCLIM too. I guess I missed that in the spec. Can you give me a pointer? Paul >

1 0

[mcclim-devel] accept-values-pane and views
by pw＠snoopy.mv.com 11 Apr '06

11 Apr '06

I have a mostly portable implementation of ACCEPT-VALUES-PANE running in Lispworks CLIM. For those that don't know, the accept-values-pane is a gadget based non modal dialog. A display function for an accept-values-pane might contain code like this: (with-slots (some-value) pane (setq some-value (accept '(member A B C) :stream pane :default some-value :view '(radio-box-view :orientation :vertical) :prompt "Pick one"))) ACCEPT is supposed to do apply MAKE-INSTANCE to the CAR and CDR of the :view parameter and the stuff in the cdr is passed on to the gadget. In this example the presentation method ACCEPT-PRESENT-DEFAULT calls (apply 'MAKE-PANE 'RADIO-BOX-PANE <stuff> VIEW-OPTIONS). But, there is no defined way to get the supplied values. Lispworks CLIM has an internal function named CLIM-INTERNALS::VIEW-GADGET-INITARGS that retrieves them. It seems that the VIEW class has only two functions. The first is to be a class so generic functions can specialize on subclasses of it, and the second is to pass gadget options via the :view keyword to ACCEPT. This functionality is pretty important for usable gadget based dialogs so I hope the McCLIM architects can consider how this can be added to the code base. Paul

2 1

[mcclim-devel] gtkairo
by David Lichteblau 10 Apr '06

10 Apr '06

Hi, here's a somewhat functional GTK+ backend, using CFFI to interface with the C libraries. For drawing operations I have borrowed Gilbert Baumann's cairo medium (search&replaced to use cffi instead of alien and with minor updates for cairo 1.0), hence the name Gtkairo for the new backend. I probably don't have to explain why a GTK backend is interesting, but since using cairo means to interface with C anyway, it seems logical to go the full way to a native backend, eliminating the synchronization issues between the two parallel server connections (CLX and Xlib) present in Gilbert's original work. As a proof-of-concept, sliders, buttons, option- and check boxes are implemented as native widgets. As you can see in the screenshot below[1], scroll bars and menus are not done natively yet. Be warned that a lot of rough edges remain. * Display glitches. Notice how some weird bars drawn in what I think are background colors sometimes appear in the address book example. In the same example, the input cursor when typing and erasing characters is not getting removed properly, leaving a trace. Interestingly, when enabling antialiasing, the cursor is drawn blurry, which might indicate that non-integer coordinates are being used. Also, the presentation highlighting rectangle leaves traces if antialiasing is enabled (which is while I have disabled it for now). * The text cursor does not show the correct horizontal position in climacs. * Menus appear but do not really work. Worth fixing, even though we would rather want native menus in the long term. * The gadgets are only a quick hack. Colored buttons (clim-fig) are missing, the slider is not quite right. Inheriting from the standard gadget panes is bogus anyway, we should build them from scratch. * Should work on Windows but does not. Using the installer from gimp-win.sf.net I see an address book window, but there are cairo font warnings in the background and moving the mouse gives an error. Although the hordes of sbcl/win32 hackers might contribute a native Windows backend sooner or later, it would be nice to get Gtkairo working on Windows, too. * ... To install Gtkairo, extract the tarball[2] into your Backend directory and apply the trivial patch[3]. GTK+ 2.8 is required for the Cairo integration. Please test and improve ;-), David [1] http://www.lichteblau.com/blubba/gtkairo.png [2] http://www.lichteblau.com/blubba/gtkairo.tgz [3] http://www.lichteblau.com/blubba/gtkairo.diff

4 4