Slashdot Mirror

← Back to Stories (view on slashdot.org)

KDE 2.0 Technology Overview

Posted by HeUnique on from the read-before-you-complain dept.

Recently, there was an article about a KDE 2.0 Technology overview here on Slashdot. Unfortunately, the article it linked to was missing some details and didn't give some necessary information, which caused a huge number of complaints and misunderstanding in issues like CORBA, DCOP etc. Now mofset has posted an updated Technology Overview with all the explanations about what's going on with KDE 2.0, CORBA, DCOM, KSycoca and other terms. What do you think?

43 of 167 comments (clear)

  1. KDE 2 = Nice, but how bad will RedHat f' it up? by notbob · · Score: 2

    Are they going to do another brilliant move and move the files out of /opt/kde again?
    It's the most annoying thing in the world to get redhat rpm's and watch them put it in a f'd up location, true switchdesk is nice and all but leave it where it was intended by the programmers!

    I know RedHat likes to make everything customized, but jesus leave it alone. I like RedHat overall and their new installer is damned nice (esp. compared to the old 4.2 which is so archaic it's almost funny), but the damn thing formats / without asking unless you select custom install. Thats crazy, and annoying as hell, done that twice to me, oh well thank god for 4 harddrives.

  2. Re:Who wants your shitty little 10 dollar app? by Arandir · · Score: 2

    $1000 is not that much, even for the small developer. If you plan to sell a shareware app for 10$ a pop, and expect to sell 1000 copies, then you've just grossed $9000! If you don't plan to sell that many copies, perhaps it's time you rethought your whole vocation.

    Head on down to your local Mom-And-Pop store on the corner. It doesn't matter what they're retailing. Now take a look at their fixtures. How much to you think it cost them? Real life example: Mom-And-Pop carpet store down the street: Armstrong Vinyl rack = $1000~; each individual carpet waterfall = $50-75$ and there are 25 of them, and this isn't covering the samples; specialized accounting software = $1500 per cpu; carpet roller in the back = $5000; etc., etc., etc. And these are the small guys!!!

    $1000 is peanuts for a quality tool like Qt, and it even comes with support and updates. It's nothing compared to what you'll have to spend on quality marketing.

    --
    A Government Is a Body of People, Usually Notably Ungoverned
  3. Re:KDE == Good by Guy+Harris · · Score: 2
    Fortunately for the world, I never did get that far

    Damn. Any interest in trying again, this time with a Qt 2.0 or GTK+ 1.2 theme?

    that's only a short step from talking paperclips...

    Anybody know if Microsoft has an SDK for the Office "Assistants"? Having Tux or Beastie suggest you use StarOffice or KOffice or... instead, or having Mr. Hanky the Christmas Poo or Bart Simpson or some other alternative, could be amusing....

  4. Re:XML by Rozzin · · Score: 2

    Yes, XML is a language.
    XML is a subset of SGML.
    XML is a metalanguage.
    XML is for doing markup.
    XML is not a programming language.

    --
    -rozzin.
  5. Re:I'm still nervous. by evilpenguin · · Score: 5

    DDE doesn't do applications embedding. That's OLE. DDE is a horse-dung IPC mechanism that sends messages in the message queue to EVERY RUNNING APPLICATION on a Windows boxen.

    The expense of ORB calls can be very similar to the cost of initially calling a shared lib, but from then on shared library calls will tend to be much faster than ORB calls. This difference gets exaggerated when a lot of data is passed in the call and/or in the result, because all of it has to go through the transport representation conversion and data transmission.

    Now, while I've done a fair amount of IDL/ORB/IIOP stuff in my time, I haven't looked into the KDE code at all. If they did it right, they should have a lightweight IPC API that can use a variety of transports and that will autmatically use the much faster local *nix capabilities on the local machine, and the moderately slower Xlib capabilties between X-displays, and use CORBA for anything more divergent. Point being the app writer should not have to particularly know or care.

    CORBA is VERY time expensive, esp. when you're talking about things that have a dramatic influence on the perception of speed, like redrawing windows.

    Often the user's feeling of performance is based more on finding the right place to stick the delay than in having the fastest end-to-end time for a process.

    Case in point: I once eliminated hundreds of user's complaints about a slow system by slowing it down about 40%. We had a PowerBuilder (ugh!) front end to a client-server application. One of the forms had a pick list that was HUGE, populated by a stored procedure call. That call would often take 3-4 minutes to complete. Users went bananas because they got the good olde Win 3.1 hourglass while the pick list was populated.

    I changed the code to pick up one record at a time from the result set and insert it in the pick list rather than make the single "all at once" call. It actually took 2-3 minutes longer to fully populate the pick list, but the users never got the hourglass and could start working the form right away. Zero complaints.

    I guess what I'm saying is, KDE is a UI. As such, it has to focus on user issues, not technological issues. I am 100% a technology guy. I'd rather satisfy myself that things are done right than satisfy users. Even so, the KDE folks want people to use their software. That means they have to address user issues first and put architecture second. It seems to me they are doing a danged fine job of balancing these concerns.

  6. Re:This looks seriously neat! by Hard_Code · · Score: 2

    Well there are ways to trim down CORBA alot to bypass network requirements, etc...but yes, even the trimmest CORBA orb will have some additional overhead over straight calls...it just needs to be used when appropriate.

    --

    It's 10 PM. Do you know if you're un-American?
  7. This looks seriously neat! by jd · · Score: 3
    KDE 2.0 looks very nice, and I'm glad the developers are using technologies which are practical, rather than using just the "glamour" stuff. (eg: Using CORBA =when appropriate=, rather than for everything under and over the sun.)

    I've tended to shy away from KDE, after KDE 1.x proved very slow on my box. However, I'm definitely going to give this a try, and see how it performs now.

    --
    It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
    1. Re:This looks seriously neat! by itp · · Score: 2

      KDE 2.0 looks very nice, and I'm glad the developers are using technologies which are practical, rather than using just the "glamour" stuff. (eg: Using CORBA =when appropriate=, rather than for everything under and over the sun.)

      I'm not sure what you're trying to say here. On a modern UNIX, you've already payed the price by using it once. If it's going to be in memory as a shared library (and ORB), why not use it multiple times?

      --
      Ian Peters

    2. Re:This looks seriously neat! by jd · · Score: 2

      In memory, yes, but the ORB'll be shunted out into swap if it's left sleeping, which frees up some RAM. The biggest factor, though, is network times. CORBA requires a stupendous number of network connections to do anything. (DNS lookup for name registry; ORB connection to obtain list of services; ORB connection to connect to service; 2 hops, even when using the same machine, to transmit from client to server). This is -not- efficient.

      --
      It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
  8. I'm still nervous. by Amphigory · · Score: 2
    I guess I don't get it. It seems like they are creating something similar to "DDE" in the Windows environment to support their application embedding operations.


    However, as I understand it, the overhead of a local execution in a good ORB (say ORBit or OmniORB) is equivalent to that of a shared library call. Why not use a good ORB and have the added benefit of network communications?


    Can someone who is brighter than I explain this? For the record, I actually use KDE and am not a GNOMEr in any real sense of the word.

    --
    -- Slashdot sucks.
    1. Re:I'm still nervous. by itp · · Score: 2

      However, as I understand it, the overhead of a local execution in a good ORB (say ORBit or OmniORB) is equivalent to that of a shared library call. Why not use a good ORB and have the added benefit of network communications?

      This is my understanding as well. Also, the memory usage should be quite tame, since this is a share library, not something that should bloat each app. However, I understand the KDE people have been having serious problems with binary bloat while using MICO.

      --
      Ian Peters

    2. Re:I'm still nervous. by LizardKing · · Score: 2

      As the article states, CORBA itself doesn't provide a machanism for embedding in X applications, it simple allows the process to be initiated. The actual embedding is still relies on X and KDE library calls, so CORBA was just adding complexity to this.

      As far as I understand it (and I'm an user of KDE, not one of the programmers), the new embedding technology is as simple an API as possible. Presumably a wrapper around CORBA is out of the question, because a wrapper around what is essentially a wrapper already is daft. Perhaps if the OMG's CORBA specification hadn't been designed by a band of muppets things would be different.


      Chris Wareham

  9. This looks like the way to go ... by LizardKing · · Score: 4

    Having recently compiled a snapshot of KDE 2.0, I can say with some conviction that it's a Windows killer. The usability is much better, and the optimised build much smoother. Having had to do some testing of Unix apps running under the Windows Reflections X server, I'm suprised at just how poorly NT performs when more than one application is open. (I mean Windows apps like Outlook and Explorer, not the Unix apps).

    The loss of Mico as a dependency for KDE 2.0 is also a good thing. Mico is just too large for it to form the basis of a component model, the only place it really shines is truly network transparent CORBA apps.


    Chris Wareham

  10. KDE == Good by Foogle · · Score: 2
    When KDE 2.0 comes out, we will be able to really start themeing our look and feel, something the GTK has been much better at in the past. With KDE theming, we can finally make GTK and KDE apps *look* the same, and that's pretty cool in my book. Right now, the only themes that they both can do are Motif/Notif and Win95/Redmond. That's not much to work with.

    On a related topic - would it be possible to rework the Lesstif libraries in such a way that they would support a different look and feel? That would make UI integration almost perfect (except for statically linked binaries).

    Anyway, just my US$0.02

    -----------

    "You can't shake the Devil's hand and say you're only kidding."

    1. Re:KDE == Good by Guy+Harris · · Score: 2
      I can look like a mac, beos, or whatever i want.. even changing icons, title bars, everything really.

      Everything? Including, say, scrollbars? The theming added in Qt 2.0 is the ability to make the widgets look different (beyond the Windows vs. Motif stuff Qt 1.x can do), not just the stuff drawn by programs such as the window manager or file manager.

    2. Re:KDE == Good by Guy+Harris · · Score: 2
      Yes, everything.

      My question (which was rhetorical; I already knew the answer to said question was "no") was about KDE 1.x, as I was replying to somebody who said

      been able to theme kde for quite a while now..

      ...

      under 1.0 it didn't work well, but 1.1 added a great theme manager, and 1.1.1 built apon that even more.

      so the correct answer to my question is not "yes, everything", given that, as you note

      because KDE 1.x is based on QT 1.4 it cannot change as many things

      The poster to whom I was replying was presumably replying to

      When KDE 2.0 comes out, we will be able to really start themeing our look and feel, something the GTK has been much better at in the past.

      in another post, a comment that was referring to the ability to theme widgets (as is clear from the stuff following said comment).

      The whole point of my comment was that the ability to theme the UI to that extent is new in KDE 2.0; it's not something that people have "been able to [do] for quite a while now", unless they've been running pre-release KDE 2.

    3. Re:KDE == Good by Eccles · · Score: 2

      Everything? Including, say, scrollbars?

      Once when I was going overboard in coding, back in DOS/Win3.1 days, I started writing a scrolling manager that would have allowed things like a little animated climbing monkey to serve as the scroll bar. Fortunately for the world, I never did get that far; that's only a short step from talking paperclips...

      --
      Ooh, a sarcasm detector. Oh, that's a real useful invention.
  11. Semantics of network transparancy by code4444 · · Score: 2

    I did some reading on the KDE mailing lists, and from what I gather the problem is not so much the efficiency of the calls, but their limitations.

    You can't use pointers across a network. All arguments are passed by value. That those values could be passed as fast as a shared library implementation isn't important. Sometimes you just need pointers.

    The straw that broke the camel's back for KDE seems to be the plugins for KImageShop. Those plugins would be processing bitmaps - potentially several megabytes of data. For a shared library you just pass a pointer. For something like CORBA you have to:

    a) serialize the bitmap to well defined external representation.
    b) transmit that to the plugin
    c) unserialize it to a bitmap object again.
    d) do the real processing
    e) serialize again
    d) transmit again
    f) unserialize again.

    This is silly. Nobody is going to run an image processing plugin over the network.

    CORBA has a place. When you do want to work across processors / OSes / toolkits / networks / programming languages you *have* to do these steps some way or another, and having something like CORBA is a huge improvement over the ad hoc solution du jour.

    You also have to deal with communications failures, the other end going ga ga, latency problems, bandwith problems, how do I find the other end on this big internet thingy anyway, security etc.

    If your application is distributed you inherently have these problems, and it's great to have a mechanism to help you solve them.

    If you just want a stinking plugin, it's a pain.

  12. A different take on things by itp · · Score: 4

    This article sounds a little bit like spin to me. Not trying to start a flamewar, but here we see a bit of the architectural advantage the Gnome folks have. Writing a completely new ORB (ORBit) might have been a bit 'o work, but it's paying off for the Gnome project, while KDE still struggles with MICO.

    Every application supports a basic set of IPC operations for communicating to other applications, and it is not reasonable to expect *every* application to link to any ORB.

    I'm no expert, but I'm not sure I understand this. If you're already going to have the ORB running, and you've got the libraries in memory, how much of a price do you pay having 100 applications using CORBA vs. 1 application using CORBA and 99 using some other mechanism?

    --
    Ian Peters

    1. Re:A different take on things by Arandir · · Score: 2

      I'm not trying to flame here, but what architectural advantage is there when your model won't allow a change in direction? ORB was not working out for everything KDE wanted it to do. So they did the sensible thing and came up with something else that was smaller, faster and easier to use, and kept ORB for those tasks where it was needed.

      It seems to me that ORB has become the holy grail of Gnome. A couple of weeks ago the so-called abandonment of ORB was touted by the Gnomies as *proof* of KDE's inferiority. Now that mosfet sttempts to correct a gross misunderstanding, you say it sounds like spin-control. To quote a great line from a great movie, "some men...you just can't reach." Face the fact if you can that there is room enough for two or more A+ desktops.

      --
      A Government Is a Body of People, Usually Notably Ungoverned
    2. Re:A different take on things by itp · · Score: 3

      First off,

      I'm not trying to flame here, ... "some men...you just can't reach." Face the fact if you can that there is room enough for two or more A+ desktops.

      You're doing a poor job, then. FYI, I in no way deny the existence of two very high quality desktop environments. This despite the fact that I choose, for my own reasons, to use, support, and develop for Gnome. In much the same way that I, as do many people, choose to use GNU/Linux, while acknowledging that there are many "A+" OS's out there (the *BSD's, for instance).

      Now, to the meat of your comments.

      I'm not trying to flame here, but what architectural advantage is there when your model won't allow a change in direction? ORB was not working out for everything KDE wanted it to do. So they did the sensible thing and came up with something else that was smaller, faster and easier to use, and kept ORB for those tasks where it was needed.

      I'm afraid we've miscommunicated here, and I suspect the fault was mine. What I was trying to say was the the Gnome project seems to have a lead in working out these architectural issues. While KDE turned out a highly polished set of applications, the Gnome project seemed to focus on a broader framework initially. Here it seems to pay off for them.

      It seems to me that ORB has become the holy grail of Gnome. A couple of weeks ago the so-called abandonment of ORB was touted by the Gnomies as *proof* of KDE's inferiority.

      First, a technical note: I believe you are confusing the terms ORB and CORBA. Second, I certainly hope that you didn't hear anyone from the Gnome project saying that this is proof of KDE's inferiority. Statements such as these only serve to undermine the spirit of cooperation we'd all like to see.

      Now that mosfet sttempts to correct a gross misunderstanding, you say it sounds like spin-control.

      Yes. To me, this sounds like a way to put a nice face on some technical issues they were unable to resolve. This is merely my opinion, being shared in a forum which invites people to share their opinions.

      --
      Ian Peters

  13. KDESoft! by Signal+11 · · Score: 3
    KDE is not the next Microsoft. They cannot, and will not develop "proprietary" protocols because of the way open source works. It's obvious Gnome and KDE are going two seperate paths. Rather than complaining about this, we should be commending both groups efforts in the GUI arena.

    The scenario alot of slashdotters believe (which is not addressed in the article) is that KDE is somehow going to become the de facto GUI. Well, due in part to the paranoia that alot of us have as well as the fact that the two groups have seperate goals, that isn't going to happen. One may be more popular than the other (How many people still use fvwm instead of E?), but because of open source (Yes, Richard, I know it's not free software..) it's impossible for either gnome or kde to co-op the other.

    Besides, if that happened the paranoia many of us share in this community would quickly fork the tree and continue along a "free" path, essentially killing the old version.

    So relax - there is NOTHING to worry about in this area. And while I'm up here on this soapbox - Redhat is OK too - so stop complaining about them becoming the next MS too.

    --

  14. Other KDE2 "technology" by Ledge+Kindred · · Score: 2
    I've tried a few times to get /. to post this link to a KDEForum article on "Magellan" - KDE2's new information manager system. It's EMail, News and PIM all in one, something like a Lotus Notes or Microsoft Exchange/Outlook except will be GPL'd. If the article is in any way accurate and not a hoax (it looks horribly functional and I have to take with a grain of salt that a project this massive has been kept under wraps and done up by only a few people working on it...) it will be a Big Win for KDE2 and any *NIX in general that can run it.

    Magellan Overview

    -=-=-=-=-

    --

    -=-=-=-=-
    My mom's going to kick you in the face!

  15. Re:KDE looks like Windows, therefore it sucks by Yarn · · Score: 2

    This isnt insightful, its only marginally funny. I'm looking forward to when it gets to meta-moderation.

    It only takes one or two moderators with nothing better to do to get stuff like this to the top.

    I've noticed that once something starts going up it tends to accelerate past 3 and up to five, even if its only mildly worthwhile.

    --
    -Yarn - Rio Karma: Excellent
  16. I certainly know what I'm talking about ... by LizardKing · · Score: 2

    How the heck KDE is going to affect load on X caused be other apps ?

    Other KDE apps you twit.

    And as someone who has been programming X applications since the bad old days of OpenLook and then Motif, I have a feeling I know what I'm talking about.


    Chris Wareham

  17. Link requires authorization?!? by Brian+Knotts · · Score: 2
    What's up with that?

    Even http://www.kdeforum.org/ is asking for a username/password.

    --
    Interested in XFMail? New XFMail home page

  18. People fear controversy, there4 they're humorless by maynard · · Score: 2

    Man, the author writes up front that it's a (Score:-1, Troll). He obviously intended it to be slightly offensive because that's the point of HUMOR.

    You folks are WAY OVER-REACTING!

    KDE is fine. Gnome is fine. Go on and continue your boring and bland lives where everything is politically correct.

  19. Re:People fear controversy, there4 they're humorle by Yarn · · Score: 2

    Thats fine, I personnally think it should be at about 2, funny. It was at 5, interesting when I posted. This post doesnt merit that ;)

    --
    -Yarn - Rio Karma: Excellent
  20. Re:Comments on CORBA by yorkie · · Score: 2

    I applaud KDE for this decision.

    If you want to really see bloat with Corba, look at the agent processes supplied as part of CA Unicenter.

    It varies from OS to OS, but on most systems the agents, which do no more than monitor a few OS stats and parameters (and badly chosen ones too :-) ), take up at least 32MB of RAM, and a large percentage of CPU cycles. Neither of these are acceptable for the purpose this software was designed for - systems management. The system is consequentially unusable in the environment I have been tasked to install it in.

    It is often the case that software developers adopt a new technology without realising the full consequences, and when they do, it is too late to go back. I have seen a major application become unusable due to the developers wanting to recode the next version in C++, as opposed to ironing out the bugs in the C port. This application consumed four times as much memory, was noticably slower, and was incompatable with the majority of existing installations. CORBA appears to be the new fad.

    I may even get round to trying a development release KDE 2.0. I have not been able to install KDE 1.1.2, as I can't get Qt to compile with gcc-2.95.1. Maybe 2.95.2, just released will fix this.

  21. Great News by warmi · · Score: 2

    Really, KDE has a chance to develop something truly usable and something that will last. They actually do care about the user which can hardly be said about most GPL software.
    Way to go , guys ...

  22. Uh oh... by Ledge+Kindred · · Score: 2
    KDEforum.org looks like it's broken. Sorry. Keep checking back though, Magellan looks awesome.

    -=-=-=-=-

    --

    -=-=-=-=-
    My mom's going to kick you in the face!

  23. Forgive my English ... by LizardKing · · Score: 2

    > > ...it's a Windows killer. The usability is much better, and the optimised build much smoother. > Um, exactly how often to you tend to (re)build Windows, then? Perhaps you meant "... smoother than on previous versions" on that last part, and I'm just being picky? ;^) I meant that KDE 2.0 built with optimisation is much smoother than Windows - no annoying lock ups while apps load or do something mildly heavyweight.
    Chris Wareham

  24. Re:XML by jilles · · Score: 3

    "XML is not a programming language"

    No, you are right but you could use it to model a program just like you would model other datastructure. I have often wondered why we still have to store our precious source code in flat file databases (ascii files). I don't see any apparent reason except that many people like to use text editors to work on their source code. Because of this much syntactic sugar is put into the languages at the cost of structure and readability.

    Treating a program as a DOM instead of a large set of ascii files scattered in multiple directories would allow for really cool tools. I'm thinking of code transformations, changing an identifier name and have the effect of the change spread through the whole program (no references to non existent stuff), no more syntax errors (the DTD prevents illegal edits), and a whole lot more.

    --

    Jilles
  25. Re:Get a clue! by Arandir · · Score: 2

    I do indeed wish that Qt were free on the windows side as well. I wasn't arguing against it. I'm very sure that once Troll Tech can figure out the appropriate funding mechanism, they will. After all, their clientele aren't exactly the type that would use and pay for a support-based funding model.

    What I was arguing against was the myth that the QPL'd Qt is only free for freeware and that once you charge for your application you must use the professional version.

    If you look at it a certain way, Qt is free for NT for you to compile QTSlash'em, you just have to run it under X under NT.

    --
    A Government Is a Body of People, Usually Notably Ungoverned
  26. Re:Is Gnome using Corba extensively? by itp · · Score: 2

    Bonobo is based upon CORBA as well.

    --
    Ian Peters

  27. It's a possibility by Foogle · · Score: 2
    A surge of software could help Linux to become the perfect desktop environment that we're striving for. On the other hand, it might not make a difference at all. Any existing software would need to be ported to Qt before we'd get it, though new software would do just fine. Except for one thing:

    Linux/xBSD users (and people of the open source inclination) don't tend to pay for their software. You need only look at some of the threads about Opera vs. Mozilla to know their heated opinions on the matter. Linux shareware might just be a doomed failure. Anyway, if someone really wants to develop shareware for Linux, there are certainly more toolkits than just Qt. Not KDE compatible toolkits, but good ones nonetheless.

    Moreover, I don't think that the KDE people should necessarily have to change their toolkit just to suit the needs of other people. They've got a wonderful product and it's built upon Qt. They don't care about the license, because they develop it for free anyway. I personally agree with them but, of course, you may beg to differ.

    -----------

    "You can't shake the Devil's hand and say you're only kidding."

  28. Compiler isn't the issue by Foogle · · Score: 2
    Who cares how much VC++ costs? It's the toolkit that's so much money. You can download EGCS for windows at no charge. It's just as good as VC++, I assure you. The only drawback is that some of the newer APIs don't have headers written for them yet. In any case, you'll never see me paying serious money for a compiler OR a toolkit, unless the programs write themselves (and no, I'm not interested in VB, thanks)

    -----------

    "You can't shake the Devil's hand and say you're only kidding."

  29. Neato. But... by Enoch+Root · · Score: 3
    This all sounds really neat. It's amazing to consider that some of these ideas are brilliant, yet simple, and never seem to make their way as simply into the corporate world than they do in the Open Source movement, where a program is an end in itself (as opposed to a marketable product) and tools like CORBA are a mean to an end.

    However, I wish there was some effort being done in making the various desktop environments intercompatible... I'd love to see development aimed at making it easier to code stuff that will run as smoothly on Gnome and KDE.

    Linux definitely needs that sort of interportability, but unfortunately it seems that development of applications for Linux is mostly modular, which leads to various branching left and right. It's a good thing Gnome and KDE aren't branching.

    Hackers of the world, unite?
    "Knowledge = Power = Energy = Mass"

  30. Re:But will KDE get swallowed apps? by ruud · · Score: 2

    I just can't live without swallowed apps in my Gnome and Window Maker docks. Will KDE ever get these?

    The current version KDE does have some basic support for them, but they do need to be the size of a panel-button. Don't know about KDE 2, though.


    --
    --
    bgphints - internet routing news, hints and ti
  31. XML by SpinyNorman · · Score: 2

    > > It is an important step to a completely
    > > component based architecture programmable via
    > > languages such as XML in as powerful a manner as
    > > the native API.
    >
    > XML a language? Surely not, or has it become more ambitious since I last checked up on it...

    FYI, XML is now starting to be used as the representation layer for RPC/RMI in XML-RPC and SOAP. AFAIK these are both Microsoft initiatives, but given that they are based on standards and replace Microsoft's proprietary DCOM, I wouldn't write them off just because of that.

    There's also libglade which allows a GTK UI to be configured at run-time via XML (not sure if there's anything equivalent in the Qt world yet).

    XML seems to be becoming pretty pervasive as a method of data representation...

  32. There is no "standards" issue here by JohnZed · · Score: 3

    Last time this subject came up, a number of people lamented the idea that KDE would abandon the "open standard" of CORBA for a new approach. I'm glad Mosfet has cleared things up a bit by explaining that libICE is equally a standard which, in fact, is a lot more common in the Unix/Linux world than CORBA.
    What I find really strange is the argument that GNOME's use of CORBA makes it more standards compliant than KDE. Don't get me wrong, if ORBit works well for this application, that's fantastic, keep using it. But ORBit actually implements only a very small fraction of a modern CORBA standard (MICO is fully 2.2 compliant with all the bells and whistles, so it is a slug in terms of performance), and does not yet provide C++ or Java bindings. Essentially, it's a handy, GNOME-only solution, like KParts is a handy, KDE-only solution.
    --JRZ

    1. Re:There is no "standards" issue here by sopwith · · Score: 2
      And which large fraction of the CORBA standard does ORBit not implement? I think you're probably repeating what someone else told you, rather than looking at the latest version.

      The point of CORBA is that language bindings are a non-issue, since an ORB for one language can talk to an ORB for another language. If you want C++, you can use ORBit-C++, Mico, OmniORB or any other C++ ORB. If you want Java, you can use whatever Java ORBs are out there.

  33. Comments on CORBA by Laxitive · · Score: 5

    OK. Lots have people have posted messages to the effect of "In a good ORB, the overhead of a method call to an interface is almost the same as the library." First of, there _is_ an overhead, but we can ignore that.

    The big problem with CORBA is _bloat_. If you implement all your internal embedded interfaces with CORBA, it leads to really unweildy sizes.

    The server for a simple CORBA demonstration (one structure and 1 interface defining 1 method), compiles to ~70K.

    The same functionality, if implemented with sockets or shared libraries, will probably take up less than 10K compiled.

    This is the kind of overhead you see with CORBA. Putting CORBA into every nook and cranny of your GUI implementation does not make it 3r33t.

    There is a time and place for CORBA. It's not for IPC, and it's not for embedded controls. It's best suited for large distributed applications.

    The K people have made a very practical decision by choosing shared libraries.

    -Laxative