| |||||||||||||
Firefox GTK+ IntegrationFirefox GTK+ IntegrationPosted May 27, 2008 17:03 UTC (Tue) by dskoll (subscriber, #1630)In reply to: Firefox GTK+ Integration by GreyWizard Parent article: Fsyncers and curveballs (the Firefox 3 fsync() problem)
Breaking working code and slowing down fast code are consequences of making progress toward other goals that the developers believe are more important. True, but what do users believe to be more important? And usually by the time you have a "Release Candidate", you've fixed up the obvious breakages. As I wrote, I don't use KDE, so I'm not looking for a KDE/Qt browser. I do get alarmed when Firefox developers break stuff and don't undo the breakage. For example, I filed a bug asking for Firefox to default to the (fast) built-in filebrowser dialog (which still ships!) rather than the (slow and broken) GTK+ filebrowser, but met with a negative response. So the question is: If you ship a superior filebrowser, why do you choose to use the stupid one by default??
(Log in to post comments)
Firefox GTK+ Integration Posted May 27, 2008 17:33 UTC (Tue) by GreyWizard (guest, #1026) [Link] Hopefully the users and developers agree about what's important but the users are more numerous and their opinions vary more. To make matters worse, each believes he or she is representative of the rest. For example, you're asking for continued default use of a custom file browser for the GTK+ port and you seem to believe this is what everyone wants or should want. It's not what I want. I want the same file browser every other GTK+ application uses. That saves me the trouble of mastering the quirks of two incompatible systems for doing the same thing. I don't mind working around a few bugs for a while to get there. Which of us is actually more representative of the mainstream of Firefox users is a difficult question but for now the Firefox developers seem to think it's me. I won't argue with that. :-)
Firefox GTK+ Integration Posted May 27, 2008 20:25 UTC (Tue) by dskoll (subscriber, #1630) [Link] Hopefully the users and developers agree about what's important but the users are more numerous and their opinions vary more. Yes of course! That's part of the joy (challenge?) of actually having customers. Commercial software producers (like my company) have to listen to their customers. Open-source ones should too. For example, you're asking for continued default use of a custom file browser for the GTK+ port and you seem to believe this is what everyone wants or shouldwant. I don't specifically want the use of a custom file browser. I want the continued use of a fast file browser. We're talking orders-of-magnitude speed difference: http://lwn.net/Articles/279345/ I want the same file browser every other GTK+ application uses. Even if said file browser is three orders of magnitude (yes, 1000X) slower?
Firefox GTK+ Integration Posted May 27, 2008 20:58 UTC (Tue) by GreyWizard (guest, #1026) [Link] Yes, even if the GTK+ file browser is three orders of magnitude slower I'd rather use it. Don't get me wrong, I would be happy to see whatever bug is causing that performance difference fixed but it's just not a problem for me in practice so I won't be the one submitting the patches. I spend at most a fraction of a percent of my time at the computer using the file browser and I believe that's true for most people. Optimizing it in just one application at the expense of a consistent user interface is a poor trade. As for listening to customers, you're implication that free software projects don't is mistaken. They do, but there are too many users with too many requests to satisfy everyone, just as there are for successful proprietary products. Available resources are spent according to what seems to be most important. You clearly have a different idea of what's important than GTK+ and Mozilla developers but this alone doesn't prove that they're wrong.
Firefox GTK+ Integration Posted May 27, 2008 23:10 UTC (Tue) by dskoll (subscriber, #1630) [Link] Yes, even if the GTK+ file browser is three orders of magnitude slower I'd rather use it. * boggle * OK, you've got me there. :-) Optimizing it in just one application at the expense of a consistent user interface is a poor trade. Well, the Firefox developers still ship their own (fast) filebrowser, something no GNOME app does. Why is that, I wonder? Consistency is overrated, IMO. If I wanted a brain-dead-boring "consistent" interface, I'd get a Mac (and I'd feel like I was wearing a straitjacket). I like my tweakable idiosyncratic interface, thanks, especially if it gives me a 1000x speedup. Anyway... this is getting a bit off the original thread topic, which is that FF3 has introduced several important regressions. If printing used to work and is now broken with no workaround by printing to a file, I don't really care about developer goals or justifications. From my point of view, it's just a project moving in the wrong direction.
Firefox GTK+ Integration Posted May 28, 2008 10:46 UTC (Wed) by Los__D (guest, #15263) [Link] If printing used to work and is now broken with no workaround by printing to a file, I don't really care about developer goals or justifications. From my point of view, it's just a project moving in the wrong direction. NOTABUG, the problem is with your system, not the browser.
Firefox GTK+ Integration Posted May 28, 2008 11:47 UTC (Wed) by dskoll (subscriber, #1630) [Link] ISABUG. Even if you find no printers, produce Postscript.
Firefox GTK+ Integration Posted May 28, 2008 11:57 UTC (Wed) by Los__D (guest, #15263) [Link] FEATUREREQUEST ;)
Firefox GTK+ Integration Posted May 28, 2008 13:09 UTC (Wed) by dskoll (subscriber, #1630) [Link] REGRESSIONNOTAFEATUREREQUEST. :-) FF 2.0 will produce PostScript even if it doesn't detect printers, AFAIK.
Firefox GTK+ Integration Posted May 29, 2008 0:07 UTC (Thu) by roc (subscriber, #30627) [Link] Sure, because FF2 had its own print dialog with its own CUPS integration etc. But there were a lot of problems with that, so we switched to the GTK+ print support. Now you will say that to ensure things keep working for all users, we need to ship support for the old print code as well as the GTK+ integration code. Of course, if we did that, people would complain about bloat. Can't win.
Firefox GTK+ Integration Posted May 29, 2008 2:53 UTC (Thu) by dskoll (subscriber, #1630) [Link] I don't care if you only ship a print dialog with gtk+ print dialog support providing you have a way to generate Postscript to a file. Surely the Postscript rendering code needs to be built into Firefox anyway?
Firefox GTK+ Integration Posted May 29, 2008 5:53 UTC (Thu) by roc (subscriber, #30627) [Link] We wouldn't want to provide "available by default" UI for a feature that only people with broken print setups would use. Someone could write an extension though. This PDF output extension might work for you if you can post-process the PDF. It probably only needs slight tweaks to make it output PS instead. https://addons.mozilla.org/en-US/firefox/addon/5971
Firefox GTK+ Integration Posted May 29, 2008 12:45 UTC (Thu) by dskoll (subscriber, #1630) [Link] Print-to-PDF extension is perfect. Thank you!
Firefox GTK+ Integration Posted May 28, 2008 18:57 UTC (Wed) by GreyWizard (guest, #1026) [Link] Are you seriously unable to understand why Firefox ships their own file browser while GTK+ applications don't? Seriously? Have you ever participated in a substantial software development project in any way? That's a rhetorical question: it's clear that you haven't. If you had you might understand that micro-benchmarks are not a sane way to judge entire applications, that development resources are limited and that no project can be all things to all people. It's too bad you're not happy with Firefox 3. I am. The developers have clearly put in a tremendous effort and have done an excellent job improving things that really matter including memory management, Javascript performance and platform integration. I'm impressed with the result and grateful for the hard work that made it possible. I think I'm not alone.
Firefox GTK+ Integration Posted May 28, 2008 19:53 UTC (Wed) by dskoll (subscriber, #1630) [Link] Are you seriously unable to understand why Firefox ships their own file browser while GTK+ applications don't? I understand it perfectly. What I don't understand is why they don't use it by default. The gtk+ fans could always change the setting to get the gtk+ browser, but it seems to me that you should choose sensible defaults, not orders-of-magnitude-slower defaults. Have you ever participated in a substantial software development project in any way? That's a rhetorical question: it's clear that you haven't. Funny man. I've been writing both commercial and open-source software for the last 18 years in areas ranging from large EDA systems to image-processing, text-processing, networking and personal productivity tools. I own a company that develops commercial software. If you really want, I can e-mail you my resume. However, you don't need to be a software author to realize that breaking formerly-working functionality (especially core functionality like printing) is a Bad Thing.
Firefox GTK+ Integration Posted May 28, 2008 19:55 UTC (Wed) by dskoll (subscriber, #1630) [Link] Oh, one more thing, I'm immensely grateful to the Firefox developers. All of my criticism is only intended to make Firefox better; I don't mean anything personal by it.
Firefox GTK+ Integration Posted May 28, 2008 20:29 UTC (Wed) by GreyWizard (guest, #1026) [Link] As I've already explained, using the Mozilla file browser by default would be the wrong choice. For most users the GTK+ file browser is used infrequently and works more or less instantaneously. Almost no one would even notice a three order of magnitude performance improvement in an number that's nearly zero. But they most certainly *would* notice and suffer from a file browser that's inconsistent with the rest of their working environment. Cognitive resources are much more important than the computational kind, so doing what you ask for would be a serious usability mistake. Now, you may have some unusual usage pattern that makes you particularly sensitive to file browser performance. Go ahead and switch to the built-in file browser if that helps. Better yet, find the bug in the GTK+ file browser and submit patches. But don't burden everyone else with poor usability just to satisfy your absurd obsession with a boring corner case. No, I don't want your resume. That would be even less convincing than your chest thumping about "18 years" of writing software. Whatever your experience you've somehow managed to avoid mastering enough of the fundamentals to understand why breaking printing functionality for one user out of millions in a release *candidate* that delivers major performance improvements and new features is not a catastrophe.
Firefox GTK+ Integration Posted May 29, 2008 1:37 UTC (Thu) by ikm (subscriber, #493) [Link] > Almost no one would even notice a three order of magnitude performance improvement in an number that's nearly zero You should try "Open with..." sometimes. Then you'd actually understand what the fuzz is all about here.
Firefox GTK+ Integration Posted May 31, 2008 3:00 UTC (Sat) by GreyWizard (guest, #1026) [Link] I have. I use it quite often with Firefox 3 Beta 5 on a low end laptop and it's practically instantaneous for me. I'm not sure what your problem is, but the right answer is to identify the bug and fix it in GTK+ not to leave an inconsistent file browser as the default.
Firefox GTK+ Integration Posted May 29, 2008 2:50 UTC (Thu) by dskoll (subscriber, #1630) [Link] For most users the GTK+ file browser is used infrequently and works more or less instantaneously. Umm... have you tried it? Try the Open With... dialog. Look, I don't know what percentage of Linux users use GNOME, but it's probably 50% or less. So the people who don't use GNOME have the choice between an irritatingly non-standard but fast file browser, or an irritatingly non-standard and agonizingly-slow file browser. GNOME users are luckier; at least their agonizingly-slow file browser is "standard". On my machine, the gtk+ browser takes about 25 seconds to browse /usr/bin wherease the Mozilla version is too fast to time. Why is that? The gtk+ browser, when faced with files without extensions, opens and reads a bit of every single file to identify the file type (by "magic") so it knows which pretty little icon to display. If that isn't abominable, I don't know what is. Better yet, find the bug in the GTK+ file browser and submit patches. I filed a bug with the gtk+ authors. Someone else has even submitted patches. They have not (to my knowledge) been accepted. As for breaking printing not being a "catastrophe", you are right. But it is a major regression and stumbling block, and to argue otherwise is simply absurd.
Firefox GTK+ Integration Posted May 31, 2008 3:35 UTC (Sat) by GreyWizard (guest, #1026) [Link] I suspect you're running an ancient version of GNOME and GTK+. On a Fedora 9 system browsing /usr/bin from "Open with..." seems snappy to me even on a low end laptop. Most likely the file magic problem you're describing got fixed some time ago. Furthermore your point about GNOME is similarly outdated because the file browser is part of GTK+ itself these days. So it's standard for all GTK+ applications. Breaking printing for all users would indeed be a catastrophe (or at least it would in a final release, which hasn't happened). But that isn't the case here. So far all we've established is that printing is broken for one user with an unusual configuration. That's unfortunate and certainly a stumbling block -- for you -- but it's not a major regression from the perspective of the Firefox team and certainly doesn't indicate that the project is moving in the wrong direction. To argue otherwise is to expose an inflated sense of your own importance.
|
|||||||||||||