dynamic FileDialog pop-ups considered harmful

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
31 messages Options
12
Reply | Threaded
Open this post in threaded view
|

dynamic FileDialog pop-ups considered harmful

Chris Muller-3
Hi all,

A while back, we introduced a dynamic FileDialog pop-up to Save as... of the world menu.  At first, it seemed like a good thing -- you can save your image in a different directory from within Squeak, cool!, right?

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?

From the users' perspective, the entire Squeak IDE has always operated within and presented only its known, limited sandbox:  vm, sources, image, local-dir, changes, and mc repositories.  Staying within this sandbox has allowed the IDE to simplify a lot of operations.  Whether filing out a single method, change-set, preferences, image, or even versioning an MC package -- it's all (pre)configured so that the user, along with Squeak's IDE, can maintain focus on presiding over the virtual object environment.  No regular IDE usecase has _ever_ bothered the user with information or questions about the world external to that sandbox.

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.  The new FileDialog is good for configuring MC repositories, but I think we should back away from popping it up dynamically from the lower-level IDE operations like Fileouts of code or preferences.  Encouraging users to use Save as... to do configuration could actually be harmful.  Besides that, it's slow.

What do you think?

Best,
  Chris



Reply | Threaded
Open this post in threaded view
|

Re: dynamic FileDialog pop-ups considered harmful

timrowledge


> On 2019-12-26, at 10:48 PM, Chris Muller <[hidden email]> wrote:
>
> Hi all,
>
> A while back, we introduced a dynamic FileDialog pop-up to Save as... of the world menu.  At first, it seemed like a good thing -- you can save your image in a different directory from within Squeak, cool!, right?

Well *I* clearly think so. There are a number of reasons why -
 - when using a package like the all-in-one it is clear that we should not save images back into Macintosh HD?Users/Tim/Documents/Squeak/Squeak-5.2-All-in-one/Contents/Resources where one is rather unlikely to ever find it again. Having a dialogue that makes it easy to save you image in somewhere a little more memorable is a good thing. I suggest that the Resources directory ought  to be read-only.
 - when I build a system like, say, NuScratch, it is nice to have the option to save the image into the place where it needs to go, which is quite probably not where I was working on building it.
 - saving to an arbitrary place using a tolerable directory tree handling UI makes it easy to save even to a different machine, which is a surprisingly frequent useful thing.

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

Umm, actually... before MC became the de facto normal way to save out code, I found it very annoying to not be able to save the file in a chosen place. Enough that I did actually have a filein for ST-80v2 (yes, this was circa 1987) to do the best I could work out to do just that.
These days I posit that a simple fileout is (almost) so rare that we should consider removing it from the menu(s).

>
> From the users' perspective, the entire Squeak IDE has always operated within and presented only its known, limited sandbox:  vm, sources, image, local-dir, changes, and mc repositories.  Staying within this sandbox has allowed the IDE to simplify a lot of operations.  Whether filing out a single method, change-set, preferences, image, or even versioning an MC package -- it's all (pre)configured so that the user, along with Squeak's IDE, can maintain focus on presiding over the virtual object environment.  No regular IDE usecase has _ever_ bothered the user with information or questions about the world external to that sandbox.

I don't see it that way at all. I claim that a lot of it is a combination of history and laziness. The oldest images simply didn't have any widgets to deal with loading or saving files within complex directory trees and so the quick 'save it here' approach was easy, quick to write and bearable. There's also the point that back then(1980-ish)  there weren't really a lot of complex directory trees to worry about and so nobody spent a lot of time caring. It was still somewhat annoying when I was at ParcPlace in the early '90s but the work cycle tended to involve starting a clean image to work on a particular bug, save the resulting changeset, delete the image. Since the changesets usually got named for the bug ID it was acceptable to end up with a pile of tolerably named changeset files in the one directory.
(The irony of working there/then was that a bunch of keen Smalltalkers ended up spending huge amounts of time doing C programming whilst the keen C++ people spent so much of their time writing Smalltalk to make the ObjectWorks-C++ product).

Perhaps some of my opinion/habit comes from 'growing up' using RISC OS where saving files or components or text snippets or images  etc was done with a single simple UI that let you drag the item to wherever you wanted it to go - or simply click 'yes' to let it go to the default. There was no difference from the programming end at all; you call the save widget with some parameters and leave it to the user.

As to specifics of the usability of the saveas dialogue, that's down to 'having' to use the directory tree widget etc. I suspect we could do something much better if we wanted to. The entire approach to the filesystem is in need of repair anyway - we've been hobbled for decades by the API in FilePlugin and the rather limited ansi C file stuff. And it is 'in plan' to try to provide some variety of collapse-to-simple/expand-to-detail as is done in Mac OS and (almost) in Windows. It's just not going to make 5.3 unless somebody works it out very quickly.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Eagles may soar, but weasels aren't sucked into jet engines.



Reply | Threaded
Open this post in threaded view
|

Re: dynamic FileDialog pop-ups considered harmful

Stéphane Rollandin
> These days I posit that a simple fileout is (almost) so rare that we should consider removing it from the menu(s).

Hmm. No. I do it all the time.

Stef

Reply | Threaded
Open this post in threaded view
|

Re: dynamic FileDialog pop-ups considered harmful

timrowledge


> On 2019-12-27, at 1:26 PM, Stéphane Rollandin <[hidden email]> wrote:
>
>> These days I posit that a simple fileout is (almost) so rare that we should consider removing it from the menu(s).
>
> Hmm. No. I do it all the time.

Interesting. Why? When? What do you use the fileouts for? Why not use MC for the job?

I'll admit I'm doing a lot of fileout from browsers and changesets right now but that's because it's VW and it's currently the easiest way to get a mass of code out of VW and into Squeak.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: IA: Illogical And



Reply | Threaded
Open this post in threaded view
|

Re: dynamic FileDialog pop-ups considered harmful

David T. Lewis
In reply to this post by Chris Muller-3
When you are saving something outside of the image, you have to save
"something" and and you have to put it "someplace".  It seems
perfectly reasonable to me to have a dialog that supports this
concept, regardless of the specific details of the host runtime
environment (operating system, web browser, whatever).

Futhermore, the general notion of saving stuff in a hierarchical
organization makes sense. It is a simple and useful strategy that maps
easily to familiar OS file systems. And as a somewhat disorganized
person by nature, I can assure you that a policy of saving too much
stuff all in the same place is not a useful simplification ;-)

Dave


On Fri, Dec 27, 2019 at 12:48:34AM -0600, Chris Muller wrote:

> Hi all,
>
> A while back, we introduced a dynamic FileDialog pop-up to Save as... of
> the world menu.  At first, it seemed like a good thing -- you can save your
> image in a different directory from within Squeak, cool!, right?
>
> 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?
>
> >From the users' perspective, the entire Squeak IDE has always operated
> within and presented only its known, limited sandbox:  vm, sources, image,
> local-dir, changes, and mc repositories.  Staying within this sandbox has
> allowed the IDE to simplify a lot of operations.  Whether filing out a
> single method, change-set, preferences, image, or even versioning an MC
> package -- it's all (pre)configured so that the user, along with Squeak's
> IDE, can maintain focus on presiding over the virtual object environment.
> No regular IDE usecase has _ever_ bothered the user with information or
> questions about the world external to that sandbox.
>
> 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.  The new FileDialog is good for configuring MC repositories, but
> I think we should back away from popping it up dynamically from the
> lower-level IDE operations like Fileouts of code or preferences.
> Encouraging users to use Save as... to do configuration could actually be
> harmful.  Besides that, it's slow.
>
> What do you think?
>
> Best,
>   Chris

>


Reply | Threaded
Open this post in threaded view
|

Re: dynamic FileDialog pop-ups considered harmful

Stéphane Rollandin
In reply to this post by timrowledge
Le 27/12/2019 à 23:57, tim Rowledge a écrit :
>
>
>> On 2019-12-27, at 1:26 PM, Stéphane Rollandin <[hidden email]> wrote:
>>
>>> These days I posit that a simple fileout is (almost) so rare that we should consider removing it from the menu(s).
>>
>> Hmm. No. I do it all the time.
>
> Interesting. Why? When? What do you use the fileouts for? Why not use MC for the job?

MC is overkill for me. I often fork an image for testing stuff, and if I
like the code I load it back in the initial image via fileout. Very
simple, no cognitive overload. BTW I am not suggesting it is a good
practice, only my own workflow.

Stef

Reply | Threaded
Open this post in threaded view
|

Re: dynamic FileDialog pop-ups considered harmful

Jakob Reschke
In reply to this post by Chris Muller-3
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.

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.

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

For example, and to come back to the topic, I would be happy if Squeak would use the save dialog provided by Windows itself. Then I could use Windows libraries, unmounted network shares, file shortcuts, and my favorites list, all without having to maintain code for any of that in Squeak itself (well except for supporting UNC paths and file access concerning those network shares...) Another example of a useful outside service would be the credentials store or some kind of authentication API. All accessible via FFI, sure, but it is no fun (tools to the rescue?). And FFI itself is not even in Trunk, well well...

Kind regards,
Jakob


Reply | Threaded
Open this post in threaded view
|

Re: dynamic FileDialog pop-ups considered harmful

timrowledge


> 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



Reply | Threaded
Open this post in threaded view
|

Re: dynamic FileDialog pop-ups considered harmful

Chris Muller-3
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 <[hidden email]> wrote:


> 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





Reply | Threaded
Open this post in threaded view
|

Re: dynamic FileDialog pop-ups considered harmful

Jakob Reschke
Am So., 29. Dez. 2019 um 07:04 Uhr schrieb Chris Muller <[hidden email]>:
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?

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.

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.
 

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.

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?

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.
 
It's simply too intrusive to impose this one way of working onto all Squeak users.

Giving no choice about the destination file is also taking away another way of working. Just saying...

Kind regards,
Jakob


Reply | Threaded
Open this post in threaded view
|

Re: dynamic FileDialog pop-ups considered harmful

Eliot Miranda-2
In reply to this post by Chris Muller-3
Hi Chris, Hi Tim,

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


> 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






Reply | Threaded
Open this post in threaded view
|

Re: dynamic FileDialog pop-ups considered harmful

K K Subbu
In reply to this post by timrowledge
On 28/12/19 1:54 AM, tim Rowledge wrote:
> As to specifics of the usability of the saveas dialogue, that's down
> to 'having' to use the directory tree widget etc. I suspect we could
> do something much better if we wanted to.

Rather than tie ourselves into Filesystem dialog UIs and get sucked into
debates on native/squeak looks, it would be useful to have proxy objects
around directories and files/symlinks/devices. Suppose we have a
DirectoryProxyMorph[*] reflecting the contents of a host directory, we
can drop our morphs, workspaces etc. into it. We can also drag out
projects/morphs/files into the Squeak World for viewing or editing. This
would be consistent with the overall object model in Squeak.

Even with native file navigators, I tend to bookmark for frequently used
directories and drag from or drop into these bookmarks rather than
navigate the noodle menus ;-). To avoid too many open windows, we could
have a shortcut to re-use the same window while drilling down/up.

[*] most host OSes support FS event notifications for
additions/deletions, so this would be like a proxy rather than a passive
holder.

Regards .. Subbu

Reply | Threaded
Open this post in threaded view
|

Re: dynamic FileDialog pop-ups considered harmful

timrowledge
In reply to this post by Chris Muller-3


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


Reply | Threaded
Open this post in threaded view
|

Re: dynamic FileDialog pop-ups considered harmful

timrowledge
In reply to this post by K K Subbu


> On 2019-12-29, at 7:27 AM, K K Subbu <[hidden email]> wrote:
>
> On 28/12/19 1:54 AM, tim Rowledge wrote:
>> As to specifics of the usability of the saveas dialogue, that's down
>> to 'having' to use the directory tree widget etc. I suspect we could
>> do something much better if we wanted to.
>
> Rather than tie ourselves into Filesystem dialog UIs and get sucked into debates on native/squeak looks, it would be useful to have proxy objects around directories and files/symlinks/devices.

Adding drag/drop handling to more tools would provide a lot of such functionality. Having a UI item that is an interface to a single directory instead of having to use an entire FileBrowser would be nice.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Forgot to pay his brain bill.



Reply | Threaded
Open this post in threaded view
|

Re: dynamic FileDialog pop-ups considered harmful

Eliot Miranda-2
In reply to this post by timrowledge
Hi Tim,

On Sun, Dec 29, 2019 at 11:40 AM tim Rowledge <[hidden email]> wrote:


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

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; [hidden email]; http://www.rowledge.org/tim
atheism: not a religion, more a personal relationship with reality.




--
_,,,^..^,,,_
best, Eliot


Reply | Threaded
Open this post in threaded view
|

Re: dynamic FileDialog pop-ups considered harmful

timrowledge


> 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!"



Reply | Threaded
Open this post in threaded view
|

Re: dynamic FileDialog pop-ups considered harmful

Nicolas Cellier


Le dim. 29 déc. 2019 à 23:35, tim Rowledge <[hidden email]> a écrit :


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

I hope it does not ask anymore to insert a floppy in drive A: ;)

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!"





Reply | Threaded
Open this post in threaded view
|

Re: dynamic FileDialog pop-ups considered harmful

timrowledge


> On 2019-12-29, at 2:50 PM, Nicolas Cellier <[hidden email]> wrote:
>
>
>
> Le dim. 29 déc. 2019 à 23:35, tim Rowledge <[hidden email]> a écrit :

>  Some OS (I'm giving you the stink-eye here, Windows 10) having very strange ideas about directory layouts and names and so forth.
>
> I hope it does not ask anymore to insert a floppy in drive A: ;)

Not even Windows does that any more.

A really, really, stupid case was actually the responsibility of RISC OS back around, ooh, 1998 or so. Because of the way RISC OS works you simply never expect to do things like 'find all root discs and give me a list'. So to implement the directory contents prim for an empty name - the escape case for 'find all root discs' back then - I had to test all known filing systems (which included CD, floppies, networks, fax, and several other virtual filing system plugins) to see if they had any content. Which in the case of the floppy and cd drives could take 5-10 seconds. Sigh.

What Windows 10 does is at least as insane though.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
"Bother" said Pooh as "Formating Drive C" appeared on the screen...



Reply | Threaded
Open this post in threaded view
|

Re: dynamic FileDialog pop-ups considered harmful

Jakob Reschke
Am Mo., 30. Dez. 2019 um 01:19 Uhr schrieb tim Rowledge <[hidden email]>:

What Windows 10 does is at least as insane though.

At the risk of side-tracking the thread: I'm curious, what is so insane about dealing with directory listings in Windows 10?


Reply | Threaded
Open this post in threaded view
|

Re: dynamic FileDialog pop-ups considered harmful

timrowledge


> On 2019-12-29, at 4:24 PM, Jakob Reschke <[hidden email]> wrote:
>
> Am Mo., 30. Dez. 2019 um 01:19 Uhr schrieb tim Rowledge <[hidden email]>:
>
> What Windows 10 does is at least as insane though.
>
> At the risk of side-tracking the thread: I'm curious, what is so insane about dealing with directory listings in Windows 10?

Trying to keep it brief - have you noticed how things like C: and 'home' and 'Roaming' etc are all mixed up?


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- His spirit guide is a three-toed sloth.



12