Embedding external parts into KDE

Thursday, 21 December 2000 | Hporten

Up to now, the KPart component model was limited to embedding in-process parts. XParts is an extension written by Matthias Ettrich, Simon Hausmann and Lars Knoll to extend kparts and make it possible to embed out-of-process components. The approach chosen is toolkit independent, as can be seen by their choice to embed Mozilla. Read on for the full announcement and details.

<h2>KDE takes a massive leap by providing interoperability with major Unix/Linux software toolkits and applications --

including Mozilla.

Linux and Unix developers, can now easily make KDE components -- no matter what toolkits and software they decide to develop with. Recent Unix/Linux desktop applications are composed of small components that could be utilized in several applications or wherever needed. KDE is now the first desktop system to be able to effectively integrate and provide transparent interoperability with such software -- whether written in the KDE native component model (KParts), plain X Windows, or GTK.

As a first step, users can now choose to use either KDE's native sophisticated HTML widget or Mozilla's (which currently utilizes GTK) inside the KDE browser, Konqueror. This easily puts Konqueror in the lead when it comes to browsing the World Wide Web, since the user now gets to select which HTML renderer works best for him/her while still using Konqueror and having all the same advantages of the popular KDE user interface and technology.

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.

The KDE project would like to thank Lars Knoll, Simon Hausmann, and Matthias Ettrich for their coding genius in making this happen.

Links:

Overview including screenshots and installation instructions

Whitepaper

Comments:

Re: Embedding external parts into KDE - krazyC - 2000-12-21

it's funny how kde gets accused of copying windows, when bonobo is pretty much an interface by interface copy of OLE. it shows great vision that kde was able to move away from CORBA when it didn't work into this beauty of a component system. if that's not enough, kparts/dcop has already shown itself capable of evolving while already providing a strong base functionality. now that's what i call innovation.

Re: Embedding external parts into KDE - John - 2000-12-21

Their is a reason GNOME has decided to base bonobo on OLE. OLE is a DAMN good component model. Sure it's complicated, but it's the best out there.

Re: Embedding external parts into KDE - krazyC - 2000-12-21

i never said it wasn't. i was alluding to the fact that kde's architecture is innovative. i'm no expert, but i think kparts will keep evolving as need arises, and meanwhile it works.

Re: Embedding external parts into KDE - Tonttu Torvinen - 2000-12-21

Sounds really great. There has been some similar projects going on (providing simplier interface to Mozilla), but it seems that this makes those efforts less meaningful. However, I just have to use this space to say this. As I'm personally running an old P200 64Mb machine, I would appreciate a lot more improvements to the speed and memory usage of KDE (and X) - rather than having all the time great new additions and configuration options. Of course optimization isn't so fun as creating something new, but it would be great if someone from the developement team could become a bit more ascetic and start removing unneeded stuff and cutting the memory and processor usage of KDE. Though Konqueror is much faster than any other browser in Linux, it is still a lot slower than any browser in Windows - including Netscape - and starting even some small games in KDE takes unbelievably long time.

Re: I would appreciate a lot more improvements... - Shift - 2000-12-21

> "I would appreciate a lot more improvements to the speed and memory usage of KDE (and X)" I think that the KDE team is also working on it : just see KDE1 and KDE2. Moreover, if you think KDE has too much fonctionality, you can use blackbox or IceWM. Konqueror can be use without KDE so you can keep this mervelous browser :)

Re: Embedding external parts into KDE - David - 2000-12-21

Agree with the above. I'm running a 600 celeron O/C'd to 800 with 128 meg of ram. Performance is no where near what it should be and win ME on this machine really blow KDE/Linux out of the water. Of course KDE is more than useable but I'm running basically a 800 Mhz PIII. This machine is also setup very well, I used mandrake 7.2 for ONLY the base libs like glibc and the init scrips, basically just enough to compile with and it's very lean. Xfree 4.0.2, QT 2.2.3 (qt-copy inc xft) & 2 day old CVS of KDE. I realize that optimization isn't as fun as hacking something new but if KDE 2.1 is released with this level of performance it will drive many users on low end machine a way. One of the main fingers pointed at Windows for years by the Linux supporters is that windows has a lot of bloat, KDE seems to be following the same path. Granted a P200 64Mb machine is not exactly state of the art but I do feel that KDE should perform to an useable level on such a system.

Re: Embedding external parts into KDE - Christian Naeger - 2000-12-21

Hey guys, I run KDE2 on a Pentium 133 with 81MB RAM. You can work quite reasonable with it (better than KDE1 but a bit slower than Win). However, I would very very much like any speed/size improvement I could get! Especially, browsing the web (or local directories) is much slower in KDE2 than in windows. Paintshop Pro for example can show me the thumbnails of a directory instantaneously (all images are painted at the same time), whereas Konqy renders every single image one after the other. The same on some www picture sites: Netscape/IE start to build up all images in parallel, Konqy starts the second image only after image one is rendered completly. Is this a bug? Easy to fix? However, KDE2 is much faster than KDE1 or Netscape6 (which is unusable on this machine). Thanks to the KDE Team!! Chris

Re: Embedding external parts into KDE - Jono Bacon - 2000-12-21

I 100% agree that performance is an issue with KDE. KDE2 is a lot slower than using Windows, and I assume we can direct part of the blame to the fact that XFree86 adds an extra layer of bloat. We do have some possible soloutions to this problem, but these soloutions need volunteers to execute them. 1. It seems that much of the problem with KDE performance is down to slow code. If KDE developers were educated more in how to write more efficient coe, this could reduce this problem. A soloution to this could be a section on developer.kde.org dedicated to performance giving tutorials and tips and tricks on writing efficient code. 2. XFree86 is a considerable hog IMHO when it comes down to performance. Although the XFree86 team are doing a fantastic job, reliance on a slow layer below KDE is a natural performance hit. The soloution to this could be a splintered off XFree86 customised to KDE, or developing KDE for the Framebuffer. I have heard that the Framebuffer can be quite slow at higher resoloutions, but I have no idea of the development of the Framebuffer. KDE running slowly on a 200mHz Pentium is IMHO not acceptable for the user. Performance is boring, but although we can all identify the problem, we need firm volunteers to solve the issue. One other idea would be to arrange a tuning week. In this week the CVS could be frozen and only performance tuning commits could be made. I believe this could prove to be a benifit for KDE.

Re: Embedding external parts into KDE - Dawit A. - 2000-12-21

1. It seems that much of the problem with KDE performance is down to slow code. If KDE developers were educated more in how to write more efficient coe, this could reduce this problem. A soloution to this could be a section on developer.kde.org dedicated to performance giving tutorials and tips and tricks on writing efficient code. Huh ? We do optimize as needed, but optimization is the last step in coding. Never ever start optimizing before features are completed unless you are locking for headaches down the road. However, there were several obvious optimizations done with respect to loading config files and loading already used librabries before KDE 2.0 release. Comparisons with Windows is also IMHO moot since we have no integration into any kernel period. We also do not load every DLL this side of the Mississipi to boast performance. Well that is not entirely right since we do similar thingsby utilizing kdeinit so that every applications will not attempt to load and re-loacate already loaded libraries, but still not to the extent it is done in Windows. Anyways IMO neither KDE nor X cannot afford to do things that Windows can for portability reasons, but I personally feel amuzed when people generally accuse developers of not optimizing or not knowing how to optimize before really understanding what issues are involved !! There are many things one needs to consider before going willy nilly into optimazations. I am sure they will be forth coming in future releases of KDE... Down the line one thing that might improve speed is multi-threading. When Qt gets to be muti-threaded then we can do the same thing to KDE and this might indeed boost performace a great deal specially with GUI blocking problems which tends to be the thing most people notice and associate with performance problems... BTW, on my machine a bare bones installation of Windows 95 was about the same speed my KDE 2.x setup above with all debuging enabled... Regards, Dawit A.

Re: Embedding external parts into KDE - Pierre Phaneuf - 2000-12-21

Good answer, except for the multithreading part. Multithreading doesn't improve speed, it improves apparent speed, which is quite different. Multithreading is actually less efficient. On the surface, doing many things at once like a multithreaded program without using real threads seems more complicated, but real multithreaded programming has so many hidden pitfalls and debugging problems that you would probably have found the increased difficulty of singlethreaded code not that great. The <a href="http://oss.sgi.com/projects/apache/">Accelerating Apache</a> project for example, has managed to make Apache 1.3 up to ten times faster and Apache 2.0 up to four times faster on the SPECweb96 benchmark. A major part of this was ditching threads for their <a href="http://oss.sgi.com/projects/state-threads/">State Thread</a> package, which simulates multithreaded behavior without actually using threads (similar to <a href="http://www.gnu.org/software/pth/">GNU Pth</a>, by the way).

Re: Embedding external parts into KDE - KdeFan - 2000-12-21

Well, I'm not sure what everyone is talking about with respect to speed problems either. I used to dual-boot win98 and kde 2.0 (on linux) on this machine (until windows stopped booting about a week ago), a plain PII-300 with 128mb, and I have found the speed to be very similar. Speed isn't the only usability concern, and I much prefer kde... and I would even if it was slower. Perhaps people are using badly built binaries?? First when I tried a kde 2 beta (binaries), I thought that it was really slow but after compiling qt and kde myself, with exceptions disabled, etc., I found kde 2 to be blazingly fast (especially considering what it actually does). When I say blazingly fast I mean it's as fast (sometimes faster, sometimes not quite as fast) as windows while being much more comfortable and configurable. Anyway, thanks kde developers!

Re: Embedding external parts into KDE - Oliver Immich - 2000-12-22

Okay, to be more precise on the performance thing and to avoid misinterpretation of what could be called fast and what could be called slow in kde2: The launching of apps itself is it which decreased my enthusiasm about kde2. I absolutely agree to what people said above, that it become quite boring to wait for an standard app like kmail or korganizer to come up. I even cannot make the binaries responsible for that since I went through three kde2-releases after final came out and all were the same slow block of software. If I should be wrong, I may ask, why didn't the kde-team give advice to the distributors to do their job 'properly'.

Re: Embedding external parts into KDE - kdeFan - 2000-12-22

If I should be wrong, I may ask, why didn't the kde-team give advice to the distributors to do their job properly. I think that may be where the real problem is. Maybe the packagers just aren't building optimally (not to complain - their efforts are appreciated). I know that I thought kde2 was slow until I found the thread here on the dot about how to compile kde (and qt in particular) correctly. It has been speedy since then. I used gnome for a week or so, and it wasn't any faster than my kde2 desktop. Aside from that I can only assume that the speed issue is more subjective than anything, because I just can't relate to your experience. For me, kmail opens quickly (certainly quicker than Outlook did) and I never really feel that I'm waiting for it. Anyway, I hope it gets worked out.

Re: Embedding external parts into KDE - japy - 2000-12-22

i remember what my former boss told me once, "you can never ever please everyone, not even if you sweat blood!". here is what i have to say: if you dont like kde then dont use it, it's that simple, u have no right to complain because ur using it free of charge. kde folks are working hard to give us a nice desktop, we should give them a big thanks first even if some of us find it unuseably right now(tho, i doubt it), just wait, think about just how long kde existed, 1996, its only been 4 years, u can give constructive criticism rather than complaining, if you have a 5 year old processor, blame it for the slowness, not your 2-month old software. and stop comparing kde to windows, its a very different world. i also cant imagine people wasting their time arguing about kde icons, its ugly, gnome icons are better, very unpleasant to they eye etc, stupid people.

Re: Embedding external parts into KDE - Nick - 2000-12-22

Reality check.. This argument does not hold water. If you don't like it, and you don't have the skills to improve it, then the best you can do is attempt to raise the issue. That's how things improve. Saying "If you don't like it, don't use it" is a rather ignorant argument. It's apparent that these people like KDE, but they want to see it improve. They are making good points about the direction KDE needs to go. Windows and KDE are in competition, and thus comparing the end user experience of KDE with Windows is a valid comparison. We all want KDE and the various platforms it supports to gain wider acceptance, and that will require it to surpass windows in functionality, speed, and ease of use.

Re: Embedding external parts into KDE - japy - 2000-12-23

>If you don't like it, and you don't have the >skills to improve it, then the best you can do >is attempt to raise the issue. just like what i said, deliver constructive criticism, not simply complain about it and make it appear kde is totaly useless. >Saying "If you don't like it, don't use it" is >a rather ignorant argument. what would you feel when your favorite desktop is undersiege? saying "i used to run kde 1.1.2on my prehistoric computer and it works lightning fast, while suddenly when i install kde 2 it crawls" is what i believe a rather ignorant argument. yes we all want kde to improve, but theres a proper place for this, and thats the bug tracking system. im sorry if i sounded so rude, i recognize that this is a disccusion and respect everyones opinion, but people wanting to switch to kde and wants to learn more first, might interpret all of this as sign that kde is not a worthy alternative. besides this is dot.kde.org, AFAIK, this site gives out good news and information about the beauty of kde, we are suppose to thank the developers here, its very irritating just after you have read a nice news about kde, then people will flood in their misseries and griefs etc. (should'nt it be all addressed to complaints.kde.org?) >Windows and KDE are in competition, and thus >comparing the end user experience of KDE with >Windows is a valid comparison. i did not say they aren't, i said kde is totally different to windows, when it comes to design, windows is the operating system itself, which makes it more integrated with its compononents, on the other hand kde runs on top of x, which in turn runs on top of linux. windows can play tricks it wants with regards to resources, but kde can do only what it is permitted by x and linux respectively. but of course, both are desktop, and that is where we can compare windows with kde: windows has intallshield, kde has ./configure, make, make install, kde has virtual desktops, windows doesn't, kde users are cute, windows user's aren't (ha ha ha) and many more. you see, we can only compare what we can see and feel on the outside, on the inside its totally different. and that is why kde's performance cannot be directly compared to windows, (not of course if we have a microsoft windows desktop environment for x!) but lets simply agree on one thing nick, before we start a "words war", lets just be happy kde users! may the force be with you all!

Re: Embedding external parts into KDE - Olivier LAHAYE - 2000-12-22

I totally agree. More over, Speed of kde2 is the same as win98 on my system. The only slow thing is XFree86 V4.01 (Frame buffer is realy slow) On thing to improve performace (if you own a very very very old obsolete computer ;-) ) is to choose a simple styles just like windows (without pixmaps). Functionnality is very important (IMHO), because it is a race to functionnality. If you quit the race, then peoples moves to the concurents. I've heard the same things between MUI and BGUI under Amiga (MUI is to KDE what BGUI is to GNOME) People using 7MHz 68000 expected high drawing speed with fancy bitmaps (they said that it was slower than the standard system (plain colors) and thus, that that was inacceptable! ) Maybe peoples could ask for high speed on 80386SX16 VGA systems? I think this attitude is stupid. The most important thing is an API that allow high developpement speed. That is the most important thing. at KDE2: This model (C++, Qt, And mode) allowed koffice in one year and lots of applications in few weeks.

Re: Embedding external parts into KDE - MichaelM - 2000-12-23

The only slow thing is XFree86 V4.01 (Frame buffer is realy slow) Not getting involved in the argument, but I actually thought X 4.0.1 was rather zippy (especially compared with X 3.3.X), but then again, I'm not using Frame Buffer

Re: Embedding external parts into KDE - Tonttu Torvinen - 2000-12-23

My comment was meant to be 'constructive critisism'. Critisism can always be taken as complaining - it just depends on the point of view and the attitude. Sure I currently have quite an old and slow computer, but I see no reason why I should spent a lot of money to upgrade it when I can do most of the things I need to do with this P200 64Mb (I can guarantee that I can imagine hundreds of better ways to spend my money). I'm not interested in having always the latest new gadgets, but what I want to have is to be able to do the things I need to do in the most comfortable way. Even though Win95 runs a lot faster than Linux&KDE, I've noticed KDE to be the best environment for me in the most cases. As the speed is the biggest problem here, I would like to see also this part to be improved. Sorry to say, but what you said doesn't sound very 'open'. Rather than openly discussing the problems people are having with KDE, you would like us to shut our mouths, be quiet and pretend to be fully satisfied - while there still is lot to improve.

Re: Embedding external parts into KDE - japy - 2000-12-24

sorry people!

Re: Embedding external parts into KDE - japy - 2000-12-24

my girl went away, so I was said I nervous

Re: Embedding external parts into KDE - Tonttu Torvinen - 2000-12-25

No problem, I was just trying to be constructively critical also to what you said.. ;)

Re: Embedding external parts into KDE - Geert - 2003-11-19

On a P200/160mb mem I can run XPpro with some services, Mandrake/KDE keeps on swapping back forth on the HD.

Re: Embedding external parts into KDE - Joao Cardoso - 2000-12-26

Curiously ha have pretty acptable performance on my ancient P166 with 48Mb. Sure it is slower in some aspects than windows 98 on the same machine but it is worth it!

Re: Embedding external parts into KDE - linuxfan - 2001-01-22

I have also found that KDE and linux was no speed demon compared to windows, and I know to a certain extent why windows seems fast. However, I have also discovered that there are reasons why linux and kde is slower than it should be. I am no expert on software and operating systems, but here are a few of the things I found result in slow performance: 1)32 bit disk read/write access is not enabled, nor is direct memory access.(more detail on this at www.frankenlinux.org) 2)the kernel is not customized, as it is the distribution's default kernel install. 3)The current constraints of linux ( for example, reiserfs is supposed to speed up performance dramatically). 4)The x server is a problem for memory usage and rendering speed. Despite all that, though, it would be nice to be able to have a fast desktop, and if anything listed above can be eliminated, or any further improvements to kde made, that would be great.

Re: Embedding external parts into KDE - ac - 2000-12-21

This is big news for the Linux desktops and the Linux community. Anyone want to submit this story to Slashdot?

Embedded bugs - Otter - 2000-12-21

..and you can be sure that the screenshot is showing Mozilla embedded in Konqueror because it contains three egregious Mozilla-specific rendering bugs!

Re: Embedding external parts into KDE - Henrik - 2000-12-21

Wow! That's just amazing! it seems to me KDE is accomplishing something almost of this magnitude every two weeks or so. I'm writing this with antialiased fonts in all my Qt apps, something that most people thought impossible in X a year ago (ok, keithp of X fame has a lot more to do with that than KDE, but patching Qt to use antialiased fonts didnt take long) Lets see - what other amazing things has KDE released since/with 2.0: * Konqueror/khtml - Probably the best and fastest linux browser of today. It renders almost everything correctly. Only IE and Netscape work with more. * Konqueror - Kickass file browser. * KParts/DCOP - As good as microsofts component technologies (whatever they're called this week) * Themes - Widget themes are fast and look good. * KOffice - Far from being finished, it's already very useable. and now this.. all i can say is wow! (again) :) How will the gnomes and the redmondites ever manage to keep up with the trolls? :)

Re: Embedding external parts into KDE - Dom - 2000-12-21

I don't want to flame, but rather alleviate ignorance here. Gnome has: * Galeon - Kickass web browser using GtkMozEmbed * Nautilus - already fully usable and able to give Konqueror more than a run for its money * Bonobo - a lot more sophisticated embedding framework than KParts (minus the recent X-Parts extension) or OLE2 for that matter * Themes - on the GTK level and soon Gnome-wide * Gnome Office - AbiWord and Gnumeric simply kick ass. And AbiWord is about to get a KDE port too. I won't even go into how WinME compares, because you'll dislike that even more... KDE2 kicks some major ass. But I wouldn't discount Gnome or Windows as easily as you do.

Re: Embedding external parts into KDE - Henrik - 2000-12-21

<blockquote> I won't even go into how WinME compares, because you'll dislike that even more... KDE2 kicks some major ass. But I wouldn't discount Gnome or Windows as easily as you do. </blockquote> Gnome, Windows and KDE each have strong points, and there's a whole lot of cool code in Gnome. My intention wasn't to bash Gnome (or Windows for that matter - I agree that it probably has the best UI of the bunch today). The point I was trying to make is that the rate of progress of KDE is absolutly astounding.. -henrik

Re: Embedding external parts into KDE - Ergo - 2000-12-21

Obviously I'm getting slightly off-topic here, but now that you brought up the gnome and redmondite falling behind thing, I suppose there's no harm in sharing my opinions. Something that I really liked about Helix Gnome when I tried it, was the easy installation method. Download one installation binary, select the programs/packages you want, and voilá. Now that's something I'd really like to see in the next major KDE release. I'm not sure whether it's possible to keep the packages up-to-date with Helix Gnome, but Windows Update seems work just fine for me at least. But it wouldn't be too hard to add it to the installation program, making KDE extremely easy to install and maintain, making it superior to Gnome and Windows in this sense too.

Re: Embedding external parts into KDE - Eric Veltman - 2000-12-21

If anything changes about KDE installation, I do hope that the installation "backend" doesn't change. I like the current feature of most Linux distributions which is called "package manager". The package manager ( RPM or whatever ) should do the work. I wouldn't like to see every suite of programs implementing its own package manager, because then it only becomes harder to manage the software installed on your Linux system.

Re: Embedding external parts into KDE - Bernd - 2000-12-22

I agree. I think installation via a packet manager ist th best way. I personally had some troubles with the Helix insatller on SuSE. KDE rpm installation was never a problem for me.

Re: Embedding external parts into KDE - baco - 2000-12-21

How about using some kind of apt-frontend? Apt works great, its clearly the most advanced package manager available. Besides, since apt is now able to handle rpm's there should be nothing to stop us from standarizing on it. Doing so would also stop us from duplicating effort, in creating yet another package management solution.

Re: Embedding external parts into KDE - John - 2000-12-21

HelixGnome for Debian is an apt frontend. The HelixInstaller is generic enough that it would easily work with KDE packages. A port to QT would not be difficult.

Re: Embedding external parts into KDE - John - 2000-12-21

HelixGnome for Debian is an apt frontend. The HelixInstaller is generic enough that it would easily work with KDE packages. A port to QT would not be difficult.

Re: Embedding external parts into KDE - Erik - 2000-12-22

apt-get kdelibs3 (of course, you'd haveta be using debian) :-p Erik

Install KDE2 on debian - Jason Katz-Brown - 2000-12-22

First of all you must run woody. Then, # apt-get install task-kde Then, you're done ;) Jason

Re: Embedding external parts into KDE - Paul Hawthorne - 2000-12-21

This sounds great. Although I'm not a programmer, I can see how this opens a whole new world to KDE. I am impressed with design of KDE2, which seems to make it very easy to expand KDE far beyond it's built-in functionality. I have recently installed CUPS as my print system. I also installed QTCUPS, which provides a wonderful print dialog. However, I am not able to configure KDE2 to take advantage of the QTCUPS. I guess the printing system in KDE2 is hard-coded to the basic lpr system. Does this announcement mean that it should be easy for someone to integrate QTCUPS into the KDE printing system? Also, while I love all the new cool stuff happening with KDE2, I hope the developers add the ability to remember window size and screen position between sessions automatically in the next update. I know I can manually save window size (in konqueror), but not screen position. At any rate, thanks KDE team for all the wonderful work you are doing. Your continued innovations are giving the linux community less and less to criticize about KDE, and giving the other computing environments less to criticize about linux in general. KUDOS!! Paul.....

Re: Embedding external parts into KDE - David - 2000-12-21

I'd really like to find more information about how KDE prints. I also have cups installed on one machine but KDE doesn't use it. Konqy only lets me print ot a file, however a cups test print works perfectly. Also what's the story with all the printer drivers in kdesupport? I have a feeling that KDE does have some sort of print system built in but I have no idea how it works!

Re: Embedding external parts into KDE - KDEer - 2000-12-22

It's a class called kprint.

Whitepaper? - KuriousGeorge - 2000-12-21

The whitepaper (at http://trolls.troll.no/~lars/xparts/doc/xparts.html) has been slashdotted. Does anyone have a mirror?

Re: Whitepaper? - ac - 2000-12-21

It's available, just really slow. If you're patient, you'll get it.

Re: Embedding external parts into KDE - Anonymous - 2000-12-21

Does this mean I can use KHTML in Nautilus?

Re: Embedding external parts into KDE - Jörgen Lundberg - 2000-12-22

No. It means that you can embed componenets from nautilus in konq e.g., but not vice versa.

Huh? - Anonymous - 2000-12-22

But Bonobo is toolkit-independent too.

Re: Huh? - kupolu - 2000-12-23

But bonobo isn't as advanced as KParts. Go ask the Gnome developers to try to catch up to KDE development :) -- Chris

Re: Huh? - Anonymous - 2000-12-23

How do you know that's true? KParts is intended to be *simple* (read developer.kde.org) Bonobo is based on CORBA, which is very powerful and complex. So Bonobo can embed KDE apps as well.

Re: Huh? - kupolu - 2000-12-24

Slowly.

KParts + Fixes = XParts (aiming to be Bonobo) - Cleber Rodrigues - 2000-12-21

As far as I know, KParts never gave much attention to other toolkits or architectures. Now this has been recognizes as a major goal. CONGRATULATIONS!!! I just don't like the way it's been presented. I mean, as if it was the pioneer technology for doing that... Or treating other toolkits with some inferiority! "...Mozilla's (which currently utilizes GTK)... It sounds as if it's a bad thing... BUT IS T??? Maybe the text should say clarify people that KParts (or XParts) NOW can do the same thing other component models such as Bonobo already do.

Re: KParts + Fixes = XParts (aiming to be Bonobo) - Peter Putzer - 2000-12-21

A lot of bark, but now bite? Where are the cool apps actually using Bonobo?

Re: KParts + Fixes = XParts (aiming to be Bonobo) - Cleber Rodrigues - 2000-12-22

Let me see: Evolution, Nautilus, Gnumeric, Gnome-DB, and almost every Gnome Application that would make sense providing a component for re-use. And actually, what does it have to do with 'cool apps' ???

Re: KParts + Fixes = XParts (aiming to be Bonobo) - Dom - 2000-12-22

Soon you'll be able to add AbiWord to that list...

Re: KParts + Fixes = XParts (aiming to be Bonobo) - anon - 2000-12-22

None of these applications is stable yet. For Gnumeric there is even a text that mentions that one shouldn't file bugreports if one compiles with Bonobo (because it is still way too broken).

Re: KParts + Fixes = XParts (aiming to be Bonobo) - Dom - 2000-12-22

I'd argue against your statement. I have a fairly large role in the AbiWord project and am an ex Gnumeric hacker (amongst other things). From what I've seen, KSpread can't hold a candle to Gnumeric (though I could be wrong here). KPresenter is pretty darn cool. KWord is a damn fine app that I want to study more. A lot could be gained from Abi and KWord people working together. AFAIK, Jody (the Gnumeric maintainer) just doesn't want to have to deal with bugreports not related to gnumeric, but rather Bonobo. This is just "boiler-plate" text that he attaches to each release announcement. If you'd try a Gnumeric release that was bonobo-enabled, you'd see exactly what I mean. Just because an Application doesn't have a "1" as its major build number doesn't mean that it's not stable. It's just under heavy development. When Gnome 1.4 comes out shortly, you'll see what I mean. Keep up the good work on KDE, guys.

WRONG! - TrollKiller - 2000-12-22

WRONG ANSWER DUDE! Gnumeric is *far* superiour to KSpread!

Re: WRONG! - Anon - 2000-12-22

Dude, that's what "can't hold a candle to" means. Did you even bother to read his post?

Re: WRONG! - TrollKiller - 2000-12-22

I was replying to your topic, not Dom's.

Re: KParts + Fixes = XParts (aiming to be Bonobo) - Thomas - 2001-01-05

Hmm, strange. So bonobo can talk to kparts ? Or use any other truely object-oriented toolkit (i mean C++ based) ? How comes ?

We are KDE Of BORG - Matthias Lange - 2000-12-21

That´s great! The following scene comes to my mind: [On the bridge of the starship Nautilus] Crewman: Look, Captain, we´re being pursued! Captain: Full Speed Ahead "WE ARE KDE OF BORG! PREPARE TO BE ASSIMILATED" Captain: Evasive Maneuvers, Fire Mozilla Grenades! Crewman: Sir, the grenades simply attach to the ship, no damage done. Captain: Oh, we better give up then... :-)

Re: We are KDE Of BORG - reihal - 2000-12-22

hehehe

Re: We are KDE Of BORG - egkamp - 2000-12-22

Assimilation is a *good* thing when everyone plays nicely and shares.

Re: We are KDE Of BORG - Markus Kohls - 2000-12-22

if i would get the same feelings when i look onto the kde-desktop as when i look at 7of9, it would be great! ;) cya. markus

We are Gnome of Q - TrollKiller - 2000-12-22

TrollKiller To protect the Internet from ignorant trolls. ------------------ "We are KDE of Borg. You will be assimilated. Resistence if futile." Gnome of Q: "Oh no, not those suckers again..." "Lower your weapons and..." (Gnome of Q snaps in his fingers) ***KABOOM!*** Gnome of Q: "Yet another KDE of Borg ship gone. Heh heh." >:-> ------------ TrollKiller To protect the Internet from ignorant trolls.

Re: We are Gnome of Q - TrollKillerKiller - 2000-12-22

What a lame reply

Re: We are Gnome of Q - TrollKillerKillerKiller - 2000-12-22

What a lame comment.

Re: We are Gnome of Q - jam_kim - 2000-12-28

Geee.... If you just want to be a troll and making such wasted comment you have accomplished it. Finally, you've found dot.kde.org.

Re: We are Gnome of Q - G Killer - 2000-12-22

>> "Lower your weapons and..." >> (Gnome of Q snaps in his fingers) >> ***KABOOM!*** >> Gnome of Q: "Yet another KDE of Borg ship >>gone. Heh heh." Gnome of Q: Caption.... Caption.... we.... G Killer: hehehehe... they can't even recognize there own ships... :)

Re: Embedding external parts into KDE - Jebediah Smith - 2000-12-21

It's impressive that not a single line of code was modified in Konqueror to do this. Something can certainly be said for the architecture of KDE2. However, I fail to see how this is in anyway revolutionary. It's been done dozens of times before in many different toolkits. The article, and comments above, and most ntoably the Slashdot article, suggest that XParts/KParts are now able to embed next to everything - Bonobo Components, OpenOffice, etc. This is simply not the case. Embedding the GtkMozEmbed component is a very special case. This component was designed as a GTK widget. QT can already use GTK Widgets. So the effect shown is different from Galeon, Nautilus, etc only in so far as it required no modification to the Konqueror code. This is all illustrated in the whitepaper linked to above. I do not mean to troll, I simply want to set many of the posters here straight.

Re: Embedding external parts into KDE - Eric Laffoon - 2000-12-22

I do not mean to troll, I simply want to set many of the posters here straight. I supposed it would be more impressive if you could figure out how to post once instead of four times.

Re: Embedding external parts into KDE - reihal - 2000-12-22

I don't think he did, it's a bug, it have happened many times before.

Re: Embedding external parts into KDE - reihal - 2000-12-22

I don't think he did, it's a bug, it have happened many times before.

Re: Embedding external parts into KDE - Matthias Ettrich - 2000-12-22

KMozilla does not require Qt's ability to utilize GTK widgets. Instead, it reparents an X-Window with XEMBED. This works on a wide range of toolkits. But your are right. There's indeed nothing revolutionary with the approach, and I don't believe the web page or the whitepaper claim this. It is basically a demonstration on what we TOLD people for a long time now: KParts is not a dead end. It's powerful enough to support other component models. The fact that we use fast inprocess components with a KDE API doesn't mean, we cannot utilize other models. The fact that we dropped CORBA doesn't mean users suffer from less interoperability. But not everybody is a developer and not everybody understands the technical issues involved. So people simply didn't believe us. "KDE does no longer use CORBA" was percieved as "GNOME components will never be usable in KDE". The only "revolutionary" thing is, that we demonstrated what technical people knew for a long time. Now, KMozilla is special, because it (or rather GtkMozEmbed) isn's a GNOME or Bonobo component. But the approach we've chosen is indepentent from that. We are confident that we will be able to provide a generic BonoboXPartHost that is able to serve arbitrary Bonobo components as KParts. This is just a bride, it doesn't require changing either Bonobo or KParts. A similar thing was done with Java and Konqueror previously, or the Netscape Plugin support.

Re: Embedding external parts into KDE - Jebediah Smith - 2000-12-22

I didn't mean to suggest that the webpage and/or whitepaper suggested that it was revolutionary. I was trying to set some of the posters here - and on slashdot - straight. If this same technology could be extended to use Bonobo, I have either read the whitepaper wrong, or you are much smarter than I:) Probably the latter. While this certainly shows off KParts' well-designed architecture, I'm unsure if this would be practical. When loading a Bonobo component, you would have all the overhead of Bonobo (oafd, ORBit, etc) along with KParts' overhead. How would this effect performance? A better idea, IMNSHO, would be a concerted effort to bring a standard COM to *N*x/BSD. Please, don't anyone reply with "We have a standard COM....CORBA."

Re: Embedding external parts into KDE - Karl-Heinz Zimmer - 2000-12-23

On Friday December 22, 2000, Jebediah Smith wrote: > While this certainly shows off KParts' well-designed architecture, > I'm unsure if this would be practical. > When loading a Bonobo component, you would have all the > overhead of Bonobo (oafd, ORBit, etc) along with KParts' overhead. > How would this effect performance? Jebediah, please don't get me wrong, but this does not sound very dramatically to me. The KParts component model was designed to be effective and easy to implement while at the same time working really FAST. There is not very much in looking for 'overhead of KParts' - trust me: the time consumed by KParts can be ignored when you have to deal with something that time-consuming as CORBA. I do *not* intend to start a flame-war against CORBA but I thought it might be good to mention that this possibility of embedding external parts into KDE is a great thing: Just be happy and forget about the *tiny* amount of overhead that might be caused by using the KParts model. Karl-Heinz <A href="http://home.snafu.de/khz/">http://home.snafu.de/khz/</A>

Re: Embedding external parts into KDE - Jebediah Smith - 2000-12-23

You're certainly right. The point of the post was that embedding Bonobo comonents as a KPart would require that oafd, ORBit, et al., be loaded. The added overhead isn't coming from KParts - It's coming from Bonobo.

Re: Embedding external parts into KDE - rsv - 2000-12-22

Does a right click on the KMozilla component in Konqueror bring up a menu? The last time I saw it, neither Galeon nor Nautilus could do it. If a standard menu does not come on a right click (with save as.. copy link etc), it is better to stick to KHTML

IDEA! (embeding Gimp into Krayon) - t0m_dR - 2000-12-22

Well, what about using this technology to embed Gimp into Krayon (the former KImageShop)!!. That way you'll have all the power that Gimp already has without the crappy UI!

Re: IDEA! (embeding Gimp into Krayon) - reihal - 2000-12-22

Make a Kparts of the GIMP libraries.

Re: IDEA! (embeding Gimp into Krayon) - Jason Katz-Brown - 2000-12-22

A kde developer told me a kimp was made, a port of gimp to qt, but that gimp devs got mad so it was never realeased... hmmmmmm... Jason

Re: IDEA! (embeding Gimp into Krayon) - t0m_dR - 2000-12-22

ummm,,,,isn't it GPL? So who cares if they were Mad!. Anyway I think that was in the pre GPL era of the QT toolkit. I Think they were Mad 'bout the licence...

Re: IDEA! (embeding Gimp into Krayon) - Cleber Rodrigues - 2000-12-23

I think this comes down to a lie. I just don't believe such a port exists.

Re: IDEA! (embeding Gimp into Krayon) - anon - 2000-12-23

Such a port did indeed exist. It was shown to some developers (I think even Miguel Icaza saw it) on Linux-Kongress and on Linuxtag in 1998.

Re: IDEA! (embeding Gimp into Krayon) - t0m_dR - 2000-12-24

sure it did, if you search for "Kimp, Linux , Kde" keywors you'll find some (OLD) material about it...

Re: Embedding external parts into KDE - ChrisWiegand - 2000-12-28

Something I keep thinking of is this: KParts seems to me (a Linux programmer and a VB programmer) to be much more like local-only ActiveX EXEs and ActiveX Controls. (To my knowledge KParts doesn't do networking). Bonobo/Corba, OTOH, is made for networking, and using it locally would have a performance hit vs. KParts (probably not much of one, but it's probably still there). Why not have both? I don't want my real-Cool-Grid widget running over a network, but putting business logic into a component on a shared server somewhere makes lots of sense to me...

Embedding IE running in Wine in Konqi!!! - TROLL PATROL - 2003-05-28

IE is like the fastest browser ever, and then embed in xparts in konquerer... totally fast... oh my god... Then embed VM ware in konqi in xparts and run mozilla in the konqi in the vmware in the konqi, totally the slowest thing ever lol.