Coding with KParts 119
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..."
Re:Managers? (Score:1)
Actually, the original post here [slashdot.org] was kind of funny, and deserves better than the -1 (with editorial moderation written all over it) that it got.
Guys stop bashing Miguel for going with .NET (Score:2, Insightful)
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.
Re:Guys stop bashing Miguel for going with .NET (Score:3, Interesting)
Re:Guys stop bashing Miguel for going with .NET (Score:2, Insightful)
Re:Guys stop bashing Miguel for going with .NET (Score:2)
I liked the ones with the dining bill that showed how much they overcharge you for licensing... although I think their intent was more along their antipiracy campaign.
--
Evan
Re:Guys stop bashing Miguel for going with .NET (Score:2)
As well, nobody is bashing Linus for implementing an operating system, although Microsoft implemented one before.
There is a slight difference between creating something with a similar scope, and a 1-to-1 clone. If you don't get it yet, don't worry - in a few months/ years, Microsoft will explain...
Re:Guys stop bashing Miguel for going with .NET (Score:1)
I think that if Microsoft plays fair,
Miguel is whole-heartedly supporting a technology that is controlled by a company that is, at best, untrustworthy. Before going too far down that thorny path, I would like to see realistic risk assessment done.
Re:Guys stop bashing Miguel for going with .NET (Score:2)
I believe the port of MS Office to the mac was the only thing microsoft has ever done that wasn't officially intended to destroy a competitor. They release to either destroy or make money. DirectX is an example of a free sdk whose sole purpose was to knock apple out of the multimedia market. THis is why Ms does not like OpenGL and would like to replace it totally with directX when it matures enough for cad users to depend on it. Why? To make it difficult to port cad apps and games to other os's.
I speak not as someone who is paranoid but someone who judges with a grain of salt. Every, and I mean every bussiness that has ever done any dealings with Microsoft has always been burned. I bet ms is working with Mono now only to knock linux out of the desktop market by patening
kparts is very cool (Score:5, Interesting)
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
Comment removed (Score:5, Informative)
Vi XPart?! (Score:1)
Re:Vi XPart?! (Score:2)
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
Re:Vi XPart?! (Score:1)
Re:Vi XPart?! (Score:1)
Re:Vi XPart?! (Score:2)
Re:Vi XPart?! (Score:1)
Bonobo and vim (Score:1)
Xparts (Score:2)
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
Re:kparts is very cool (Score:3, Informative)
Umm... ActiveX components are impossible to escape in the Windows world. Almost everything you use is an ActiveX component. VB programs are made exclusively of ActiveX components. Windows itself is a massive library of ActiveX components. IE is just a collection of ActiveX components. Office is a collection of ActiveX components.
Are you sure of what you are saying here?
COM, not ActiveX (Score:3, Informative)
ActiveX does enter the picture, though, because its pretty simple to write ActiveX components that handle a lot of the COM busywork. Delphi [borland.com] and C++ Builder [borland.com] ship with utilities that help generate such components.
Re:COM, not ActiveX (Score:2)
COM Automation (usually called OLE Automation) is based on ActiveX objects which implement specific interfaces. In other words, I do not have ActiveX confused with COM. It seems you do.
Re:COM, not ActiveX (Score:2)
This page [microsoft.com] has the only online copy I could find of the chart that describes the basic parts of COM technology and how they relate. The terms are out of date (ActiveX is still referred to as "OLE Controls") but the basic relationships haven't changed.
I think there's a certain confusion because MS loves to tweak its terminology (just like they love to tweak everything else). And the market wonks don't help by taking every new technical term and finding every use -- and abuse -- possible as a brand. (No .NET peanut butter yet, but it wouldn't suprise me.)
Re:COM, not ActiveX (Score:2)
An ActiveX control is essentially a simple OLE object that supports the IUnknown interface. It usually supports many more interfaces in order to offer functionality, but all additional interfaces can be viewed as optional and, as such, a container should not rely on any additional interfaces being supported.
OLE Controls are not the same thing as ActiveX controls. Fundamentally ActiveX is a simplification of the original OLE to the essential IUnknown interface with everything else optional.
I am indeed saying that all COM objects are ActiveX objects. That is the fundamental point of my argument. In fact I screwed up in what I wrote. That proper subset thing was the wrong way around. Teach me for being Erudite...
Re:COM, not ActiveX (Score:2)
Read that page again very carefully. It describes IUnknown as a defining characteristic of ActiveX controls -- then adds the fact that all other COM objects implement them too!
Re:COM, not ActiveX (Score:2)
Actually, it doesn't say that at all. There is no place on the page (or any other page that I've found) that suggests that there is any type of COM object that is not an ActiveX control. There is no such thing as "all other COM objects" because there are no "other" COM objects.
What it does say frequently is that all COM objects are ActiveX controls because they implement IUnknown. There is no confusing of the issue because it's very simple - if a piece of code supports IUnknown then it is an ActiveX control.
I believe you are confusing yourself by thinking that "OLE Control" and "ActiveX Control" are the same thing. They aren't. An OLE Control is an ActiveX Control (because it supports IUnknown), but an ActiveX Control isn't necessarily an OLE Control because there is no requirement for an ActiveX Control to support the dozen or so interfaces required to be an OLE Control.
Sigh. (Score:2)
Re:Sigh. (Score:2)
Nothing on that page suggests anything different to what I've been saying. Perhaps you can help out my obviously limited comprehension skills by pointing out exactly what I'm supposed to be looking at that proves something other than an ActiveX control being anything that implements the IUnknown interface?
If you go back to the definition of an ActiveX control from the MSDN library [microsoft.com] rather than trying to find gems among the marketing slides on Microsoft's site you always come back to the core definition:
"An ActiveX control is essentially a simple OLE object that supports the IUnknown interface."
If you could point me to some site that says there are any more requirements that the implementation if IUnknown and the ability to self-register then perhaps you may have a case.
Re:Sigh. (Score:2)
This was such a bad piece of writing, I don't go past the first few paragraphs until you trotted it out for the third time. Apparently you didn't either, or you would have found "an ActiveX control--or COM Object for that matter" and "An ActiveX control, by virtue of being a COM object".
Also, this web page is just a tutorial. The COM programmer's guide is here [microsoft.com]. It's also pretty sloppy, but it does do a better job of describing the relationship between COM and ActiveX.
Re:Sigh. (Score:2)
You would also do well to actually read what I am saying because I think you are missing the point. Nowhere have I said that only ActiveX uses IUnknown. All I am saying is that if a piece of code supports IUnknown then it is an ActiveX object (possibly among other things). None of the pages you have linked to have disputed that definition. Just because something is technically an "ActiveX Control" doesn't mean it isn't an OLE Control, a MTS component or anything else.
I read the entire page several times. I've also read dozens of books on the subject which concur with the statements on that page. Apparently you simply aren't understanding what I'm saying, or are just trolling because I am in complete agreement that an "ActiveX Control" is a COM Object (it's virtually synonymous). In fact, here's some quotes for you:
"It just barely passes as an ActiveX Control because it implements the IUnknown interface" Professional VC++5 ActiveX/COM Control Programming, p73
"...an ActiveX Control is any specialized COM object that supports the IUnknown interface and self-registration." The Active Template Library: A Developer's Guide, p291
"OC96 changed the definition of a COM-based control from one of those gargantuan COM classes implementing a ton of interfaces to a COM class implementing only IUnknown." MSJ, The Visual Programmer, April 1999
(there's plenty more - that's just what I found on my desk at the moment)
The link you posted does not address "ActiveX" at all - it was written before the time that Microsoft renamed COM objects to be ActiveX controls in a fit of marketing hysteria. The only place ActiveX is mentioned inside that topic is to link back to the page which we were originally discussing.
If you are so adamant that I am mistaken, please educate me and let me know what more an object needs to be an "ActiveX Control" besides IUnknown and the ability to self-register? Please provide a link and a quote from the page that you got the definition from.
In the end, I think you'll find I'm correct in that any object that supports IUnknown and is self registering is an "ActiveX Control".
... and TINO (Score:1, Informative)
Yet another Linux component thingie (YALCT)
No kidding - see this article [yahoo.com]
kde the beast... (Score:1, Offtopic)
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...
Re:kde the beast... (Score:4, Informative)
There was a survey at dot.kde.org [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 [www.suse.de] about C++ applications on the desktop.
Eric Krout
Re:kde the beast... (Score:3, Informative)
Re:kde the beast... (Score:1)
neither prelink nor objprelink seems to be installed or available as packages. very strange because the guy making prelink is from redhat.
even more strange, here is a trace of exec:
$ LD_DEBUG=statistics konqueror
02593:
02593: runtime linker statistics:
02593: total startup time in dynamic loader: 197802673 clock cycles
02593: time needed for relocation: 191792475 clock cycles (96.9%)
02593: number of relocations: 20241
02593: number of relocations from cache: 33562
02593: time needed to load objects: 5807702 clock cycles (2.9%)
considering the low level of relocations, i assume there is some (obj)prelink done somewhere. from what i discussed once with bero, i think it's fully prelinked. but, there are no
moreover, where to find a true website about prelink, FAQ, HOWTO and stuff ? all i can get is mail archive, which is completely clueless.
to add to my confusion, i found that [freelists.org].
well, as u've understood, i'm lost, and i can't even access to people.redhat.com to download the damn thing, i don't know why, but connection's refused. clues anyone ?
and, finally, did someone try to compare prelink and objprelink, or the combination of the two, to see which method is the fastest/more efficient ?
Re:kde the beast... (Score:2, Informative)
Re:kde the beast... (Score:1)
David
Re:kde the beast... (Score:1)
But you are always free to get the sources and compile it yourself with the experimental malloc enabled.
Re:kde the beast... (Score:1, Informative)
kde 2.x on p-100 (Score:1)
Re:kde the beast... (Score:2, Informative)
disadvantages (Score:3, Informative)
Re:disadvantages (Score:2, Interesting)
Re:disadvantages (Score:2)
So I don't think it's a big deal if the component takes down the entire application, as opposed to having the component just leave the application in a semi-usable state (or place undue burden on the main application developer to consider all failure conditions and create recovery procedures for each one).
Re:disadvantages (Score:1)
Just C++, that is main disadvantage for me.
Nearly everything can interface to C, nearly anything
can interface to C++
Refreshing Attitude (Score:5, Insightful)
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.
Also, see... (Score:2, Informative)
Xt (Score:1)
Re:Xt (Score:1)
Re:Xt (Score:2)
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
KParts won't dominate (Score:3, Insightful)
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.
Re:KParts won't dominate (Score:3, Informative)
Re:KParts won't dominate (Score:2)
Re:KParts won't dominate (Score:2)
I don't see how having to pay for a qt license amounts to nickel and diming....
Re:KParts won't dominate (Score:1)
Re:KParts won't dominate (Score:2)
So lemme get this straight: You want them to give their stuff to you so you can earn money off it? Nice business plan I guess, but if you think about it for a while I'm sure you'll see why it doesn't quite work the way you'd like it to.
Re:KParts won't dominate (Score:2)
Umm, Microsoft gives away it's SDK and compilers and provides the developer libs as a free download. You don't need to pay MS a thin dime to develop on Windows (except for the base OS, but if you are tricky you could compile for Windows on Linux or BSD).
Microsoft has a free compiler for Windows now? I guess I got duped into buying VC++ then. And how am I supposed to test my apps on Windows if I don't have it?Re:KParts won't dominate (Score:3, Interesting)
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).
Kylix CLX is QT (Score:1, Interesting)
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.
Re: WRONG: Kylix CLX is *NOT* Qt (Score:1)
Incorrect! (Score:3, Informative)
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.
Look again (Score:2)
Re:a CVS viewer?? (Score:1)
CLX model is basis for .Net and JavaBeans (Score:2, Informative)
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,
God Hemos, your spekking is shocking (Score:2)
Maybe not
IBM and Linux (Score:1)
they sure are investing a lot of time..
What's wrong with the software industry??? (Score:3, Interesting)
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?
Re:What's wrong with the software industry??? (Score:2, Insightful)
Re:What's wrong with the software industry??? (Score:2)
For some reason many people actually believe this. The fact of the matter is that it's just not true. First off, the salary of the programmer is distributed over several coppies of the program. Secondly, your product would be worth far more (people would pay more) if your product worked 10x faster than a competing product. The problem with free software is just as you've said: you've got no incentive to improve the program, it's just not fun is it?
Re:What's wrong with the software industry??? (Score:2)
XFce is smaller and faster than CDE while having neatly all the features, and many of it's own features CDE doesn't have.
Good programs are just good programs.
Re:What's wrong with the software industry??? (Score:1, Interesting)
You try to sound like you know what software engineering is, but if you think you can utterly disregard things like reusability, ease (speed) of implementation, and non-techie friendly interface design (all of which come at a cost to efficiency), you have a lot of learning to do. Engineering is about making trade-offs between a lot of conflicting ideals, not just the two or three you happen to decide are most important.
Speaking in non-programming terms, I'm sure the auto companies can design cars with >60 mpg fuel efficiency, if that were the only criterion they used. Of course, they might not have the pickup that paying customers want; they might be so light they don't meet federal crash safety regulations; maybe they pollute the air worse than current engines do. And maybe they'd be so noisy and inconvenient that people won't buy them. When you factor in real-world (e.g., market) considerations, there's a reason why people don't solely optimize for the one value you think supercedes all others.
Oh, and one more thing...it's perfectly possible to write highly efficient c++ code if you have to; all the low-level c operators are there, and if you keep a tight rein on the number of virtual functions you call, you can keep processor overhead under control. But that (like a lot of your post) is neither here nor there.
Thoughts on Borland's CLX (Score:1)
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
Whoops forgot #4 (Score:1)
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.