Slashdot Mirror
Konqueror Embeds Mozilla with XParts
navindra writes "KDE's component technology, KParts, has been extended to support out-of-process embedding of components theoretically including GTK components, Bonobo, and OpenOffice UNO components. Even better, the same technology could be potentially be used by GNOME to embed KDE components. Here are some screenshots of Konqueror embedding the Mozilla rendering component, and the whitepaper on XParts. This appears to be an important step forward in the interoperability of free desktops." The screenshots page has an excellent overview of what this does, and what it means. This is extremely impressive stuff people.
Just a thought... don't know whether that's realistic or not... but couldn't WINE be used (after some heavy modifications, I guess) with XParts to embed Windows apps info Konqueror (or any other app).
Opus: the Swiss army knife of audio codec
That's just it -- MS keeps taking their standards to a "new level". What's the use of a "standard" if every app that uses it is obsolete in 6 months?
__________________
This is great news for Linux desktops. The KDE people did a wonderful job here. However, I don't see how you can possibly say "KDE is cooperating and GNOME is doing nothing". That's just being a troll. The wars are over. Put your guns down. Now there's just friendly competition. They worked together to make a Window Manager spec, and I'm sure eventually someone will make a bonobo interface for embedding KDE components. But please, don't tarnish this great moment by turning it into a flamefest.
Engineering and the Ultimate
Just so you'll know, after looking over the white paper a little bit, it ends up that this is actually KDE playing catch-up to GNOME. X-Parts does not allow embedding of arbitrary GNOME component into KDE. It only allows embedding of out-of-process components into KDE, which GNOME has had for a long time. GNOME's embedding also does not require any specific toolkit (see OpenOffice as an example). No, Konquerer did not have to be modified to do this, but Mozilla _did_. This support has been in GNOME for some time.
Remember, this does not allow the arbitrary embedding of any GNOME component. It requires a wrapper for each GNOME component before being embedded. This is currently available for GNOME.
I'm not trying to discount what they've done - its very, very great! But I don't want people misunderstanding it either. I'm looking forward to the day when arbitrary components from either can be embedded. Whoever does it first will simply give the other person something to build from. Let's stop fighting, calling names, whatever. It's a great day, and let's be happy.
Engineering and the Ultimate
However, this is all beneficial. When you can reuse components, the programming cycle can speed up tremendously. In the case of the Java the biggest push is for Enterprise Beans, the Java equivalent of ActiveX controls. Take a few activeX/beans, and a visual editor, and you can get the fundament UI/engine intergration completed in minimal time, leaving more time to work on the mechanics of using that data in the program. The only problem with the Java and MS solutions is that a majority of the components were closed source, so how could you be sure that a simply text box did not report back to some site on the net?
With an open-sourced based system, at least you now have a better chance of obtaining open-source components, and thus you can evaluate those components for security problems. In addition, you have the ability to modify behaviors slightly if you don't like how the default component works without drastically affecting the rest of the code since the component is really just a drop-in.
And now the fact that KDE and Gnome, which use different component models, might be able to share components means more components and options are available to developers which could enhance the user experience more.
"Pinky, you've left the lens cap of your mind on again." - P&TB
"I can see my house from here!" - ST:
Lately, I've been hearing Windows developers talk about how cool it is to use Cygwin on NT. Yet I recall using the Gnu EMX tools under OS/2 over 5 years ago.
In addition, it is especially cool having this feature in a free and open environment.
It actually has nothing to do with mentioning preference. There is quite a bit of difference between saying "I like KDE better than GNOME because..." and "Those GNOME people really suck at this". In addition, if you had read the other responses, you would know that, actually, GNOME did this first, so its a moot point anyway. KDE and GNOME are both great. I generally like the way GNOME works better, but I think the KDE people have done a wonderful job. I also appreciate TrollTech doing the right thing and putting QT under a free license. That was absolutely wonderful. Great things have come out of both camps - each of the office systems have their strengths and weaknesses. However, trashing one or the other does no good whatsoever.
Engineering and the Ultimate
...ActiveX?
admittedly open, and a first for Unix/Linux.
Hopefully people will take it further by writing their own, and it KParts can be what ActiveX wasn't - an extensible and portable standard, and actually trusted as a download (if security is handled properly!)
Fross
It seems that all the most exciting stuff is happening in KDE. The KDE 2.1 beta has a great deal of cool stuff, like HTML preview icons, text preview, and some very slick kio plugins. Things like seeing your Diamond Rio and digital camera as just a part of your directory tree is NICE. Drag a picture off of your camera right onto an FTP site. Isn't that how it should be??
Significantly, these features are being added with a minimum of pain. The embedded mozilla required NO changed to Konqueror. Adding digtal camera support to the Image Viewer (kview) didn't actually touch the kview code. KDE is built on *very* solid technical ground, with plenty of room for planned growth. It seems that having a high quality C++ architecture really helps.
Ok, on the one hand, you have mozilla, which is huge. The politically correct opinion is to claim "this is because it incorporates too many functionnalities which are not web-related (mail, news, composer, dildo, XML-dynamic-interface-whatever, etc...), but that gecko, mozilla's rendering engine, is great, light, fast. etc..." The problem is: it's not true. And Galeon brings us the proof. Here we have a lightweight, unbloated, slick gtk-interface, which embeds gecko, and that's it (plus, some functionalities, such as printing and cookies are not implemented yet). And the result is... a web browser almost as big as mozilla, which immediately goes over 20 Megs in RSS (half being shared).
On the other hand, you have Konqueror, with a good rendering engine, almost fully complete, which is less a memory hog than Galeon: it's not everyday that you meet a KDE application which takes less memory than its Gnome counterpart (actually, this is the firt time I see something like this: the empirical rule used to be: if a KDE app takes N megs, an equivalement Gnome app will take Nx0.7 megs on average). What does it mean? It means that if you embed Konqueror's rendering engine in a simple Gtk/Gnome GUI, you may potentially get, at last, a fast, light, good, complete web browser, lighter than Konqueror, without all these silly kdeinit processes that you need to kill with a napalm gun. And Gtk/Gnome based, which may be significant for some. So this move is potentially excellent.
This is really cool! I've always had a hard time deciding what desktop I liked best, because half of the applications I wanted was Gnome apps and the other half was KDE apps - those times may well be gone now (if I were to choose to use KDE2).
Remember Miguel De Icaza recently talked about getting more "reuseablility/code-reuse" under Unix (I know that is badly written, but you know what I mean!) - well it seems that the KDE-Team was listening.
As it says (here: story at dot.kde.org):
This is only a first step. Other possibilities include providing transparent access to OpenOffice components within KOffice, and embedding other Bonobo components, such as the various Nautilus components, inside, say, Konqueror... The goal is to provide the most powerful desktop for users by allowing them to pick and choose whatever software they like while still in the familiar and comfortable KDE environment. KDE is close to closing the schism within the Linux desktop environments by being the first project to allow users to utilize all the software written for different user interfaces within the KDE environment with unparalleled integration.
Also, people writing standalone applications that do not utilize any desktop technology can easily integrate with our environment in ways previously impossible.
What is cool too, is the this comment:
"It is important to note, that we did not have to modify a single line of source code in KDE or konqueror to get this running."
Greetings Joergen
An in-process component is one that is implemented simply by loading a library. An out-of-process component is one that runs in its own process. With in-process components, everything shares the same address space, and method calls are made directly. With out-of-process components, the components are in a different address space/process than their containers, and thus must communicate using pipes/sockets/something other than a direct method call. They have some added benefits, like not having to use the same toolkit as the parent component. As was mentioned in the article, glib and KDE both have their own event loops, which vary quite drastically. Trying to fit them in together in the same process space is quite difficult. However, if they can each run on their own, you have fewer problems with that. However, it adds complexity to the communication between parent and components.
Engineering and the Ultimate
Linux isn't a good programming platform for me right now because it doesn't have a standard object model
No standard? What about CORBA? More of a standard than Microsoft's DCOM, even if the API is horrendous.
If you mean no standard across desktop environments, then you'd be right. But object models are far more than ways of making GUI applications interact, so XParts is just the last piece in the jigsaw.
Chris
Look at the build ID on the Mozilla screenshot. The build of Mozilla they are using is from October 10, 2000. It is probably the M18 release of Mozilla. Any Mozilla follower will tell you that today's release is light years ahead of M18, and even NN 6.0.
It's based on DCOP. It allows you to do this in Python (and other languages, of course)
" )
//g'`
/kdesktop HTTP/1.0
----
#!/usr/bin/python
from dcop import *
from qt import *
app = DCOPApplication( "kspread" )
table = app.default.getDocuments()[0].map().table("Table1
table.setSelection( QRect( 2, 2, 4, 6 ) )
rect = table.selection()
print rect
print "done"
----
or you can do this to control a presentation!
----
# Python version of David Faure's dcop presentation automation script for kpresenter
#
# Simon Hausmann
from time import sleep
from dcop import *
app = DCOPApplication( "kpresenter" )
doc = app.KoApplicationIface.getDocuments()[0]
view = doc.firstView()
startAction = view.action( "screen_start" )
print "Starting Presentation %s" % doc.url()
startAction.activate()
sleep( 5 )
act = view.action( "screen_next" )
while startAction.enabled() == 0:
sleep( 10 )
if startAction.enabled() == 0:
act.activate()
print "Presentation finished."
------
This stuff is also expose via xmlrpc. That means that you can access it from ANY language that can open a socket and send text through. Here's one in shell script:
-------
#!/bin/sh
port=`sed -e 's/,.*//' ~/.kxmlrpcd`
auth=`sed -e 's/.*,//' ~/.kxmlrpcd`
cat > cmd.xml
KDesktopIface.popupExecuteCommand
$auth
EOF
length=`wc -c cmd.xml | sed -e 's/cmd.xml//;s/
cat > head.xml EOF
POST
Content-Type: text/xml
Content-length: $length
EOF
( echo open localhost $port
sleep 1
cat head.xml cmd.xml
) | telnet -8E