Slashdot Mirror
QT Mozilla Port
LowneWulf writes: "Check it out! The Mozilla QT port has finally been checked into the Mozilla tree! Annoucement from the author here."
The sad part is that I've switched to mostly using Konqueror these days. Less memory. Less crashes. Loads faster. AA fonts look better. Mozilla has a ton of excellent functionality that I look forward to getting in on (plus I've had a few compatibility problems with javascript and Konq). But its cool to see this coming along.
Two points:
1) What Moz wants more than anything else is to spread the renderer (and hopefully the plug-in model) as far and wide as possible. They don't care all that much about the chrome and all. If that spreads, great... but I get the impression that spreading the renderer is just as important if not more so. Hence, embedded apps (which includes not only "net appliances" but also QT, GTK, and (gasp) AOL) are a prime concern and they spend a lot of time making sure that embedded support is done correctly.
2) I get the impression that QT is not actually "supported" in any meaningful sense. In other words, like the OS X and OS/2 ports, Moz puts it in CVS and provides ftp space and supports it in that way. But they don't actually support it in any meaningful way- i.e., programmer man-hours. In this sense, the QT and other OS ports are proof that Open Source has worked for Netscape- it has allowed others to come in and contribute, reducing cost and maximizing impact for Netscape.
~luge
IAAL,BIANLY
The basic answer is that the 5% of the code that is not cross-platform is a lot of the most performance sensitive code in the product (graphics rendering, networking, file access, etc.) Mozilla/Netscape have poured tons and tons of man-hours into optimizing that code on Windows. Those hours (since they are in non-XP code) do very, very little for the other platforms. In contrast, they've put very little time or money into optimization on Linux and other platforms. Obviously, they've optimized the XP code as much as possible, but that only goes so far- the lowest level stuff is where a lot of optimization work has to go on, and that just hasn't happened on Linux yet. IMHO, optimizing that stuff is where old-school Linux gurus could be of the most help- learning the guts of Moz isn't easy, but that type of stuff is "just" X calls and things like that, where folks not very familiar with Moz but intimately connected to X and other common sub-systems might be able to make a quick and important contribution. Until there is both marketshare and serious competition in Unix, Netscape/Moz isn't going to do it for us.
~luge
IAAL,BIANLY
Firstly, mozilla isn't really "slow". Its a complex little beast. Its less a "web browser" and more an application framework with built in Javascript engine and cross platform GUI descriptor langauge (XUL).
Practically the entire 'application' is built from XML and Javascript. That's why its so themable and is also why it is being used to develop cross platform applications (www.activestate.com - check out Komodo).
To bypass the slowness, get Galeon. (galeon.sourceforge.net). The latest version is stable and is Just A Web Browser. You need mozilla installed as Galeon uses it as the HTML engine but none of the extra stuff (mail, news, composer) are enabled and it flies along really nicely.
It very rarely crashes, copes with plugins and java perfectly (well, wherever I've tested that anyway) and has a really nice recovery mode which reverts to the open pages you had if ever it does loose its sanity (a very useful feature).
It you want to know how good the vanilla HTML handling in Mozilla is, try it. You really won't be disappointed.
At least the concept is not new. There was something called QTScape done a very long time ago right when the Mozilla project first started. Of course back then the code was based on the old Navigator code and is completely outdated. Its good to know there is some work being done on this though. I think that using the QT toolkit good give Mozilla a significant speed improvement. I know that Konq. is fast as well but it would be interesting to compare the speed of these two browsers when they run on the same toolkit. I have a feeling that Konq. would still be a little faster but perhaps not by nearly as much. Plus Mozilla has many features that Konq. doesn't have.
Seems like a great browser, but when I installed KDE 2.1.1 and loaded up Konq, I couldn't try to load any web page without it crashing. Is this common, or just an oddity for me. It really annoyed me, was looking forward to trying it out. Galeon works like a charm however, and plain mozilla is too sluggish to pay any attention to whatsoever. If netscape 4.x wasn't so ugly viewing a lot of pages nowadays, it would still be my browser of choice, it still seems to render faster than any mozilla-based project. Can't wait to see a Mozilla 1.0 with all the sluggish debugging ripped out. I wish there was a branch where debugging was removed just to show off what mozilla could be capable of. Maybe then we wouldn't criticize that so much.
XML is like violence. If it doesn't solve the problem, use more.
Oddly enough, as times pass and IE gains market share, it gets MORE standard compliant than it ever was. The new IE 6 even goes as far as not being compatible with IE 5.5 and below so that it is more strictly compliant with HTML 4.0, XHTML and CSS 1 & 2 (don't worry, there's a switch to drop the compatibility mode and use the strict standard mode, the compatibily mode being run by default).
One good thing with the lack of competition in browsers is that Microsoft doesn't feel the need to divert from the standard and introduce new funky tags. I'm not saying this won't change to something worse, or that we won't see "Windows only" functions spring back to life, but for now IE 6 is the most standard compliant browser ever, while being the one who face the smallest competition ever.
Please before flaming me go read the IE 6 preview papers first...
I'd just like to step in and tell you that "Amiga weenies" are the most loyal, intelligent, and mature computer users I've ever known. They support the best technology. Period.
------
And that question is:
Why is Mozilla so much slower on Unix than on Windows?
And I have a question of my own to ask:
Can the "chrome" be scraped off of Mozilla, and replaced with GTK/QT/whatever?
- - - - -
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
Why can't I compile any app with QT support?
More to the point, why doesn't QT allow me to compile GTK apps against it, or vice versa?
Remember X2 and K56Flex? No? They were two different 56k modem standards. Both groups expected their implementation to be ratified by the International Telecommunications Union, who were going to analyse the points of each and decide of a 56k standard.
In the end, the ITU decided that both standard had their good points. V90, a standard that took the best bits of K56Flex and X2 and combined them into a single standard, became the order of the day. And the crappy X2 / K56Flex incompatibilities died a graceful death.
Could an independent group such as LI do the same to GTk and QT? This would solve...
1) Wasted memory.
2) Lack of consistent appearance.
3) Lack on consistency in widget behaviour.
4) Some of the lack on consistency in UIs, but not much.
5) Lack of solid cross platformability for particular toolkits. I am told GTK for Win32 is not the best right now. A solid cross platform Unix-based / Windows toolkit would help Open Source Unixes a great deal
6) Limitations of widget availability between both toolkits.
Please bear in mind this is a completely different concept to merging KDE and GNOME, which have less to do with Qt and GTK than many people think.
Thoughts anyone?
You can't really compare these two as projects, because they have completely different goals. Mozilla has to work on 3 different platforms. When Mozilla was started, there was no mature widget set that they could use for the Mac, Win, and *nix, so they had to build their own (in the form of XUL/JS) while they were building the app that used it! (Also note that this UI system was built optimized for Win32)
The Mozilla project is also focused on embedding their layout engine into other products, such as the upcoming AOL for linux release. They've also built a really nice email client too, which is on-par with most other free email clients, such as outlook express.
Konqueror, while a really cool web browser, has had just one goal: surf the web, on unix, on X, and on KDE2.
Side note: due to the excellent design of both these projects, we can now expect a mozilla KPart, that we can use to browse the web through konqueror using the mozilla layout/js engines, very soon now! I think it's already in the works...
--
python -c "x='python -c %sx=%s; print x%%(chr(34),repr(x),chr(34))%s'; print x%(chr(34),repr(x),chr(34))"
Of course, you chose to only respond to one side of his rebuttal. You also said: "This is like asking why you can't compile a C++ program against glibc..."
Which is exactly what I just showed.
Anyway nitpicking whether a C++ program can use C functions overlooks the original point that libraries have to have the functions you want to use. Would you have preferred if I said "That is like trying to compile a Java program against libstdc++ or a C program against rt.jar?"
You most certainly can call libc functions like 'printf' and 'fgets' from C++ programs
Really. Is this because libc is also used by g++ when compiling C++ programs or that libstdc++ reimplements the functionality of libc. Either way your argument is pointless with regards to the original point that the library needs to have the functions you require.
Write a library in C, and every single language under the sun can easily talk to it.
Oops, now I realize I'm being trolled. You got me. IHBT. IHL. HAND
--
What's the real purpose in supporting ui ports (GTK+, Qt) if the Mozilla languages (XUL, etc) are supposed to replace those (to be more cross-platform friendly)?
Right, but it's still a legitimate question to ask which is a more sensible way to go about it. The reality is that the Konqueror team has come up with a pretty solid browser for Unix and embedded Qt with a tiny fraction of the resources and experience of the Mozilla project. Meanwhile, after all the labor invested in XUL/JS and the performance penalty it enforces on the browser, what do they have? The Mac version is pretty much despised for its poor performance and Mac integration (especially compared to Mac IE, which kicks ass) and the Unix version is dog-slow.
If I were Steve Case, I'd be asking why they didn't just maintain Windows, Mac and Unix ports (keeping as much of the rendering engine cross-platform as possible) and make them each as good as possible. As it stands, they've pretty much conceded Windows and Mac market share to Microsoft, and now their monopoly on the Unix browser is crumbling.
(Yes, I know, if I'd just try the latest nightlies, I'll see that everything has changed. ;-) )
Unsettling MOTD at my ISP.
A feature I think that would be cool in Mozilla would be a bit of code like:
If ( ImageSize == 468 x 60 ) && ( KillAds == 1)
Image = Transparent468x60
Where the "KillAds" boolean is set in the preferences menu... Hell, maybe someone has already done this. I think I heard some talk that AOL would never allow such a feature to be included, but it would be easy enough to add in, I guess...
PK: 09F911029D74E35BD84156C5635688C0
Now if only they could address your other complaints...
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
-
-
-
-
-
-
Please bear in mind this is a completely different concept to merging KDE and GNOME, which have less to do with Qt and GTK than many people think.QT and GTK use different langages (C vs. C++ - yes that's too much of a difference to compensate for in any reasonable way).
If this came about, what would be the point of having 2 toolkits anyway? Why don't we all just switch to Win32 programming and use WINE? One toolkit is better than 2, right?
KDE can import your GTK+ and IceWM themes, making "lack of constant appearance" a matter of user choice.
What lack of consistency in UIs? Buttons, scrollbars, checkboxes, radio buttons, dockable toolbars - these concepts are almost identical in both toolkits. The only difference is in their appearence (KDE puts two buttons at the bottom of a scrollbar, but only in some themes, etc - this would be solved by QT importing GTK themes).
Making GTK compile QT apps (even though it's really impossible) would not help the stability, speed, or functionality of the Windows port of GTK, so it wouldn't help get a quality free toolkit for Windows any more than simply working more on GTK for Win32 directly.
Finally, the "limited widget availability between both toolkits" problem is about to go away. With QT-GTK and GTK-QT widgets almost ready and XParts in the works, programs for either toolkit can use widgets or components (think KParts/Bonobo) from both.
What? It has everything to do with QT and GTK! GNOME was started for the express purpose of providing a desktop environment based on something other than QT. If KDE and GNOME used the same toolkit, merging them would almost be a trivial task. Their choice of toolkits is the only thing really keeping them apart.
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}