dynamic FileDialog pop-ups considered harmful
Locked
12
12
Re: dynamic FileDialog pop-ups considered harmful
 
|
Do you mean all the kinds of top-level items and the ones under "This PC" in Windows Explorer? Does it impact the tool in Squeak (i. e. reflect on the listing API) or are you simply not fond of the user experience in Windows's own applications? :-) Am Mo., 30. Dez. 2019 um 01:27 Uhr schrieb tim Rowledge <[hidden email]>:
|
Re: dynamic FileDialog pop-ups considered harmful
|
|
> On 2019-12-29, at 4:35 PM, Jakob Reschke <[hidden email]> wrote: > > Do you mean all the kinds of top-level items and the ones under "This PC" in Windows Explorer? Does it impact the tool in Squeak (i. e. reflect on the listing API) or are you simply not fond of the user experience in Windows's own applications? :-) Yes, and no idea because I avoid using windows like a plague. I've had to use it a bit recently for VW work. Horrible experience. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Borrow money from pessimists--they don't expect it back. |
Re: dynamic FileDialog pop-ups considered harmful
|
|
In reply to this post by Jakob Reschke
It already got side-tracked from the original topic of IDE design, which was my fault for bringing up the secondary topic of performance. It's okay, we did cover the primary issue which is usability of the modal popup design. I actually love Subbu's angle of thinking about it, and our system could do it. THAT is what we should do (or something like it, we're up to three proposals now). Squeak's IDE should present that it understands core competencies of development, and LEAD users by not offering haphazard ways to do configuration management, e.g., "Save as...". Ultimately it's a path to nowhere, possibly even pain, and yet exacts a significant and mandatory cost to the IDE's consistency, usability and scope. Being able to work in the Smalltalk sandbox is why we're all here, and not in a C# group. We should provide the tools that users deal with the outside world like a boss. Best, Chris |
Re: dynamic FileDialog pop-ups considered harmful
|
|
> On 2019-12-29, at 5:00 PM, Chris Muller <[hidden email]> wrote: > > Squeak's IDE should present that it understands core competencies of development, and LEAD users by not offering haphazard ways to do configuration management, e.g., "Save as...". Ultimately it's a path to nowhere, possibly even pain, and yet exacts a significant and mandatory cost to the IDE's consistency, usability and scope. What exactly is it that you are objecting to here? You've claimed to have a much better way to save and load preferences; what is that way? What is the actual problem with providing users with a simple and familiar way to save/load a preferences file? If it is simply that you don't think preferences should be saved to files, then please separate that from complaining about any particular technique for choosing the file. After all, if there is a totally better way we want to know. Similarly with saving images as different names and in different places. It isn't a common thing to do, but when you do want to do it I claim it is helpful to have a UI affordance that makes it simple. Do you actually claim it is better to use a FillInTheBlank and have to remember path details to type in? Are you claiming that changing an image name should be done only in host tools? Because that will really screw up your 'flow'. Not least because of having to rename two separate files. You haven't explained at all, in any way whatsoever, what is a problem. Gish-galloping around the place does nothing helpful. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Useful Latin Phrases:- Quo signo nata es? = What's your sign? |
Re: dynamic FileDialog pop-ups considered harmful
|
|
In reply to this post by Chris Muller-3
Am Mo., 30. Dez. 2019 um 02:01 Uhr schrieb Chris Muller <[hidden email]>:
Drop places in Squeak that represent external locations or services might be nice, yes. Although still somewhat peculiar because 1) it is not the way people are used to from other, non-Squeak applications; and 2) why not interact with the real outside object instead of the proxy... but better than nothing as long as integration does not reach or work that far. Again my impression is that this would be Squeak pretending to be the OS/window manager/viewport to your whole machine, which it actually is not in most setups. Note that these drop places or listing morphs may further contribute to screen clutter and real estate scarceness, which a modal dialog circumvents. "Where did I bury my home folder in this project??" As far as I know we currently cannot raise morphs while something is being dragged. In Windows you can raise an application from the background by hovering the dragged object over the task bar item of the hidden application, so you can then drop the object on it. |
Re: dynamic FileDialog pop-ups considered harmful
|
|
In reply to this post by Chris Muller-3
Am Mo., 30. Dez. 2019 um 02:01 Uhr schrieb Chris Muller <[hidden email]>:
I cannot make up a coherent image of this in my mind. In one message you say that other users' workflows should not be obstructed, and now, as I understand you, you say that the IDE should prescribe a certain way of working which does not include forking images. I have seen people who like to do that. I myself am even stranger and would sometimes like to fork things inside a single image, which is one reason why I am so interested in Environments. Then you might tell me that it were not "best and proven practice" to put so much stuff in one image and that I had fallen for some "haphazard way to do configuration management". I could reply that filing out code in pieces with auto-generated file names is a "haphazard way to do configuration management", too, and that those file out menu items only take up valuable space.
Use proper version control facilities, which is proven practice in the rest of the software engineering world... Yet some people like filing out, as we have just seen in this thread, and I don't think we will drop this capability any time soon. So instead I might be better off replying that the Save As functionality and the save dialogs involved in it are simply not "a significant and mandatory cost to the IDE's consistency, usability and scope", but rather a basic functionality like filing out that some people expect from the system.
We can proclaim and wish for all the tools we want, but ultimately our resources (manpower) are limited and we won't get all the great tools we want in the short term. To have everything written and inspectable in Smalltalk is nice, but only if requiring that does not keep you distracted from solving actual problems. Example: While there are dozens of text merging tools out there for each major platform, no acceptable such equivalent thing for the merging of methods has been implemented or rather adopted in the Squeak trunk yet. In the end it might have been more productive to call such other application to do the merging and read the results back into the image, as an intermediary solution. I vote for solving the unnecessary efficiency problem of the current file dialogs and then stick with them. Until some messiah submits the implementation (!) of the "one and only" way to do proper software engineering with Squeak, which is unanimously accepted as the true revelation by everyone... Am Mo., 30. Dez. 2019 um 02:01 Uhr schrieb Chris Muller <[hidden email]>:
|
|
|
In reply to this post by Jakob Reschke
On 30/12/19 7:27 AM, Jakob Reschke wrote:
> Drop places in Squeak that represent external locations or services > might be nice, yes. Although still somewhat peculiar because 1) it is > not the way people are used to from other, non-Squeak applications; and Squeak already reifies host resources like Clipboard in System-Support this way. Adding a folder proxy will make Squeak UI consistent with such objects. > 2) why not interact with the real outside object instead of the proxy... > but better than nothing as long as integration does not reach or work > that far. Again my impression is that this would be Squeak pretending to > be the OS/window manager/viewport to your whole machine, which it > actually is not in most setups. A host folder is "outside" Squeak and needs a proxy to reify it. The OP is on how to avoid having to browse the entire tree of folders when all one wants to do is store or retrieve files from a few folders. Squeak is a virtual machine hosted on an OS. Folders are objects controlled by the host, so it makes sense to send a message to store/retrieve files through proxies rather than reproduce an entire file navigation implementation into Squeak. > Note that these drop places or listing morphs may further contribute to > screen clutter and real estate scarceness, which a modal dialog > circumvents. The clutter problem is a different one from the problem OP raised. It applies for any window not just open folders. Squeak already has patterns to reduce clutter. A folder proxy could be a Flap or ProjectViewMorph that accepts accepts dropped objects without opening. Regards .. Subbu |
Re: dynamic FileDialog pop-ups considered harmful
|
|
In reply to this post by timrowledge
Hi all,
maybe it's not a rational thing. I also follow Chris "everything in one folder" approach. On Windows it's super portable. I just opened a 3.6 which somehow has made it through the decades to this Win10 laptop and everything worked out of the box. And I assume that's true for all Squeak installations I have. And I would also consider the thought "Where should this go?" an annoyance. I remember having lost data because I was too eager to leave the computer to wait for success. :-) Squeak lends itself to so many different ways of using it. I'd love if it stays that way. Cheers, Herbert Am 29.12.2019 um 23:35 schrieb tim Rowledge: > >> 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!" > > > |
Re: dynamic FileDialog pop-ups considered harmful
|
|
Just my 2 cents:
+1 for asking the user where to save a fileout.
-1 for forcing to use the OS' shell dialog. Why that? While I appreciate the comfort of a native shell dialog, I see a lot of drawbacks:
Best,
Christoph
Von: Squeak-dev <[hidden email]> im Auftrag von Herbert König <[hidden email]>
Gesendet: Montag, 30. Dezember 2019 14:21 Uhr An: [hidden email] Betreff: Re: [squeak-dev] dynamic FileDialog pop-ups considered harmful Hi all,
maybe it's not a rational thing. I also follow Chris "everything in one folder" approach. On Windows it's super portable. I just opened a 3.6 which somehow has made it through the decades to this Win10 laptop and everything worked out of the box. And I assume that's true for all Squeak installations I have. And I would also consider the thought "Where should this go?" an annoyance. I remember having lost data because I was too eager to leave the computer to wait for success. :-) Squeak lends itself to so many different ways of using it. I'd love if it stays that way. Cheers, Herbert Am 29.12.2019 um 23:35 schrieb tim Rowledge: > >> 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!" > > >
Carpe Squeak!
|
Re: dynamic FileDialog pop-ups considered harmful
|
|
In reply to this post by Herbert König
> On 2019-12-30, at 5:21 AM, Herbert König <[hidden email]> wrote: > > Hi all, > > maybe it's not a rational thing. I also follow Chris "everything in one > folder" approach. On Windows it's super portable. I just opened a 3.6 > which somehow has made it through the decades to this Win10 laptop and > everything worked out of the box. And I assume that's true for all > Squeak installations I have. It probably is , just so long as the OS changes haven't broken things. Which they do sometimes; libraries get broken or removed, DLLs ... do whatever DLLs do to irritate, new restrictions on execution permissions, blah blah blah. One time long ago Apple subtly changed how memory was allocated and BOOM! VW couldn't start up. Nice. > > And I would also consider the thought "Where should this go?" an > annoyance. I remember having lost data because I was too eager to leave > the computer to wait for success. :-) The key point here is that nobody has seriously proposed demanding the user use a restrictive UI for anything that is a common, nor indeed part-of-work-flow activity. And the UI in question offers more flexibility than the current (or prior, in the case of saving an image with a new name) UI without costing any effort in the context of the total UI interaction. Adding even as much as a full second to - move pointer to dock - click on squeak menu - click on 'save as..' - open text filling in UI to allow typing of new name - click or CR - system saves image, copies changes is nothing. The human perceptual response to get to the typing is probably the slowest part - unless you have a huge image/changes and/or a slow disc/network drive. Adding the one-morphic-frame-cycle delay to provide a UI that can let you see if you already have an image of the 'new' name you were thinking of, if you are actually in the directory where you want the image to be, to choose new directories or even make one - if that really ruins your day? Well, feel free to propose a (preference guarded, please) alternate approach that skips it. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Klingon Code Warrior:- 2) "My program has just dumped Stova Core!" |
Re: dynamic FileDialog pop-ups considered harmful
|
|
In reply to this post by timrowledge
On Sun, Dec 29, 2019 at 7:52 PM tim Rowledge <[hidden email]> wrote:
"Show in Folder" button like in Firefox, Chrome. I already said that.. I also proposed a "Select..." button, which would use your FileDialog. Both proposals are existing in other apps, "familiar..."
YES, absolutely!!! and have to remember path details to type in? Tim, please wake up, YOU are the one who has to remember a path, not me, because that's how you do configuration management -- sprinkling your .image and .prefs files around by navigating a tree widget in a modal dialog. I use a configurable build system, I define everything, then Version it, then press one button. "One-click" deploy. "One-click" install. What you're doing is hundreds of clicks, error-prone... Tim, what about your experience with Personal SqueakSource, does that not give you the context of what I'm describing? Are you claiming that changing an image name should be done only in host tools? No, of course not, I do it all the time, that's why I can't stand the new "Save as..." popping up the FileDialog. It's a BEAST now... and for bad reasons even.. :( Because that will really screw up your 'flow'. Not least because of having to rename two separate files.
I tried my best in the opening of this thread to lead your thought process, by posing that initial question, but you never really addressed it... I believe that's where "consensus" lies, but I can only lead a horse to water, not make him drink.... :/ The primary purpose of Image "Save as..." is to jump into a new image to try something that might be dangerous. It is NOT, I repeat, NOT, configure your application. But that's what you want to use it for and, unfortunately, it killed user performance with the original use-case. Worse, it introduced a new place where we breach the Smalltalk sandbox at a new place where it never was before. If we take our IDE design seriously, we should think long and hard about that. - Chris |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |