A big thank you to whoever made the tree in FileList display in alphabetical order

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

A big thank you to whoever made the tree in FileList display in alphabetical order

Squeak - Dev mailing list
+!



Reply | Threaded
Open this post in threaded view
|

Re: A big thank you to whoever made the tree in FileList display in alphabetical order

fniephaus
Here's the commit:
http://forum.world.st/The-Trunk-Tools-tpr-980-mcz-td5118919.html

On Mon, Jul 20, 2020 at 8:03 PM gettimothy via Squeak-dev
<[hidden email]> wrote:
>
> +!
>
>

Reply | Threaded
Open this post in threaded view
|

Re: A big thank you to whoever made the tree in FileList display in alphabetical order

Squeak - Dev mailing list
Thank you! And thank you TPR!


---- On Wed, 22 Jul 2020 05:33:48 -0400 [hidden email] wrote ----

Here's the commit:
http://forum.world.st/The-Trunk-Tools-tpr-980-mcz-td5118919.html

On Mon, Jul 20, 2020 at 8:03 PM gettimothy via Squeak-dev
<[hidden email]> wrote:
>
> +!
>
>




Reply | Threaded
Open this post in threaded view
|

FileList improvements (was Re: A big thank you to whoever made the tree in FileList display in alphabetical order)

timrowledge


> On 2020-07-22, at 5:51 AM, gettimothy via Squeak-dev <[hidden email]> wrote:
>
> Thank you! And thank you TPR!

You're welcome.

I'm thinking maybe an option to show/hide hidden files might be useful at some point too.

And we still need to do something about better handling of remote servers; ftp isn't the best supported option anymore, the UI for dealing with adding/editing/removing them is terrible and our example servers are long evaporated.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
I'm so skeptical that I'm not sure I'm really a skeptic



Reply | Threaded
Open this post in threaded view
|

Re: FileList improvements (was Re: A big thank you to whoever made the tree in FileList display in alphabetical order)

Chris Muller-3
Please don't take this personally, I'd really like to see an option to turn it off.  I really miss the plain, blazing-fast text box which let me begin typing immediately, let me cut and paste fully-qualified names, and literally, was a 10X faster workflow for the operations that now involve being forced to navigate a tree, click-by-click, intermixed with scrolling and visually scanning with my tired, bloodshot eyes.  Operations like "image save as..." or "add repository..." went from < 1 second with no disruption in thought, to > 10 seconds for it to put up the big dialog I don't want to see at all because it almost always leaves me at... "umm..  what was I doing..?"

 - Chris

On Wed, Jul 22, 2020 at 12:44 PM tim Rowledge <[hidden email]> wrote:


> On 2020-07-22, at 5:51 AM, gettimothy via Squeak-dev <[hidden email]> wrote:
>
> Thank you! And thank you TPR!

You're welcome.

I'm thinking maybe an option to show/hide hidden files might be useful at some point too.

And we still need to do something about better handling of remote servers; ftp isn't the best supported option anymore, the UI for dealing with adding/editing/removing them is terrible and our example servers are long evaporated.


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
I'm so skeptical that I'm not sure I'm really a skeptic





Reply | Threaded
Open this post in threaded view
|

Re: FileList improvements (was Re: A big thank you to whoever made the tree in FileList display in alphabetical order)

timrowledge


> On 2020-07-22, at 6:38 PM, Chris Muller <[hidden email]> wrote:
>
> Please don't take this personally, I'd really like to see an option to turn it off.  I really miss the plain, blazing-fast text box which let me begin typing immediately, let me cut and paste fully-qualified names, and literally, was a 10X faster workflow for the operations that now involve being forced to navigate a tree, click-by-click, intermixed with scrolling and visually scanning with my tired, bloodshot eyes.  Operations like "image save as..." or "add repository..." went from < 1 second with no disruption in thought, to > 10 seconds for it to put up the big dialog I don't want to see at all because it almost always leaves me at... "umm..  what was I doing..?"

Feel free to add a preference if you feel you must. But note that on a Pi - the slowest machines in regular use with Squeak -  it takes less than 1 tenth of a second to open the image-save-as dialogue, so if your machine is taking even close to 10 seconds there is something interestingly weird going on and we need to profile it to find out why.

Also, simply type a file path in the text box and return. It even does the #assureExistence checks to make sure the path exists. Or use no path and it will save in the same directory it came from. Or paste that stuff in as before. It all still works.

Also, strictly speaking, gettimothy was referring to the FileList anyway...

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: DPC: Double Precision Crash



Reply | Threaded
Open this post in threaded view
|

Re: FileList improvements (was Re: A big thank you to whoever made the tree in FileList display in alphabetical order)

Chris Muller-3
Feel free to add a preference if you feel you must.

Thanks since I know you don't care to have more preferences, but a "Sandbox Mode" will be needed for the Dynabook experience.
 
But note that on a Pi - the slowest machines in regular use with Squeak -  it takes less than 1 tenth of a second to open the image-save-as dialogue, so if your machine is taking even close to 10 seconds there is something interestingly weird going on and we need to profile it to find out why.

It depends on how many and how deep the directories you have, and what kind of HD they're on.  But another few seconds quickly accumulates simply from having to grab the mouse just to regain focus on the field where I can type the filename.  Even with my change which centers that field under the hand, there's another "feature" which ensures dialogs are always, fully, 100% on-screen.  So, the focus is lost.  It was trying to be friendly, but I just wanted to paste in the name and be done.
 
Also, simply type a file path in the text box and return. It even does the #assureExistence checks to make sure the path exists. Or use no path and it will save in the same directory it came from. Or paste that stuff in as before. It all still works.

Good to know!
 
Also, strictly speaking, gettimothy was referring to the FileList anyway...

The alphabetization was a very overdue improvement, thanks.

 - Chris


Reply | Threaded
Open this post in threaded view
|

Re: FileList improvements (was Re: A big thank you to whoever made the tree in FileList display in alphabetical order)

timrowledge


On 2020-07-23, at 8:36 PM, Chris Muller <[hidden email]> wrote:

It depends on how many and how deep the directories you have, and what kind of HD they're on.

Yes, I guess the directory tree traversing might take a long time in some cases; which in itself is probably sometihng deserving some profiling. Also one might consider a better navigation idiom than the rather (over, in my opinion) extensive "all the subdirectories of my parent directory and up we go" approach. It is (was) a *major* pain for RISC OS because of the expectation of multiple filing systems related to devices that have to try to spin up CDs etc just to decide whether there is a root there. But that just opens up a long complaint about the appalling state of filename handling.

 But another few seconds quickly accumulates simply from having to grab the mouse just to regain focus on the field where I can type the filename.

The keyboard focus is in the text field immediately the dialogue is opened, so that ought not be a problem. I guess if it really has taken multiple seconds to build the directory tree morph then one might have moved the mousse around in that time and changed that?

The thing that I suspect would make a lot of people happy and have uses in many dialogue related situations is the building of a collapsing dialogue section. We had some discussion of the idea a while back and Marcel tried a few ideas. The dialogue ought to open with a label, the text field and an 'click me for more' icon - something vaguely like this -
Clicking the down-caret would open it up to a full directory handling tree widget. I believe this would be a major improvement.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Fractured Idiom:- HASTE CUISINE - Fast French food




Reply | Threaded
Open this post in threaded view
|

Re: FileList improvements (was Re: A big thank you to whoever made the tree in FileList display in alphabetical order)

David T. Lewis
On Fri, Jul 24, 2020 at 12:04:01PM -0700, tim Rowledge wrote:

>
>
> > On 2020-07-23, at 8:36 PM, Chris Muller <[hidden email]> wrote:
> >
> > It depends on how many and how deep the directories you have, and what kind of HD they're on.
>
> Yes, I guess the directory tree traversing might take a long time in some cases; which in itself is probably sometihng deserving some profiling. Also one might consider a better navigation idiom than the rather (over, in my opinion) extensive "all the subdirectories of my parent directory and up we go" approach. It is (was) a *major* pain for RISC OS because of the expectation of multiple filing systems related to devices that have to try to spin up CDs etc just to decide whether there is a root there. But that just opens up a long complaint about the appalling state of filename handling.
>
> >  But another few seconds quickly accumulates simply from having to grab the mouse just to regain focus on the field where I can type the filename.
>
> The keyboard focus is in the text field immediately the dialogue is opened, so that ought not be a problem. I guess if it really has taken multiple seconds to build the directory tree morph then one might have moved the mousse around in that time and changed that?
>

+1 for profiling.

-1 for more preferences.


> The thing that I suspect would make a lot of people happy and have uses in many dialogue related situations is the building of a collapsing dialogue section. We had some discussion of the idea a while back and Marcel tried a few ideas. The dialogue ought to open with a label, the text field and an 'click me for more' icon - something vaguely like this -
>
> Clicking the down-caret would open it up to a full directory handling tree widget. I believe this would be a major improvement.
>

That looks like a good approach.

Dave


Reply | Threaded
Open this post in threaded view
|

Re: FileList improvements (was Re: A big thank you to whoever made the tree in FileList display in alphabetical order)

Chris Muller-4
In reply to this post by timrowledge
It depends on how many and how deep the directories you have, and what kind of HD they're on.

Yes, I guess the directory tree traversing might take a long time in some cases; which in itself is probably sometihng deserving some profiling.

My understanding is it's a VM issue.
 
Also one might consider a better navigation idiom than the rather (over, in my opinion) extensive "all the subdirectories of my parent directory and up we go" approach. It is (was) a *major* pain for RISC OS because of the expectation of multiple filing systems related to devices that have to try to spin up CDs etc just to decide whether there is a root there. But that just opens up a long complaint about the appalling state of filename handling.

+1
 

 But another few seconds quickly accumulates simply from having to grab the mouse just to regain focus on the field where I can type the filename.

The keyboard focus is in the text field immediately the dialogue is opened, so that ought not be a problem. I guess if it really has taken multiple seconds to build the directory tree morph then one might have moved the mousse around in that time and changed that?

It's because I use mouseOverForKeyboardFocus.  The dialog doesn't always open with the text field under hand, so initial focus is lost.
 
The thing that I suspect would make a lot of people happy and have uses in many dialogue related situations is the building of a collapsing dialogue section. We had some discussion of the idea a while back and Marcel tried a few ideas. The dialogue ought to open with a label, the text field and an 'click me for more' icon - something vaguely like this -
Clicking the down-caret would open it up to a full directory handling tree widget. I believe this would be a major improvement.

I know that's the conventional look for "apps" that use files as their only storage, but would you be open to considering a more "Squeak-style" approach?  What if the regular text menu could have a "select file or directory" entry added to it?  So it would be available _everywhere_ in the IDE.  This "Squeak-style" approach preserves its sandbox capability modelessly (e.g., without needing a preference), while still providing developers that flexible hook for launching your dialog to select and paste fully-qualified names, anywhere.

Unfortunately, Marcel concluded that ToolBuilder can't open a modal upon a modal without at least hacking (that's paraphrased, BTW).  If Marcel's finding is true, at least there's always the single-field text box as a preference.

 - Chris
 


Reply | Threaded
Open this post in threaded view
|

Re: FileList improvements (was Re: A big thank you to whoever made the tree in FileList display in alphabetical order)

David T. Lewis
On Fri, Jul 24, 2020 at 03:23:20PM -0500, Chris Muller wrote:

> >
> > It depends on how many and how deep the directories you have, and what
> > kind of HD they're on.
> >
> >
> > Yes, I guess the directory tree traversing might take a long time in some
> > cases; which in itself is probably sometihng deserving some profiling.
> >
>
> My understanding is it's a VM issue.
>

Perhaps someone with a real-world use case could run a profiler on it and
find out where the time is going? It is sure to be dependent on the file
systems and operating systems and networks involved, so it might be quite
helpful to see the profile for a case where the system is behaving badly.

Dave


Reply | Threaded
Open this post in threaded view
|

Re: FileList improvements (was Re: A big thank you to whoever made the tree in FileList display in alphabetical order)

timrowledge
In reply to this post by Chris Muller-4


> On 2020-07-24, at 1:23 PM, Chris Muller <[hidden email]> wrote:
>
>>  But another few seconds quickly accumulates simply from having to grab the mouse just to regain focus on the field where I can type the filename.
>
> The keyboard focus is in the text field immediately the dialogue is opened, so that ought not be a problem. I guess if it really has taken multiple seconds to build the directory tree morph then one might have moved the mousse around in that time and changed that?
>
> It's because I use mouseOverForKeyboardFocus.  The dialog doesn't always open with the text field under hand, so initial focus is lost.

Oh, well I don't use that option because it drives me nuts, so obviously I won't see that issue.

So, what actually happens when you go for a 'save as'? Somewhere you are triggering it, presumably from the dock or the World menu? What happens that makes it problematic?

> I know that's the conventional look for "apps" that use files as their only storage, but would you be open to considering a more "Squeak-style" approach?  

I'm open to anything that makes it really easy to get people to save a freshly opened new image under a new name and (generally because of the way the all-in-one etc work right now) in a new directory. That was the driving intent that lead me to make the new file dialogues, though I claim they have plenty of other uses.

In a properly thought out GUI (*couch*RISC OS*cough*) the idiom would be to have a tiny file save dialogue with a text field, yes/no buttons and a draggable icon that you drag to any filer anywhere on the systm. That works brilliantly to handle saving to files, other machines, remote sites, printers, fax machines (yes, you could try faxing an application), compression utilities, other applications, all in a perfectly uniform manner. Why did nobody else steal this brilliant idea?


> What if the regular text menu could have a "select file or directory" entry added to it?  So it would be available _everywhere_ in the IDE.  This "Squeak-style" approach preserves its sandbox capability modelessly (e.g., without needing a preference), while still providing developers that flexible hook for launching your dialog to select and paste fully-qualified names, anywhere.

I'd need some more explanation for that. What would the workflow for it be? Do we want still more entries in menus all over the place (because to be honest I think we need some serious trimming of menus combined with making proper use of hierarchical menus) or am I misunderstanderising?


tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Borrow money from pessimists--they don't expect it back.