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

[mcclim-devel] file-browser demo program
by Robert Goldman 09 Jan '07

09 Jan '07

I have committed a working, but undesirable version of the demo. This one fixes some bugs that weren't really CLIM bugs, per se, but were either incorrect, or at least unportable, treatments of CL pathnames. A remaining problem is that the file-browser would try to edit (really list) directories on any pathname, not just directory pathnames. My attempt to fix this originally relied (I think correctly), on the use of a presentation type of (and pathname (satisfies cl-fad:directory-pathname-p)). Unfortunately, and and satisfies presentation types don't work properly in McCLIM. For now, I have also committed this alternative version for reference as file-browser.lisp-type-abbrev. It could become the real version when the presentation types are fully fixed. Sorry to leave things like this, but I will probably be unable to work on McCLIM again for a week or so, so thought it would be best to leave things at least *better*, if not fully fixed. Cheers, R

1 0

[mcclim-devel] modified clim Spec latex
by Robert Goldman 08 Jan '07

08 Jan '07

I have modified the clim spec to load its images through includegraphics rather than through epsfig, making it equally usable through pdflatex and latex. In pdflatex, I additionally tweaked it to generate hyperlinks, making it easier to read the document online. Anyone have any objections to my committing these changes? Best, Robert

1 1

[mcclim-devel] RGBA image drawing
by David Lichteblau 07 Jan '07

07 Jan '07

Hi, McCLIM CVS now has experimental support for 32 bit RGBA images, based on Closure's AIMAGE code. Both API and implementation are up for discussion, and I would be glad to receive feedback. One API issue is that Closure draws aimages to CLX pixmaps, and keeps a cache of these pixmaps. To keep this cache functional, I decided to put medium-specific data into the design instances used to draw images. Normally designs are not bound to a particular medium, and existing code for indexed-pattern does not expose its caching to the user. Perhaps a better implementation strategy could be used for both rgb-image-design and indexed-pattern? More serious perhaps is the current implementation's limitation to true color visuals. Closure itself had sophisticated support for all kinds of X11 visuals, including dithering algorithms. The routines used there are similar to the code found in CLIM-CLX's indexed-pattern implementation. Basically, code suitable for the current colormap is compiled at runtime into a function that maps abstract colors and x/y coordinates to X11 colors. (This code can be found in closure/src/renderer/x11.lisp) Perhaps someone who understand the indexed-pattern drawing routines knows what the right approach to this is. Should x11.lisp be moved into McCLIM? Can it be merged with the code that Backends/CLX/medium.lisp already has? Thanks, David

1 0

Re: [mcclim-devel] file-browser example application
by Robert Goldman 07 Jan '07

07 Jan '07

Robert Goldman wrote: > Troels Henriksen wrote: >> Robert Goldman <rpgoldman(a)real-time.com> writes: >> >>> I made a stab at it, but no, it didn't seem to work. I am attaching two >>> different versions of the file-browser: one that works, using a new >>> presentation-type, dir-pathname, and one that tries to do the job with >>> (and pathname (satisfies cl-fad:directory-pathname-p)), that doesn't >>> work. >> It seems that the `and' type doesn't work at all. Try doing (present 2 >> 'integer) and then (accept '(and integer)) - the previous output will >> not be selectable. >> > Hm.... > > At least in presentation-defs.lisp, there is no accept presentation > method for AND. Is this the culprit? > > By analogy, I tried whacking together the following definition for > presentation-defs: > (define-presentation-method accept ((type and) > (stream input-editing-stream) > (view textual-view) > &key) > (let ((scan-begin (stream-scan-pointer stream)) > success > value) > (dolist (and-type types) > (setf (stream-scan-pointer stream) scan-begin) > (multiple-value-setq (success value) > (block try-accept > (handler-case (values t (accept and-type > :stream stream > :view view > :prompt nil)) > (parse-error () (return-from try-accept nil))))) > (unless success (simple-parse-error "Input type is not of type ~S" > types))) > value)) > > But then I get an error that SATISFIES is an unknown presentation type. > I suspect that this is because it's not a primary presentation type, so > I need to use presentation-typep here instead of a recursive accept... > > Best, > R > OK, the following works to let me enter values of type (and pathname (satisfies cl-fad:directory-pathname-p)) to the command prompt. But I still don't get the ability to mouse-select the directory list entries for the presentation-to-command-translator. (define-presentation-method accept ((type and) (stream input-editing-stream) (view textual-view) &key) (let* ((subtype (first types)) (value (accept subtype :stream stream :view view :prompt nil))) (unless (presentation-typep value type) (simple-parse-error "Input type is not of type ~S" type)) value)) BTW, the command prompt is pretty uninformative: Edit Directory (and) : Is this where an abbreviation and description would be helpful? Cheers, R

1 0

[mcclim-devel] file-browser example application
by Robert Goldman 07 Jan '07

07 Jan '07

The guided-tour has a test application that's a file-browser. I wanted to try to figure out how to read pathnames in an application I'm writing, so I tried to fire up the file-browser. Unfortunately, it didn't work, mostly because it made assumptions about the way that CL pathnames work that didn't map onto either SBCL or ACL, the two applications on which I tried it. I am attaching a patch which makes it work (if the patch about pathname presentations, that I sent earlier today, is also present). I am inclined to commit this, since (a) it's just part of an article, so can't be on anyone's critical path and (b) it seems like a Bad Thing to have a tutorial out there featuring exemplars that don't work. The downside is that CL pathnames are so intractable that the only good way I found to make this work was to use CL-FAD. Dependencies on libraries seems generally like a bad thing in a small tutorial like this, but importing enough code to make it work w/o the library would probably obscure the tutorial intent even worse. BTW, I think a more elegant solution might be made that would use satisfies to define the dir-pathname presentation-type more declaratively. But I couldn't figure out how to do it... best, Robert

3 4

[mcclim-devel] menu bars
by Christophe Rhodes 05 Jan '07

05 Jan '07

Hi, Consider the attached code, which demonstrates that it is possible with current McCLIM to change the contents of menus from within the app. So far, no surprises -- we have a nice dynamic UI, right? The surprise is that it isn't possible to do this to the contents of the menu bar itself: the menus there are fixed when the pane is instantiated, I believe. So my question: is this intentional? Is it desireable? (And what does Legacy CLIM do? :-) Cheers, Christophe

2 4

[mcclim-devel] Presenting pathnames
by Robert Goldman 05 Jan '07

05 Jan '07

In presentation-defs.lisp there's some code that stuffs :wild into the name field of pathnames before presenting them, together with a comment that says that pathnames can't be represented if they don't have names. I have checked, and pathnames can be printed w/o names, at least on SBCL and ACL. Adding random stuff to the pathname also seems a little like the wrong thing to do. Would the following patch be appropriate: Index: presentation-defs.lisp =================================================================== RCS file: /project/mcclim/cvsroot/mcclim/presentation-defs.lisp,v retrieving revision 1.65 diff -b -u -F^(def -r1.65 presentation-defs.lisp --- presentation-defs.lisp 13 Dec 2006 21:33:43 -0000 1.65 +++ presentation-defs.lisp 5 Jan 2007 20:35:08 -0000 @@ -1470,10 +1470,15 @@ (define-presentation-method present ((ob ;; XXX: We can only visually represent the pathname if it has a name ;; - making it wild is a compromise. If the pathname is completely ;; blank, we leave it as-is, though. - (let ((pathname (if (equal object #.(make-pathname)) - object - (merge-pathnames object (make-pathname :name :wild))))) - (princ pathname stream))) + + ;; AFAICT the above assertion is simply untrue. At least it is + ;; possible to princ a directory with no :name component in ACL and + ;; SBCL. +;;; (let ((pathname (if (equal object #.(make-pathname)) +;;; object +;;; (merge-pathnames object (make-pathname :name :wild))))) + (princ object stream)) +; ) (define-presentation-method present ((object string) (type pathname) stream (view textual-view)

1 0

[mcclim-devel] Patch: gtkairo backend CL source conventions 2/2
by Douglas Crosher 04 Jan '07

04 Jan '07

The gtkairo backend use some source code conventions that are not in the tradition of CL; using C style names for functions and constants. This patch tranforms the source to standard CL conventions. For example: cairo_text_extents -> cairo-text-extents :CAIRO_ANTIALIAS_DEFAULT -> :cairo-antialias-default gdk_cairo_create -> %gdk-cairo-create GdkCapStyle -> gdk-cap-style GTK_POLICY_AUTOMATIC -> *gtk-policy-automatic* Regards Douglas Crosher

1 0

[mcclim-devel] Patch: gtkairo backend CL source conventions 1/2
by Douglas Crosher 04 Jan '07

04 Jan '07

The gtkairo backend use some source code conventions that are not in the tradition of CL; using C style names for functions and constants. This patch tranforms the source to standard CL conventions. For example: cairo_text_extents -> cairo-text-extents :CAIRO_ANTIALIAS_DEFAULT -> :cairo-antialias-default gdk_cairo_create -> %gdk-cairo-create GdkCapStyle -> gdk-cap-style GTK_POLICY_AUTOMATIC -> *gtk-policy-automatic* Regards Douglas Crosher

1 0

[mcclim-devel] Listener menus
by Christophe Rhodes 04 Jan '07

04 Jan '07

Hi, The attached restores working menus to the Listener. (It's not completely clean; I'll try to explain why). The first thing to do, done in the middle hunk of the three-hunk patch, is to put back the listener-view specializations to the interactor and the pointer documentation. (The latter isn't necessary, but I think it's right anyway). The first hunk is the magical one: it defines a command-or-form accept method which treats menu-items specially. The problem is that a menu-item is a perfectly good form, at least according to the various presentation translators around; therefore, the command-or-form input context "captures" the menu item. I'm not sure that this is ever desired behaviour, but it's certainly not desired behaviour inside read-frame-command of the listener, so we reintroduce an input context for menu-item inside the command-or-form context, and throw to the outer context handler established by the McCLIM-provided read-frame-command :around method. As I say, I'm not sure that it's ever desireable for 'expression or 'form input contexts to capture menu-items; if it isn't, then probably mcclim itself ought to prevent it from happening, maybe by a similar trick inside the system accept methods? It all looks a bit horrible, though. It's not great for the user as it stands, though, because as far as I can tell there's no standard menu-item presentation type -- the one that McCLIM implements is good, but it's not in Gilbert's annotatable spec -- and the contents of *input-context* are explicitly unspecified. The third hunk of this diff is an alternative approach, handling menu-items specially if they're returned from read-frame-command. This feels clunkier somehow -- for instance, the menu-item objects are printed at the repl -- but seems to violate fewer abstractions. Comments? Cheers, Christophe PS: when I apply this patch and click on a menu item for, say, Show Class Subclasses, the resulting dialog box eats my first keystroke using Drei, but not using Goatee.

3 8