Re: nice file opening window

From: Andrew Dorrell <>
Date: Sun, 21 Jun 1998 22:44:12 +1000

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


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
          idea to have globally redefinable file-delimiter and

L194: * used as wildcard but this is only what the user sees.
          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

        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.


        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:")


        (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

This archive was generated by hypermail 2.3.0 : Mon Jul 21 2014 - 19:38:59 CEST