Jon Berry wrote:
>
> Hi Andrew,
> Thanks for sharing your file-selector code. It looks like it is
> probably more flexible than the default. What I'm really after is a
> file-selector that works on Windows and would allow me to change, say, from
> C:\xxx to f:\yyy\zzz. Can you outline what would have to be done to make
> that work?
> thanks,
I have gone over my code and here is my conclusion:
I don't think it would be very difficult. The main functions which
would need to be modified are 'find-files' and compose-file-name.
The former only needs to be modified if glob works differently on
windoze (ie. uses *.* in place of * for matching all files). This
would only require separate definition of a glob-all-files variable,
probably globally.
On the latter, care should be taken to ensure that 'compose-file-name'
acts as a true compliment to 'decompose-file-name' under windoze. The
correct delimiter character needs to be specified. Currently this is
specified in the call to compose-file-name but it would probably be
better to define it as a global variable and change the definition of
compose-file-name to make use of it.
If this was done it is possible that no changes at all would be
required to hlistbox.stk (although there may be some loss of
generality for dealing with non-file structures). Minor changes to
file-selector.stk would be required as listed below. Most are code
cleaning such as using compose-file-name instead of string-append!
On filters:
Filters are managed through procedures and operate on lists of file
names - so they are fairly independent of platform specifics. Also
the filter labels (displayed in the choice entry) need not be the same
as the glob explressions used.
One other issue is managing hidden files. My code assumes the Unix
model, but again this is managed via a filter procedure -
hidden-file-filter - and can be readily altered to use any mechanism
you please.
The following are my working notes which might also be useful to
porters:
file-selector.stk:
L117-118: use compose-file-name instead of string-append in glob
expressions (allows choice of filename delimiter). Also *
-- under unix needs to be *.* under windows? Probably a
good
idea to have globally redefinable file-delimiter and
all-files-wildcard.
L194: * used as wildcard but this is only what the user sees.
This
could equally be set to the string "All files"
L206: * used as wildcard but will be processed by glob->regexp
L259: "*" used as in both of the above
L136: Windows uses a different mechanism for hiding files
L162: Does windows understand the directory name "." ?
L215: "/" assumed as delimiter character
L230,236: "/" used as delimiter and should use compose-file-name in
place of str
ing-append
The case of file filters is special as glob is not used to
implement these. Rather I convert the glob style expresion
(more like a shell wildcard) to a regexp which is applied to
the list of files (the list of files is got using (glob
dir/*)). In practice this means that some of the platform
differences can be managed in the glob->regexp function: I
don't think we will need to change it at all, especially as
the filter choice pulldown need not display the glob
expression being applied (note the synopsis of the filter-add
function (filter-add <file-selector> label spec). Here label
is the text displayed in the choice entry menu and spec can be
a procedure, regexp or glob-style wildcard string. In all of
these cases it is a proc which ends up being stored within the
file-selector widget: a proc which takes a list of strings and
returns a filtered list of strings.
hlistbox.stk:
This file is more actively in use by me and I have cleaned it
so that all paths are composed using compose-file-name rather
than string-append. Most of the porting work would therefore
be centered around these calls which, at the moment, use none
of the optional args (for delimeter, drive letter, see below).
It would be trivial to add these as required.
Notes on compose-file-name: (compose-file-name path . args)
This is intended to be a compliment to decompose-file-name.
I was really bad at commenting this: The path is a list of directory
names (no delimiters). This kind of approach was flagged in earlier
communications in the STk mailing list so I thought I'd adopt it. The
(optional) args are used for two things: the first arg is used as a
delimiter (with the default being "/". The second arg is intended to
handle drive names and is prepended to the result in the case where
the first directory in the path is not equal to the delimiter. This
handles the fact that "/" is both the name of the root directory and
the delimiter character in UNIX.
I thought this might be useful when dealing with that other operating
system but it may not be. For example:
(compose-file-name '("c:" "mypath" "more-path") "\" "c:")
will produce an eroneous result. The correct result would have been
given by
(compose-file-name '("mypath" "more-path") "\" "c:")
or
(compose-file-name '("c:" "mypath" "more-path") "\")
It depende a little on how the (STk builtin complimentary function)
decompose-file-name operates in the windoze world. I don't have
access to this information.
A better way is possibly:
(define *file-delimiter* "/") ;; Use "\\" for that other platform
(define (compose-file-name path-list)
(apply join-strings *file-delimiter* pathlist))
--
Mr Andrew Dorrell *
Faculty of Engineering /---\ Whoo? *
University of Technology, Sydney (o o) / *
AUSTRALIA ( : ) .
^ ^
*
Received on Sun Jun 21 1998 - 14:45:07 CEST