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.

5 of 204 comments (clear)

  1. Re:Good question in "talkbacks" by luge · · Score: 5

    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

  2. How to Fix Mozilla's Slowness by Phill+Hugo · · Score: 4

    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.

  3. Here's an idea by Nailer · · Score: 4

    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?

  4. Re:Mozilla vs. Konq, development time... by dimator · · Score: 5

    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))"
  5. Re:Mozilla vs. Konq, development time... by update() · · Score: 5
    You can't really compare these two as projects, because they have completely different goals.

    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.