Slashdot Mirror
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..."
I just have to say how impressed I am with anything KDE related. They seem to really always make sure they have the horse in front of the cart, when it comes to their libraries and subsystems.
.. while I can't speak for the technical equivilences, I can say that they simply don't seem to get used enough in the Windows world .. ie, that centralized functionality seems to run counter the competative software marketplace, which is a real shame.
.. haha, whats the point of componants then? :P)
I've done a few things with QT and KDE (before KParts, unfortuantely), and I was blown away by the cleanliness of the architecture of KDE's codebase and subsystems.
KParts in action is extremely cool.
BTW, I suppose ActiveX controls are the Windows equivilent (they communicate over COM and DCOM as I recall?)
I think KParts, technical superiority/inferiorities not withstanding, is far more useful because open source developers are far more interests in centralizing functionality and more likely to attempt to reduce redundancy in codebases and application bases. That's why I think KDE is such a winner, and will benifit from a componant based archecture far more in the long run. (IE is a componant too, and MS claims they can't even 'unglue' it from the OS
"Old man yells at systemd"
Perhaps the biggest complaint with ActiveX was all the overlapping confusing interfaces and APIs that one has to become familiar with in order to properly code a component (especially during its early days). Couple that with obtuse confusing documentation (which has improved over the years) and you had (still have?) a real stomach bleed when implementing a new control back then. -- Version 2 is always cleaner, nicer and more consistent ;)
I understand where you're coming from, although to be honest, my high-end Athlon chip and DDR RAM don't mind KDE at all.
There was a survey at dot.kde.org about users' #1 concerns about the desktop environment. About one out of four said they were concerned with its speed.
That being said, you should definitely read (or at least skim through) this article about C++ applications on the desktop.
Eric Krout
There is one thing that strikes my attention about kparts in the listing of disadvantages. "A single component can bring down the entire application." That can be annoying, I wonder if they'll find a way to implement another application to catch the falling components should there be a problem. Personally, I'd rather have 2 windows doing 2 different things, as that's a favorite X feature. Nothing against KDE, i like/use it. I really like the krash handler too. a lot.
"i can never say no to anyone but you"
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.)
Would have been a good idea to link to the solution for the problem described in this article, IMHO.
Programming can be fun again. Film at 11.
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.
Ah yes... You are correct. However, there is a new thing called Xparts. This is basically works just like a Kpart, but is actually a proxy which can communicate with objects written in other languages. It's talked about in the article.
In fact, they mention that a "vi" Xpart is under development. So you could embed vi in kmail and write all your email in vi.
Need Free Juniper/NetScreen Support? JuniperForum
ActiveX does enter the picture, though, because its pretty simple to write ActiveX components that handle a lot of the COM busywork. Delphi and C++ Builder ship with utilities that help generate such components.
If you think a dependence on Qt means a dependence on KDE, you don't understand what either are. Qt is a cross-platform library. KDE is a desktop environment based on Qt. (Interesting, since KDE is Unix/Linux only. I gather the KFolk just liked the Qt API.) No Qt application needs KDE to run, unless it specifically uses the KDE API.
Kylix is itself a CLX application, so it needs Qt to run. It does not require KDE or any other desktop or window manager. When I put this in the release notes, a reviewer objected to the implication that you can run Kylix without a window manager. In point of fact, you can -- I tried it. Not very practical, but it is possible.
About that Qt DLL. Yes, you need it to run CLX apps under Windows. This is not a precedent! I can't think of any non-trivial Windows application that doesn't require at least one aftermarket library to run. Check your System32 directory. See any .BPL files? These are Borland Package Libraries, a kind of DLL. Their presence means you've installed an application written using Delphi or C++ Builder.
It's bugged me from day one, and yet it seems nobody else notices... Either everyone in the world is a moron, or people who work in the software field think that they live in a world apart from everyone else...
Programming is engineering... Some engineers make an engine run, some make web browsers. The basic concepts are the same. Yet, the software industry bastardizes those principles.
Engineers design things to be cheap an effecient. The software industry designs things to be cheap as hell. It's the equivalent of an engineer designing a plastic car engine. Reclkess disregard for performance and stability, focusing solly on price.
It's terrible. That's the reason why Windows is unstable, slow, et al. The developers do everything just so it works... What's most software engineer's solution to unstable programs? More code on top to do more error checking. Don't even think of coding correctly in the first place.
KDE developers use C++. Why? because you can QUICKLY and EASIALLY write bloated programs, and that's all they care about. They don't care about a quick piece of code, just that it works. I shouldn't single out KDE, since this practice is ubiquitous in software design.
Everyone decides how they can write things easier, not how they can write something that will work better, run faster, use less memory, etc. It's just not how things are done. So we go out and buy new computers that suck up more power and more money out of our pockets because the programs are getting slower. HOW THE HELL DID WE GET HERE? Why is it acceptable to spend thousands every couple years? If you focused that money on good programs, you wouldn't need to upgrade. If you have programs that run nicely in 16 Megs of RAM, why spend thousands to upgrade?
Software practices like this are going to come to a head. They have to. It's going to reach a point where people either refuse to buy new computers because they don't have the money, or want to spend it on something else. Or the otther possibilty is power concerns. We may reach a point where traditional cooling methods are not enough, or power cannot be generated fast enough to suppy all these computers. Then the computer dillema will solve itself. More effecient hardware will accompany more effecient software. Perhaps one company will come forward and say 'Our software will run more quickly on the computers you are throwing away, than the software of our competitors on those new computers they said you had to buy.' Then things will change. Then KDE will no longer be a glutton for CPU power. Then people say dammit, I'm sick of this upgrade shit. I'm keeping my computer. It works just fine. I'll use the software that runs nicely on it and not touch KDE until they clean up their code.
Then, we will all use XFce as our desktops, Dillo to browse the web, OpenBSD as our OS, low-power Laptops as our platform, and do away with Mozilla, Windows, Athlons/P4s, Gigantic CRTs, and any programs that eat up more memory or CPU cycles than they need.
The only question to ask is, how far off are we? How long will it be before the real world invades the computer world and smacks some sense into all the developers, engineers, and geeks? I think we will all be much happier, and who wouldn't be happier when they're spending less money on their PC habbit?
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant