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

[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

[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] patch for possbility sorting
by rpgoldman＠real-time.com 07 Apr '06

07 Apr '06

In BEIRC, one can end up with an enormously long list of candidate possibilities for completing a command, because IRC has so many commands. The possibilities are not ordered at all, so the list is pretty much useless. The following patch to input-editing would fix this problem by sorting the set of possibilities alphabetically. I realize that this may not be optimal, because it's a "one size fits all" solution. OTOH, it's clearly better than just getting an arbitrarily permuted list, so I suggest that it be adopted. I have commit privs, but have mostly used them for documentation and Allegro-specific compatibility fixes, so I'd love some validation (or reasoned rejection) before committing. Thanks all, R P.S. It occurs to me that we could avoid pointlessly sorting length 1 lists by dumping the call to sort inside the VALUES call in the ELSE branch of the final if of complete-from-generator-possibilies. But that shouldn't change the question of whether this is a good idea or not... --- input-editing.lisp 10 Mar 2006 21:58:13 -0000 1.49 +++ input-editing.lisp 7 Apr 2006 19:00:18 -0000 @@ -781,6 +781,9 @@ (defun complete-from-generator-possibili (incf nmatches) (push (cons str obj) possibilities)))) (funcall generator initial-string #'suggester) + ;; attempting to get the list of candidates sorted [2006/04/07:rpg] + (setf possibilities + (sort possibilities #'string-lessp :key #'car)) (if (and (eql nmatches 1) (string-equal initial-string (caar possibilities))) (values (caar possibilities)

2 3

[mcclim-devel] scroll
by Irene DURAND 07 Apr '06

07 Apr '06

Hello, With the latest version of mcclim, my application Autowrite has a problem that wasn't there before. When I scroll up a scrolling pane the top of the pane is empty and I cannot see anymore what was at the top of the pane. -- Irène DURAND http://dept-info.labri.u-bordeaux.fr/~idurand

1 1

[mcclim-devel] issues (bug?) with with-tab-layout in beirc
by rpgoldman＠real-time.com 05 Apr '06

05 Apr '06

I was trying to debug a space requirement issue in beirc, so I wanted to grab hold of its tab-layout-pane (which is named 'query). Oddly, I find that (get-frame-pane <frame> 'query) returns nil. I managed to use a back door to find the pane, and it *does* have a name: BEIRC(31): (slot-value tab-pane 'climi::name) QUERY It was defined as follows: (:layouts (default (vertically () (with-tab-layout ('receiver-pane :name 'query) ("*Not Connected*" server 'receiver-pane)) ;; (68 io) ;; no drop-shadow prompt (make-pane 'clim-extensions:box-adjuster-gadget) io (20 pointer-doc) (20 ;<-- Sigh! Bitrot! status-bar)))) The with-tab-layout does have the :name option, and it invokes make-pane. AFAICT, make-pane should stuff *application-frame* into an arglist and invoke make-pane-1, which should stash this pane away in the named-panes slot of the *application-frame*. But this is evidently not happening (or, I suppose, that slot could be overwritten). Alternatively, I suppose that *application-frame* might be unbound at the time this with-tab-layout gets evaluated? I'm pretty sure that this is a bug, and that the tab-layout pane IS intended to be exposed to get-frame-pane. But I'm not sure how to fix it, myself. Thanks, R

4 6

[mcclim-devel] define-presentation-type
by Christophe Rhodes 02 Apr '06

02 Apr '06

Hi, I think I just got bitten by the (specified) restriction that one can't inherit-from OR presentation types in define-presentation-type. It would have saved me some time if McCLIM had detected my erroneous code earlier -- is that possible? Cheers, Christophe

2 1