DEC
21
2000

Embedding external parts into KDE

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.

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

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.


By krazyC at Thu, 2000/12/21 - 6:00am

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.


By John at Thu, 2000/12/21 - 6:00am

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.


By krazyC at Thu, 2000/12/21 - 6:00am

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.


By Tonttu Torvinen at Thu, 2000/12/21 - 6:00am

> "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 :)


By Shift at Thu, 2000/12/21 - 6:00am

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.


By David at Thu, 2000/12/21 - 6:00am

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


By Christian Naeger at Thu, 2000/12/21 - 6:00am

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.


By Jono Bacon at Thu, 2000/12/21 - 6:00am

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.


By Dawit A. at Thu, 2000/12/21 - 6:00am

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 Accelerating Apache 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 State Thread package, which simulates multithreaded behavior without actually using threads (similar to GNU Pth, by the way).


By Pierre Phaneuf at Thu, 2000/12/21 - 6:00am

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!


By kdeFan at Thu, 2000/12/21 - 6:00am

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'.


By Oliver Immich at Fri, 2000/12/22 - 6:00am

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.


By kdeFan at Fri, 2000/12/22 - 6:00am

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.


By japy at Fri, 2000/12/22 - 6:00am

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.


By Nick at Fri, 2000/12/22 - 6:00am

>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!


By japy at Sat, 2000/12/23 - 6:00am

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.


By Olivier LAHAYE at Fri, 2000/12/22 - 6:00am

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


By MichaelM at Sat, 2000/12/23 - 6:00am

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.


By Tonttu Torvinen at Sat, 2000/12/23 - 6:00am

sorry people!


By japy at Sun, 2000/12/24 - 6:00am

my girl went away, so I was said I nervous


By japy at Sun, 2000/12/24 - 6:00am

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


By Tonttu Torvinen at Mon, 2000/12/25 - 6:00am

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


By Geert at Wed, 2003/11/19 - 6:00am

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!


By Joao Cardoso at Tue, 2000/12/26 - 6:00am

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.


By linuxfan at Mon, 2001/01/22 - 6:00am

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


By ac at Thu, 2000/12/21 - 6:00am

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


By Otter at Thu, 2000/12/21 - 6:00am

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? :)


By Henrik at Thu, 2000/12/21 - 6:00am

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.


By Dom at Thu, 2000/12/21 - 6:00am

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.

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


By Henrik at Thu, 2000/12/21 - 6:00am

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.


By Ergo at Thu, 2000/12/21 - 6:00am

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.


By Eric Veltman at Thu, 2000/12/21 - 6:00am

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.


By Bernd at Fri, 2000/12/22 - 6:00am

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.


By baco at Thu, 2000/12/21 - 6:00am

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.


By John at Thu, 2000/12/21 - 6:00am

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.


By John at Thu, 2000/12/21 - 6:00am

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

Erik


By Erik at Fri, 2000/12/22 - 6:00am

First of all you must run woody.

Then, # apt-get install task-kde

Then, you're done ;)

Jason


By Jason Katz-Brown at Fri, 2000/12/22 - 6:00am

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.....


By Paul Hawthorne at Thu, 2000/12/21 - 6:00am

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!


By David at Thu, 2000/12/21 - 6:00am

It's a class called kprint.


By KDEer at Fri, 2000/12/22 - 6:00am

The whitepaper (at http://trolls.troll.no/~lars/xparts/doc/xparts.html) has been slashdotted.

Does anyone have a mirror?


By KuriousGeorge at Thu, 2000/12/21 - 6:00am

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


By ac at Thu, 2000/12/21 - 6:00am

Does this mean I can use KHTML in Nautilus?


By Anonymous at Thu, 2000/12/21 - 6:00am

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


By Jörgen Lundberg at Fri, 2000/12/22 - 6:00am

But Bonobo is toolkit-independent too.


By Anonymous at Fri, 2000/12/22 - 6:00am

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

--
Chris


By kupolu at Sat, 2000/12/23 - 6:00am

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.


By Anonymous at Sat, 2000/12/23 - 6:00am

Slowly.


By kupolu at Sun, 2000/12/24 - 6:00am

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.


By Cleber Rodrigues at Thu, 2000/12/21 - 6:00am

Pages