From the Fedora RPMs.

Comment on attachment 160746 [details] [diff] [review] Patch This is just a backport of what is on the trunk already, so it already has r/sr. I'd like approval to land on the aviary branch.

Comment on attachment 160746 [details] [diff] [review] Patch *cough* so ask for it? :)

I attach this just for reference; caillon points out that it still has the amd64 crash (forget the bug number).

I think landing this needs to block aviary1.0; all our Linux distributors are currently doing subtly different things, and that has to stop! Or, uh, I'll cry.

Thanks. I still want to load attachment 160746 [details] [diff] [review] on the branch because that's what the trunk currently has. I'll sift through the novell patch and find out what they added and merge that into a different patch with the first one already applied. I also want my fixes in bug 260872 landed on aviary.

That sounds like a great plan.

do we have a list of regressions that happened when this landed on the trunk? sounds like there were a few... just want to make sure they addressed

do we have a list of regressions that happened when this landed on the trunk? sounds like there were a few... just want to make sure they are addressed

can we get a pref to control this? that might be another option.

sounds like this patch is in synch with the trunk.

Why would this be off by default?

Because it hasn't been well-tested in our firefox distributions, which include people with downrev gtk2s, because there has been widespread user dissatisfaction with the file dialog (not presenting path entry, "save as" format selection for web pages, not confirming replace), and because we need to be conservative about making late-breaking changes to our users, who have been running gtk2 firefoxes for many months and will not have their "first experience" be with the filepicker. Many of our gtk2-having firefox users, in fact, had never seen the gtk2 filepicker until we plunked it onto the trunk, and were quite taken aback. (Even on KDE systems, we use gtk2 today, and the filepicker has a very GNOMEy feel; it reflects GNOME UI policy around what options should be presented to users, beyond simple widgetry appropriate, IMO, for a toolkit like GTK. That's a virtue for some distributors, but it may not be for ftp.m.o builds.) I want to see one true gtk2 filepicker in the tree that our distributors can pref on or off as they choose, to avoid divergence of the code and platform, but it may well be that the "ftp.mozilla.org" distributors will want to pref it off. I hope that helps.

(In reply to comment #13) > Because it hasn't been well-tested in our firefox distributions, Very fair. > because there has been widespread user > dissatisfaction with the file dialog (not presenting path entry, fair, I don't like this either. Hopefully shortly it'll just type-ahead find everything. > "save as" format selection for web pages, ? I'm not sure what you mean by this, but if it is what I think it is, it is perfectly implementable (though admittedly I can't provide manpower to do it right now, grrrrr. :/ > not confirming replace), and because we need to I believe we added this to the patch, I'm not sure, though. Certainly we discussed it- it's not a shortcoming of the file selector itself, but of the patch used to implement it. > be conservative about making late-breaking changes to our users, who have been > running gtk2 firefoxes for many months and will not have their "first > experience" be with the filepicker. Many of our gtk2-having firefox users, in > fact, had never seen the gtk2 filepicker until we plunked it onto the trunk, and > were quite taken aback. (Even on KDE systems, we use gtk2 today, and the > filepicker has a very GNOMEy feel; it reflects GNOME UI policy around what > options should be presented to users, beyond simple widgetry appropriate, IMO, > for a toolkit like GTK. That's a virtue for some distributors, but it may not > be for ftp.m.o builds.) I'd suggest that very few KDE users actually use firefox; the suggestion internally that KDE should offer firefox was met... um, well, 'great offense' was one way of putting it. So I'd suggest that it shouldn't be much of a consideration for you guys. If/when you make a serious push for KDE users, you'll have to do this all over again for them. The filepicker has a deliberately GNOME-y feel, of course. Again, though, that's a general direction lots of projects are leaning- Real and OpenOffice, for example. This is not bad company for a third-party project to follow. > I want to see one true gtk2 filepicker in the tree that our distributors can > pref on or off as they choose, to avoid divergence of the code and platform, Totally reasonable. > but > it may well be that the "ftp.mozilla.org" distributors will want to pref it off. Not sure what you mean by ftp.mozilla.org distributors here? > I hope that helps. Yup. Totally understand the 'we're near 1.0' thing- that's a totally valid argument. Hopefully my responses have cleared up the other issues some, though.

(In reply to comment #14) > > "save as" format selection for web pages, > > ? I'm not sure what you mean by this, but if it is what I think it is, it is Being able to pick "save as complete page" vs. "save just the HTML". > perfectly implementable (though admittedly I can't provide manpower to do it > right now, grrrrr. :/ Yes, I think we can have an utterly kick-ass GTK filepicker. I just don't know if we can have it in time for 1.0, and I don't want that decision to be a gating point for getting the code into the tree, and at least RHAT and Novell using the same stuff. > I'd suggest that very few KDE users actually use firefox There are people who use KDE because they made a conscious choice to pick a distribution, and there are people who use KDE because it's what someone put on their desktop when they installed Linux. The people who are passionate about KDE purity are likely not happy with the gtk2 filepicker, probably even less so than with the XUL filepicker, because they get the "usability regressions" without actually integrating any better into their application environment. > The filepicker has a deliberately GNOME-y feel, of course. Again, though, that's > a general direction lots of projects are leaning- Real and OpenOffice, for > example. This is not bad company for a third-party project to follow. I don't want to speak ill of anyone here, but I don't think that the user-experience goals for those projects are the same. > > but > > it may well be that the "ftp.mozilla.org" distributors will want to pref it off. > > Not sure what you mean by ftp.mozilla.org distributors here? People deciding what goes into the binary builds stuck on ftp.mozilla.org. *HUG*!

For tracking, these are the relevant gnome bugs (mainly because i've hunted for these now 3-4 times, and figure I should just write them down somewhere): - lack of a location bar (and the non-discoverability for C-l): http://bugzilla.gnome.org/show_bug.cgi?id=136541 - lack of save-as types dropdown: http://bugzilla.gnome.org/show_bug.cgi?id=135901 - I couldn't find a bug for the lack of a dropdown filter thing in the Open dialog, but the lack of manually typed filters is: http://bugzilla.gnome.org/show_bug.cgi?id=141153

caillion, any closer to a pref controlled patch? need to get it landed soon.

Would be slightly easier if I can land what I have first since I'm already maintaining several co-dependent patches. This is on my hit list. I will have a fix by tomorrow at the absolute latest.

think something will be ready to land tomorrow that will get this in, and off by default... reviewers standby!

If you were talking to me, I'm ready and waiting. If you weren't, I guess I'm still ready and waiting, actually.

with 2004102109-0.9+ (on fc2), the xul file picker is still being used (as expected) instead of the native gtk2 one. what is the name of the pref which controls this?

There isn't a pref, yet. Its just turned off completely for now.

Going to resolve this I guess. Rest can happen in other bugs.