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"
Yet another Linux component thingie (YALCT)
No kidding - see this article
The problem with all of this is how heavy it is to run a kde program. I am a fan of the fast lightweight programs even if I do have a decent computer. I prefer blackbox, rxvt and so on. While I appreciate the "beauty" of kde and the work the project does for attracting users to linux for desktops, I hate how long it takes to load up and then don't even think about using an app without using the whole kde environment.
My only problem with it is how slow it is, but I guess that's a little unfair for the features that it comes with...
--------------------------------- Born Again Bourne Again Believer: New Life, GNU/Linux Be Free!
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
long live kde you guys seriously did a great job. thank you.
We have another good component architecture - Xt. It's just a shame a lot of young whippersnapper open source developers these days don't take the time to understand the X window system before plunging into wheel-reinvention, then complain how "X is slow", when they've just gone and effectively "misprogrammed" it, treating it like the dumb framebuffer that it isn't.
Choice of masters is not freedom.
Just a few months ago I had decided that I wanted to use a few components in a kylix application that I was writing. I immediately looked at how to integrate kparts into my application. Much to my horror the architecture is hands down C++ only. That is not, I repeat not a component architecture. They do mention xparts on the site but fail to mention that it is a very beta piece of code, I even have doubts that xparts is being maintained. So is CORBA the solution? Well no CORBA is slow as dirt, but components need to export language neutral interfaces. I do not like the company pushing the term .Net but I do however like the concept.
Kparts is a component model for C++ only. This makes it a wannabe component model. Corba is not the answer either since a orb imparts to much overhead. The idea behind Kparts was pretty good but they left out the single most important part, language neutral.
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.
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
It works fine on that the computer I believe has 64mb of ram (I don't recall at this moment though). Running redhat 7.1, works very well as a backup X computer.
Man would I love that, but I can't find it. Has anybody here tried it? Is it basically Cervisia plugged into Konqueror?
Here's an idea for all of you who were complaning of lack of work : http://www.sendthisnow.com/html/code4food.html
Either you're not trying, you're fucking stupid, or you're 12.
Actually, the original post here was kind of funny, and deserves better than the -1 (with editorial moderation written all over it) that it got.
What I'm listening to now on Pandora...
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. 90% of CLX classes (everything non-GUI) don't even link with or call Qt in anyway. 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.
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,
Wow! What about Vi plugged into KDevelop?! The best of both worlds! (And a dream come true for me ;)
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.
It seems like IBM is making a real effort to be involved in the development of Linux
they sure are investing a lot of time..
Try a bigger monitor, or a smaller head!
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.
Another thing about slapdown actually asking those of us who are actually consistently moderated down to pay $5 (to have this de-moderation happen):
Have you visited : http://www.TheGloriousMeept.com ?
And before you moderate me down.. I am a meept missionary. plain and simple. The meept's article refers to the demise of VA Linux about a year ago. As most of you in this thread are FROM VA linux. I suggest you wake up.
The MEEPT is all that holds free open source together (*if* you can get into the club).
I'm ashamed to say I'm contributing to this thread running to more than 100 comments. 100 was common when the MEEPT was here, along with the spirit of open source.
Moderate me down and pay the price.
MEEPT!!
This is already possible with Bonobo and GNOME. Not to knock KDE. I just wanted to drag my prefered desktop in too :)
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
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.
Sorry, I just did a search for *.BPL in my C:\WINNT40 directory and found nothing. Been running NT4 for years now (and given ms's current practices, probably for years to come). I've got lots of non-trivial Windows apps as well.
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.
I've worked extensively with Borland's CLX. Delphi 6 (Windows) and Kylix 2 (Linux) support this cross-platform language. Supposedly you are supposed to have a single source code base that is cross platform. There are a few major problems with this: .SO. This file is several megs compressed. So if your app was previously 500k its now 3.5 megs and this can be a tremendous strain on your web server and bandwith usage.
1. CLX itself and its structure has MANY bugs and memory leaks. In all fairness CLX is a first generation language but it is equivalent to an alpha test edition. I recall reading a post in borland.public.delphi.clx.using where someone had open and closed a blank form about 100 times and generated a 6 megabyte memory hole.
2. CLX isn't well supported by Borland. I wonder if they are planning to drop support for CLX altogether. Kylix 2 came out well less than a year than Kylix 1 and included some fixes for CLX. Users were pretty steamed because Borland never released CLX fixes for Kylix 1. K2 was really a bug fix release of K1 and Borland wanted people to pay for the updates. Borland recently released service pack #2 for Delphi 6 but still there are no CLX fixes. Borland also maintains freeclx.sourceforge.net which is supposed to be a community effort to improve CLX. That site is basically dead despite the fact people actually submitted bug reports at one time.
3. Applications written with CLX require a very large dynamic runtime library QTINTF.DLL or
Almost forgot one of the most important points...
4. Forms written in the Linux flavor of CLX and the Windows flavor of CLX appear differently at runtime. This defeats the whole purpose of having a single cross-platform code base. The optimal solution is to have separate forms for each OS.
Read this.