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.

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/b2b7479b/attachment.html>