This feature request is directed at much the same territory as bug 21482, "[ENH] Improvement to Save File dialog", but with a different approach. First, quoting law@netscape.com from that bug report, >The features in the standard file picker dialog are outside of our control. This RFE is only possible if that were to change; that is, if those dialogs were to be overhauled or replaced, so this is obviously for later. It would be relatively easy to add an MRU (Most Recently Used) folders list, as a FIFO list, for the folders that have been saved to, in the preferences, and then put the entries on a drop down list on the "File Save" dialog, for quick choice rather than filesystem navigation, later. This would be easy to use, and although it would mean customizing the platform-specific "File Save" dialogs, this could probably be done cleanly (UI-wise) - and I, for one, would use this feature every day.

m16

It appears that on Win32, it should be possible to add MRU directories to the standard file picker without starting over. See http://www.iarchitect.com/mfame.htm (User Interface Hall of Fame) -- search for CoolEdit95, then scroll up just a bit to see an example of an MRU list being appended to an otherwise standard file picker dialog. The developer is at http://www.syntrillium.com/

*** Bug 32014 has been marked as a duplicate of this bug. ***

Given that bug 32014, "Need to remember last-saved-in directory for file downloads", which is 4xp, has been made a DUP of this, it appears that that functionality will be provided by using the top item on the MRU as the default Save folder -- or, putting it another way, that basic functionality will be provided by the facilities implemented for the new functionality in this RFE. On that basis, this couldn't be just an enhancement anymore, unless 32014 were split off again, especially now that it also blocks a major severity bug. Raising severity; removing [RFE].

Of course, if we were to conclude (and rightfully so, IMHO), that bug 32014 really wasn't a dup of this bug, then you might have to undo those changes (i.e., reduce the severity and change back to an RFE). I think 32014 is a dup of a bug that's already been fixed. I know I put in code that passes the directory to nsIFileWidget. There were problems with the implementations of that interface not working properly on all platforms, but I thought that was fixed.

spam: moving qa contact on some bugs from paulmac to sairuh@netscape.com

Adding "list" after "MRU" in Summary to make the specifics of this bug clearer. It's not my place to judge whether or not not bug 32014 should be a DUP of this; I was just making the implications clear. No skin off my nose if those changes get undone. Bug 34974, "Save Image As doesn't remember the last directory", appears to be working on Win32 only.

tweaking summary

I think the last used directories is a good idea, but maybe it could be simpler. In konqueror on linux/kde2, there is a seperate bookmarks folder for "save as" dialogs. This could contain some paths the user enters, and they are available every time a "save as" dialog comes up. When browsing directories in the save as screen, there should af course, be a "add new bookmark" button too then...

spam: over to File Handling.

*** Bug 115574 has been marked as a duplicate of this bug. ***

From duped bug 115574: Suggested UI: +- Open/Save a file -----------------------------------------+ | ________________________________ | | Recent directories: |________________________________|\/| | <-- here it is :) | ---------------------------------------------------------- | | _______________________ | | Look in: |_______________________|\/| |^| [ Favorites ] | <-- bug 115981 | +--------------------------------------------------------+ | | | files (favs) listed here | | | | | | | | | | If you like this idea, you might also like my other suggestion in bug 115981 (Quick access to "Favorites" directory in the "Open" and "Save As..." dialogues in Windows). Please change the subject line to help this bug get some lovin': "Quick access to the 10 last used directories via dropdown list in the "Save As..." and "Open" dialogues (MRU)." Also, please add keyword: mozilla1.0 (Sean Richardson?)

Whatever is decided to do with this bug, please ensure that the systemwide filepicker is not usurped by Mozilla as is done by Lotus Smartsuite and a few other apps, and was briefly done by Mozilla (see http://bugzilla.mozilla.org/show_bug.cgi?id=69972#c5). XFile is yet another reason to stick with my "dead" OS, OS/2. See also bug 120127.

The (dead) OS/2 filepicker may be good, but the most-used OS (win and Linux) have **** and lacking-in-features filepickers. ANYTHING to enhance these inadequate OS filepickers would be a vast improvement (i.e., MRU and Favorites). Even MS Word fixes this discrepancy. I am tired of manually & cumbersomely navigating directory trees. Could someone please change the subject to include ALL filepicker dialogues (Open, Save, and Save As)? Sean R: are you still involed in mozilla or this bug?

If someone would GPL port XFile to windoze and Linux (or even create something similar from scratch) then no one would need to be reinventing the wheel with each app. Surely creating a decent filepicker couldn't be that big a challenge. I multiboot to Linux and find the miserable native filepicker (just like windoze) to be a major usability handicap preventing from seriously attempting to migrate from OS/2.

What is the difference between this and bug 125210? Is this bug for the Windows or the XP filepicker?

Reassigning to default owners (the "netscape.com" guys are gone, right?)

Patch from duped bug 125210

*** Bug 125210 has been marked as a duplicate of this bug. ***

Bug 125210 (which contains lots of useful discussion that's not relevant to this bug, btw) was for the XP filepicker. This bug, as originally filed and before people fucked it up, was essentially a tracking bug for the 4-5 different filepickers we have. Dupping like that is a good way to make sure none of this ever gets resolved.

this bug, as it is, is useless, and I'd happily wontfix a windows version of it because I don't think we should hack the platform filepickers for something they should provide. Peter: why did you attach the patch to this bug too instead of just referring to it?

> This bug [...] was essentially a tracking bug No, it was (and is) "to add an MRU" (see comment #0, 4th para) > is a good way to make sure none of this ever gets resolved. Nothing has happened since 2002. It doesn't get much worse than that. ;) > I don't think we should hack the [windows] platform filepickers for > something they should provide. Well, Windows 95/98/NT *don't* provide this. That is the reality. Any decent program adds these standard improvements to the atrocious Windows default filepicker (e.g., WordPerfect, even Word). Now if the filepicker in Win2k and WinXP have this functionality, and we aren't interested in supporting these (older) versions of windows, then we may not need this bug in windows. > Why did you attach the patch to this bug too instead of just referring to it? I'm not experienced with managing patches, so I wasn't sure of the best course-of-action. I'll see if i can do it the way you suggest...

Comment on attachment 138813 [details] [diff] [review] "what I have so far" Removing (obsoleting) this patch, as it already exists in bug 125210. See http://bugzilla.mozilla.org/attachment.cgi?id=75336&action=view

> No, it was (and is) "to add an MRU" (see comment #0, 4th para) Yes. That involves 5 separate patches, written probably by 5 separate people, definitely reviewed by somewhere around 10 different people. And all that independent of each other. Also note that it's possible that the bug would be wontfixed for some platforms (eg mac) but not others. In other words, there should be one bug per filepicker impl and this bug to track. Unless you have a way to give a bug 5 different owners. Lack of platform-specific bugs is a large part of the reasons this hasn't happened. The other large part is that there was a certain amount of opposition from people who would need to approve the changes. I'm punting this, since this has nothing to do with file handling and I'm tired of the useless spam (and thought I was well rid of it).

> there should be one bug per filepicker impl and this bug to track. Well, I'm glad someone spelled that out after 4 years. :-\ If that is what's needed, I can gladly identify this bug as a "[Meta]" bug and create dependent bugs for each OS. Please let me know. Also, any idea how to handle the various OS *versions* (win9x, win2k, winXP, etc.), since they may each need to be "fixed" differently? It would seem silly to have separate bugs for each, but using the newest version (winXP) may be misleading too. Thoughts?

the different windows versions can be tracked in the same bug. they go down the same codepath.

from experience, the ms word dialogs tend to suck when compared w/ os native dialogs. There are pictures and rants available. If you can't find them, I can repeat them. The wordperfect dialog (which isn't really a dialog, it's a full windows) is missing the places bar. (otherwise, I happen to like wp's dialogs, but there's no way i'm writing that dialog for mozilla -- too complicated.)

> the ms word dialogs tend to suck That wasn't the point. The point was that Microsoft itself "enhances" the filepicker of it own OS. > I happen to like wp's dialogs, but there's no way i'm writing that dialog > for mozilla -- too complicated. Adding Favorites (bug 115981) and MRU would already be enough. ;)

Filter "spam" on "guifeatures-nobody-20080610".