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 ;)
If you want components isolated, then you'll probably have to run them in a child process or at the very least its own thread. In the process case, calls to the component and events from it must be marshalled in some way across the process boundaries. Pretty much like RPC but locally (on Windows it's called LPC - Local Procedure Calls, on Solaris it's called doors). This is CPU intensive. Sharing data between components will also be very time/CPU consuming since data must be marshalled back and forth. And how can you share data between processes where all changes are visible in all processes without a very high overhead? In the thread case, calls to the component and events from it must be synchronized in some way. An event for instance cannot be delivered until the receiver is ready. Of course you could use event queues, but you'd have to protect them with mutexes. With a lot of components, there will be a lot of lock/unlock scenarios and it will slow things down. And the worst case scenario is when one component crashes during a lock.. Who's gonna unlock it? Designing a threaded architecture requires a lot of thought and skill. I'd say threading and multiprocessing should only be used when absolutely necessary. Bad use of both technologies will punish you later...
First one should observe the difference between visual and non-visual components. Non visual components aren't really relavant to this. They are invisible so they don't get drawn to screen. Visual Components on the other hand are drawn to the display and have their own ways of getting there. Visual CLX components are really just QT with some code added to make them easy to use from Object Pascal.
This is why KDE is listed as a requirement for Kylix because if they have KDE then they have QT. Also if you compile a CLX app in Delphi, then your windows EXE will require a QT DLL (I forget which one.)
Anyway the point here is that CLX doesn't really belong in this discussion.
Slashdot is an anagram for Has Dolts, and I am Dolt number 468543
The goal of KParts is certainly not to dominate, but to do the job well in KDE. Without KParts there would be no embedding in Konqueror nor KOffice (etc.), no GUI merging etc.
;)
There's nothing in KParts that attempts to dominate the world - nor even other component models. Why would there be ?
KParts itself won't dominate. However, if KDE ever dominates, then KParts will by association dominate too
David (co-designer of KParts).
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