getOpenFile etc. wish-list

[Dave Bodenstab]

It is annoying, after having clicked my way through the tk_getOpenFile/
tk_getSaveFile dialogs, to have to repeat the same steps the next time
tk_getOpenFile/tk_getSaveFile is used. There should be a way to figure
out what the user did so that the next time these dialogs are run I can
supply as defaults the directory and/or default filetype that was last
used.

I see that if I omit the -initialdir parameter, then the last
directory used is the default (contrary to the documentation (8.4.9)
by the way), but this directory name is shared by both get/save so
there's no way to have separate directories for get/save.

For instance, suppose I have an application to convert sound files.
I happen to keep my .wav and .au files in directory $HOME/recordings/
and I decide that I want to convert some .wav files to
.mp3 files and put the results in /tmp/. So the first time tk_getOpenFile
is used, I click to $HOME/recordings, and choose "*.wav" as the
"files of type" pattern. When tk_getSaveFile is used, I click to
/tmp and choose ".mp3" as the "files of type pattern", and type in
my file name. After converting the first file, the application
would ask for the next file to convert via tk_getOpenFile. At this
point, *I want* my directory selections and file patterns to be
remembered so I don't have to constantly re-enter them -- and *I
want* them kept separately for Open and Save.

Specifically, for tk_getOpenFile (tk_getSaveFile) would be similar:

+ If I chose one of the -filetypes, I want to specify *that* filetype
to be a) the default extension, and b) the initial pattern used by
-filetypes the next time tk_getOpenFile is used

+ If I manually type "filename.suffix" then I do not want ".suffix"
to be the default extension the next time tk_getOpenFile is used

+ If I click through the directory hierarchy, I want *that* directory
to be the -initialdir the next time tk_getOpenFile is used

+ If I manually type a path (relative or absolute) into the "File names:"
entry box, then I would *not* want tk_getOpenFile to remember either
the directory or the file type the next time tk_getOpenFile is used.

I see that I could figure out the filetype entry chosen by looking at
::tk::dialog::file::__tk_filedialog(filter).

I could use [file dirname] to at least get the directory for the file name
returned, but I can't tell if it was via clicking through the directory
hierarchy or if I typed the path manually.

Obviously, using ::tk::dialog::file::__tk_filedialog(filter) would risk
breakage at some point in the future.

Must I re-implement my own get/save dialogs to accomplish what I want?
How to other Tcl applications handle this... or do they just make
the user repeatedly go through the dialogs?

Thanks for your thoughts.

[Ulrich Schöbel]

Am Thu, 23 Feb 2006 21:22:58 +0000 schrieb Dave Bodenstab:

> I see that if I omit the -initialdir parameter, then the last
> directory used is the default (contrary to the documentation (8.4.9)
> by the way), but this directory name is shared by both get/save so
> there's no way to have separate directories for get/save.

Hi Dave,

as you say, -initialdir does exactly what you want. Why don't you
use it? Save your recently used file to some variable and set
initialdir on your next call of tk_getOpenFile accordingly.

Where's the problem?

Best regards

Ulrich

[Dave Bodenstab]

I agree, most of the time this will work, and I am going to do this.

This just seems like something the get/save dialogs should automatically
handle -- I get so frustrated with most windoze dialogs forcing me to
repeatedly do the same thing over and over... I figured that Tcl
could do better by default.

As a wish though, I would
like to be able to type an entire path as an exception and not
affect the "remembered" directory. Relating to my example, I'm converting
.wav files, but then I remember I've got a single .wav file in /var/tmp.
It would be most convenient if I could just type "/var/tmp/x.wav" to
convert that file, but still have the application default to my
$HOME/recording/ directory when it asks me for the next file to
convert. Otherwise, I've now got to re-click through the dialog to
return from /var/tmp to $HOME/recording/.

Also, I'm wishing that it would remember the .suffix; if I've got
a few .wav files in the directory containing a 100 .au files, it would
be convenient to select "*.wav" as the filename pattern and have
it be remembered -- but again, not if I type /var/tmp/xxx.ogg as a
full path name. I guess I could remember the last suffix used too.

Maybe I'm being too picky... Thanks for the reply, I was just
wondering how or if anyone else dealt with this.

If there were a means for me to interrogate the dialogs to see what
the user did to arrive at a particular file name, then I'd have the
info I'd need to do what I want :)

[Bruce Hartweg]

well, you could mod your UI a bit - start with an entry for the filename
if user types it in there then no "remembering is done - if they click
the browse button to bring up a file chooser, then remember what dir &
extension are picked and default them the next time around.

Bruce

[Darren New]

Dave Bodenstab wrote:
> Maybe I'm being too picky

It's impossible to be too picky about making a UI work as the customer
expects.

--
Darren New / San Diego, CA, USA (PST)
"I think these anchovies are spoiled.
They're not flat."

[Dave Bodenstab]

Bruce Hartweg wrote:
>
> well, you could mod your UI a bit - start with an entry for the filename
> if user types it in there then no "remembering is done - if they click
> the browse button to bring up a file chooser, then remember what dir &
> extension are picked and default them the next time around.
>

In the actual app. I need to pick the pair of images for a stereo
view; the whole app. is very mouse intensive. I think that having
to move my hand from the mouse to type two filenames would be quite
annoying (and error prone given the filenames from the Mars rover site)!

I've changed things to remember the directory returned by the get/save
dialogs and also the file extension, so it works a lot better than
before. If I have the lone exception though, then I have to do a
lot of clicking to move through the directory hierarchy.

[Bruce Hartweg]

Dave Bodenstab wrote:
> Bruce Hartweg wrote:
>>
>> well, you could mod your UI a bit - start with an entry for the filename
>> if user types it in there then no "remembering is done - if they click
>> the browse button to bring up a file chooser, then remember what dir &
>> extension are picked and default them the next time around.
>>
>
> In the actual app. I need to pick the pair of images for a stereo
> view; the whole app. is very mouse intensive. I think that having
> to move my hand from the mouse to type two filenames would be quite
> annoying (and error prone given the filenames from the Mars rover site)!
>

no, you still have the file chooser by button, that remembers the
directory & extension settings (all mouse picking), my suggestion
was having the entry as an alternative for the rare case you mentioned
where you wanted to enter and off-the-beaten-path that you didn't
remembered. This was in response to you wanting to know whether the
user typed the name or picked it from the list - if it is a separate
widget you can just ignore it. Also if the entry is filled by the choice
from the chooser, it might be easier to edit it the next time by
changing a single letter or two.
i.e.

/big/long/path/filename2005jan12.ext

instead of clicking and scrolling through 100's of files, just a quick
click/backspace/3 and you have

/big/long/path/filename2005jan13.ext

> I've changed things to remember the directory returned by the get/save
> dialogs and also the file extension, so it works a lot better than
> before. If I have the lone exception though, then I have to do a
> lot of clicking to move through the directory hierarchy.
>

Bruce

[Eckhard Lehmann]

Dave Bodenstab wrote:
> It is annoying, after having clicked my way through the tk_getOpenFile/

Well, that can be handeled by -initialdir, like Ulrich pointed out. I
think tk_get(Open|Save)File work quite correct for this. Why should the
developer(s) of these dialogs know how the end user wants to handle
initial directories? That is entirely up to the application developer
in my opinion.

But I have a different complain about tk_get[Open|Save]File, that
occures frequently on Unix systems - and I have not found a workaround
for it yet:
In a usual unix home directory you have lots of hidden files and
directories that start with a dot. Normaly, in a file open/save
operation I don't want to touch any of these hidden directories or
files - but nevertheless I *always* have to view the hidden directories
and *always* have to scroll to the left until I get the list of
directories that I am really interrested in (the ones that don't start
with a dot). That is *really* annoying if you have to do several
open/save operations.

So my question and a first point on my wish-list for these dialogs
would be to have an -exclude option that glob's or regex'es directories
not to show, so that I can for instance say:

tk_getOpenFile -initialdir $::env(HOME) -exclude ".*"

Or something similar - anyway something to exclude hidden files on
unix. On Windows systems, the file browsing properties are inherited by
the folder options anyway. So if I tell in the folder options that I
want to see hidden files/directories, then I will see them in
tk_get[Open|Close]File as well and vice versa. So there is no real
problem here. I don't know anything about how this all is handled on
Mac.

Any thoughts about that? How can I submit such a wishlist point? (if
this was not done already... I am probably not the only one who want's
to browse unix home directories ;-))

However, it could be that I am overlooking something and it can be done
already. If so, please enlighten me...

Eckhard

[Ulrich Schöbel]

Hi Eckhard,

sounds useful. Write a TIP and send it to Donal K. Fellows,
AFAIK he kindly helps you to complete and polish your TIP.

Kind regards

Ulrich

[Donal K. Fellows]

Eckhard Lehmann wrote:
> So my question and a first point on my wish-list for these dialogs
> would be to have an -exclude option that glob's or regex'es directories
> not to show, so that I can for instance say:
>
> tk_getOpenFile -initialdir $::env(HOME) -exclude ".*"

Actually, the best thing is to add something to the dialog to turn
off/on display of "hidden" files (defaulting to off, of course). This
could then be done without an API change, and hence wouldn't require a
TIP (and porting to the other platforms we support).

Donal.

[Donald Arseneau]

"Donal K. Fellows" <donal.k...@manchester.ac.uk> writes:

> Eckhard Lehmann wrote:
> > So my question and a first point on my wish-list for these dialogs
> > would be to have an -exclude option that glob's or regex'es directories
> > not to show, so that I can for instance say:
> > tk_getOpenFile -initialdir $::env(HOME) -exclude ".*"
>
> Actually, the best thing is to add something to the dialog to turn
> off/on display of "hidden" files

For the more general case, rather than -exclude, I would prefer
a -filter option, providing the glob pattern to use (defaults to
ordinary glob or glob *). This is in keeping with various file
selection dialogs that provide a "filter" button. Unfortunately
mathch patterns are so limited, they don't include anti-matching
like [^.].

Anyway, for display of hidden files, a clear (non-hackish) option
is called for; one that works independent of how each OS tags its
hidden files.

--
Donald Arseneau as...@triumf.ca

[Dave Bodenstab]

Eckhard Lehmann wrote:

> So my question and a first point on my wish-list for these dialogs
> would be to have an -exclude option that glob's or regex'es directories
> not to show, so that I can for instance say:
>
> tk_getOpenFile -initialdir $::env(HOME) -exclude ".*"
>

Just a thought... what if a superset of the contents of

::tk::dialog::file::__tk_filedialog

were available via an additional option (say -uiVarName <name>)?
Have <name> be an array which contains:

- what (if anything) was typed via the keyboard into the filename:
- which was the final item selected (if any) from "files of type"
- any more things that a user could select from the dialog

My example of one typing a one-time exceptional file path is
perhaps contrived. However, consider an example of a directory
containing lots of image files of different types: jpg's, png's,
gif's, etc. Assuming that tk_getOpenFile provided the -filetypes
option for each of the various file suffixes, a user could
select one of those types to help them filter the list of files.
This works two ways though.

If the application uses the suffix of the file returned by
tk_getOpenFile as the default filter (looks like tk_getOpenFile
uses the first item of -filetypes for this) the next time
tk_getOpenFile is used, then the user sees only the .jpg's if
the last file selected was a .jpg.

But what if the user actually selected the ".*" all files
filter because they *wanted* to see *all* the files? Now, when
the application "remembers" which filter to use, it is wrong.
The user has to repeatedly re-click the ".*" all files.

I, as a user, would like the application to present me with the
same set of files that >I< selected the last time the dialog
was used. If I selected "*.jpg", then I would expect that it
would remember that I selected "*.jpg". Likewise, if I selected
".*" all files, then I want that remembered too.

I don't think that this is too contrived. I've had to continually
re-click the file filter with some windows apps, and it is really
annoying after a while.

[Eckhard Lehmann]

> Unfortunately
> mathch patterns are so limited, they don't include anti-matching
> like [^.].

To the user could appear as regexp as well, like lsearch, switch etc.
do it. I can't say much about the underlying implementation...
Anyway it would be great to have one of the proposed options "show
hidden" button or -filter.

Thanks for your thoughts

Eckhard

[Donal K. Fellows]

That's in many ways beside the point. For various reasons, deploying
changes in the tk_get{Open,Save}File API onto all the supported
platforms is *very* hard. The problem is making Win and Mac do sensible
things with everything (Win is especially brain-dead); if you can get
an "acceptable" solution without an API change, please do that since
the alternative is a world of pain as far as I can tell. In the case of
Unix hidden file handling, I think this is possible and reasonable.
(Indeed, I believe you could even get away with always starting in the
"don't show hidden" mode, which would make things even easier to code!)

Donal.

[Koen Danckaert]

Hi,

If you have Tcl/Tk 8.4.12, find the file "tkfbox.tcl" in your Tk installation. At line 777, you will see:

set ::tk::dialog::file::showHiddenBtn 0
set ::tk::dialog::file::showHiddenVar 1

Replace them by:

set ::tk::dialog::file::showHiddenBtn 1
set ::tk::dialog::file::showHiddenVar 0

And you're done...

Bottom line: this functionality is already present in Tk, but for some reason it's not exposed yet...

Koen

[suchenwi]

Instead of editing a file in the Tcl/Tk distribution, you can also add
the two "replace with" lines to your script. This may be some more
robust, in case you update to 8.4.13, or you deploy your script to some
other user...

[Koen Danckaert]

Well yes, of course, but the problem is that you can't set these variables until you have called tk_getOpenFile once.
In another thread last week I learnt this has to do with autoloading, but I don't know how to 'force' this without actually calling tk_getOpenFile.

Koen

[suchenwi]

catch {tk_getOpenFile -with-invalid-argument}

:-)

[Eckhard Lehmann]

suchenwi wrote:
> catch {tk_getOpenFile -with-invalid-argument}
>
> :-)

That's it... Thank you both very much!
BTW, the variables should default to these values - or is there a
special reason for the current default setting?

Eckhard

[Torsten Reincke]

This is how TkRat (www.tkrat.org, written by Martin Forssén) does it.
There is a checkbox in the upper
right of the dialog which can be used to toggle the state of hidden
files. Veeeeery useful indeed!

It should be easy to pull the code out from this software and
incorporate it into the core dialog. I do not know, jowever, what
license is associated with this code. The relevant file is called
rat_fbox.tcl and there is code in the rat_fbox::create procedure which
builds the gui element:

checkbutton $f1.dot -text . -variable ${dataName}(showDotfiles) \
-command "rat_fbox::updateWhenIdle $w"

and sure code elsewhere to make the magic happen. All this could be a
nice starting point!

Torsten

[Jeff Hobbs]

I snuck that feature in somewhere along the way, and haven't
exposed it because it would require TIP'ing, doc changes, etc.

--
Jeff Hobbs, The Tcl Guy
http://www.ActiveState.com/, a division of Sophos

[Torsten Reincke]

> set ::tk::dialog::file::showHiddenBtn 1
> set ::tk::dialog::file::showHiddenVar 0
>
> And you're done...
>
> Bottom line: this functionality is already present in Tk, but for some reason it's not exposed yet...

There is just one problem here. You need to have called the tk_get*File
once before you can issue the two command shown above, else you will
get the error:

% set ::tk::dialog::file::showHiddenVar 0
can't set "::tk::dialog::file::showHiddenVar": parent namespace doesn't
exist
%

Bug or feature?

Torsten

[Eckhard Lehmann]

Torsten Reincke wrote:

> % set ::tk::dialog::file::showHiddenVar 0
> can't set "::tk::dialog::file::showHiddenVar": parent namespace doesn't
> exist
> %
>
> Bug or feature?

Neither bug nor feature. Tcl just needs to know a namespace before it
can set variables in it ;-).

Solution:

namespace eval ::tk::dialog::file {
variable showHiddenBtn 1
variable showHiddenVar 0
}

Eckhard

[suchenwi]

I'd still suggest to call
> catch {tk_getOpenFile -with-invalid-argument}
before setting the variables.

Otherwise, when a file selector is needed, the corresponding file is
sourced, and probably overwrites your settings again...

[Eckhard Lehmann]

Hmm, I see what you mean... Exactly that is what happens.

Thanks,

Eckhard