dynamic FileDialog pop-ups considered harmful

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.

> On 2019-12-28, at 7:44 AM, Jakob Reschke <[hidden email]> 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 <[hidden email]>:
>
> 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; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: BGL: Branch and Goto Lunch

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.

It's simply too intrusive to impose this one way of working onto all Squeak users.

> On 2019-12-28, at 10:03 PM, Chris Muller <[hidden email]> wrote:
>
>  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.

Well, let's measure it. On My Pi3, probably the slowest machine regularly running Squeak, with about 10% of the performance of a typical laptop of the last 5 years. That way we'll get an idea of how terribly slow it is to open a complex dialogue like the FileSaverDialogue.

With a little whacking to make a suitable method that sidesteps having to actually interact with it before getting a time worked out, it turns out that it takes 170ms to create, open, and display the dialogue. On a typical laptop I'd expect around 20ms - or about a single frame refresh cycle. I won't even bother to measure the time it takes for the plain old FillInTheBlank because it can't be less than that in a Morphic world unless one has fiddled with the cycle rate. Oh hell, let's measure it anyway - 115mS on the same machine.

So to save an image with a new name via the UI, a not common activity but one that would typically involve wanting to at least see some reminders of what image names are in use in the current directory so as to not accidentally over-write them, or to save to a different directory, the new dialogue adds *no* visible time to open and no extra clicks. You still have to type any new name just as before. It simply provides more information and user action choice.

For saving preferences - again a not-common activity, and in any case one where you've mentioned an altogether different approach - using the FileSaverDialogue clearly adds some time over simply clicking on a button. However, I claim that it adds utility by providing a UI route to choosing where you save said preferences. That means one can keep a single (or several if that be ones desire) preferences file to share between images kept in different places or different machines. And if the general view is that it is better to be restricted to the preferences file always being 'my.prefs' in the image directory and having to manually find and copy it to any other directory where one has an image - well I don't care since it was a suggestion based on 5 minutes work.

For handling fileouts from a browser it doesn't bother me personally because I so rarely do that that I haven't noticed. I think it's fairly poor UI in general to only allow saving some item in one place under one name. It's especially stinks in the context of a deep and rather opaque context like the all-in-one directory tree. A simplistic (but I think bad) option would be to have two menu options
file out
fileout as...
.. since we already have way too many items bundled up in poorly laid out menus.

I'm not seeing any cases where I'd expect any terrifying interruption of mental state. The only case mentioned so far where one might be wanting to rapidly click-click-click would be filing out a bunch of items in a browser - I suppose one might be quickly clicking on a bunch of methods/classes and hitting menu->fileout repetitively? In which scenario there is plenty of UI interaction already getting in the way and there must be much, much, better ways to do the job. At the very least we ought to be able to multi-select browser list items to improve that sort of action. Or provide drag/drop to a filelist?

All in all I'm having a lot of trouble seeing where there is a problem. Clearly I need simpler explanations of the issue in order to comprehend it.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
atheism: not a religion, more a personal relationship with reality.

> On 2019-12-29, at 12:45 PM, Eliot Miranda <[hidden email]> wrote:
>
> That's not a valid comparison.  You're looking at a small machine with a very small file system.  You need o run it on a large machine with a very full filesystem.  The time taken isn't dependent on the speed of the machine, but dominated by the amount of files and directories examined.

Mmm... ok, the file directory scanning for the tree view is certainly horribly horrible. The most complex one I have to hand is my iMac, using an image within a bundle; that's a bunch of layers down in some relatively big directories and is essentially instant.

The current algorithm for generating the directory tree does some extraordinary hoop-jumping that must surely be improvable.
 - it gets a listing of the root directory's subdirectories and wraps each one in a complex Morph
 - it builds a list of the directories in the path to the current image directory keeping the full pathname of each for some reason
 - it finds the first root directory subdirectory morph and scans from there through its siblings to find the first one with a name suitably matching the first thing in the above directory pathname list
 - which it expands
 - which causes it to list all the subdirectories  and so on until the list of directory pathnames is exhausted

So at least it doesn't read the name and path of every file in the entire universe.
It *does* add in the names of any cached known servers (which I've mentioned several times is very out of date and in need of flushing). It does use the possibly wasteful FileDirectory>>#directoryNames that reads every name in the directory and test every one for directory-ness; surely there are faster approaches for most OSs? It does rely on assumptions about root directories, which we can blame on the generally inadequate filesystem code. Some OS (I'm giving you the stink-eye here, Windows 10) having very strange ideas about directory layouts and names and so forth.

A very deep directory tree above your image directory will add time, as will any of those directories being very large. We could certainly design a faster approach to building a useful directory display for the typical purposes a FileDialog is useful for; the current one simply reuses the stuff in the FileBrowser.

But I claim that for occasional use UI such as finding a new place/name to save you image, or your preferences, or  whatever, that anything less than half a second is effectively instant to human perception. Unless perhaps you are a dyed in the wool twitch-gamer with perceptual reflexes tuned to microseconds in preparation for being beamed up by the alien visitors that need your mind to fight a galactic war.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Klingon Code Warrior:- 2) "My program has just dumped Stova Core!"

What Windows 10 does is at least as insane though.