Developers from Nokia and Mozilla have been working hard to port the Mozilla Platform and Firefox to Qt and there are now some solid results available. An experimental build of Firefox Qt is available, and you can download the sources from Mozilla's mercurial repository. The plan is to merge the Qt branch into the central Mozilla branch to make the port official. KDE Dot News spoke to developer Oleg Romaxa from Nokia who came to Akademy 2008 from Finland.
Why did you do this port?
Because we were going to make Maemo use Qt in the future and we were making a browser based on Mozilla for the N810, so now we are making this new browser version based on Qt. Before, there was no Qt port available for Mozilla. It only took us 5 days to port it. We asked for help from Mozilla and they sent a team to Finland for a week.
What's the current state of the port?
The Qt port is mostly ready now for our browser. For full Firefox support, we need to implement XUL widgets, theming, and make some implementation for Flash player (NPAPI) support: it works but doesn't currently draw anything.
Will this be supported in future?
Yes, we will support it. We will cooperate with Trolltech to ensure it continues to be supported.
What is Mozilla's interest in this?
Mozilla are interested in mobile devices. Nokia make mobile devices, and will be using Qt. If you look at the mobile Firefox requirements, Qt support is in that.
Why are Nokia now developing two browsers? This one and QtWebKit?
Nokia will use the best browser for the job. Currently, we cannot make a full-featured and integrated browser with WebKit in mobile. But with Mozilla, we do not need to do anything, we can take existing models and API's which are available. Also, NPAPI support is already in the Gecko web rendering engine. They are also concerned that WebKit is to some extent controlled by Apple, who are in competition to Nokia with their iPhone.
What are you hoping to get out of Akademy?
I'm hoping to find people and ask them what they think about the Qt port and having Mozilla integrated into KDE. So far people are just talking about WebKit.
Will distributions package it?
That would be interesting to know. Maybe Kubuntu would like to have it...
Also, i've heard of Russian companies making KDE-based distributions and they might be interested in having Firefox without having GTK installed.
Do you think Mozilla will get rid of GTK?
No, Mozilla will support officially only the ports they have a particular interest in. If it helps to expand their market they will be more interested.
Where can people find more information?
There is a branch available on Mozilla's Mercurial repository. http://hg.mozilla.org/users/romaxa_gmail.com/index.cgi/mozilla-qt/ is the latest branch, it should soon be merged when I fix a final outstanding bug.
What needed doing for the port?
We ported Cairo to gain a QPainter backend. It's not full-featured, but it's enough for a web browser. Qt's implementation of the Cairo backend is much simpler than with GTK, because Qt is better able to integrate graphics and widgets.
Can the Cairo backend be used for other Cairo applications, like swfdec?
I'm sure it's already possible to do most of what's needed, images and compositing are there. It's not fully implemented but it's mostly complete. We are talking to Cairo developers to push the Qt backend into the Cairo source tree.
Nokia will introduce Qt to the maemo platform in addition to GTK+.
"They are also concerned that WebKit is to some extent controlled by Apple, who are in competition to Nokia with their iPhone."
If Nokia is concerned about Apple's control on WebKit, that's a pretty bad sign, isn't it? KDE should be even more worried, because there are less resources to push the development to where KDE needs.
Is normal that Company Foo is only interested to do what is useful for Company Foo's customers, and likewise for Company Bar. But that makes me think if there is an organizational way of making all parties happy, or we will end seeing plenty of branches. I wonder if something like the Java Community Process would had prevented KHTML's fork, or if Apple's secrecy would blow it all no matter what KDE would do on its side.
Which direction does KDE need for WebKit that's incompatible with Apple's? Performance and standards support are best for both.
And it's been said before but if it turens out that Apple is somehow hostile towards KDE, GNOME, Nokia, and Google (Android) then these organisations can fork WebKit at any time. WebKit is free software -- no matter who hosts the SVN repository.
"Standard support" is a nebulous thing. First of all, standards change.
Mozilla people think EcmaScript 4 would be a great thing for the web,
while I think it's a disaster, and hope we'll never have to support it.
A lot of the things that Apple likes to back --- things like CSS transforms, etc., ---
I would judge to be bloat and hope they would be kept away from the web,
in part because I don't think our primary graphics platform is
well-suited for it. Of course, I tend to be a minimalist on those things,
and I am not a huge fan of web applications as-is (well, the most popular ones
get an increase in the user's mobility at the expense of the degree of their
control over their data).
"Performance" also doesn't exist in vacuum --- often times performance improvements result in increase in complexity and decrease of maintainability of code
and do not provide any tangible benefit besides looking good on marketing materials
(and yes, I am guilty of that as well, though largely because performance stuff is fun). Apple also seems to have strayed away quite a bit from KHTML's founding KISS philosophy, in part for performance optimizations.
And while it's been said that people can '"just' fork Foo' repeatedly, lots of wrong things have been repeated many times. And this one is one of them. Most of these organizations are just mainly port masters thus far (well, Google isn't, and KDE isn't involved, period), and there would have to be a lot of readjustment of roles, etc. to get something like that off-the-ground. And the increased complexity of the codebase, and its readjustment into commercial-vendor centric development make it even more difficult. The community structure and technical roles would have to adjust dramatically. Can it happen? Sure.
Can you assume that it'll happen if needed? Nope.
And yes, people always bring up egcs and Xorg just about now except... those weren't actually forks --- they were disputes over governance of projects between the actual development community and the community's "leadership", which basically ended up with the developers telling the leadership to lead the empty set.
Having said that, I have a lot more trust in the direction of Apple's team than Nokia's/TrollTech, since they:
1) Have at least talked to us consistently over the last few years. I won't call it a cooperative technical relation (there is an awful lot of talking past each other), but a friendly acquaintance is better than nothing, and there were improvements going both ways from some discussions. And really, while I am being 100% unobjective, a "hi" goes a long way towards building trust. We have a reasonable understanding of where we stand, of what our differences in technological philosophies are, and I have a great deal of respect for Apple's developers.
On the other hand, most QtWebKit developers don't even seem to communicate with the KDE development community outside of aKademy and the occasional "hey, look at cool stuff we're doing" blog posts. This has fortunately changed a bit lately since Ariya at least hangs out in #khtml.
2) While Apple competes w/Nokia on cell phones, and they compete with KDE on desktop (well, we -wish- we competed with them on desktop, anyway...) they -are- on desktop, and they value a lot of things we value as well (or at least used to, pre-4.0 *sigh*): consistent, integrated, desktop experience with full-featured native applications. Nokia's business pushes them in an opposite direction, where their focus is near certainly away from the desktop.
Yes, Apple competes with KDE on the desktop, but Apple also learned that collaboration on underlying libraries helps them just like Novell and Red Hat benefit when both work on the Linux kernel.
WebKit started rocky but later evolved into a platform agnostic framework. I think it's awesome that KDE technology through WebKit is now being integrated into GNOME.
Even though Apple employs most WebKit developers, the WebKit project itself is now meant to be an independent technology provider. That's something that can't be said about Mozilla. Gecko releases are bound to Firefox releases and that's one major releases roughly every two years. (Gecko 1.8 was released with Firefox 1.5 at the end of 2005, Gecko 1.9 was released just recently.)
You know what's funny about this whole nonsense? There have been declarations and forests destroyed (figuratively) about the wonderfulness of Webkit, QtMozilla and on and on.
You know what I can use today? And have been able to use for the last number of years? Khtml.
I thank you and the khtml crew for that.
Odd isn't it.
"+1", as they like to say.
For those who love Konqueror, more power to you. I'm happy you enjoy your browser. Whether or not KHTML is a great rendering engine I'll likely never know, because I so greatly prefer the features and interface that Firefox offers.
Okular is this great viewer now. Dolphin is becoming a great FM. I'd really like to see a dedicated browser. If Konqueror is going to be a super-app, let it pull from each of these projects dedicated individually to being the best apps they can be. Konqueror is already pulling kparts from Dolphin.
I hope/assume this is the future of Konqueror.
Indeed. You are able to use and enjoy Firefox now and have been able to for quite a while.
My point isn't about which is better or worse. With all the noise about all these wonderful things, it comes down to you having firefox, me having khtml. I am not convinced that anything will change.
Theres a couple dedicated browsers for KDE in the early stages of development. Theres Eureka (http://kde-apps.org/content/show.php/Eureka+Web+Browser?content=84590) which is based on KParts, it looks rather minimalistic (at least currently). Theres also Foxkit (http://www.kde-apps.org/content/show.php/Foxkit+Web+Browser?content=82962, disclaimer: I develop it :P) which directly uses QtWebKit (and not KParts) but really isn't ready for prime time yet.
"I so greatly prefer the features and interface that Firefox offers."
Could you go into some detail here? Just curious since I'm developing a potential competitor :P
Add-ons and extensions are great, but I can't see any other browser supporting Firefox add-ons, unless they bring in XULRunner, which isn't likely to happen (I assume).
Some Firefox things I love include dragging and dropping tabs to rearrange them. I love the awesomebar. I love the menu and interface being designed for web browsing, and not file managing. Conversely, I like my file manager interface to be designed file managing, and not web browsing. I like being able to have my bookmarks in folders, and tag them as well. I love built-in spellcheck. I like a built-in download manager. I like having a built-in RSS reader.
For all I know, Konqueror does many of these things. However, I stumble with the interface enough, and prefer some Firefox feature so much more (like Adblock plus and better Flash support) that I can't bring myself to use Konqueror and find out.
>dragging and dropping tabs to rearrange them
Been in Konqueror for a long time, perhaps as long as it has had tabs.
It's more advanced than Konquerors current standard location bar. It seem more akin to the Alt-F2 with multiple runners approach of KDE4. Adding Nepomuk to the mix, it's most likely only a matter of time before such advanced features are avaliable in ALL location fields across KDE.
>I love the menu and interface being designed for web browsing, and not file managing.
Konquerors profile has handled this for years. My web browsing profile has never been like the filebrowsing one, they are both designed for their different usagepatterns.
> have my bookmarks in folders, and tag them as well
Konqueror does tagging(Comments), and even kfm the KDE1 predecessor did do bookmarks in folders.
Built in spellcheck in Konqueror predates any Gecko based browser.
>built-in download manager
KGet is a plug-in, but the major distributions install it by default.
>built-in RSS reader.
Konqueror has intergrated support for KDE RSS reader Akregator.
Konquerors adblock works very well, altouch it has room for some improvements. Since Flash is broken, improving support are hard until it gets fixed.
Note that the Akregator plugin doesn't work in konq-plugins 4.1.0 (some required files are not installed), I fixed it for 4.1.1 (and for the Fedora 9 4.1.0 package).
I like looking videos over the web. My problem is, that the flashplugin doesn't produce any sound on my system. It's really a shame, but I tried everything possible from alsa-configuration to oss to different flash versions. No sound at all :( With the video-downloader extension of firefox, that never really bothered me. It's abled to download every embedded media I found till today.
Now that I switched to KDE4.1, I don't want to use the gtk-version of firefox anymore. Konqueror is pretty slow on my system, but what's much worse: There is no extension that helps me download embedded media and watch it with my favorite media-player. So I ended up using Opera, wich I really don't like, but at least I can download videos with some annoying widget.
The hole interface of opera (though it's qt4) doesn't really fit into KDE4 as well, so I have high interest in a video-downloader for konqueror and I guess there are lots of other users penetrated by adobe in the same way.
Make a plugin for konqueror (or arora), that's abled to find and download embedded media, even if flash is deactivated, and you would have a kickass feature. (Almost) Nobody likes flash :)
Are you using a 64-bit distro? I've seen some people using Flash in a 64-bit distro that don't have the necessary 32-bit libraries installed to get sound working in Flash.
I'd have to know more about your setup to be sure.
No, it's a simple 32bit system with an athlonxp 2000 and a soundblaster16 soundcard and sometimes a terratec phase 22. Have this problem since flash moved to alsa and tried several soundcards and linux-distros. Nevertheless, since I'm so used to download all flash-vids I want to see, I wouldn't be happy to have flash with sound but no option to download the media.
What just comes into my mind: there are quite some browser-extensions that can detect every embedded media by just getting point to the containing website. Shouldn't it be possible to stream those media to the favorite media-player and giving the choise to download it?
Again, I think a lot of people do not actually need flash for interactive websites or flashgames and would therefor be very happy if they wouldn't need this big, buggy and lame plugin inside the browser.
You likely need to configure ALSA then. And you may want to see if you're running the in-kernel ALSA, or the out-of-kernel ALSA.
As far as embedding media in the web, many people use Flash for a variety of reasons.
1 - It uses less bandwidth for people who don't want the entire clip. It only streams while I have the page open.
2 - There is less wait with streaming as opposed to waiting for the while clip to download.
3 - It (somewhat) prevents you from just downloading the media. There are extensions to take media from Flash, but it helps with liability to make the effort.
4 - If you use Flash, you can be pretty sure almost everyone on the web can access the media in the page, as opposed to embedding some other media playing device that might not work as well for some people.
HTML 5 should include new media tags to allow people to just use one tag, and then link to the media. Each browser/platform will determine then how to open and play that media.
sure, flash has it's qualities. Also I really tried hard to set up alsa, but it won't work. I have sound in every application, also properly set up primary and secondary soundcard. Everything is fine, but flash won't give a damn bing.
It's ok to me, since both firefox and opera offer me possibilities to download the media and view it with my favorite media player. Opera even gives me the possibility to stream the media to vlc, so there is not really a bandwith-problem with this concept. Still I can't use konqueror for not offering me that.
Also, I will probably buy a pandora in a couple of months and it's almost sure, there won't be flash available to this device, as well as every non-mainstream device with a different architecture then x86 will not have decent flash support. I guess most users of such devices won't use konqueror because of that. Flash videos are a part of the internet experience and html5 won't solve this to it's fullest. It may improve the situation, but it's pretty sure, a lot of video-portals will keep with flash.
is entirely extension-based:
1) Adblock+, with the BRILLIANT element hiding selector tool, is the most critical.
2) Gotta have mouse gestures, at least as configurable as the Firefox extension "Firegestures" (or Opera).
3) Gotta have Flashblock, with a "whitelist".
Nice but not absolutely required by me:
4) colorful tabs and tab-mix-plus functionality.
5) sometimes, it's easier to "rip" unwanted ads using "RIP" and Greasemonkey than Adblock.
6) Mozilla's implementation of "userchrome" is really nice, when they mess up something as badly as the "bookmark" dialogs in FF3. (Defaults sizes of folder trees are way to small, and I've got lots of space for bigger pop-ups or my 1920x1200 screen). So I just fixed 'em, easy as cake. Fighting with Devs about layout choices is much less satisfactory for everyone, because they *DO* have to fit everything into small screens for other users (eePC, for example).
BTW, here's my list:
Generated: Fri Aug 15 2008 20:38:00 GMT-0700 (PDT)
User Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:126.96.36.199) Gecko/2008070206 Firefox/3.0.1
Build ID: 2008070206
Enabled Extensions: 
- about:safebrowsing 1.0: http://www.google.com/search?q=Firefox%20about%3Asafebrowsing
- Adblock Plus 0.7.5.5: http://adblockplus.org/
- Adblock Plus: Element Hiding Helper 1.0.5: http://adblockplus.org/
- AutoFormer 0.4.1.5: http://autoformer.mozdev.org/
- Classic Compact Options 1.1.3: http://blog.environmentalchemistry.com/2008/03/firefox-theme-classic-com...
- CLEO 4.0: http://customsoftwareconsult.com/extensions
- ColorfulTabs 3.3: http://binaryturf.com/
- Connect to address 1.1.9: http://www.blackbirdblog.it/progetti/connect-to-address
- Console² 0.3.9.2: http://console2.mozdev.org/index.html
- Ctrl-Tab 0.18.3: http://en.design-noir.de/mozilla/ctrl-tab/
- Download Statusbar 0.9.6.3: http://downloadstatusbar.mozdev.org/
- ErrorZilla Plus 0.4.4: https://addons.mozilla.org/en-US/firefox/addon/5398
- Extension Developer 0.3.0.20080526: http://ted.mielczarek.org/code/mozilla/extensiondev/
- FEBE 6.0: http://customsoftwareconsult.com/extensions
- FireGestures 1.1.3: http://www.xuldev.org/firegestures/
- Flashblock 1.5.6: http://flashblock.mozdev.org/
- Forecastfox 0.9.7.7: http://forecastfox.mozdev.org/
- Form Saver 0.9.0: http://www.botsko.net
- Greasemonkey 0.8.20080609.0: http://www.greasespot.net/
- Html Validator 0.8.4.0: http://users.skynet.be/mgueury/mozilla/
- JSView 2.0.5: http://forum.softwareblaze.com
- Linkification 1.3.5: http://yellow5.us/firefox/linkification/
- Mozilla Quality Extension 0.1.5: http://quality.mozilla.org/
- MR Tech Toolkit (formerly Local Install) 6.0.1: http://www.mrtech.com/extensions/
- Nightly Tester Tools 2.0.2: http://www.oxymoronical.com/web/firefox/nightly
- Nuke Anything Enhanced 0.68.1: http://www.google.com/search?q=Firefox%20Nuke%20Anything%20Enhanced
- Open Addons 1.0.8: http://openaddons.extra.hu
- PatchForLibrary 4.4: http://space.geocities.yahoo.co.jp/gl/alice0775
- Platypus 0.80: http://platypus.mozdev.org
- QuickJava 0.4.2.1: http://quickjavaplugin.blogspot.com/
- Redirect Remover 2.5.5: http://redirectremover.mozdev.org
- Remove It Permanently 188.8.131.52: http://rip.mozdev.org/
- Right-Click-Link 1.1.3: http://rickardandersson.com/
- RSS Validator 3.0.0: http://www.nu22.com/firefox/rssvalidator
- Screen grab! 0.95: http://andy.5263.org/screengrab/
- Stop-or-Reload Button 0.2.2: http://v2studio.com/k/moz/
- Tab Mix Plus 0.3.6.1.080416: http://tmp.garyr.net
- Text Complete 0.9.9.4: http://www.cfavatar.com/textComplete.cfm
- Tinderstatus 0.2.10: http://tinderstatus.mozdev.org/
- Toolbar Buttons 0.5.0.5: http://codefisher.org/toolbar_button/
- Total Validator 5.3.0: http://www.totalvalidator.com/tool/extension.html
- User Agent Switcher 0.6.11: http://chrispederick.com/work/user-agent-switcher/
- View Dependencies 0.3.3.0: http://mozilla.queze.net
- View Frames 1.0: http://mozilla.queze.net/
- Web Developer 1.1.6: http://chrispederick.com/work/web-developer/
- YesScript 1.3: http://www.google.com/search?q=Firefox%20YesScript
Installed Themes: 
- Classic Compact 3.0.9: http://blog.environmentalchemistry.com/2008/03/firefox-theme-classic-com...
- Default: http://www.mozilla.org/
Installed Plugins: (3)
- Default Plugin
- Java(TM) Plug-in 1.6.0_05-b13
- Shockwave Flash
...and I've got swampland in Florida to sell you. What worries Nokia about WebKit and Apple is the fact that Nokia doesn't have an equivalent that it OWNS.
Didn't Nokia write the version that runs on scaled down screens, which then showed up on the Iphone?
Great post, not sure I agree completely but definitely a good read.
I guess a company like Nokia has enough experience with it ;) But jokes aside: I fully understand why people prefer choice and there are lots of good reasons. There is no problem that there is QtFirefox, Konqueror, Dolphin and Arora. But as an computer scientist it annoys me to see so much code duplication on core technologies.
Plasma wants to use QtScript and QtWebKit. Konqueror wants KJS with KHTML. I am not sure which SVG is used by Plasma but I guess both ;)
When there will be a QtMozEmbed available I am sure some Qt-apps will use it instead (surely for some good reasons). But now my RAM is filled with yet another HTML+SVG renderer...
So without wanting to troll I would like to ask if there are any plans how to handle the situation.
Don't forget that Qt also has two different XML APIs, as well as having both a lite and full HTML renderer.
No worries, I'm sure things will shake out.
I don't really dislike KHTML vs. WebKit (they have very different philosophies, and getting rid of one of them would not make sense). What I dislike, though, is the duplication inside of Qt: Why does Qt contain QtScript as well as WebKitJs (sorry, don't know the name), QStyle and WebCore, QML and WebCore .... Wouldn't it be possible to port Qt's existing stuff to WebKit or port QtWebKit to Qt's existing infrastructure (less likely, due to the fact that many web sites would expect QtWebKit to behave like other WebKit ports)?
As for the QtMozEmbed, I can't really imagine very many non-Mozilla programs using it, primarily because QtMozEmbed won't become part of KDE (KHTML) or Qt (QtWebKit), removing most motivation to choose it over the former ones.
As for Nokia, it's probably (to be perfectly tackless) greed. They don't want any tweaks they make to their software appearing on other software (read: the iPhone), even though WebKit is probably more appropriate for embedding (WebKit is smaller and faster than Gecko). I don't think it'll help them too much, either, since Apple could've written the code Nokia did, anyway. And, any tweaks Apple makes to WebKit, Nokia would get them, too). Oh, well, we get a Qt Firefox this way.
Bigger screenshots would be nice. (Besides, it would have been really cool to see Mozilla use, say, wxWidgets instead to put the Windows and GTK under one hut, because then it would be "easy" to add Qt to wx, thereby benefitting not just Mozilla.)
Mozilla already uses such an abstraction, which makes such an alternative backend implementation possible in the first place.
The first attempts to port Mozilla suite to Qt toolkit date 2000.
I wonder why it has taken so long to finally admit that such a port is a good thing to have?
I've suggested it several times and I was told a QT replacement of the GTK widgets would be too hard and take too long. It seems the initial work was done by one guy in a matter of days, but now a team is working on really finishing it.
I see, and I suppose a native windows and a native macOS port was trivial. People keep saying all kinda $hit and worse, people keep believing that.
All the earlier claims about XUL by mozilla was hogwash, then ? Why didn't they just come out and say they hated anything KDE and that would be that !
This could really help a Qt port of SWT, especially since SWT already uses Cairo for 2D graphics rendering (on Linux anyway).
There is with Scribus already a Qt application which uses Cairo.
Scribus uses Cairo to render to an off-screen pixmap, then blits that to the Qt canvas. It's very slow and makes it hard to update only dirty regions. Instead, it redraws a whole tile if any part of the tile is dirty. In practice, it lands up redrawing the whole visible canvas a lot of the time.
The ability to use a Qt canvas as a direct Cairo backend will be really beneficial to Scribus, though plenty of work on the Scribus drawing code (which is a bit scary in places) would be required to get the most out of it.
The last couple of years indicate that the SWT community, i.e. both SWT developers as well as users, have very little interest in a Qt based SWT implementation, otherwise somebody would have at least tried to create one.
Nonsense, while it may be true of the developers, it isn't true of the users...I know I'm not the only one. Remember, it was only recently that the licensing became such that it would even be possible.
Licencing was commonly used as an excuse not to put any resources into a Qt backend because all the resource the already existing backends had consumed.
It has always been possible to create a Qt based SWT because of Qt/X11's QPL licence.
If there are users who would prefer a Qt based SWT for whatever reason, they so far have failed to communicate that need with the SWT project.
Iirc there were rumours about a SWT/Qt branch, but kept behind the curtain, because of licensing issues, years ago. Maye the QPL didn't suite for the one or the other reason.
Since v.4.4.1 Qt is not available under QPL anymore, but the linking exception list includes, among various other licenses, the Eclipse Publice License 1.0.
I am pretty sure it has never been a licencing issue but that this is always used as a quite convenient excuse since it sounds correct (i.e. GPL being one of Qt's licences)
Unfortunately this myth has spread a lot, but luckly the change in licencing (the exceptions you mentioned) now show clearly that there obviously have been and are other, undisclosed, reasons not to do a Qt based SWT.
Well, the exception is nice, but not a free ticket. Since all other code you want to use in some way, has be compatibly licensed, too, you cannot freely choose from the pool of GPL licensed software and distribute resulting binaries.
It would be quite an improvement, if companies like IBM wouldn't create yet another license for every single of their open source projects and either dual-license or simply use the LGPL or GPL with some linking exception to protect their commercial interests.
if this is about 'mozilla platform', cairo backend and such, will this also mean qt thunderbird ?
Nokia could buy Opera Software (also from Norway as Qt) and it's Qt based browser Opera.
Why didn't tat happen?
The Maemo is already using Gecko/Firefox for the GTK side, it'd be less work for them to have a single rendering engine for both GTK Maemo and Qt Maemo. Open sourcing Opera would also probably be quite a challenge and take a while to make sure all the code could even be open sourced.
Not to mention it is much cheaper to do a little coding rather than just buy Opera.
Nokia is smart and is afraid of dependencies. That is a good sign.
With the advent of KDE 4.1, I made the switch from Ubuntu to Kubuntu. I was never able to get rid of Firefox from my computer, however, and I have permanently avoided using Konqueror. Not that Konqueror is a bad web browser, it isn't; I just simply can't live without Firefox's superb plugins which so much enhance the entire browsing experience. I truly hope that Nokia completes the XUL-QT port. Not only will this port directly benefit Firefox, but it may also support XUL as a graphical front-end for many other applications. Gtk+ has never caught on with the Mac, while QT has enjoyed huge success on Windows/Linux/Macs. This is truly great news! Thank you Nokia!
I'm pretty sure XUL already supports native OS X widgets, so it doesn't use GTK on OS X nor will it need Qt on OS X.
You would be correct.