Hello,
My File Selector is completed. The source code is attached. New versions will be available at http://bl0rg.net/~mgr/flux/file-selector.lisp
You'll *have* to apply the also the following patch for the CLIM-Listener (attached and at http://bl0rg.net/~mgr/flux/CLIM-Listener.patch ). This patch mandatory as the File Selector will not work correctly without it. (More below.)
Also you'll need a quite new CVS version of McCLIM. That is after 00:39:32 CEST of today...
Screenshots:
http://bl0rg.net/~mgr/flux/File-Selector-in-its-own-window-1.0.png and http://bl0rg.net/~mgr/flux/File-Selector-embedded-into-the-Clim-Listener-1.0...
(Note in the second screenshot that, although only "syntax" is specified as Filename, "syntax.fasl" is selected (i.e. will be returned if one clicks on OK). This is because "fasl" is the current Filetype and there is no file "syntax" (without the extension). I hope I've got other minor details right, as well.)
Problem with ACCEPT:
There is a general problem regarding ACCEPT and its parameter :DEFAULT. The clim 2.0 spec says in the section about ACCEPT-1:
If default is supplied, then it and default-type are returned as values from accept-1 when the input is empty.
In McCLIM there is currently no way to specify "" in an ACCEPT with :DEFAULT (that is non-equal to ""), as "" is considered to be "empty". (If you enter nothing or explicitely "" to a promt of an ACCEPT outside an ACCEPTING-VALUES the default value will be returned; inside an ACCEPTING-VALUES dialog a text-field will be displayed in which "" is normally not displayed, unnecessary to say that in that case the specified default is also returned.)
Even worse, there is *no way* to distinguish between the cases that the user left the default untouched and he or she removed the content of the field completely. No third return value for that. Quite inconvenient!
It would also be inconvenient to have to enter "" for the empty string. There is no keyword :ONLY-INSERT-DEFAULT. That would be the behaviour that I want: The default is only inserted into the field but whatever is there after the user edited the field will be the return value of the ACCEPT call, *untouched*. The clim 2.0 specification seems to supply no way to do this! As a workaround I can only think of a button "empty the field" right next to each accept text-field. I really hope I missed something.
This means for the File Selector that you cannot empty a formerly speciefied Filename of Filetype again *by editing the text-field*. To empty those textfields just left-click on a directory for the Filename, and middle-click for the Filetype. The "Parent Directory" and the pathname in the title of the directory listing always work for this.
It would be very nice if somebody had a closer look at CLIMI::HANDLE-EMPTY-INPUT, CLIMI::INVOKE-HANDLE-EMPTY-INPUT, and friends.
More information on the patch to the CLIM-Listener
I hope Andy Hefner likes the patch. It adds : - sort-by for filenames to COM-SHOW-DIRECTORY, - an icon and a cond-clause in ICON-OF for wild pathnames, - a wrapper for LIST-DIRECTORY (that NCONCs the subdirectories of the directory to the output of LIST-DIRECTORY if it is called with a wild pathname), - and does some minor changes to COM-SHOW-DIRECTORY. Also it removes the SB-POSIX LIST-DIRECTORY for SBCL as that one completely ignores the pathname-name and -type, which renders it quite useless for :wild searches (pune or play on words intended).
Comments are welcome, of course. Hope you like it, Max
On Tue, Aug 30, 2005 at 04:38:13AM +0200, Max-Gerd Retzlaff wrote:
Hello,
My File Selector is completed.
Oh, I've forgotten to mention that it is no real gadget that will be called when there is an (ACCEPT 'PATHNAME) in the +gadget-dialog-view+ (or other gadget-views). For that WITH-OUTPUT-AS-GADGET would have to work (compare my earlier mail about that).
But it is a normal ACCEPTING-VALUES dialog that can be displayed in a seperate, new window or "embedded" into a pane of the host application. Actually it is quite uncomplicated in its use, I think.
Right now it inserts a VRACK-PANE in the children slot of the parent's parent and adopts the former children into another VRACK-PANE that is a child of the other VRACK-PANE. (If the parent is embedded into a SCROLLER-PANE it gets the SCROLLER-PANEs parent, if that's again embedded into a BORDER-PANE it gets its parant.) Afterwards, if it was embedded into another pane, the original pane hierarchy is reconstruced.
And the temporary panes are forgotten.
Apropos forgotton, please have a look at the function FORGET-NAMED-PANE and its comment in the beginning of file-selector.lisp:
(in-package :climi)
;;; This is rather ugly. But right now named panes are pushed onto the ;;; slot FRAME-NAMED-PANES of the frame (in an :around method to ;;; make-pane-1 in frames.lisp) and *never* removed. Not nice, as the ;;; File Selector makes temporary panes that are nevertheless named. ;;; Even more ugly as they get the same name on every call of the File ;;; Selector. Apart from the accumulation of unused panes, which pane ;;; will be returned if I call (find-pane-named *application-frame* ;;; 'files) and there are several panes with this name? Therefore the ;;; panes are right now manually removed by the following function.
(defun forget-named-pane (pane &optional (frame *application-frame*)) (setf (frame-named-panes frame) (delete pane (frame-named-panes frame))))
Yeah.
Regards, Max