Hello,

this thread actually started on climacs-devel. As the discussion has become more McCLIM than Climacs specific (at least in this sub-thread), I'll send this answer to mcclim-devel. If you're not subscribed to climacs-devel, refer to the following links for the context:

http://article.gmane.org/gmane.lisp.climacs.devel/275 http://article.gmane.org/gmane.lisp.climacs.devel/276

On Thu, Sep 01, 2005 at 09:16:17PM +0200, Robert Strandh wrote:

Max-Gerd Retzlaff writes:

...

I propose that COM-SHOW-DIRECTORY should become a general PRESENT method for a presentation LIST OF PATHNAMES, as well as the construct

(let ((icon (clim-listener::icon-of pathname))) (when icon (clim-listener::draw-icon stream icon :extra-spacing 30))) (princ (clim-listener::pathname-printing-name pathname long-name) stream))

should be CLIM's general PRESENT method for PATHNAME in TEXTUAL-DIALOG-VIEW. (The latter is already defined in file-selector.lisp.)

This code has a problem (aside from the very unfortunate indentation),

Sorry, I had copied it from the Emacs on my other machine via the mouse and the other Emacs didn't know about proper Lisp indentation, as it was in the Fundamental mode.

[This code has a problem ] namely that it assumes that the listener is present. At the moment, I do not think that is a good idea.

This is going to be a general problem for other applications as well. We are often going to want code that means "if this package exists and this symbol has a function definition in that package, then call the function with the following arguments" . Perhaps a macro FUNCALL-IN-PACKAGE like this:

(funcall-in-package :clim-listener (#:icon-of pathname) (message "sorry..."))

I don't think that this is a good idea. We have ASDF to load all required packages. Already we have to insert #-/#+ constructs to do things that depend on implementation features. We shouldn't do the equivalent for packages.

And regarding COM-SHOW-DIRECTORY (as PRESENT LIST-OF-PATHNAMES, or something like that), ICON-OF, DRAW-ICON, etc.: I think they should become part of McCLIM together with the FILE-SELECTOR and ACCEPT and PRESENT methods for the GADGET-VIEW class or subclasses thereof. Perhaps in the files mcclim/gadget-pathname.lisp and gadget-pathname-utilities.lisp; at least as an extension of McCLIM.

ICON-OF, DRAW-ICON and so on should only be used in the presentation methods (or in functions that are only called from these methods). That is the actual applications only call PRESENT and ACCEPT directly. And if the extension of the "nicer" pathname presentation methods (if it will be an extension) is not loaded, the current (more general) presentation methods will be used. No problem there.

(That could even work for the PRESENT LIST-OF-PATHNAMES method, if it will be implemented as proposed and if it will be included in the file presentation-defs.lisp (and not in the assumed extension package), as it would also use the current general presentation methods, if the extension package is not loaded.)

But I really think that an extension package is the wrong thing, as the specification defines a PATHNAME presentation type and also the standard views. I couldn't find it stated but the spec surely arranges for presentations methods for the standard presentation types and views. Dialog.lisp actually states: ;;; Hack until more views / dialog gadgets are defined.

Moving the presentation methods from the Clim-Listener to McCLIM (or an extension of it) is a good idea in my opinion, as these methods are right now not only used by the Listener itself anymore but also by the file-selector, and you can surely think of other application that could make use of more intuitive and simply nicer presentation methods for the GADGET-VIEW class and/or subclasses of it.

For example the file-manger and the Dired-like application that John Splittist has suggested. Hm, I think I'll accept the challenge and try to write a simple file-manager. Once there are the presentation methods it shouldn't be really that hard thanks to CLIM: Two panes (perhaps based on ESA) for directory listings (PRESENT LIST-OF-PATHNAMES), some presentation-to-command translators, some accepting-values dialogs (for renaming, etc), some drag and drop translators.. And you have it. --- Of course, it will nevertheless take quite some time as the supposedly simple things are always much harder to achieve than expected. :) At least the result will likely be not very long.

Well, just let me some time and I'll try to reorganise the existing methods and write the proposed ones. And if they are indeed as nice as I hope we can think about including them into McCLIM, then. (Be prepared that it'll take some weeks as I have not much time during the next weeks. But I don't think that's a problem. Perhaps it's not to bad to think about it for some time.)

Ah, actually I just noted that there is the sequence presentation type with one parameter "type": "The [presentation] type that represents a sequence of elements of type type. So "my" LIST-OF-PATHNAMES presentation type will just be the type SEQUENCE (of) PATHNAME. Very nice.

Regards, Max