faq
flatforty
contribute
subscribe
configure
search
rdf
main
|
| Matthias Ettrich On Universal Components |
Posted by Navindra Umanee on Monday 06/Aug/2001, @00:27
from the what-about-dot-net dept.
Matthias Ettrich's talk on Universal Components at LinuxForum (also given at LinuxTag) is finally now online. You can view the slides
as you watch in Real Video format (part
1, part
2) or listen in ogg
format. Matthias covers everything from basic concepts of
components to CORBA, COM, Universal Objects, and UCOM
in Qt3.
Particularly notable is the coverage of Universal
Objects, which is apparently a concept that originated from a Borland/Kylix developer, and
the
promise of future component interoperability between the likes of
Qt, KDE, Kylix, Phoenix Basic, Python, GTK+ and what not.
Intrigued, I thought I'd take a closer look at QCom. Unfortunately, qcom.h
itself seems pretty evil (it may help if you come from COM-land), so
it is advisable to also consult the write-up which is fairly nice and concise. Personally, I find it somewhat surprising that one would have to deal with seemingly low-level details such as UUIDs and the such; one wonders what other options are available.
Finally, another useful thing you may learn from this presentation
is whether and when to pronounce Qt as "queue-tea" or "cute". (Hint: it depends on random intricate QuanTum fluctuations in ice
cubes.)
<
|
>
|
|
The Fine Print: The following comments
are owned by whomever posted them.
( Reply )
|
|
Over 40 comments listed.
Printing out index only. |
How will this effect KParts in KDE 3 ?
by Ariya Hidayat on Monday 06/Aug/2001, @02:08
|
Since IIRC KDE 3 will be based on Qt 3 and if this UCOM will be part of KDE 3, what can we expect from KParts ? Will it be converted to use UCOM or just as it is ?
|
[
Reply To This | View ]
|
depressing
by Mike on Monday 06/Aug/2001, @02:13
|
People are re-inventing 20 year old technology, badly.
|
[
Reply To This | View ]
|
|
|
Give the .kpr files
by Thomas on Monday 06/Aug/2001, @03:37
|
As very often in the kde world, you give a link to the html pages generated by kpresenter, but not the .kpr file itself.
Sure, the .html version is what most people will read, but I, for one, always like to get this presentation on the original form to be able to read it with a more user friendly interface and fullscreen. Usually I can get the .kpr by asking the author.
Is Matthias' presentation available somewhere ? and if not, could you put it ? thanx !
|
[
Reply To This | View ]
|
|
|
Alternatives
by Catalin Climov on Monday 06/Aug/2001, @05:14
|
One may want to check out Korelib, for a lightweight QCom "alternative":
http://www.thekompany.com/projects/korelib/
|
[
Reply To This | View ]
|
COM sucks
by Androgynous Howard on Monday 06/Aug/2001, @09:13
|
I really do not know whats the deal with QCom. COM sucks. Even microsoft has found that out by now. COM will not be used by .NET. It is a legacy technology that they will get rid of as fast as possible.
Linux will never win the desktop when they keep imitating ten year old microsoft technology. At least they should imitate *current* microsoft technology. I think a platform independent binary format similar to java or .NET is the way to go.
|
[
Reply To This | View ]
|
|
|
COM inherently flawed??
by Bud Millwood on Tuesday 07/Aug/2001, @09:53
|
Microsoft tried to use COM to build an "extensible" OS. Linux is an extensible OS without COM. Why? Because COM uses a binary format and an OO paradigm. It depends *way* too much on close coupling. Orthogonality requires loose coupling, something Unix in general has always had. That's why Unix is so much more extensible than Windows - it's an orthogonal OS.
I'd hate to see KDE/QT fall into this trap of coupling things too tightly. One of the first lines of the UCOM docs says "you can never delete an interface". Want to know why? Because it's *too* tightly coupled to everything else. Ever wonder why grep is so damn handy? Because it has a data driven design: single input, single output, universal data representation. No knowledge of "controls" on a component. It can be extended to work in ways its designers never dreamed. Tightly coupled components simply cannot.
I do not believe that a data-driven design is the best way to build an extensible UI, but I certainly believe that COM, UCOM and other close coupling technologies severely limit extensibility. (Interesting because that's what they claim to be good for). The only gain is for the short-term, where apps seem to know all kinds of things about each other. They *do*, and that's the problem.
- When you only have a hammer, everything looks like a nail.
|
[
Reply To This | View ]
|
|
|
Missing point?
by Outsider on Thursday 09/Aug/2001, @11:58
|
I'm not a KDE developer, but I am planning a QT app, because it's nice to program and I want it cross-platform. Some of you people are missing the point when you say "why should QT do this when KDE already does?" Maybe KDE does but that doesn't help me a whole lot.
Wouldn't it be nice if a lot of Windows developers started doing QT? Then when people compare OS's, they can discover that outside of Microsoft apps, they can run the same software on whatever platform they choose. Don't you think that would help break Microsoft's monopoly on the desktop?
(Incidentally, I'm planning to GPL on the Linux version, and on other platforms work out the closest thing to GPL that I can.)
|
[
Reply To This | View ]
|
|
|
COM, VB and ease of coding
by Ignorant non-contributor on Friday 17/Aug/2001, @09:09
|
I haven't used COM myself, only talked at length with someone who has, but...
I have the impression that a COM component on Windows isn't easy to code in C++. However, its saving grace is that a COM component is easy to use from VB. Thus, the hard work of a C++ coder makes life easy for VB coders thus encouraging code reuse. Can anybody confirm this?
If so, doesn't this mean QCOM is not right for KDE ON ITS OWN? ie there needs to be something in the role of VB (python? kscript?) which takes advantage of the QCOM components and is easy to use.
|
[
Reply To This | View ]
|
|
The Fine Print: The previous
comments are owned by whomever posted them.
( Reply )
|
|