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.
Embedding external parts into KDE
Straight URL iss xpar ts.html
http://members.dingoblue.net.au/~pjmenz/K/lar
Have fun.
How is that like IE? Explain slow, I have a hard time following some posters logic.
"Science is about ego as much as it is about discovery and truth " - I said it, so sue me.
Moderation on slashdot is getting horrid. I REALLY wish we could meta-mod specific posts instead of having to do 10 random ones.
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?
__________________
First - I'm not a GNOME bigot. I'm a *standards* bigot. My complaint against what's going on with KDE isn't because I prefer GNOME (although, to be honest, I do), but because I dislike the reinvent the wheel syndrome.
I'm aware that KDE did use CORBA, and abandoned it. I think that their *reasons* for abandoning it sucked.
They used an ORB which had lousy performance. So what was their response? Not fix the ORB. No - it was to totally reinvent the whole idea of an ORB from scratch, and then implement their new non-standard ORB.
Yes, some ORBs are slow. What's the solution? Fix the friggin' ORB. Yes, the CORBA bindings can be a pain in the butt to program to. Is the correct answer to discard the entire standard infrastructure and invent your own from scratch? I'd much rather see someone *fix the bindings*.
CORBA presents a set of bindings which were a political compromise. No one likes them. But you can do CORBA and *not use them*. Take an IDL compiler, and have it generate something different, but keep the standard infrastructure.
The KDE folks could have optimized and ORB, and prettied up the bindings, and still taken advantage of the widely acknowledged standard for componentry. But instead, they discarded it, and then reinvented it.
What's the cost of that? You constantly need to rewrite code to work with KDE. I've got a ton of CORBA components that I can use in a UI. Can I use them in KDE? Sure - but I have to basically write a brand new kparts wrapper for each of them.
I just don't believe that when the standard is adequate, that it's appropriate to discard standard infrastructure in favor of your own homebrew. CORBA is adequate, if implemented well. So implement the standard well.
Exactly! Or to anywhere else. One of the most useful examples of this that I use is to drag images directly from my digital camera to web sites via ftp. Looking in the source tree from the latest CVS the kio_slaves currently are:
gzip
nfs
tar
smb
finger
ldap
nntp
smtp
thumbnail
gopher
imap4
man
pop3
sql
audio CD
Another cool feature is that the Audio CD ioslave enables you to not only play cds but to rip cds directly if you have cdparanoia libs installed by dragging and dropping the track(s)
see: http://dot.kde.org/975053591/ for more information.
KDE has one *major* issue though, nobody except those how follow KDEs development closely seem to know about these features. It really is a great desktop enviroment and looks very nice with anti-aliased fonts.
A journey of a thousand miles starts with a brutal anal raping at airport security
None of what you mentioned is exciting. It's all catch-up work. KDE2 as a whole is rather exciting. So is Evolution.
But come on - HTML Preview icons, Text preview...Digital Camera supporrt. This is all catch-up work. There is no innovation here.
Windows has had everything you've mentioned for almost three years now. What's exciting is the speed of development, the Bazaar method of development, and some of the really cool projects with innovative features nearing release.
signature smigmature
- James
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
I agree! A couple of months ago, I was convinced that KDE was being left behined gnome - which isn't good (although I'm an E man, myself :).
But now - Kde is becoming attractive, even to an E user. Alpha blending, anti-aliasing, mature component architecture....very nice indeed.
Looks like the gnome team are gonna have to do a bit of work on bonobo to catch up with this.
Well done KDE developers! (i may even install KDE2.1 when it appears...).
i wish i was but oh well
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:
Mozilla engineers are working on all these things to reduce the disk and memory footprint without throwing away any functionality. As it stands, it is still a fast browser, *much* better at rendering web pages and more standards compliant than any other browser on Linux.
The difference comes from being open or being closed. I always liked the idea of COM and .NET, but I don't like what MS does with it. Meaning their common tactic of embrace and expand. People get suckered in and they change the system so that you are stuck with MS and don't have any other choice. But if it is in an open environement, where all development is viewable, and source code available, and such, it can grow and be use with no worry about being locked into one system.
.NET is full compatible with Linux, then I may change my mind about Microsoft.
I'm sure we will soon see GNOME using the same technology if this catches on.
MS keeps saying that they will become compatible with others, but their record is poor in this respect. If they port something, it is usually of lesser quality.
I don't consider myself a hypocrite, unless this ends up as some proprietary protocol and I'm still supporting it.
I'm not saying everything must be open source, but I do believe all protocols must be. When COM and
Steven Rostedt
Steven Rostedt
-- Nevermind
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.
Could you spare a clue stick. What's an
out-of-process component and how it is
different from any other component? Is it
just that you need a wrapper for it?
Wow, its just like... COM. Linux isn't a good programming platform for me right now because it doesn't have a standard object model. Microsoft took this to a new level with COM/COM+, and is set to do it again with .NET
I look forward to seeing a real standard on Linux, and then perhaps I can consider it for my projects.
-
The IHA Forums
Natural != (nontoxic || beneficial)
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
If you support KDE, or if you don't, you have to admit they are pretty inovative. This is very impressive. Hopefully other desktops will follow suit. Interoperability benefits everyone in the Open Source community.
"Science is about ego as much as it is about discovery and truth " - I said it, so sue me.
...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.
In Konqueror, use a URL of pop3://pop3server/
Watch as it asks you for your password, and displays all the emails on the server as files in that "directory". Drag one off to your desktop, or just click on one to read in right there in konqy.
Oh, and this works for SMTP urls too. Try it!
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
While the skedged solution works, there are some unmentioned and ugly details.
Skedged? I've never heard that before and it's not in the Jargon file. What does it mean?
Although, given the line "Those advantages are unvaluable for a lightweight and tightly integrated office suite like KOffice."it may just be another bit of KDEse.
Case in point, Terminal Services (like X remote display). I'm sure if you search the archives you'll find someone effectively saying "so what" about its introduction into NT 4.0 and 2000.
Well - let me turn the tables.
So what. Way to play catch-up.
We have to be more cautious now.
/.
Yes, this intiative will bring us to a new
level in terms of standard.
Yet, we also open up possibly gaping security
holes if we are not ever vigilant.
This might be the chance to prove Linux can do
it even as an increasingly commercially viable
platform.
rm -fR
so it's "impressive" when it is for linux, but change the name to COM and .NET and add TONS of functionality over what this is, and it sucks?
people who dis MS technology haven't programmed COM objects before, I can tell you that much.
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.
Let's stop fighting, calling names, whatever. It's a great day, and let's be happy.
For someone who's supposedly advocating peace between the two projects, you've got a pretty negative attitude.
it ends up that this is actually KDE playing catch-up to GNOME
These developers are people, and that's really quite an insulting thing to say. I'm not going to say you're wrong - I don't know enough about it. But if you were to say, oh, "You're just playing catchup to Canadians" to an American, speaking about technology, you'd get a very negative reaction. Heck, if that particular American was big enough and patriotic enough(or if you said it in a place full of big, patriotic people), you'd probably get your ass kicked.
The KDE and GNOME projects get along fairly well, despite their obvious differences. Your attitude is what causes what problems exist - it's called arrogance.
Dave
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
Barclay family motto:
Aut agere aut mori.
(Either action or death.)
First, I'm a C++ hacker. So keep in mind that my answer is probably subtly (or blatantly) biased.
The answer(s) to why GNOME is written in OO C is pretty straightforward. There were (and still are) compelling reasons to do it in OO C:
1. STANDARDS CONFORMANCE.
C++ is a convoluted spec with an almost infinite amount of tremendous subtleties. When GNOME was first being devised, C++ had just been standardized and no compiler was anywhere close to standards conformant.
2. WIDESPREAD ADOPTION OF COMPILERS.
Some compilers (Sun's C++, for instance) are hideously broken. Terribly, awfully, ridiculously broken. While gcc is available for most UNIX platforms, the GNOME project didn't want to force people to use gcc to compile GNOME. By using ISO C89, for which all UNIX vendors provide good compilers, it enables GNOME to be compiled and run on platforms without gcc.
3. C IS NO SILLIER THAN C++.
For a long time, C++ was just a preprocessor add-on (see AT&T's cfront C++ `compiler'), which took C++ source code and translated it into OO C. Anything you want to do in C++ you can do in C--maybe not as easily, but you certainly can do it.
... Now, you may read this as me slamming C++ for being baroque, convoluted, etc. I'm not. I don't think there's a good reason today to avoid C++ for OO work, given that gcc is so tantalizingly close to fully conformant. (Sun C++ is still ridiculously broken, as is MS VC++.) But if you want crossplatform, portable code which can be compiled under MS VC++, Sun's compiler tools, GCC and KAI and so on, your choices in languages are severely curtailed.
Gnome, as a desktop, is regularly second, indeed. Yet you can't deny that it also brought several innovations that were incorporated later in KDE (embedded panel applets, for example, and an independent component system, which KPart was not).
Yet there were REALLY USEFUL AND INNOVATIVE Gtk apps years before useful KDE apps. Actually, and sorry if this is flamebait, as far as I'm concerned, Konqueror is for me the first and only useful KDE application. The only useful Qt-based app before that was Qps, which is not part of KDE.
I support Gnome because of Gtk (and Gimp),and because of Gphoto, Gnumeric, Abiword, Dia, Gtk-XEmacs etc... On these kinds of apps, KDE is not only second, it is way behind.
Still, for some reason, I'm regularly impressed by the talents of these KDE folks. Too bad this does not translate in more original and useful applications. The problem is that Gnome, regardless of the respective technical merits, has been more succesful at creating a dynamic to involve "a priori neutral" talented developers with excellent ideas that give birth to Dia and Gphoto. And I think the key to this dynamic is called Gtk.
It's not that Java itself it closed source, but most of the beans that are released for it are 'binary' only, and generally put through a babelizer-like program to prevent debuggers from helping to discover the code of the program. All you get is a simple .jar file.
"Pinky, you've left the lens cap of your mind on again." - P&TB
"I can see my house from here!" - ST:
ah yes, moderated down to oblivion by the mindless herd of shitheads known as "moderators".
Fact: We had a MVC app with a blank form that (on user interaction) open shared libraries over NFS and reparented widget trees...not a line of code was altered in the MVC app, and the shared libs were all subclassed.
This was with Motif and X, five years ago.
Oh yes, such wonderous inovation, "people".
Treatment, not tyranny. End the drug war and free our American POWs.
See my user info for links.
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