Discussion of general topics about Mozilla Firefox
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.
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).
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.”
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.
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?
Unity with GNOME. That encompasses a dozen other reasons.
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.)
How hard would it be to implement hidden options for every trivial UI difference of opinion?
Solaris has GNOME these days, and GTK2 is the only supported toolkit on Tier 1 Unix platforms anyway.
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.”
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.
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.
Well, at least we all agree on something...
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.
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.
Considering the change was made by people who are employed by Red Hat, I don't think it was malicious.
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.
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.
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.
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.
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.
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.
'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.
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.
Who is online