Hi Chris, Hi Tim,

> On Dec 28, 2019, at 10:04 PM, Chris Muller <asqueaker at gmail.com> wrote:
> 
> 
> Thanks for all the feedback folks, we're of course in agreement that:
> 
>      > As the user of both the external world and the Squeak world *I* want to preside over all those objects.
> 
> it's just that there is more than one time, place, and way to do that.  We're talking about IDE design, not the ABILITY to interface to the outside world, which we're all already are doing in our own various ways.  That's why I was hoping you would share your thoughts on the opening question I invited everyone to evaluate deeply:
> 
> > 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?
> 
> 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.
> 
> 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.  Seriously, interjecting a mandatory modal popup every time there's any interaction with the file system?  Tim, I find it incredible that you feel this is "low impact".  Dude, it's even emperically measurable along dimensions of user wait-time!  Liken to booting up phreaking windows, a solid HD light, chunking away, as I wait for my golden opportunity to... wait for it...  get ready to do same slavish response to the computers bidding as everyone else 99.999999999999% of the time with this function... wait for it.... -- NOW! smack that darn OK button!  Train-of-thought, obliterated!  :/ It's simply too intrusive to impose this one way of working onto all Squeak users.

Then the issue is *not* having a custom file dialogue.  The issue is that the dialogue is badly engineered (not Tim’s fault; this is history) because it tries to compute a snapshot of the user’s entire directory tree at startup instead of just the current directory, subdirectories in it, path to the home directory.  So what we need is to reengineer so that the model of the file system displayed in the dialog’s directory hierarchy starts off being local and lazily expands as one explores the file system using the dialogue.

I’m with Stéphane in finding a file dialog essential.  I use Monticello and I also use the refactoring and rewrite engines, but I also edit Smalltalk files (I even have a shell script that inserts up-to-date time stamps into a source file) because sometimes that’s a very quick way if getting done code fixed or generated. I also use compile:classified: and Smalltalk.  Which ever took us right for the job.  And a good file dialogue is an essential tool.  Tim did a great job revamping the dialog. Can we help in improving if further?  Let’s not throw the baby out with the bath water.

> 
> Please don't put Preferences-tpr. into trunk, I'm sure we can find a more optimized solution to your need.  One idea is a "Show my.prefs in FileBrowser" button (or whatever) that opens up Squeak's FileBrowser with my.prefs *pre-selected* for you.  You could then copy/move/rename easily to your hearts content.  In fact, doesn't FileBrowser even let you save your "favorite" directories?  Imagine not having to navigate those directory trees!  Also, you would have access to cut-and-paste the full path, unlike with your modal one currently.  It's a fundamentally more-powerful tool for what you're trying to do, we can still keep Squeak's toll-free highways we've enjoyed all these years.
> 
> Best,
>   Chris
> 
> 
> 
> 
>> On Sat, Dec 28, 2019 at 12:39 PM tim Rowledge <tim at rowledge.org> wrote:
>> 
>> 
>> > On 2019-12-28, at 7:44 AM, Jakob Reschke <forums.jakob at resfarm.de> wrote:
>> > 
>> > Hi everyone,
>> > 
>> > In my opinion Squeak should not neglect the outside world as a data dump.
>> > 
>> > Am Fr., 27. Dez. 2019 um 07:49 Uhr schrieb Chris Muller <asqueaker at gmail.com>:
>> > 
>> > IMO, the external world (OS, etc.) should preside over its own objects, just as Squeak's IDE should, over its, to each the maximum degrees possible.
>> > 
>> > As the user of both the external world and the Squeak world *I* want to preside over all those objects. The bounds of both systems are arbitrary to me. To achieve some kind of integration, Squeak should be able to view the outside and work with it in a reasonable, open-minded fashion. Either by providing good tools to deal with the outside world or by providing and implementing the proper interfaces of the outside world.
>> 
>> I agree with that sentiment. 
>> 
>> > 
>> > About those interfaces with the outside world and insular software:
>> > Windows has a nice object-oriented shell concept, but so few applications integrate properly. The shell objects, mostly files, could have many useful verbs (messages) in the context menu, provided by non-Microsoft software, or generously implemented drag and drop handlers, or send-to targets. TortoiseSVN and TortoiseGit are fine examples: they add version control verbs to every file you can browse. They might not be the best or most efficient Subversion or Git clients out there, but in my opinion they are the only ones true to the spirit of the Windows shell. But for almost all file types and software you are supposed to "Open" the file and then endulge yourself confined in the application that opens the file.
>> 
>> A practical problem with most OS's and connecting to other applications is that it seems to have become extremely painful to drive one application from another. And the choice of doing everything through a tiny lens of 'file' makes it a bit more painful to me.
>> 
>> > 
>> > About Squeak as such insular software:
>> > Today vanilla Squeak does not care all that much about the outside world or integrating with it. The border of the window provided by the VM is like a magical veil you cannot cross except by arcane ways (FFI) or with the wisdom to shape the universe (extending the VM, instead of the image).
>> 
>> Well we did try to make both of those as easy as practical. The FFI stuff is a pretty good (very) low-level interface to anything that also works via system calls etc. I dare say there  are ways it could be made faster and easier. Start a project to find them!
>> 
>> > The drag and drop implementation with the outside world is very limited (cannot drag anything to the outside, cannot accept anything specific in an application that lives inside) and nice services that live outside are seldom used.
>> 
>> I *think* that any morph can test and choose to accept a drop from outside? Starting a drag within Squeak and making it work to drop outside ... don't think I've seen that worked on. Again, RISC OS is the absolute champion for that approach to UI.
>> 
>> > 
>> > For example, and to come back to the topic, I would be happy if Squeak would use the save dialog provided by Windows itself. 
>> 
>> That is something that ought to be doable and would have a lot of value for many projects. VW does it so far as I can see. The trick is deciding what parts of the user experience you want to control (in order to do special things the host UI doesn't do, for example) and which you want to delegate to the host UI - and when, and how to accommodate both cases and ost of all, how to find the time to work it out.
>> 
>> 
>> tim
>> --
>> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
>> Strange OpCodes: BGL: Branch and Goto Lunch
>> 
>> 
>> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20191229/3a474f22/attachment.html>