Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
KDE GUI

KDE 2.0 Technology Overview 167

Posted by HeUnique 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?
This discussion has been archived. No new comments can be posted.

KDE 2.0 Technology Overview More

KDE 2.0 Technology Overview

Comments Filter:
  • It all depends on which CORBA implementation you use. I have a simple CORBA demonstration server here, on which 'size' reports 4119 bytes on the server and 3938 bytes on the client.
  • Ah yes, XML-RPC. It makes sense now.
  • been able to theme kde for quite a while now.. can even plugin enlightenment.

    I can look like a mac, beos, or whatever i want.. even changing icons, title bars, everything really.. 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.

  • 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.
  • I whole heartedly agree. In addition to which the corba semantics and definitions have all been defined by committee which means that every one tried to be nice to one another trying to achieve consensus and it shows. Ease of programming definitely seemed to have been at the bottom of their wish list.
  • so you're basically saying that linux is only for the rich-either large companies like IBM and Oracle or people who have enough time on their hands to give away their work for free. Screw the small developers huh?
  • 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 completely agree with you. Having KDE and GNOME in /usr makes me sick. Then, if you want to compile KDE and GNOME apps from tarballs they install to /usr by default. For me, /usr is sacred. I believe anything not being core components of the OS should go to either /usr/local or /opt.


    I have been using KDE since Beta2, compiling eveything from tarballs. I decided to try GNOME a few weeks ago. Since I did not want to mess /usr with packages that do not belong there, I had to edit the gnome rpm specs amd recompile all SRPM packages to install them in a different location. I could have compiled from tarballs in the first time, but I wanted to prove my point.


    For those of you who like to place certain applications in /opt, here's a script I have declared in /etc/bashrc to automate your $PATH to reflect new directories in /opt. It was made by cpg, not me.



    repath () { # pick new stuff off /opt
    for i in /opt/*/bin ; do
    if [ -x $i ] && (echo $PATH | grep -v --silent $i); then
    PATH="$PATH:$i"
    fi
    done
    }

  • $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.
  • 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....

  • Support? Ever call MS? At my old job, we had a problem with this query on sql server 6.5...called tech support, they insisted it was us. Then they tried it...they crashed it too. Called us back a few days later...'don't do that' was their solution. You call that support?

  • Re:XML (Score:2)

    by Rozzin ( 9910 )
    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.
  • ...is for KDE to be able to use GTK+/E themes.

    That would be very, very nice. I have precisely no clue as to how hard it would be, though.

    On a different note, I'd like to know how much effort is going into the installer for KDE 2.0; the 1.0 one wasn't much to speak of (although it's better than GNOME's - i.e. it does at least exist).

    Peter.
    --

  • Re:I'm still nervous. (Score:5)

    by evilpenguin ( 18720 ) on Tuesday October 26, 1999 @06:57AM (#1586338)
    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.

  • 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.
  • Yes, the KDE developers have consistently chosen the most practical route when faced with tough design decisions. This goes for GUI design especially, at least in my opinion. KDE apps work, and they're easy to use.

    Anyway, I'm wondering what GNOME's extensive use of CORBA and KDE's general eschewing of CORBA will mean for full integration of the environments. In particular, I wonder when, if ever, kpanel will communicate with E. I love E, but not being able to use the taskbar in kpanel is too much of a loss to let me switch over (from kwm, natch). For those of you who are wondering about kpanel and E playing together, the launchers and swallowed apps work fine if you invoke kpanel --no-KDE-compliant-window-manager, but the dern taskbar (the only good thing Microsoft ever invented, except maybe Joliet) doesn't work. D'oh!


    Beer recipe: free! #Source
    Cold pints: $2 #Product

  • This looks seriously neat! (Score:3)

    by jd ( 1658 ) <imipak&yahoo,com> on Tuesday October 26, 1999 @05:56AM (#1586347) Homepage Journal
    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.

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

  • Umm CORBA is used in distributed computing, along with Java. In fact today I was just talking to a guy who has been doing just that, at NASA. As far as being open sourced it's not but it is quite a substantial example, that it isn't as useless as you say. I personally haven't worked with it though so I don't know how difficult it is to learn.

  • This looks like the way to go ... (Score:4)

    by LizardKing ( 5245 ) on Tuesday October 26, 1999 @05:58AM (#1586351)
    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
  • 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."

  • I rather like the idea of two levels of IPC: a basic set and the whole CORBA shebang. Maybe the existence of a simple set of common hooks in this department will encourage more developers to make their programs friendlier to other programs. More modularity is a good thing, to me.

    I'm looking forward to the release. Whenever that is. :)
  • 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.

  • A different take on things (Score:4)

    by itp ( 6424 ) on Tuesday October 26, 1999 @06:01AM (#1586357)
    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

  • KDESoft! (Score:3)

    by Signal 11 ( 7608 ) on Tuesday October 26, 1999 @07:03AM (#1586359)
    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.

    --

  • 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 [kdeforum.org]

    -=-=-=-=-

  • This irresponsibility is proof that immature wannbe's should be allowed to moderation. Welcome to slashdot, folks.

    I completely agree! I'm supposed to be getting -1's folks, WTF are you moderators thinking?!?!?!?
  • 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.
  • What are distributed objects that are OS and platform independent good for? Presumably you already know the answer. (Hint: it is NOT "nothing")
  • XSL is an application of XML, not XML itself. You don't use the existence of C as proof that ASCII is a programming language.
  • The people who are responsible for the file path standard (FSSTF? some acronym, who can remember) says that anything that comes with the distribution CD should go in /usr. Everything that goes the local system only (not network), should go in /usr/local. /opt is packages that was not included in the distribution.

    RedHat follows the standard. If you get a package from RedHat, it installs into /usr. If you get a KDE package from KDE, it installs in /opt.

    I do agree with you, though, that putting desktop environment (spreading GNOME and KDE all over the place) is a very BAD IDEA. Someone should change the standard.

  • Re:XML (Score:1)

    by mill ( 1634 )
    Yes, and you don't markup text in XML either, but with an application of it.

    The original claim was "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." but of course they mean an application of XML. Just like Glade doesn't save an representation of a Gtk GUI in XML.

    When people say "XML" they mostly mean "an application of XML" and in that context XML is an programming language - if one wants to.

    /mill
  • An ORB is not a huge 10MB daemon running on your system (at least it doesn't have to be). It is a library that marshals requests to possibly remote or out of process objects. If you use two different ORBs at the same time, you would just have two libraries in memory -- many of the CORBA services such as name service and interface repository could be shared (and you probably would want to).

    CORBA does not have to be huge. For instance there is a partial implementation of the marshalling (not services) code written in a bit over 1000 lines of emacs lisp.

  • 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

  • E is KDE compliant as Of 0.16 - so it'll work with the taskbar.

    George Russell
  • It's a matter of perception. Where you see evidence of some sort of bias, I see mere silliness and tomfoolery. A waste of time and resources, to be sure, but that's nothing gnu around here, and welcome in small doses.

    I'm a huge fan of KDE and I thought it was damn funny. The original moderator must have mis-read "Insightful" as "InCITEful".
  • What's up with that?

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

    --
    Interested in XFMail? New XFMail home page [slappy.org]

  • 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.
  • > KDE 2 will have a much better clipboard support - any data can be copied and pasted, it will be recognized by mimetype. That sounds really nice. Will it have more than one clipboard though, or still just use XA_PRIMARY? I can't find XA_SECONDARY used for anything - what about nominating that as a clipboard for search text? Copy and paste on a typical KDE app doesn't behave the way a Mac/Wiindows/NeXT user would expect. For instance, if you open a text file with kwrite. Select some text, then choose the copy command from the menu. Then scroll down the file a bit and select some more text. Then choose paste from the Edit menu. Ask a Mac user whether they thought the text in the file will have been changed and they will say "yes", but a KDE user will say "no". Any text you select is automatically copied to the clipboard overwriting what was there (whether you wanted that to happen or not).
  • No, it doesn't. I built it from the source RPM last week.


    Beer recipe: free! #Source
    Cold pints: $2 #Product

  • 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 ;)
  • Having a completely finished desktop environment won't be the windows killer. It's a great first step to having the completely integrated office suite which is what will bring in the masses and the business users.
  • Language, yes. Programming language, no.
    XML = eXtensible Modeling Language.
    --
    Man is most nearly himself when he achieves the seriousness of a child at play.

  • Applet-screenshot: here! (Score:1)

    by Anonymous Coward

    A screenshot of a well-known applet in kicker (formerly known as kpanel) can be found here [uni-kiel.de].
    The new hicolor-icons are not in CVS-HEAD yet though. So if you don't like the icon above, be aware of the fact that it is still one of the old locolor-icon for people with 8-bit-graphics-adapters.
    If you haven't seen the new icons yet, have a look here [kde.org] (PNG) or here [kde.org] (JPG)!
    (This one is a screenshot of KDE 1.1.2)

    Have a nice day,

    ac
  • 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.
  • 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.
  • Yep. Gnome is the future. All these 12 people who are using it can certainly confirm that.
  • 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 ...
  • >It's obvious that Gnome and KDE are going two >seperate paths. Rather than

    Yep, and that's one of the best things about the two projects. I got the feeling at the inception of GNOME that it was created to compete in a way with KDE. That's fine, and choice between two desktop systems is good, but I think it's wonderful if they diverge in what their core focus is at a certain point in time because not only does it give you choices, but it gives you choices spread across a field rather than clustered in one area of desktop useability.

    I hope that made sense.
  • KDEforum.org looks like it's broken. Sorry. Keep checking back though, Magellan looks awesome.

    -=-=-=-=-

  • There's a very good discussion of the problems that arise if you fail to choose distributed interfaces carefully at:

    Facades As Distributed Components [c2.com]
    Distributed Facade [uiuc.edu]

    My heuristic is that one should design CORBA interfaces thinking of them as network protocols, not as collections of objects in a program.

  • Re:XML (Score:1)

    by Rozzin ( 9910 )
    You don't appear to be someone unfamiliar with programming, so I'd love to see some of your code, and hear what languages you've written in.
  • ..And see all the FREE software for Linux and
    KDE. Shareware and Linux rarely goes together,
    because most GPL-software is far better than
    shareware anyway.
    Big commercial-applications may be better,
    but the companies behind those have no problem
    with the license-fee.
  • So says RMS. KDE 2.0 will use Qt 2.0 which is not only "open source", but better yet it is "free". Being a sysadmin at a shop that is migrating from Windows to Linux/Solaris/NetBSD I am really psyched about this great desktop environment that will make the migration much much easier.
  • > > ...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
  • Cetainly more than $1000.00 per developer if you had actually known what you were talking about.

    Enterprise Edition of MS Visual Studio > $2500.00 US.
    Delphi Client/Server version > $1500.00 US

    BTW, thats per developer pricing. And yes there are cheaper versions (less tools/features) of each.

    Neither price includes long term support, thats extra, a lot extra.

    might get some discounts for large purchases at a very large organization. Small ISVs like most of us have to pay up for the latest and greatest.
  • All that fancy stuff that kde did via its fancy mechanisms is easily and best done by X. They now see that X itself has the power required to implement 95% of their management...it was there all along. Congrads KDE team for waking up.

  • Re:XML (Score:3)

    by jilles ( 20976 ) on Tuesday October 26, 1999 @08:28AM (#1586427) Homepage
    "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.
  • That has to be my single-least-favorite part of KDE. No dock apps.
    Of course, I just have a bunch of Wmaker dock apps on the side
    of my screen and I tell the advanced window settings to make them
    start stikcy and never get focus. Works pretty well.


    I definately think that the panel is the weakest portion of kde (1.x) at least.
    Can you run the gnome panel and kill the kde panel? Hmmm?
  • 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.
  • 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
  • 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...

    Nitpicking apart, this strikes me as a very sensible approach. CORBA is a bloated enough standard as it stands without being made to do things it wasn't designed for. Has anyone ever heard of DCOM before? Where else is it used?
  • 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
  • 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
  • I just can't live without swallowed apps in my Gnome and Window Maker docks. Will KDE ever get these?
  • I meant DCOP of course...
  • Bonobo is based upon CORBA as well.

    --
    Ian Peters
  • I boot up with the penguin,
    My system ain't no lie,
    I don't run that fascist MS crap,
    I got the birdy suit and tie!


    Boot up the lilo and watch dmesg roar,
    see init launch /bin/sh and rc galore,
    It's OK to startx,
    fvwm's my friend,
    but touch that KDE crap
    and stain your self with

    Chorus
    MMMMMSSSS MMMMMSSSS

    stain yourself with
    MMMMMSSSS MMMMMSSSS
    unchorus

    KDE's like Windows,
    It's DCOM by 'nother name,
    you want the real baby,
    you'd write it in pure Xlib!

    So next you boot the penguin,
    give yourself a pause,
    should you consider KDE,
    know it breaks the UNIX laws!

    Chorus
    MMMMMSSSS MMMMMSSSS

    stain yourself with
    MMMMMSSSS MMMMMSSSS
    unchorus
  • Take a look at http://www.kde.org/applications.html ( and many other places ) and see all of the _freeware_ available.
    KDE dying because of lacking shareware ? A good joke. This is definitely not a reason for KDE to die.
    Also, if you sell your something for Gnome for $10, that not free.
    Oh, and btw, IMHO Qt is one of the reasons KDE is that successful as it is.
  • Yes, there definitely *is* a gain. CORBA's inter-process communication is, despite having a very elegant concept, rather heavyweight. Every RPC, while almost completely hidden from the programmer, transfers a large amount of data between processes (which may be on the same computer or distributed). The object identifier alone is some 200+ bytes large (which allows, in theory, nice things such as process migration, but is also quite cumbersome).
    The libICE mechanism is more lightweight, and remember, since it is also standard, involves no overhead from the point of view of loading new shared libraries.
  • Not even GPL'd is truly free. Only public domain is truly free.
    Enough said.
  • Get a clue dude! Qt is 100% open source and RMS certified Free. Go to Troll Tech and download it! No questions asked. No need to enter in a credit card number.

    Yes, the ***Windows*** version is proprietary, but the X11 versions free. And there's nothing preventing you from porting one to the other. You can even use Free Qt to create proprietary X11 apps!

    You said: "even M$ doesn't charge a developer fee." I say bullshit. Go price out the full version of VC++. But then you may be comparing the much cheaper (but still charged for) VB to Qt, and if you are, you really need a clue if you think they're equivalent in any way.
  • Yes, everything.

    KDE has a theme manager that will both tell QT what do do and change as many other things as possiable (such as the title bar style in the window manager, the icons used on the desktop...). It even tries to get Motif applications to chage their theme (just the default colors) as much as possiable (you have to restart them after you install a new theme, and I cannot change everything on a Motif application.) If you want an preview of this get KDE 2. There is also a theme control panel in KDE 1.1.2, but because KDE 1.x is based on QT 1.4 it cannot change as many things.

  • Re:XML (Score:1)

    by mill ( 1634 )
    Umm, and what do you call XSL?

    /mill
  • For what it's worth, I'm getting into it just fine right now.
  • 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.

  • Well, one thing, it's total vaporware. There are no downloadables yet (though it "should be ready" by Dec, '99.

    Also, what PIM needs a PII/233+ and 64MB of RAM to run (with faster processor/more RAM suggested)? Is it cracking RC5 blocks in the background? It's an email reader/addressbook/to-do list! How can it possibly need that many resources? Sorry, at home I may have a system that will support that, but at work I'm on a lowly P/166 w/ 64MB RAM that is shared as a server with 3 other people. If I can't use it on a reasonable machine, then forget it! That sort of bloat I surely don't need.

  • Re:A different take on things (Score:3)

    by itp ( 6424 ) on Tuesday October 26, 1999 @08:47AM (#1586453)
    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
  • I had a major breakdown (someone fiddled around with the server, filling the disk), but it's up again (damn, why does it break just today :}).
    Unfortunately some newer comments were lost. I hope I can get them back, and then I'll move to Zope 2 ;)

    The login prompt was due to wrong TinyTable permissions after the backup.
  • 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."

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

  • That's an oxymoron if I ever heard one...let's see a Sun E10k, that's big iron, but as a desktop?, for one thing it's too high and too hot, not to mention expensive.

    As for you main point, yes bloated office apps can make any computer slow, regardless of the OS.
    --
  • How the heck KDE is going to affect load on X caused be other apps ??
    Do you know what are you taking about ?
  • 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.

  • XML a language? Surely not, or has it become more ambitious since I last checked up on it...

    Well, that is what the L stands for, after all. XML = eXtensible Markup Language

  • Neato. But... (Score:3)

    by Enoch Root ( 57473 ) on Tuesday October 26, 1999 @06:12AM (#1586463)
    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"

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


    --
  • ...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? ;^)
  • 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 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...

  • KDE doesn't affect the load caused on the computer by other programs. However, KDE does place a sizeable strain on older x86 hardware w/ slow, small memory subsystems (P133 16mb EDO ram). It's not really possible to have KDE speed up X applications. However, it is possible to clean up the KDE code and have it use less memory and processor time.
  • Um, I find NT to handle very well with multiple apps. I regulary have 20 or so apps open, about 10 IE windows, ICQ, SQL, SET, REAL etc etc etc....and it's fast as.

    Ever tried to open more than one netscape? Or maybe staroffice?
    ROFL
  • 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...
  • To reinforce what an AC said before, and perhaps clarify it: the article by mosfet seems, to me, to be saying "We've resolved these technical issues, and here's how" rather than "Uh oh... uh... look over there!" Which is what you seem to be saying it says. That is to say, it isn't spin-control, because there's nothing to spin... they've resolved the issues, in a way that looks to me, as a programmer, to be good.

    That was probably more confusing than the original AC post by that other person...
  • >My question (which was rhetorical; I already knew the answer to said question was "no") was about KDE 1.x...

    I withdraw my flame then. Sorry.
  • I can't find any mention of improved clipboard services in the KDE 2.0 doc. When I looked at the KDE 1.1.2 code recently there were only three types of clipboard data - text, bitmap and URL's. Clipboards aren't as glamorous as components and run time linking and so on, but they are probably going to be used the most often. It would be nice to have a clipboard type for search text, set up a search for a word in one app, change to another app and hit search - it might look for the same word. Or richer data types like PDF, RTF or similar so you can paste text with attributes in a standard manner.

  • KBasic? (Score:1)

    by Anonymous Coward
    I would love to see a development system like Visual Basic. Yeah I know, I can hear the flames already, but VB allows you to knock up some nice database apps in a snap. It's just a shame they only work under Windows.

    May not be appealing to serious developers, but VB has a lot of followers, and some of us (including me) make a nice living cooking up these bespoke apps for our customers. If I had something like VB, I could easily convert some of my customer over to Linux.

  • There is no "standards" issue here (Score:3)

    by JohnZed ( 20191 ) on Tuesday October 26, 1999 @06:34AM (#1586481)
    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

  • Comments on CORBA (Score:5)

    by Laxitive ( 10360 ) on Tuesday October 26, 1999 @06:43AM (#1586483) Journal
    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
  • 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.

  • 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

    If I am not mistaken (but I have no references at hand) there is an ongoing effort to make KDE and Gnome more interoperable - e.g. by using the same window manager hints etc (okok, it may be details, but they still are).

    That said, I installed KDE 1.1.2 not long ago, and after overcoming some initial annoyances (formerly a die-hard fvwm-user) I must say that, asside from some minor glitches I am mostly positively surprised by the system (long rant about what could be better left out for readability)

    Awaiting kde-2.....

Slashdot Top Deals

The finest eloquence is that which gets things done.

Close