I really hate that new Linux filepicker in 1.5b1

Discussion of general topics about Mozilla Firefox
User avatar
johann_p
Posts: 8479
Joined: November 5th, 2002, 3:05 am
Location: Sheffield, UK

I really hate that new Linux filepicker in 1.5b1

Post by johann_p »

For some reason it takes much longer to show the new filepicker than the old one -- every time I need to save a file or open a file or do anything where the new dialog is shown, I have to wait.

Apart from this I hate that the file selection area is *always* closed by default. I practically always need to navigate to some different directory and for this I first need to open that damned dialog.

Is there some way to configure this so that the damned thing remains open per default?

I would also have loved to see at least some directory bookmark feature or similar if they change the default filepicker, but of course, nothing of the things that users that are not just casual newbies need has been implemented here again.

The same damned filepicker gets used for the new TB 1.5 version too, BTW, so I have the same problems with TB too.
Hendikins
Posts: 26
Joined: December 31st, 1969, 5:00 pm
Location: On a train

Post by Hendikins »

We're using the GTK2 filepicker now. Rest assured I hate it too, and whinged/bitched/moaned when it started being used. I'm afraid that fell on deaf ears, and there is no way to use the XUL filepicker (unless you go patching).
User avatar
johann_p
Posts: 8479
Joined: November 5th, 2002, 3:05 am
Location: Sheffield, UK

Post by johann_p »

Sigh.

I just wonder on what grounds they implemented yet another usability degradation? Are the guys how decide this actually using FF or just making these decisions on what they find most "cool" at the moment?

Maybe at least the GTK2 filepicker *does* allow to be brought up in "open" mode somehow or does it *force* users to click it open every damned time?
“Two things are infinite: the universe and human stupidity; and I'm not sure about the the universe.”
User avatar
Thumper
Posts: 8037
Joined: November 4th, 2002, 5:42 pm
Location: Linlithgow, Scotland
Contact:

Post by Thumper »

File bugs on the GTK2 filepicker beahviour. If you use KDE, move to the hills and howl at the moon.

Whining never helps. The community often does. Use the latter, better.

- Chris
User avatar
johann_p
Posts: 8479
Joined: November 5th, 2002, 3:05 am
Location: Sheffield, UK

Post by johann_p »

OK -- originally I just wanted to know whether there is some way to convince the filepicker to always come up "open" -- e.g. by a hidden preference. I still do not know if the GTK2 filepicker would allow this through it's API so it could still be something that might be possible to do just by calling it differently from withing FF/TB..

I know that whining doesn't help, but when they ruin my FF experience, emotion sometimes overwhelmes me, *sob*.

I think the filepicker does have the advantage of allowing directory bookmarks (I was totally wrong about this in my first post).

On the other hand I wonder what the compelling reason for making this switch really was. This does have a couple of disadvantages apart from the issue I mentioned here too: no more theming of the filepicker, no way to implement features that are specific to the filepicker of a browser, e.g. referring to whether or not the title of the page should be used as a default name or what became of the options "save as web page, complete; save as html; save as text" which where just wonderful to have???
What makes using the new filpicker outweigh all those advantages the old one had?

EDIT/PS: I wonder how difficult it could be to make a hidden preference that would simply enable the use of the old filepicker? Is this planned to remain in the code base for other OS at least -- e.g. what about Solaris?
User avatar
Thumper
Posts: 8037
Joined: November 4th, 2002, 5:42 pm
Location: Linlithgow, Scotland
Contact:

Post by Thumper »

On the other hand I wonder what the compelling reason for making this switch really was.


Unity with GNOME. That encompasses a dozen other reasons.

What makes using the new filpicker outweigh all those advantages the old one had?


At the moment, mostly wishful thinking. The required bugs could do with a lot more spec writing and a lot less stop energy / pointless commentary. (this isn't directed at you.)

EDIT/PS: I wonder how difficult it could be to make a hidden preference that would simply enable the use of the old filepicker?


How hard would it be to implement hidden options for every trivial UI difference of opinion?

Is this planned to remain in the code base for other OS at least -- e.g. what about Solaris?


Solaris has GNOME these days, and GTK2 is the only supported toolkit on Tier 1 Unix platforms anyway.

- Chris
User avatar
johann_p
Posts: 8479
Joined: November 5th, 2002, 3:05 am
Location: Sheffield, UK

Post by johann_p »

OK -- so does this mean that all the browser-specific features of a filepicker that would make a browser-user's life so much more easy (e.g. the one where one could specify how to store a HTML page -- HTML+all needed files, HTML only, text) will forever disappear from FF because they now use the GNOME filepicker for no apparent compelling reason?
“Two things are infinite: the universe and human stupidity; and I'm not sure about the the universe.”
User avatar
Thumper
Posts: 8037
Joined: November 4th, 2002, 5:42 pm
Location: Linlithgow, Scotland
Contact:

Post by Thumper »

Look, I know that it's partially due to the language barrier, but is there the slightest possibility that when you're replying to me you could refrain from phrasing things in a way which makes it sound like I am personally responsible? I'm fed up being attacked by you.

(e.g. the one where one could specify how to store a HTML page -- HTML+all needed files, HTML only, text)


No. This is a shortcoming of the GNOME save box. This is available in the native Windows file picker. Eventually this will be fixed.

For what it's worth, by the way, I think the GTK filepicker is an abortion from the eighth rung of Hell. The solution, however, is not to continue putting resources into maintaining a completely different third-party filepicker.

- Chris
Hendikins
Posts: 26
Joined: December 31st, 1969, 5:00 pm
Location: On a train

Post by Hendikins »

Thumper wrote:For what it's worth, by the way, I think the GTK filepicker is an abortion from the eighth rung of Hell.


Well, at least we all agree on something...
User avatar
johann_p
Posts: 8479
Joined: November 5th, 2002, 3:05 am
Location: Sheffield, UK

Post by johann_p »

Thumper wrote:Look, I know that it's partially due to the language barrier, but is there the slightest possibility that when you're replying to me you could refrain from phrasing things in a way which makes it sound like I am personally responsible? I'm fed up being attacked by you.

I swear that it was not meant as a personal attack -- on the contrary I am glad and thankful that you pointed out some of the background to what is going on here to me. If it sounded like I was attacking you, I apologize.

Maybe sounded a bit angry (but that anger is directed to whoever made that decision -- who is that, BTW?) because I do have trouble to see any sense behind this decision: if the GNOME filepicker is flawed/not ready yet and actually worsening the situation and if the XUL filepicker is proven to work in a stable way and is still better, why make the change? Or rather, why make it now and punish all Linux FF users by doing it? Keeping the old filepicker hardly would have needed any additional ressources, changing to the new one definitely did and probably will continue to do so.
Why take useful features away now, invest the work of changing this and live with a worse situation for an unknown period of time (Is there a plan of who the GNOME filepicker will be improved and when it will be ready? I have the feeling that some of the useful features one would like to have in a browser's "save" dialog will never make it into the standard GNOME filepicker)?

I also wonder why "Unity with GNOME" (whatever that really means) is such a compelling reason to outweigh all these problems?

Again, these questions are directed to woever knows about these issues. I would love to hear the person comment who is responsible for the decision, but I also think it could be something interested (Linux) users can and should discuss. After all, here is a better place to do this than in some bug description, no? Or should we all simply accept that those who make these decisions are totally immune to arguments no matter who good and well-founded they are?
Maybe I am wrong and there *are* good reasons for doing this and doing this now but maybe also I am right and and this should not have been done.
User avatar
Nanobot
Posts: 578
Joined: April 28th, 2004, 7:25 pm
Location: California
Contact:

Post by Nanobot »

I agree that the GNOME filepicker is pretty bad. I would rather have the KDE filepicker, but that probably isn't a realistic option. The XUL filepicker had several shortcomings as well, and I'd rather have a more native filepicker with the functionality of the XUL one intact. As it is, every option has pros and cons, and I don't see the decision as being an unreasonable one.

Still, between the XUL filepicker and the GNOME one, I think I would personally prefer the XUL one.
User avatar
Thumper
Posts: 8037
Joined: November 4th, 2002, 5:42 pm
Location: Linlithgow, Scotland
Contact:

Post by Thumper »

johann_p wrote:If it sounded like I was attacking you, I apologize.


Accepted.

if the GNOME filepicker is flawed/not ready yet and actually worsening the situation and if the XUL filepicker is proven to work in a stable way and is still better, why make the change? Or rather, why make it now and punish all Linux FF users by doing it?


Considering the change was made by people who are employed by Red Hat, I don't think it was malicious.

Keeping the old filepicker hardly would have needed any additional ressources, changing to the new one definitely did and probably will continue to do so.


You're going to have to explain how removing code increased the resource burden. It might have increased the burden on users who want to do things which the GNOME filepicker makes difficult, but that isn't the same as development resources.

Why take useful features away now, invest the work of changing this and live with a worse situation for an unknown period of time (Is there a plan of who the GNOME filepicker will be improved and when it will be ready? I have the feeling that some of the useful features one would like to have in a browser's "save" dialog will never make it into the standard GNOME filepicker)?


We've had the "utility versus usability" argument around here often enough, and I'm not in charge of GTK, but I assume improvements are planned. It was changed because people who are employed to make the GNOME desktop happen made it so. There are things which the new filepicker makes possible which were difficult or impossible using the old one too.

I also wonder why "Unity with GNOME" (whatever that really means) is such a compelling reason to outweigh all these problems?


Some people don't want to have to learn how to use a new filepicker for every application. Some developers would rather not have to maintain a filepicker for every application. In the end, the people who made the decision are the same people who hack the code in question, so they probably know what they're doing.

Or should we all simply accept that those who make these decisions are totally immune to arguments no matter who good and well-founded they are?


There's no point in bringing in absolutes here. The more extreme your language is, the less chance you have of convincing people to change their minds. If you aren't paying people to do your bidding, they're not going to have much time for moaners.

Occasionally the only way to get things fixed is to put in some elbow grease. I've whined about the menu bar sucking on XP for years, and ended up having to fix it myself (enduring the idiocy of hundreds in the process). My fix pissed off enough people to stir interest in the real bug, and it might get fixed properly by someone who knows what they're doing in time for 1.5.

Maybe I am wrong and there *are* good reasons for doing this and doing this now but maybe also I am right and and this should not have been done.


If you're going to get it reversed then you're going to need some solid arguments. Personally I think your efforts would be better served filing bugs on GTK's filepicker.

- Chris
User avatar
Thumper
Posts: 8037
Joined: November 4th, 2002, 5:42 pm
Location: Linlithgow, Scotland
Contact:

Post by Thumper »

Having just went and looked at the gtk filepicker: what the hell are you talking about? Right underneath the file chooser on the right hand side is a listbox which allows you to pick the save format.

- Chris
auk
Posts: 3
Joined: October 1st, 2005, 4:32 pm
Location: southern california, us
Contact:

Post by auk »

'Unity with GNOME' means a lot. it aids in accessibility and is a pretty good step forward in GNOME HIG compliance. i worship the Mozilla and GNOME projects, (in that order). i would aslo really like to see better xul/gtk integration.

there are several thigns that bug me in the GNOME filepicker, but the previous XUL filepicker had many more problems than the new one, for one, the gnome filepicker has much better navigation for higher-level directories and frequently visited places (home, desktop, etc).

what really bugged me in the xul filepicker was that there was no way to create a new directory, and that there was no distunguishing icons between different types of files. also i kept trying to right-click for various actions.
User avatar
Robert S.
Posts: 4399
Joined: April 24th, 2004, 3:04 am
Location: Bay Area, CA

Post by Robert S. »

You can change it back to the built-in filepicker by modifying the following in nsFilePicker.js which is located in the app's components directory. After making the change you have to re-register the components which is easily accomplished by disabling then re-enabling an extension and then restarting. Installing or un-installing an extension will also force a component registration.

Code: Select all

    compMgr.registerFactoryLocation(FILEPICKER_CID,
                                    "FilePicker JS Component",
//@line 278 *snip*
                                    "",
//@line 280 *snip*
                                    fileSpec,
                                    location,
                                    type);

to

Code: Select all

    compMgr.registerFactoryLocation(FILEPICKER_CID,
                                    "FilePicker JS Component",
//@line 278 *snip*
                                    FILEPICKER_CONTRACTID,
//@line 280 *snip*
                                    fileSpec,
                                    location,
                                    type);
Post Reply