> On 2019-12-26, at 10:48 PM, Chris Muller <asqueaker at gmail.com> wrote:
> 
> Hi all,
> 
> A while back, we introduced a dynamic FileDialog pop-up to Save as... of the world menu.  At first, it seemed like a good thing -- you can save your image in a different directory from within Squeak, cool!, right?

Well *I* clearly think so. There are a number of reasons why - 
 - when using a package like the all-in-one it is clear that we should not save images back into Macintosh HD?Users/Tim/Documents/Squeak/Squeak-5.2-All-in-one/Contents/Resources where one is rather unlikely to ever find it again. Having a dialogue that makes it easy to save you image in somewhere a little more memorable is a good thing. I suggest that the Resources directory ought  to be read-only.
 - when I build a system like, say, NuScratch, it is nice to have the option to save the image into the place where it needs to go, which is quite probably not where I was working on building it.
 - saving to an arbitrary place using a tolerable directory tree handling UI makes it easy to save even to a different machine, which is a surprisingly frequent useful thing.

> 
> So, why, when we use "fileOut" on the methods menu, don't we want to put up this dialog?  Something doesn't feel right about that, right?

Umm, actually... before MC became the de facto normal way to save out code, I found it very annoying to not be able to save the file in a chosen place. Enough that I did actually have a filein for ST-80v2 (yes, this was circa 1987) to do the best I could work out to do just that.
These days I posit that a simple fileout is (almost) so rare that we should consider removing it from the menu(s).

> 
> From the users' perspective, the entire Squeak IDE has always operated within and presented only its known, limited sandbox:  vm, sources, image, local-dir, changes, and mc repositories.  Staying within this sandbox has allowed the IDE to simplify a lot of operations.  Whether filing out a single method, change-set, preferences, image, or even versioning an MC package -- it's all (pre)configured so that the user, along with Squeak's IDE, can maintain focus on presiding over the virtual object environment.  No regular IDE usecase has _ever_ bothered the user with information or questions about the world external to that sandbox.

I don't see it that way at all. I claim that a lot of it is a combination of history and laziness. The oldest images simply didn't have any widgets to deal with loading or saving files within complex directory trees and so the quick 'save it here' approach was easy, quick to write and bearable. There's also the point that back then(1980-ish)  there weren't really a lot of complex directory trees to worry about and so nobody spent a lot of time caring. It was still somewhat annoying when I was at ParcPlace in the early '90s but the work cycle tended to involve starting a clean image to work on a particular bug, save the resulting changeset, delete the image. Since the changesets usually got named for the bug ID it was acceptable to end up with a pile of tolerably named changeset files in the one directory. 
(The irony of working there/then was that a bunch of keen Smalltalkers ended up spending huge amounts of time doing C programming whilst the keen C++ people spent so much of their time writing Smalltalk to make the ObjectWorks-C++ product).

Perhaps some of my opinion/habit comes from 'growing up' using RISC OS where saving files or components or text snippets or images  etc was done with a single simple UI that let you drag the item to wherever you wanted it to go - or simply click 'yes' to let it go to the default. There was no difference from the programming end at all; you call the save widget with some parameters and leave it to the user.

As to specifics of the usability of the saveas dialogue, that's down to 'having' to use the directory tree widget etc. I suspect we could do something much better if we wanted to. The entire approach to the filesystem is in need of repair anyway - we've been hobbled for decades by the API in FilePlugin and the rather limited ansi C file stuff. And it is 'in plan' to try to provide some variety of collapse-to-simple/expand-to-detail as is done in Mac OS and (almost) in Windows. It's just not going to make 5.3 unless somebody works it out very quickly.


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Eagles may soar, but weasels aren't sucked into jet engines.