Ars Technica Reviews Mozilla 837
Aglassis writes "This Ars Technica review gives mozilla 1.0 an overall score of 7/10 (9 for Gecko and 6 for the browser). The major detractor was the user interface, since it didn't feel like a Windows application. This was probably due to a poor understanding by the authors of XUL. Overall they say that mozilla would make a good substitute for IE 6 but there is no major reason to switch over."
tabs (Score:4, Informative)
Re:tabs (Score:1, Informative)
Re:There is no major reason to switch... (Score:2, Informative)
That's not to say that Microsoft isn't playing Embrace and Extend because CSS styled scrollbars still render styled in standards compliance mode despite the fact that those definitions aren't in the CSS standard anywhere.
Re:There IS a reason to switch over... (Score:3, Informative)
I believe the problem you are having is with IE's handling of shortcuts to URLs, which is all that Favorates actually are. If you have this option checked and hit a favorate, it will open the favorate in the last used window. This often turns out to be the first one you opened.
Re:7 is about right... (Score:3, Informative)
W3C [w3c.org] sets HTML standards. What you're suggesting is to let Microsoft determine HTML standards? HTML standards are there so that many people using many platforms from PCs to cell phones can access web pages. Microsoft's goal, on the other hand, is to have every PC, PDA, cellphone, TV, and video game user a Microsoft customer. Does that not seem like a conflict of interest?
If that's not what you are suggesting then it sounds like you are just to lazy to create proper HTML pages, prefering instead to settle with tool that requires the least amount of knowledge. However, there are better WYSIWYG HTML editors out there. Try Dreamweaver.
Long live text zoom. (Score:2, Informative)
Jynx
Re:its not a xul issue (Score:4, Informative)
It just lacks the spit-and-polish that other Mac OS X applications have. Mozilla doesn't get the text navigation shortcuts (option- and command-arrowing through text) quite right, it doesn't get the 'new document' behavior quite right (if it has no windows open and I click on the 'M' icon in the dock then it should create a window), the pulldown menus don't look quite right, it shouldn't hijack Command-W to close tabs instead of windows... sure, there's another project ('Chimera') to create a Mac OS X-friendly version of Mozilla, but there shouldn't *have* to be; the original Mozilla shouldn't be such a Frankenstein's monster on Mac OS X in the first place.
IMHO, the Mozilla developers made a very bad decision when they decided to create their own GUI toolkit from scratch rather than rely on the interface of each operating system Mozilla ran on. Sure, Mozilla's controls look the same on Mac OS X as they do on Windows and Linux and Be and OS/2 and OpenVMS... but who cares? I don't want it to look like a Windows application on my Mac. And having to reinvent the wheel and get all the buttons and scrollbars and pulldowns working right must have added at least a year or two to Mozilla's schedule, and they still need work.
Re:Mozilla e-mail (Score:2, Informative)
See the "Advanced" button under both Account Settings and Outgoing Server (SMTP) under Mail & Newsgroup Account Settings.
XUL is what .NET wants to be (Score:1, Informative)
MozApps shows the power of XUL.
Re:Tabs are great... (Score:2, Informative)
Have you looked into Multizilla [mozdev.org]? It's a much nicer tab implementation than the tabbed interface of the stock mozilla. Plus it's got a few other nice features, such as browser spoofing for the websites designed by lazy idiots who make everything IE only. Like any mozilla add-on, it's quite tiny, and worth a spin.
Re:Well... (Score:2, Informative)
Re:its not a xul issue (Score:2, Informative)
"This theme simulates the appearance of previous Netscape versions for the Windows operating system".
Sad, but almost true.
Re:its not a xul issue (Score:2, Informative)
This is the option that most developers prefer when writing professional cross-platform applications. It also helps to track down bugs in some cases, because your UI logic is separated more thoroughly from your core application logic (this bug appears only on this platform, therefore it's more likely to be in the UI or platform-specific code; this bug appears on all platforms, so it's most likely in the platform-independant code; not to mention not having to iron out bugs in the interface toolkit if the native interfaces are stable). Microsoft tried the 'one look on all platforms' thing with Office a couple of versions ago, and basically pissed off the majority of Apple users (and they have a larger percentage of the Apple market for office suite software than they do of the Windows market for office suite software), and eventually they went back to using the native OS' interface in the new version.
Re:It should "act" the same, too. (Score:1, Informative)
Re:There is no major reason to switch... (Score:2, Informative)
Re:Major Reasons to swtich: (Score:2, Informative)
Download an IE scin for Mozilla (Score:1, Informative)
Re:tabs (Score:2, Informative)
Re:tabs - not for me (Score:2, Informative)
Re:x-platform (Score:5, Informative)
Repeat a lie enough and it will become truth I guess.
The real skinny on XUL: It is not as slow as people make it out to be. It is not the reason for Mozilla having any speed problems. It *is* compiled into native instructions when your browser is up and running. This functionality made it into the tree some time ago. Too many people were howling about the slowness of XUL two years ago to notice apparently.
Don't believe me? Try running a profiler on Mozilla sometime and report back the hotspots. What's that? Even though the source is available and people have access to profilers, not one of the XUL naysayers here even tried? But that would mean that they pulled XUL performance stats out of their asses. (To be fair, a couple of years ago, XUL had some major redrawing and rendering issues -- not the case today. Maybe it's just a case of stale info that desperately needs to be thrown away) In addition, projects like Galeon are not faster because of native widgets (although it may have been the case a couple of years ago). IF you look at feature-to-feature, Mozilla does more than Galeon. Just look at the JavaScript engines, the DOM handling (the DOM debugger, the DOM inspector,
etc.), the fact that Galeon only runs on one platform(!), etc. Galeon is not Mozilla + native widgets. Galeon is Mozilla-- + native widgets.
Does XUL intrinsically look exactly like native widgets? No. Does the classic theme look very much like native widgets. Absolutely. Does the modern theme look like native widgets? No. Was it planned to look "native"? No! Modern theme looks the same no matter what platform you are on. If you want consistency of browser UI when using multiple operating systems (as I do), then use Modern. If you want something more akin to a native feel, use classic. If you absolutely want native widgets, use Galeon, K-Meleon, or Chimera. That's what these projects are there for!
As a side note, XUL is rendered by Gecko. You can't say that one is slow while the other is fast. They are different limbs of the same beast.
As was pointed out on the Mozilla performance newsgroup, there is no magic "native" flag that makes video cards paint faster. Whether a widget is linked from a shared library, compiled from C, or read from an XML file (and later translated to machine instructions), they all paint to the same canvas: the system graphics library. If MFC has some innate advantage here, I'm sure that the folks who write Qt and WxWindows would love to hear about it as well as they would no longer be "native" either.
The reason that Mozilla developers can handle the large number of platforms that Mozilla runs on is because of XUL. The code is amazing in its cross-platform purity. Fix a mail client bug here and it's fixed everywhere. Fix a UI bug there and its fixed everywhere. Contrast this with fixing a UI bug in the Windows code and it must be fixed in Mac (OS 9- and OS 10+), X (Xlib, GTK+ and Qt ports), BeOS, OS/2, OpenVMS(!), Amiga, etc.
I'm not saying that XUL didn't take a long time. I'm not saying that it saved a whole lot of development time until recently. What I am asserting is that all new bugfixes and enhancements can now happen much faster (and have been for the last year or so) than would be possible with native libraries and widgets. And it's not like Mozilla isn't modular and reusable; how do you think Galeon and K-Meleon were able to be released so quickly? They whipped up a barebones UI up on the infrastructure written by Mozilla developers. If you like Galeon, K-Meleon, and Chimera, it probably has more to do with liking barebones UIs than an inherent deficiency in Mozilla's UI. That said, if that's your preference, more power to you. Just don't shit on someone else's meal when your food comes from the same kitchen.
What the Mozilla developers have done is akin to shunning assembly language for C. Back in the day, C was slow and bloated as compared to hand-crafted assembly. Then people noticed that they wrote more and with fewer bugs with C. Then the compilers got better. Then assembly didn't make much sense except in small niches. Imagine! Writing your UI in a simple text file and handling UI events in a simple scripting language. Don't like the UI colors? Just edit CSS files instead of editing
But I can hear it now. "But it's not as fast as compiled UIs." "It uses more memory." In a couple of years, advances in the rendering engine and the XUL processor (think 'compiler') will narrow the gap so far as to make the gap imperceptible. It's assembly versus C all over again. Which side do you want to be on? Personally, I think life is too short for recompiles.
If you want to get down and dirty, recompiling at every step, write an operating system or help out on the Gecko renderer and XUL processor. For everything else, there's XUL, scripting, and CSS.
be constructive please (Score:3, Informative)
Stop accepting things like they are, change the world (of software) now!
Can you be a little more specific? How wold you like your browser to look and act, besides like IE? The "cited usability problems" were that the thing did not act like IE. Here's what some constructive criticism looks like:
IE user interface problems noted under win2k:
"Favorites" can't have characters in their names that mess with old DOS conventions.
ftp, http, local files are remembered and treated sepearatly. This artificial division makes swithching between the different "zones" difficult to do and makes the history file much less useful.
User settings are poorly organized vary from version to version. Typically kept under multiple menue items and burried in a forrest of tabs in nonsensical dialogs, IE's user settings are both harder to find and less empowering when located.
Abomnible on off control of scripting, no image control. Adverts are impossible to turn off.
Fav icon suffers from typical M$ bugs. Often loads wrong image, takes forever to display. Gives user information away without asking.
ftp site browsing sucks. The psuedo Apple triangle file tree browsing is much much better than IE's stupid attempt to make ftp sites look like local folders. Confusion is not integration, Micro$oft. ftp site non response locks up entire interface. Talk about pathetic.
Those are some things off the top of my head. I rarely use IE at work, but sometimes I have to. When I do, I notice that kind of crap. If all of these problems were to be fixed, you would have something much closer to Mozilla. That's what the open source folks did - they changed the software they had available and made some new stuff bassed on user wants and best practices. This was done while M$ was bussy catching up to Netscape 4, and adding new hooks to their other software that no one wanted, and works wretchedly today. What kind of input do you think M$ got for IE? It took advice from content pushers and advert makers. Pthththt!