Hi Tim,

On Sun, Dec 29, 2019 at 11:40 AM tim Rowledge <tim at rowledge.org> wrote:

>
>
> > On 2019-12-28, at 10:03 PM, Chris Muller <asqueaker at gmail.com> 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.
>

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.


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.
>

Find the machine with the largest file system you can find, full of files
and directories, and try it there-on.


>
> tim
> --
> tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
> atheism: not a religion, more a personal relationship with reality.
>
>
>

-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20191229/86c69923/attachment.html>