Can we specify or make uigetfile() remember its window position or view mode/sorting?

I've always avoided using uigetfile() because of how cumbersome it is and because it doesn't adhere to any of my system preferences that affect file management dialogs in other applications. It never remembers what the last path was or how the window was configured.

I've managed to implement a workaround for making the path persistent, but I'm struggling to figure out any acceptable way of managing the window size, view mode, and sorting behavior without manually mousing every single time.

I could probably resort to doing some sort of bash script with xdotool and wmctrl that waits for the dialog to appear, but I want to know if there's something at least a little less ridiculous, but less involved than reimplementing the whole thing. I'm open to undocumented solutions, as I'm probably going to be the only one using it. Web searches haven't turned up anything, but I figured I'd ask.

[Walter Roberson]

There might possibly have been some mechanism in R2019b (which you noted as your release), but by R2025a there is no hope.

[DGM]

I didn't even want to open that can of worms, because that's pretty much where I expected things were going.

Answer 1

[Matt J]

This file exchange submission seems to do most of the above,

https://www.mathworks.com/matlabcentral/fileexchange/10867-uipickfiles-uigetfile-on-steroids?s_tid=srchtitle

The last position of the dialog is remembered automatically, and the FilterSpec option can beused ot specify the initial folder path.

[DGM]

It's more of a lateral shift. Current version doesn't work in R2019b, but older versions do. It seems practical path persistence requires an external workaround like I'm already doing. Maybe the "recall" functionality could fill that role to some extent, but that seems to require foresight (but maybe i'm using it wrong). The window geometry is persistent, so that's good. The view sorting isn't persistent, nor are any columns (other than name) actually displayed. It's not really a tabular view with sortable columns; instead it's just a name-list view with buttons for sorting by parameters which are themselves invisible.

It's like a lot of things. It's probably offers certain valuable functionality, but since it eschews common conventions, it's hard to justify when what I want is vanilla. I'm looking for something that makes the uigetfile() dialog behave more like other standard dialogs across other applications. I'm reminded of the time I learned Dvorak for a week.

[Matt J]

Well, I think you will have no choice but to make your own appdesigner app. It seems like something that shouldn't be too hard to do using a uitable, as well as setpref and getpref.

[DGM]

Appdesigner itself doesn't actually work in my environment. That doesn't stop me from programmatically building a UI, but it's probably less convenient than intended.

I'm probably going to focus on an external workaround script. That would have the advantage of working in any older versions I might run. It has the disadvantage of being useless to anyone else though.

[Matt J]

Appdesigner itself doesn't actually work in my environment.

Can't imagine why. It's been around since R2016.

[DGM]

https://www.mathworks.com/support/bugreports/1797911

It's not just appdesigner, and it extends to more than text fields.

[Matt J]

That doesn't stop me from programmatically building a UI, but it's probably less convenient than intended.

Since you have R2019b, you still have GUIDE. I wonder if the text field issue affects that as well. If not, that would give you a better GUI-building alternative than purely programmatic GUI construction.

Answer 2

[DGM]

I just made an embarrassing bash kludge as a workaround. It works good enough for now, but I'm not going to post that mess on the forum. Reimplementing the dialog would be the proper way, but I don't need it that badly, and I can't expect that it'll work for anyone else in newer versions, so the total value is limited.

As a side note, I did notice that in fact uigetfile() did once have the ability to specify the window location. By R2019b, it was mentioned in the synopsis, but had been internally disabled -- or rather, it says it will be "ignored", but it's only safely ignored for certain cases. Otherwise it causes an error instead.

EDIT:

In my testing of my own lazy idea, I discovered several annoyances that limit the practicality of any solution which uses uigetfile() at all.

• I'd prefer to have a tabular view sorted descending by date (so that new items are on top). While I can sort by date, the view only realistically supports ascending sorting by any field. Otherwise, the file/directory precedence is also reversed.
• While the tabular view works on the initial directory displayed in the dialog, navigating to any other directory will change the table width to some arbitrary narrow width which is smaller than even that associated with the default window size. Consequently, one can never actually make use of a larger window.
• The dialog always shows hidden files, and I know of no way to control that. Maybe it could be done by complicating the filter expression, but I haven't figured it out.

So long story short, I can't fix these things with window management or input automation tools. If I want a roughly normal file dialog that has a working tabular view, I'd have to reimplement it. A lot of the underlying tools are in private m-code. That might be of use, though I don't know that I'd bother reimplementing everything (e.g. stuff like default file selection).

As an aside, I don't know why the small-icon view is always so common, unless it's just one of those things that's just "always been that way". I would have expected the waning ubiquity of 8.3 filenames would have made this zig-zag reading task into a universal frustration, but maybe everyone loves doing eyeball gymnastics.