Slashdot Mirror

← Back to Stories (view on slashdot.org)

Coding with KParts

Posted by Hemos on from the how-to-make-better-programs dept.

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..."

8 of 119 comments (clear)

  1. Re:kde the beast... by EricKrout.com · · Score: 4, Informative

    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

  2. disadvantages by theCURE · · Score: 3, Informative

    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"
  3. Re:kde the beast... by __past__ · · Score: 3, Informative

    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.
  4. Re:Except by austad · · Score: 5, Informative

    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
  5. Re:kparts is very cool by throx · · Score: 3, Informative

    I can say that they [ActiveX Components] simply don't seem to get used enough in the Windows world

    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?

    --

    Fear: When you see B8 00 4C CD 21 and know what it means

  6. Re:KParts won't dominate by stilborne · · Score: 3, Informative

    kparts is licensed under the LGPL. you can link to it even from commercial applications, just like the rest of the kde libraries.

  7. COM, not ActiveX by fm6 · · Score: 3, Informative
    I think you're confusing ActiveX with COM. COM is the basic encapsulation API with a client-server model. ActiveX is a component model based on a specific kind of in-process COM server. It's true that VB components are simply ActiveX objects. (Even some basic commands that were once built into the compiler are now methods for ActiveX objects. This is hidden by making the object references a default.) And it's also true that COM is pretty pervasive in Windows apps and Windows itself. But its mostly other forms of COM. Office, for example, relies heavily on COM Automation to support the VBA scripting engine. You can also script Office apps from other languages that support COM.

    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.

  8. Incorrect! by fm6 · · Score: 3, Informative
    This is why KDE is listed as a requirement for Kylix because if they have KDE then they have QT.
    I'm pretty sure there's no such requirement listed. Actually, I'm quite sure -- I wrote the release notes for Kylix 1. You need Qt to run CLX GUI applications. You need recent versions of standard Linux libraries to run all other CLX applications. That's it.

    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.