Eeep! What has happened to the nice little [ .. ] button in the Save As filepicker? There used to be a button in the top right of the dialog that would jump up to the parent directory. Now if you want to go up a level in the directory structure you have to use the dropdown list. I first noticed it was gone in Linux build 2002021206 but I think it has been gone for a while now. I suspect that it dissapeared with Ben's Save As imporovement patch describe in bug 120174 I used that button almost every time I saved a file! It was like a brother to me! ... okay, maybe thats going to far, but I would really love to have it back :)

This is not a regression and don't blame Ben. :) It's a conscious design decision. See bug 121354 and bug 58312.

Marking invalid. "It's not a bug, it's a feature".

Ick! How dissapointing! I wholeheartedly disagree with the decision to remove it. There is absolutely no reason why the parent-picker dropdown has to be mutualy exclusive to an up-directory button. If the space it was taking up was a concern, it could have simply been made smaller. *sigh* But if the powers that be have spoken, then the powers that be have spoken... I am going to really miss that button; My one and only true friend! Farewell little button! It is better to have loved and lost than to have never loved at all!

Well, no reason beyond confusing redundancy of interface and ugliness of button. :) I have to say that I liked it too, btw...

by that logic, the "back" button would a confusingly redundant version of the session history in the "Go" menu. (don't tell a soul I said this, but my precious dear departed up-directory button *was* a little bit ugly-- but I try not to judge my friends by appearance)

v

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

What a shame! Mozilla now have the worse save dialog ever! Seems like I'll have to wait until kde-bindings-kmozilla works or return to using galeon :P

The dialog is a work-in-progress... it'll be getting a history dropdown soon....

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

Boris, what is a good size for the folder up icon? I modified a 16x16 folder icon (from the bookmarks) with a little up array, but it is too small IMO.

reopening since someone is willing to deal with this. :)

It seems a little small to me too, but 24x24 would seem too large, I think.... mpt? trudelle? marlon?

That's small to my old eyes too, but similar in size and appearance to the corresponding icon on Win32. I don't see any problem with having such a button (or even a nice accelerator like say Backspace :-), but Netscape can't afford to spend time on this for MachV though, sorry.

I see no reason why the icon has to be 16x16. It should just look good with the rest of the dialog. I suggest a similar layout as the system-wide filepicker in windows has with the up button, the "new directory" button, and the "home directory" button on the top right. Here is a slightly larger version of the modern button, it is 20x16 and uses all of the available space.

Hmm how is the save dialog created, is there a css that defines it? I wasnt able to find it myself, but I dont really know how it is done. Would be good if there was a way to dry test the layout without having to program anything. Another question: is it possible to have tooltips on the buttons in the dialog? Having a nice icon with a tooltip should clarify the dialog for most users I suppose.

Why not take the opportunity to put a create folder button too? It would be very good IMHO, and VERY usefull to me.

The dialog is created by the code in xpfe/components/filepicker/res The files are installed (per xpfe/components/jar.mn) in toolkit.jar/content/global for the xul/js and in en-US.jar/locale/en-US/global for the dtd/properties. There is no CSS, but there is a directory for it and it would be installed in toolkit.jar/content/global as console.css is. Tooltips are doable. The create directory button is doable but there is a separate bug on that (=a patch that does both would be fine, though). Backspace already works to go up a directory as long as the focus is in the directory listing. If we have icons I'm willing to do the XUL/css/whatever to put the button back, assuming UE wants it (trudelle, this is why I cced you on the bug). I'll also work on hunting down reviews (from non-netscape people if need be). That second icon seems to have a non-transparent smudge in the top right. Is that as designed? Or was that an accident?

Corrected icon - i cant make the previous obsolete since I dont have authorization for that.

This is the usual icon for creating a new subdirectory

This shows how the modern save as dialog could look with both icons added. The size of the button is not optimal yet, but I couldnt figure out how to make them auto-adjust to the size of the image without showing extra empty space. Adding tooltips seems to be straightforward too. The MRU directories dropdown could go under the "look in" menu. What is everybody's opinion about a *different* solution though, where "look in" is replaced by the MRU menu and the ancestors pop up from a little drop-down button that is close to the "up" button - similar to the little menu near the navigator "back" button that too has all the ancestors of the current page? I think that would be a consistent solution that would also save space.

bz: I'm not UE, I manage the engineers on Navigator/XPApps/XPToolkit/etc. components. I'm pretty sure UE has no time for this now either.

Can someone translate to an outsider what that means? I have looked at the XUL and I think it isnt too hard to get at least a somewhat enhanced dialog going, but I dont want to waste my time if it is not wanted.

It means this is not needed for any release, so most of us can't justify spending any time on it. If you are capable of doing this, your help would be much more appreciated on a bug that is needed (keyword nsbeta1+, topembed+ or mozilla1.0+)

I disagree. I think this is MUCH needed. It's the minimal having up and create dir on save dialog. If you don't want/have time to deal with chromo, you should never used it in first place, but used common system save dialog, as win32 or gtk. Now that the damage is done and chrome is used everywhere (I'm not saying chrome is a bad thing at all, just that it should not take place every place), you should work to make it work :)

I completely agree with you. This is a very important feature for Mozilla 1.0. And it should not be too problematic or create new bugs. I really like the "potemkian save as dialog screenshot". Please write a patch for this Johann. If it will not be accepted for 1.0 there is at least an option for people who compile Mozilla and there is a better chance that it will be in Mozilla 1.1.

> If you don't want/have time to deal with chromo, you should never used it in > first place, but used common system save dialog, as win32 or gtk. We do use the common system filepicker on Win32. The GTK one is completely unusable due to its lack of reasonable Unicode support. Please don't flame unless you know what you're talking about. If someone comes up with a patch to do this (Johann seems to be pretty much there) I will be perfectly happy to review and hunt down sr/approval from non-netscape people if Netscape does not want to deal. Johann, should I assign this bug to you?

Boris, I originally just dropped in to provide the icons and some unasked for advice :) I am a complete XUL newbie, so I will probably need some help initially.

Advice I can provide (via email or irc or whatever). If you would be willing to work on this, that would be great. As a side benefit, you learn some XUL and can fix other bugs. :) I'd suggest leaving the "new directory" button out of this for now, since that will take a lot more work than the "up a dir" button...

ok, I'll do that and do it incrementally. Thanks for offering help I will use PM for that.

i have done the changes for adding an up and a home button with different buttons for modern and classic and tooltips, but I have difficulty creating a patch. I know how to use patchmaker to record changes to xul, js, and dtd files, but how do I add new files, especially gif files to a patch?

Since we agreed this bug to be for discussion: I guess the go up and other features that change to some directory should be done in the filepicker, so that they get added to both save and open dialogs and the two look consistently. However, any "new" dir button only makes sense in save. And I am not sure if the potential MRU dir list should be the same for save and open.

This shows what the *different* solution in comment 21 would look like with the modern skin: The "Look in:" menu shows the 10 most recently used directories instead of the ancestor list. The "up" button goes up one directory level, and the array to its side shows a dropdownmenu of the ancestors. The "home" button goes to the home directory, and the array to its side shows the list of the 10 most recently bookmarked/favorite directories. The first entry in that menu is separated from the rest and used for adding a new bookmark, showing some text like "Add to bookmarked directories" Please regard this as a proposal for what *could* be done in the longer run that tries to work in most of the suggestions I have seen for that dialog. Comments welcome.

This is a zip archive with the modern and classic versions of the images needed for the subsequent patch. The are stored with path info relative to the chrome dir.

Johann, where exactly in the source tree (not just the chrome tree) are the graphics files to go? It sounds like you want them in themes/classic/global/filepicker and similarly for modern. If so, please add to jar.mn in themes/classic and themes/modern the mappings from real paths in tree to chrome paths in final chrome.

the things discussed and proposed here are related to bugs: http://bugzilla.mozilla.org/show_bug.cgi?id=112900 dir bookmarks and new dir http://bugzilla.mozilla.org/show_bug.cgi?id=58311 create dir in filepicker http://bugzilla.mozilla.org/show_bug.cgi?id=125210 remeber N most recent dirs http://bugzilla.mozilla.org/show_bug.cgi?id=115981 favorites for save and open

As another note, please look at the summary and let's keep this bug focused on fixing the issue there. :)

boris i was just going to suggest to change the summary because having a central bug for discussion about the look and feel of the filepicker dialog seems to be reasonable and several different requests might possibly get solved by a "combined" solution?

Um.. sure. Punting the bug to you, then (since you're doing the work anyway :)).

The diffs for the files modern/jar.mn and classic/jar.mn as requested in http://bugzilla.mozilla.org/show_bug.cgi?id=125133#c36 Thanks for your help with this Boris.

Is there a chance to get the trivial patch I submitted checked in before 1.0 branches? The more elaborate enhancements can probably be ready for two release cycles later.

I am bit confused on how work on the filepicker should proceed: I was expecting that the checkin for the small patch I provided in attachments 72581, 72583, and 72641 would not be a big issue. This is only around 6 lines of code and 4 new gifs, and three new localization constants but might do what quite a couple of people want. I think in relation to its simplicity it is something that could quite easily go into mozilla before 1.0. Is there anything missing from my part? I was planning to start working on the more involved changes (which would cover bug http://bugzilla.mozilla.org/show_bug.cgi?id=125210, http://bugzilla.mozilla.org/show_bug.cgi?id=112900, http://bugzilla.mozilla.org/show_bug.cgi?id=58311, http://bugzilla.mozilla.org/show_bug.cgi?id=115981 eventually) in an incremental fashion as soon as somebody from NS approves that this is actually wanted.

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

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

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

Comment on attachment 72583 [details] [diff] [review] patch for filepicker with added up and home buttons Any reason you reindented the menulist? Any reason for the width="1" on the "home" button? Drop the extra newline after the definition of goHomeDir(). I'd call the function goHome(), not goHomeDir(), but that's just me. :) "Go to home", not "Change to home". "Go up a level", not "Go up one directory level"

There sure was a reason for the reindented menulist, but a bad one, undone. Same for the width="1" and extra newline. Changed the function name to goHome(), just to make you happy :) Changed the locale strings as you suggested.

Comment on attachment 74048 [details] [diff] [review] corrected patch for filepicker with added up and home buttons >+ <button image="chrome://global/skin/filepicker/folder-up.gif" maxwidth="36" tooltiptext="&folderUp.tooltiptext;" oncommand="goUp();"/> >+ <button image="chrome://global/skin/filepicker/folder-home.gif" maxwidth="36" tooltiptext="&folderHome.tooltiptext;" oncommand="goHome();"/> timeless just noted that you should use id attributes for the buttons, not use the image attribute, and add rules to filepicker.css (in both themes) that set a list-style-image for the buttons. That way other themes can usefully skin them. Do that and r=bzbarsky

Comment on attachment 72641 [details] [diff] [review] The missing patch for the jar.mn files r=fabian for the jar changes (not the main patch, that's for bz :-)

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

Can't we just have ".." and "." as items part of the file picker like mots other inux application does it? Why do we want to be inconsistant?

I second Comment 52

The only apps I can find that use "." are apps using the standard GTK picker. The KDE apps I have lying about (and these are admittedly old) have ".." and no ".". Netscape4 just lists all the dotfiles all the time, and gv has a ".." and a huge "Rescan Directory" button (wow! what a crowded filepicker design). Consistency is not a strong case for "." here. The ".." is a separate issue. Patches accepted.

Having a seperate up button makes the mozilla filepicker consistent with other more modern filepickers on linux (e.g. the konqueror, staroffice) and to some extend with the windows filepickers. This is a plus for people switching between apps and OSes. Also, pressing the up button is in many situations easier and faster than scrolling the dirtory list to the point where the ".." is and then doubleclicking that. So I am in favor of keeping my design, obviously :) However, whether or not to include the ".." in the scrollable directory list at all is a different question. Some people have argued that ".." is "confusing" (this lead to the removal of the button with the ".." in it in the first place, remember?). Personally I dont think that it really would be too confusing for most linux people, so I would be in favor of adding this to the scrollable list for those people who are used to that kind of navigation.

It has long been the "standard" in file selectors to have both a "." and a ".." . And while many have stated reasons for the inclusion of ".." in light of its absence in 0.9.9, noone, that I have seen, has made a case for inclusion of a "." in the recent discussions. I will now. Most popular OS's of the last decade and a half have been of the multi-tasking variety. UNIX, AmigaOS, Mac, Windows, BSD, and Linux have all been multi-tasking. In such an environment, especially in ones that are particularly stable with applications having long "open times", it's entirely possible that one app will change the contents of a directory "behind the back" of another open app. The longer more apps are open the more likely this scenario will happen, particularly with "popular" directories. The most efficient way to counter this "behind the back" scenario is with the current directory '.' "button", a.k.a., the refresh button. I wouldn't argue against having a refresh button next to the parent directory ("..") button, especially, since one could make a good case for refeshing before **every** directory access, particularly in a very active computing environment. How else can you be assured of directory listing accuracy? I could live with the refresh button not being in the "open", but at the top of the directory list. In which case, *I'd* like to see it followed by a parent dir ("..") button, for consistency, even though it already exists in the "open".

Boris: why did you mark attachment 72579 [details] (new potemkian) obsolete? I think it could serve as a base for discussion and I plan to implement it later, should there be some consent and constructive outcome of the discussion. Maybe it would be good to seperate the "up button" issue that should get fixed by the simple patch and the "design" discussion into two seperate bugs? This would also make it easier to fix the "up button" bug but still leave the dsicussion bug open for future enhancements?

Comment on attachment 72579 [details] new potemkian save as dialog screenshot Unobsolete this... This bug _did_ start out as the bug for the "up a dir" button. Then people started talking about a generic redesign... you're doing the work, so it's your call what you want to do with the bug. :)

Thank you, Johann, I *really* missed the "create directory" button. But there exists yet another issue related to the "Save page as" dialog. In Internet Explorer's Save as dialog, the suggested filename is constructed from title of the page. It's very convenient. For example when I save discussions on Slashdot for later reading at home, mozilla suggests to name every file "article.pl". It's annoying to make up meaningful names for the files. A new "Set filename to page title" checkbox would be a very nice feature and probably quite easy to implement for someone who has the ability to do it.

Tomas, that has nothing to do with the actual filepicker.... Please take it to the relevant bugs (there are at least two on the issue -- one in which the decision to use the filename in preference to the page title was made and one in which there is a patch to fix some edge cases when we _should_ use the title but do not).

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

Comment on attachment 74048 [details] [diff] [review] corrected patch for filepicker with added up and home buttons marking this needs-work per comment 49...

sorry for the delay, busy in the coal-mines :) Hope that is what you were talking about in #49, also moved the max-width spec into the css.

Any chance the new file picker will made in moz 1.0?

Comment on attachment 72581 [details] archive of GIF images needed for subsequent patch r=bzbarsky

Comment on attachment 75351 [details] [diff] [review] corrected patch for up and home buttons, according to comment 49 r=bzbarsky. The change to the classic theme CSS needs to be hand-tweaked to apply to both themes/classic/global/win and themes/classic/global/mac but otherwise the patch looks great.

I've asked for sr.

Hmm I am puzzled: I did everything without the sources until now but now I realize that in the source tree there is a filepicker.css in classic/mac and classic/win, but not in classic/unix or just ./classic. (however there is only ./modern/filepicker.css) But isnt the filepicker *only* used for unix since win and mac use native widgets? Since both classic/win and classic/mac seem to be identical I suppose that means my patch should also identically change both? Will it be easier to review stuff when I switch to making patches against the source tree?

> there is a filepicker.css in classic/mac and classic/win, but not in > classic/unix or just ./classic. (however there is only ./modern/filepicker.css) Right. Modern is platform-independent. Classic is not. Unix usually uses the "win" version of classic. > But isnt the filepicker *only* used for unix since win and mac use native > widgets? Yes. You want logic in the themes/ layout? :) > I suppose that means my patch should also identically change both? Yeah. > Will it be easier to review stuff when I switch to making patches > against the source tree? Yes, because I applied the patch to test and tested both themes (so I had to edit the patch to get it to apply).

(sr: please ignore this, the patch to sr is 75351 together with 72641 and 72581) This is a zip that contains all I have for now to let people discuss UI issues: it can be installed and tried out easily in a binary distribution: (linux only!) 1) save the zip file potemkian.zip into your mozilla/chrome 2) unzip the jars en-US.jar, modern.jar, classic.jar, and toolkit.jar by changing into the corresponding dir (e.g. ./toolkit) and doing e.g. "unzip ../toolkit.jar" 3) from the chrome dir, apply the patch: "patch -p0 < potemkian.diff" 4) update all the jars, by changing into the subdirs and updating the jar: "cd toolkit; zip -ur ../toolkit.jar *" 5) start mozilla and try out Most of the stuff is still functionless, but it should be enough to get a feel how this could work so people can decide if they want it. This also includes Boris' patch for recent files, but using the recent files dropdown currently breaks something with the text entry ... One more thing I would like to have is a text entry box with a drop down menu instead of a menu list. So that the "look in" function would be pretty similar to the goto URL interface in the browser. The filter field of course would take some regexp and limit which files and directories are shown. To get rid of this again, after exiting mozilla: "patch -R -p0 < potemkian.diff" Then update the jar files again. PS: I have read somewhere that in theory there should be a way to test this without updating the jars first, but I didnt figure out how?

Maybe I did something wrong (I'm without bbackspace after upgrading for kde3rc3) but this is what I got in the end.

Iuri, looks like the new images are not found: unzipping potemkian.zip from the chrome dir should put three new files into ./modern//skin/modern/global/filepicker/ (and likewise for classic). Then you should update the modern.jar: "cd modern; zip -ur ../modern.jar *" Be sure not to forget the "jar" extension, otherwise zip will create a file mit extension .zip.

Worked. The thing is that for some reason I don't know why, zip -ur didn't saw the new gif files. So I created the modern.jar by entering chrome/modern and using zip -r ../modern.jar *, now it works. I'll test classic soon, but I want to know how this will affect themes. If I install a theme will it still have the buttons? Or themes should be rebuild to include the buttons when it merge on tree?

Themes will have to provide their own images and css files for the new version of the filepicker. Older themes will have the filepicker look similar to what is shown in your attachment 75566 [details] -- no images. Is there a way to provide e.g. the images for classic as a "fallback" for old themes somehow?

Boris asked me to round up attachment 72641 [details] [diff] [review] and 75351 into a cvs diff. I haven't actually tried the patch out yet, just took the two patchess and manually applied the changes locally. Marking 72641 and 75351 obsolete by this patch.

Comment on attachment 75853 [details] [diff] [review] cvs diff -u format sr=jag Fine by me, what do you think, bryner?

What about a per url based favorite dir? e.g.: Today - Surf to http://www.mozilla.org/ - right click the mozilla logo - save as - filepicker dialog pops up - you chose the dir /home/me/mozilla-stuff - surf to anyother site - save something somewhere other Tommorow - Surf to http://www.mozilla.org/releases/ - File -> Save Page as... - filepicker dialog pops up - automagicly moz choses the dir /home/me/mozilla-stuff That would be nice...

I believe that is a different bug, a filed one too... this bug is about the filepicker UI, not the backend needed for the functinality you describe...

Comment on attachment 75853 [details] [diff] [review] cvs diff -u format I think the jar.mn changes have r=fabian and the rest has r=bzbarsky. Either way, I just looked at the patch and it also has r=caillon.

Jag, I'm assuming your sr= also covered the images since sr=ing just the patch will not work. I'm going to transfer sr= to attachment 72581 [details], and request approval on that and attachment 75853 [details] [diff] [review]. I'll check this in later tonight.

Comment on attachment 72581 [details] archive of GIF images needed for subsequent patch transferring sr=jag

Comment on attachment 75853 [details] [diff] [review] cvs diff -u format a=asa (on behalf of drivers) for checkin to the 1.0 trunk

Comment on attachment 72581 [details] archive of GIF images needed for subsequent patch a=asa (on behalf of drivers) for checkin to the 1.0 trunk

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

As a note, Christopher checked in the "up button/home button" patch (thank you!). At this point, I'd advise using other bugs for any development work... this one is getting unwieldy with discussion and patches (so discussion could stay here or in the newsgroups, but new patches should get bugs of their own).

Comment on attachment 72581 [details] archive of GIF images needed for subsequent patch resolving patch since it has landed but the bug hasn't been resolved

Comment on attachment 75853 [details] [diff] [review] cvs diff -u format landed. obsoleting patch so it doesn't look like an approved patch waiting to land.

Back from 10 days without a computer! - thanks to all who worked on this to get the patch checked in! Following Boris' advice I will make this bug dependent on suitable bugs discussing the individual issues and getting the patches: - new dir button (bug 58311) - remember N recently used dirs for open/save (bug 125210) - allow favorite dirs / folder bookmarks (bug 115981) - filter file/dir names (bug 57385) - scroll to last file opened (bug 96982) In addition, these bugs are related (any other?): - dir bookmarks and create dir (bug 112900) is a dup of 58311 & 115981 - bug 57215 is related but if my last proposal gets implemented will be WONTFIX. (I think the GTK filepicker isnt that much of a platform standard anyways, and if it is, it is a bad one and will get fixed soon) - bug 80636 : "platform consistency" again, but mainly dup of what is discussed here

ok i have a patch for the "new dir" bug 58311 and would like to go for the "recently used dirs" bug 125210 next, but for this I need some status info on bug 132831, because I need that functionality for the button. Can anybody help to find out about this?

Noting related bug 116951. The filter field I have suggested here previously would clean up the mess that has been introduced by the "file type" dropdown: selecting a method of storing (full web page, just html), file format conversion (html or txt), and filtering by filename extension. This mess should get cleaned up and seperating the filter function from the rest might be a good first step. BTW instead of a simple input field an input field that is combined with a dropdown menu will be nice for the filter: either enter a filter template or select one from a list of predefined ones (that might get adapted by the mime type of the current file for a save operation). Since the type dropdown would not be used for filtering any longer with this solution, it should be removed from the filepicker for an open operation, unless we implement some kind of more elaborated type detection based on the content of the file ...

Separating filtering from the save mode should be done very carefully. The only way of doing it that I see is to set the filter field based on the save mode by default and to change the filter field when the save mode changes... That _may_ work, but I haven't really thought carefully about it yet.

Boris, where exactly do you see the problems? As far as I see it filtering and the save mode/coversion are two completely unrelated things: on Linux, there isnt really a necessary connection between file type and file name (and hence, extension). Since it is often done by convention, it will be friendly to the user to initialize the filter with some commonly used extension pattern though.

The problem lies in the fact that the nsIFilePicker interface works with filters. So people will set filters via that interface. Those settings should be somehow translated to selectable filters in the XP filepicker, since there are places where we're not using those filters to select a save mode (eg when doing "open file"). The filter/mode separation cannot be done easily on the nsIFilePicker interface level, since Windows and Mac use native filepickers and hence would not be able to add a separate "mode" field in addition to the "filter" field. In any case, make sure to run the proposed changes by a UI person.

(In reply to Boris Zbarsky (:bz) from comment #12) > reopening since someone is willing to deal with this. :) It seems that this is not true anymore -> invalid