262450 - GtkFileChooser for Aviary branch

Status: RESOLVED FIXED

(Firefox :: Shell Integration, defect)

Description

[Christopher Aillon (sabbatical, not receiving bugmail)]

From the Fedora RPMs.

Comment 1

[Christopher Aillon (sabbatical, not receiving bugmail)]

Attachment: Patch

Comment 2

[Christopher Aillon (sabbatical, not receiving bugmail)]

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 3

[Mike Connor [:mconnor]]

Comment on attachment 160746 [details] [diff] [review]
Patch

*cough* so ask for it? :)

Comment 4

[Mike Shaver (:shaver emeritus)]

Attachment: A patch from Novell with confirm-on-replace, maybe some other stuff.

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

Comment 5

[Mike Shaver (:shaver emeritus)]

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.

Comment 6

[Christopher Aillon (sabbatical, not receiving bugmail)]

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.

Comment 7

[Mike Shaver (:shaver emeritus)]

That sounds like a great plan.

Comment 8

[chris hofmann]

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

Comment 9

[chris hofmann]

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

Comment 10

[chris hofmann]

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

Comment 11

[chris hofmann]

sounds like this patch is in synch with the trunk.

Comment 12

[Luis Villa]

Why would this be off by default?

Comment 13

[Mike Shaver (:shaver emeritus)]

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.

Comment 14

[Luis Villa]

(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.

Comment 15

[Mike Shaver (:shaver emeritus)]

(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*!

Comment 16

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

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

Comment 17

[chris hofmann]

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

Comment 18

[Christopher Aillon (sabbatical, not receiving bugmail)]

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.

Comment 19

[chris hofmann]

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

Comment 20

[Mike Shaver (:shaver emeritus)]

If you were talking to me, I'm ready and waiting.

If you weren't, I guess I'm still ready and waiting, actually.

Comment 21

[sairuh (rarely reading bugmail)]

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?

Comment 22

[Mike Connor [:mconnor]]

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

Comment 23

[Christopher Aillon (sabbatical, not receiving bugmail)]

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