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..."
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.
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"
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.)
Gnome's gnotices also has an article about designing and debugging corba application, using the great application ethereal as an example.
http://www.talknerdy.org
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
Also give the betas of KDE3 a shot. They are a LOT snappier on my PIII-500/256RAM box. A lot of work has gone into speeding up KDE, and I believe there's more coming.
The CLX component framework, architecture, and library is modeled after VCL, which sits above the OS APIs and GUI APIs. VCL was originated in Delphi in 1995 and was the basis for the JavaBeans component spec (called Baja I think) back in 1996. Java didn't have a component spec, and Borland was making one modeled after VCL, so the Baja ideas were "donated" to Java. CLX is most definitely relavent to this converstaion and it's ideas and origins are actually the model for the even .Net component framework. Take a look at the .Net component framework and it will look suspiciously like CLX. Almost even spooky. Why? Not too strange when you consider that the designer and architect for .Net was one of the Borland architects of the original Delphi VCL which CLX is based on.
.Net uses Winforms (which uses Win32) to render GUIs.... and CLX uses Qt to draw GUIs.... 90% of CLX classes (everything non-GUI) don't even link with or call Qt in anyway. The CLX is Qt idea is old outdated and not accurate.
By the way, despite what someone said earlier, the CLX framework itself is completely independent of Qt. The Visual CLX components use the Qt runtime to render GUI components, so yes a CLX TButton ends up calling a Qt Button, but it's definitely not Qt or even a Qt wrapper. VCL uses Windows GDI and Win32 API to render GUIs, JavaBeans use AWT or Swing to render GUIs,
Don't you mean Koding with Kparts?
;).
Maybe not
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.
You may also be interested in knowing that now in KDE CVS there is an experimental simplified malloc implementation which supposedly can give a perfomance improvement of upto 30%!!
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.
emacs, dammit :)
:-D
emacs doesn't lend itself to integration into GUI apps very well; it eats too many keys. So i guess I'll have to just use emacs alone
My other car is first.
Oh god, not again...
Way back when I developed ActiveX's the requirement to be able to call them out of process was, basically, the root of all evil. In order to be able to call something out of process it is necessary to state which parameters are going [in] and [out], and marshalling code needed to be written to be able to pass pointed to structures over the process boundary. Needless to say it was a bit of a shitfight. To hear KParts is going this way is *not* music to my ears.
Solution? Don't allow people to pass pointers over process boundaries. Use something light and yummy for the inter process stuff and something designed for the job (corba) out of process.
Dave
I write a blog now, you should be afraid.
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
No way ! I wrote my own widget set on Xlib back in 1996. Real men don't need bloat like Xt ;)
:)
Actually I did. Didn't use anything but Xlib. But it's gone now - you really need a capable and *standard* widget set (eventually comprising dialogs like "file open" etc.) to make apps that are nice (not use usable).
Today I use Gtk--, which I find is a really neat wrapper around Gtk+ (let's me use widgets using a decent language).
I suppose someone ought to go thru the code in the used libraries today, rip things out, and make them run efficiently on the sparc20 which will be the only system they would be allowed to use for the task. For some reason, it seems it's a lot more fun to add new features, than to spend a year wading thru piles of rotten code... Wonder why
I did specify the system32 directory, did I not? That's where the third-party libraries go. Also try sorting files by mod time so you can discover DLLs added by non-Delphi/BCB apps.
Read this.
Mmm. Great point. So maybe someone should write an emacs KPart.
My other car is first.