Among the most exciting things to come out of aKademy, the recent KDE Community World Summit, is a Qt port of Mozilla's Gecko rendering engine. This will give Gecko the full native look and feel of KDE/Qt, and make it available as a KPart, where it can provide an alternative HTML renderer for Konqueror.
"This is the best of both worlds for KDE" said Lars Knoll of the KHTML
project. "Integrating Gecko side by side with our existing renderer
opens a lot of doors, without any compromise of the hard work and clean
design that make KHTML what it is."
On the night before the start of the hacking marathon, a conversation
including, among others, Ian Geiser, Lars Knoll, Dirk Mueller, and Zack
Rusin happened onto the topic of integrating Gecko into KDE. Lars and
Zack jumped into Mozilla's code, to see how feasible such a plan might
be. Within four days (and before the end of the marathon) the two had
a working port: Gecko running on Qt. They credited the speed of
implementation to the maturity of the respective technologies and KDE's
component architecture (though the caliber of the hackers certainly
didn't hamper the effort). In their implementation, Qt is just another
platform for Mozilla, parallel to the drawing and widget layer for
Mozilla's other platforms like GTK, Win32, or MacOS X. Though the work
is on-going, the team is close to integrating Gecko into Konqueror,
connecting Gecko to the higher level browser machinery in Konqueror
such as KWallet and KCookieJar.
The Mozilla organization was supportive: "We are delighted to work with
the KDE community, both to extend the reach of Gecko, and to be part of
an effort bringing even greater depth to the KDE desktop. Making Qt
another platform for Mozilla, and Gecko another option for KDE is a win
for both users and developers" commented Mitchell Baker, President of
the Mozilla Foundation.
There have been previous starts at this idea in the past. Trolltech's
QtScape, some initial Corel work, and a Mozilla-based XPart, foundered
from lack of maintenance and little advocacy within the Mozilla
community. The current team will be full-fledged contributors to the
Mozilla code-base, with KDE people and mozilla.org behind the effort.
The Qt port will live and develop in Mozilla's CVS repository. The
code to embed the corresponding QWidget will live, naturally, in KDE's
repository.
Comments
... of Qt's toolkit and KDE's component system in action. It was very cool to watch Zack and Lars rip though the code like no tomorrow. I think this is a great example that shows off the power of the KDE archatecture for enterprise applications. Now all we need is Opera and Konqueror supports basicly all the big rendering engines ;)
Were you in the middle of a spasm when you wrote that? Mozilla is already portable across three GUI toolkits. I don't think this qualifies as a "great example of Qt's toolkit [...] in action."
Good work on the part of the developers, but what was that garbage about "enterprise applications"?
What he means is that integrating a foreign html renderer into KDE and porting a html renderer to QT were achieved quickly thank to the high quality of both technologies. The fact that gecko has been designed to be portable was fundamental too.
toca
I think he meant it as a compliment to both Mozilla and Qt/KDE related techonologies. How many ports of Mozilla have been accompilished in less than a week?
Congratulations on the great hack!
I take it that for the immediate future KDE will provide KHTML as default and Gecko as an "alternative". Are typical Konqueror users expected to know that they can switch from KHTML to Gecko? Or are we expecting that distributors will evaluate the choices and choose one themselves?
What has the Kecko team found so far, is Konqueror with Gecko competitive vs Konqueror with KHTML? I suppose if it is, it only makes sense to defer to Gecko as the default since it has a massive and independent development effort behind it.
Have any distributors expressed an interest in using Konqueror with Gecko instead of Firefox? I suppose the next step would be to get KaXul in Konqueror.
> Have any distributors expressed an interest in using Konqueror with Gecko instead of Firefox?
Novell/SUSE has (with Novell Linux Desktop in mind).
Killer! That's quite encouraging.
I think many KDE-default distros will be interested too, as many of them default to Mozilla-browsers or present both a Moz browser and konqueror browser--- such as Mandrake, Knoppix, Linspire, Xandros, mepis,
With improvements from Apple, I don't see the point to be honest. Firefox is a cross-platform application, not one to be integrated into a desktop.
Getting geko to be the standard for open source layout engines helps everyone since you get more eyes looking at a code base instead of their own code.
This just looks like further movement in the goal to merge geko and khtml.
More developers on geko (whether they use gtk and the suite (mozilla) or firefox) is a very good thing(tm).
Unfortunately Gecko is not better. Why on Earth do you think Apple chose KHTML (and they worked on Netscape/Mozilla!)
Because it is easier to maintain and faster (since it wasn't intended to draw itself, and because accuracy wasn't a top preference).
owned.
In all the CSS support (and correctness) tests I have seen, Gecko is the best. No doubt KHTML is getting close, but I have no good reason to take your assertion as a truth.
Apple chose Gecko because of size and cleaner-coding of KHTML. This is not an issue for the end-user (Gecko browsers such as Firefox are under the 10 MiB). What the end-user wants is good rendering.
Which is why Apple chose it. Browse backwards and forward between a handful of pages to see the speed difference. Apple needed a rendering engine that gave them a selling point for Safari (rendering speed) that would get IE off Mac. They succeeded. If they didn't think it would render well, they would never ever have picked it over Gecko.
I am sure for many people Gecko works better, but I have had some aweful luck lately. khtml seems to do a better job on many of the sites I visit. Great hack guys, but for now I will stick to khtml.
Bobby
The advantage of this integration, is that in the future you can use gecko rendering engine with native KDE components. Just like under MacOSX, when they use Safari, everything looks OSX native, just like firefox under windows. But when I firefox on linux or OSX, the buttons all look strange (or primitive).
For MacOSX the camino project is a good start, but for what I mostly need it. It is the designmode option in Gecko, so you can edit like RichText in your browser. That works with Mozilla & Firefox, but not yet with Camino.
And it AT THE MOMENT certainly doesn't work with KHTML. I know there is someone who has been working on it for the last two years, but it still isn't finished, and even when it is finished, it will take some time, for someone to build a script that supports RICHTEXT editing in MSIE & GECKO & KHTML.
I would like to see firefox with KDE look & feel, and also firefox with MacOSX look & feel.
I think that would be a win for all plattforms. I do not really like Konqueror for webbrowsing, probably because I'm used to the shortcuts for firefox, they are mostly the same under windows and linux.
And JavaScript handling for gecko and KHTML still isn't 100% the same, so I still have to test and improve the script under KHTML, after that it works for GECKO & MSIE. But I have to say, that correcting a script after it has been made to work for GECKO is much easier, than correcting it to work for MSIE!
Also, what about JavaScript in Konqueror/Gecko? Is this still handled by kjs or does Gecko take over? Essentially, does using Gecko in Konqueror mean that rendering will be 100% comparable with Firefox or will there be something missing?
JavaScript is done by Gecko, read Zack's blog.
Well, as neat as this sounds, I would like to see a standalone web browser that supported the extensions of Firefox on the Qt side of things. I really don't want to see Gecko rendering in Konqueror as much as a Gecko browser for KDE that's not Konqueror. Hopefully we will see this.
My main complaints about Konqueror are twofold:
No mozilla extension capability, so no adblock.
Clicking on home takes you to your home directory.
Well, when this is done, won't you just be able to use Firefox with Qt/KDE instead of GTK?
Right now, Firefox can be compiled on Linux against either GTK2 or GTK1. On other platforms (Mac or Windows, it can be compiled against their native toolkit. So there's no reason to not add a third toolkit option for Linux, as it's quite possible.
I agree. I spent ages trying to work out how to set my home page before realising that I couldn't have a filesystem home page and a separate web home page.
I think they should separate the web browser from the file browser. Allow the web browser to display local files and the file browser to display web pages, but you do different things in a web browser to a file browser...
I agree. File manager and web browser should be two apps with a lot in common, rather than the same app except configured differently. Or even just giving seperate sets of preferences for the two would be enough...
Uh... you can do that already.
Please lookup the docs for Konqueror profiles.
We've already done this. Yes, starting Konq the web browser can be made to have a different starting page than Konqueror the file manager. But when you hit the Home button in the web browser, suddenly you're browsing the filesystem. The docs for Konqueror profiles are silent on this subject (which is part of why I use Mozilla instead)
Ok, that's trickier, but not impossible.
* Create a plugin that simply goes to your home folder (that's the hard step ;-)
* That plugin should now be available to add as a button in the toolbars
* On the web profile, use the "Home" action in the toolbar
* On the file manager profile, use the new plugin
Tada!
I appreciate that a solution can be created, but I prefer my one-step solution: 1) Don't use Konqueror for anything but file browsing until this is fixed.
Had you been any less of an asshole about it, I would have published the plugin, since I just wrote it. Your loss.
He isn't the only one who thinks that this behaviour is weird.
It would be great if it'll get fixed.
It's a solution, sure, but it's also a dirty hack. May publish it on friday if I have any free time.
Can you not fix some CSS bugs that have been bothering me too? I just want to see how unhelpful I can make you.
No, since that would involve actual work, instead of editing the example konqueror plugin and changing ten lines of code.
I don't think that separating web from file browser would be a good thing. Integration is the key KDE is so much powerful and so much different from the other desktops. If the problem with the homepage button is the only problem you have, it is a good sign that things are working quite good :)
Yeah, I am not saying Konqueror should get slimmed down. I like its universal file viewer capability among any i/o slave, including the web. I mean, I think that it should have HTML capability, but I think that overall Konqueror makes for a poor web browser as opposed to Firefox and makes an excellent file browser as opposed to Nautilus, or heaven forbid, Windows Explorer.
But I think that Mozilla's extension system is the best around and it's foolishness not to support it.
KDE is full of duplicate applications and despite my constant complaining that a lot of these should get deprecated, like kedit, kpaint, and noatun (nothing against noatun, but I find the similarities with kaboodle and its uncapabilities compared to amarok reason for its removal) to name a few, what's bad about a new web browser for KDE?
> KDE is full of duplicate applications and despite my constant complaining that a lot of these should get deprecated, like kedit, kpaint, and noatun (nothing against noatun
- kpaint is already gone
- kedit will be gone whenever kate supports bidirectional-text (being localized is very important to kde)
- noatun+arts will be gone in kde 4.0, unless someone manages to port it to kdemm, which is unlikely since it's tied into arts very closely
Personally, I think if they're going to drop an editor, they should get rid of KWrite.
KEdit has an advantage in that it's very light. Kate has an advantage in that it's very powerful. I use both regularly, depending on what I want to do. KWrite is neither as light as KEdit, nor as powerful as Kate. I never use it, ever--there's no reason to.
Now, dumping Noatun, that I can agree with. JuK runs circles around it, IMO (I recently switched to JuK from XMMS, and like it quite a bit). Unfortunately, JuK doesn't support streaming audio, but AmaroK does. AmaroK also runs circles around Noatun, tho I prefer JuK to AmaroK in every area except streaming.
To gain anything they have to drop KEdit, since KWrite and Kate are the same editor. KWrite is only a light version of Kate, without all the advanced stuff.
Personally, the only one I use is KWrite, because a lot of files that I look at would be a lot harder to use without syntax highlighting. If I need anything more powerful than KWrite I tend to jump straight into KDevelop.
I guess removing KWrite would work though, as we have a really light editor (KEdit) and a slightly heavier editor (Kate), and then a full development IDE.
I for one don't want to see Noatun go for the very simple reason that Juk sound quality is not very good (I don't know why but the sound its garbled) as compared to Noatun which plays with very high fidelity. If someone has had the same problem and found a way to fix Juk let me know so I can fix it too..... otherwise I would hate to boot into Windows just to listen to MP3s
I had issues with Juk on certain files causing lots of static. My guess is it had to do with the bit rate or frequency or some other setting. I never did figure out what caused it, as it went away when I upgraded to KDE 3.3. :-) If you've not yet upgraded I suggest you do so, as there was probably a lot of cleanup internally for that sort of problem.
Noatun has always bugged me, as it takes a long time to load and then doesn't let me edit tags. Why bother with it? :-) (Or if it's supposed to, it malfunctions for me.)
Elsewhere in this thread someone mentioned that artsd is going away in KDE 3/4/4.0. Why is that? Has ALSA caught up to the point that artsd is redundant?
Regarding the first point (why bother with noatun), I must say that I've been a long-time noatun advocate. I tried Juk for a week or so a little while ago, and loved the id3-editing portion. However, it fell down when it came to how I use my mp3-mplayer. I hate how it resets to whereever you starting playing in the playlist whenever you hit stop (rather than go to beginning of the the current song). In fact, I think that's the only thing that was wrong with it, and that alone was enough to drive me back to noatun :-) It's something that's very simple, but incredibally annoying if done wrong.
Secondly, arts and alsa are not on the same level. If KDE switched to alsa as it's multimedia layer, it would suddenly not be usable (for sound and video) on any *BSD, OSX, or Cygwin. Alsa does stand for Advanced *Linux* Sound Architecture, you know :-) The last I heard (and admittedly, it's been a while), kde-multimedia was looking seriously at gstreamer to use instead. There may be other systems, I forget. But basing it directly on alsa (or oss, or CoreAudio, etc) is simply not an option. Oh, and it definetly won't go away for 3.4, which by definition has to be compatible with all 3.x apps.
I agree too! KHTML is great, but having the web browser integrated with the file manager is a real PITA. Homepages is one example (and I must commend the KDE team on there not being many more), but also just the fact that Konquror the file manager had more than enough stuffed into it with out need a web browser on top of that. Also, I can't see why they were married in the first place, a web browser and a file manager are two completely seperate concepts. Also, to the person who says this is good integration, it isn't! It would be good integration if clicking an HTML opened it in the appros browser (which I'm sure it does), but making and application bloated in terms of features is bad. Usability?
It isn't a matter of making Konqueror a bloated application. It's actually a relatively lightweight container. The parts which are loaded in order to accomplish a task don't need to be loaded at the same time unless you're using both. That goes for the kparts viewers that load directly in Konqueror as well. This argument is somewhat akin to stating that Netscape is a bloated app because Adobe's PDF plugin loads Acrobat Reader in the same window. The main difference is that the apps are more closely knit in KDE, with more options.
Re-read my initial post. I said bloated in terms of features, not resources.
I did read it, but it seems to miss the point. Konqueror isn't a web browser or file manager. It's a container application, sort of a universal meta-browser. The file manager and HTML renderer are simply plugins. Features can be added or removed dynamically by adding or removing plugins. If you don't use it as a file manager, then it isn't. The same is true about the web browser portion. Calling it bloated in terms of features seems a bit silly since features can be added or removed dynamically. If you take that away, it's no longer Konqueror.
As an example, try right-clicking on a text file in the file manager. Choose "open in new window" from the menu that pops up. If you have the appropriate kpart, voila, Konqueror is now a text editor. Depending on what other plugins are present, other data types may have a part that can be loaded into konqueror. PDF files, filesystem trees and audio files are examples off the top of my head. You can use the location bar or even one of the plugins to access other plugins. IMO, it's a great model for data access that isn't constrained by a focus to be a single type of application.
Completely agreed with mr. Anonymous from previous post.
If you think konqueror supports to much mimetypes, then go to the 'File Associations' dialog and remove unwanted mimes from the 'Embedding' tab. Eg. to make konqueror not supporting HTML anymore, simply configure it at text/html to not embed with the khtml part, and put your favorite browser on top of the 'Application Preference Order'.
Actually it helps me get my work done faster that kde is network transparent all over the place and that konqueror is a kpart viewer that uses ioslaves to grab data. I do web stuff for a living and in my world a lot of html resources are on remote sites that I need to access with sftp, ftp, webdav, etc. With konqueror I can go to any url that the system can recognize and an appropriate kpart is launched. khtml will render pages just fine no matter what protocol is used to get them and that saves me many hours a week.
You may consider it bloated and horrible usability but for me it is the primary purpose I use kde. I have used gnome some and the integration was just too painful. In kde I set spellcheck ONCE. I set proxy settings ONCE. I set my default editing compenent ONCE. I set my address book settings ONCE. It just saves me so much time by having stuff network transparent in a world where resources really are network transparent it is just that most are not used to dealing with network transparency. I have also worked with windows and mac machines extensively over the years and for web app stuff I consider them unusable. Overall the ioslave system should be some vfs layer just about the os (ie still userspace but below almost all the rest of userspace) So that you have one http, webdav, sftp, imap, pop, gzip etc layer on the system and EVERY app that uses it can do so. Think of how much nicer many things would be if mozilla, opera, lynx, links, wget etc did not have any understand of http at all but used a very nice vfs layer instead. You could improve the protocol, add a new version, fix bugs etc and all transparent to the apps.
The kde way really is the right way to do this to stop so much duplication of effort and they really have not gone far enough but at least the developers seem to be pushing for more transparency over time.
Completely agree with Kosh - KDE's network transparency is awesome once you get used to it. It's good for new computer users as well - you shouldn't have to use different applications for each type of file resource. Lots of things fit very well into the ioslave model, so you have two great usability bonuses:
- Only learn one overall model for file access. (protocol:/[domain/]path, with graphical browsing to make the path part easy)
- Only learn one interface for file transfers and access (Konqueror)
Compare with the way GNOME are trying to do it - one model for the desktop (spatial), another for file dialogs (hierarchal/browsing), and then another for remote access (URL based). The internet is here to stay and KDE embraces it.
I prefer to think of Konqueror as a GUI equivalent of a shell. No one would say that bash was bloated because you can do a million and one things with it - it is the glue that allows you to use the other programs. Konqueror is the same for file access and viewing, except you don't need to have programmer leanings to use it.