Coding with KParts
wrinkledshirt writes "IBM DeveloperWorks has an article here about coding with KParts, KDE's component architecture. It's a little thin, but given that no single component technology has claimed victory yet for Linux, just thought this might be an interesting read for some. It also might lead to some good discussion comparing people's experiences with KParts, ORBit ? , Bonobo ? , or Kylix ? 's CLX..."
Truth is, all software houses use each other for
.NET, if it
R&D.
KParts -truth must be told- is good ol ActiveX components, albeit cleaner.
The ATL with its COM architecture is one of my
favorite win32 tools, along side MFC. KPart is
an integral part of KOffice, in the same ways
COM components are part of MS Office.
No one is bashing the KDE team for going with the
devil, just because they have seen the devil put
its weight behind component based software and
make it work.
Miguel also sees the samething, and he knows that
the devil would never have adopted
didn't work.
After all the hype and noise about .NET, tomorrow's technology tomorrow, I'm glad there is now a little focus on some of the great technologies we have *today*.
KParts is modest. It doesn't not try to solve all the problems of the programming community. But it's *damn* good at what it's good at.
Like they say, the right tool for the right job. Only rarely will you find a one-size-fits-all solution.
(Please browse at -1 to read this comment.)
And no single component technology will "claim victory". Different applications have different needs. For some applications, CORBA interoperability is absolute essential.
KParts in particular is further held back by the fact that it is covered by the GPL: commecial developers do not like being nickled-and-dimed just to put their software on Linux, in particular since the industry standard is free. And KParts is (at least perceived to be) biased towards C++.
It's nice what the people over at KDE are doing. But don't expect world domination.
All these "component architectures" are really mostly driven by limitations of C and C++ anyway. In the long run, the issue of component architectures will largely go away, as desktop software development shifts to Java and C#. Yes, Java and C# still require some conventions for components, but they already have most of the hard parts implemented as part of the language.
Of course Mozilla is slower than Dillo, because it has more features. Of course KDE architecture, that makes life easier for programmers, has a cost in performance. This is obvious. No one is forcing *you* to use them. I'll tell you why I'll keep using the KDE framework to write my applications. First, the design is very clean, DCOP, KParts, KIO, etc are simply awesome. Second, it makes easier and faster writing applications with the GUI features that most people nowdays want (yes, you are not one of those), Third, I don't really care about the small little performance cost I have to pay, it is perfectly acceptable with today's computers, at least with mine, and all of my friends. As it has been said many times, CPU time is way cheaper than programmer's time. And finally, this is free software, I'm already giving my time to write software for free, if there are some people still using pentiums at 100 megahertz that will bitch about my "bloated" software, I couldnt care less. There are other programs they can use, anyway. Sergio
"Agree with them now, it will save so much time."