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

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

[mcclim-devel] eps bug
by David Lewis 01 Apr '06

01 Apr '06

Hi, If this was me, I apologise now, but somehow eps output from invoke-with-output-to-postscript-stream now always gives a bounding box with 0 width. This should fix it: --- Backends/PostScript/sheet.lisp 7 Mar 2006 15:43:44 -0000 1.13 +++ Backends/PostScript/sheet.lisp 30 Mar 2006 13:12:10 -0000 @@ -74,11 +74,11 @@ ((:eps) (let ((record (stream-output-history stream))) (multiple-value-bind (lx ly ux uy) (bounding-rectangle* record) - (setf translate-x (- (ceiling lx)) + (setf translate-x (- (floor lx)) translate-y (ceiling uy)) (format file-stream "%%BoundingBox: ~A ~A ~A ~A~%" 0 0 - (+ translate-x (floor lx)) + (+ translate-x (ceiling ux)) (- translate-y (floor ly)))))) (t (multiple-value-bind (width height)

2 1

[mcclim-devel] New mcclim.asd: please test!
by Andreas Fuchs 31 Mar '06

31 Mar '06

Hi all, You all probably had to delete your .fasls at some point in the past, because somebody updated setf-star.lisp in the past, and asdf doesn't track rebuilds across defsystem boundaries. I just wrote a new (and more precise, cooler) asdf compile-time dependency groveler, and used it to merge the four systems that make up mcclim's core: :clim, :clim-lisp, :clim-core and :goatee-core. Now, all the components are in one system, and dependencies should be correctly tracked again. - Deleting .fasl files should be a thing of the past. (: The new system definition uncovered two bugs in mcclim already, which were masked by randomly "good" build order. (-: So, here's the new mcclim.asd. It's a drop-in replacement for the mcclim.asd in CVS. Please replace the mcclim.asd in your checkout with this one, and report your results to the list. To give a useful report, I'll have to ask you to delete your fasl files one last time, though. (: Cheers, -- Andreas Fuchs, (http://|im:asf@|mailto:asf@)boinkor.net, antifuchs

2 1