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..."
Yet another Linux component thingie (YALCT)
No kidding - see this article
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"
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.
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
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
kparts is licensed under the LGPL. you can link to it even from commercial applications, just like the rest of the kde libraries.
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,
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.
You should also have a look at current KDE3 CVS -- there is a configure switch --enable-fast-malloc=full, which makes applications quite a bit faster!