[mcclim-devel] ideas on presentation methods for pathnames (was: [climacs-devel] Re: a patch for climacs (mainly regarding COMPLETABLY-PATHNAME) + a gimmick)

Fri Sep 2 01:36:54 UTC 2005

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

-- 
Max-Gerd Retzlaff <m.retzlaff at gmx.net>

For your amusement:
Make it idiot-proof, and someone will breed a better idiot.
	-- Oliver Elphick
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/mcclim-devel/attachments/20050902/209e6d91/attachment.sig>