<div dir="ltr"><div dir="ltr">Am So., 29. Dez. 2019 um 07:04 Uhr schrieb Chris Muller <<a href="mailto:asqueaker@gmail.com">asqueaker@gmail.com</a>>:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">That's why I was hoping you would share your thoughts on the opening question I invited everyone to evaluate deeply:<br></div><div dir="ltr"><div><div><br></div><div>> 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?</div></div></div></div></blockquote><div><br></div><div>I don't usually fileOut so I don't really care about this particular interaction. But I do know that VA Smalltalk lets you choose the destination file every time you file out code. To me this appears to be the natural way. In Squeak it has been different for all these years, so you are used to the current way and it has become your preferred workflow. Newcomers might wonder "where did the file go?" or even "what happened at all?" if they are not prompted for the file out location. Which way is better is certainly a matter of preference.</div><div><br></div><div>Similar problem: in a web browser, where to put the downloaded files? Do you want to have them all in the Downloads folder? Or do you want a prompt each time? I use the prompt because otherwise I would have to fire up another file manager, go to downloads, then move the file to the place where I actually want it. I believe most people rather use the default folder. There is a preference to change this, and the default folder path, and having the choice is the right way to go about this in my opinion. I won't advocate to change fileOut behavior because as I said I don't use it anyway.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div><div><br></div><div>Apply the right tool to the right job, at the right place so that user performance with the IDE can be optimized across  dimensions of not just "flexibility," but speed and **different ways of working**.  Some of us prefer to "interface to the outside world" via one-click build, config, and deployment tools which may or may not be written in Squeak.  We stay fast and optimized in the sandbox until the time to interface.  Less-serious projects might simply want to use Squeak's built-in FileBrowser to move files or directories around in the external world, to do their configuring.</div><div><br></div><div>The point is, there other ways of copying and moving your files where you want than erecting toll-booth stops for everyone all over the IDE. </div></div></div></div></blockquote><div><br></div><div>If you go this all the way, and file management is the responsibility of other programs, then there should be no Save As for the image at all. Rather the user should copy the image before saving the "fork" to the original image. Or it would be only a prompt for the file name and the primary action is rather "change the name under which the image will be saved". Except for the wording, was it that way before?</div><div><br></div><div>Being used to save dialogs in other applications, a simple string prompt might be regarded as a cheap workaround by some, even though it might be the most efficient solution. Also a save dialog is also a file name prompt, but with some extra widgets in it, so having the full dialog should not be a drawback.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div><div>It's simply too intrusive to impose this one way of working onto all Squeak users.</div></div></div></div></blockquote><div><br></div><div>Giving no choice about the destination file is also taking away another way of working. Just saying...</div><div><br></div><div>Kind regards,</div><div>Jakob</div></div></div>