Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
KDE GUI

Interview: KDE League Chairman Andreas Pour 181

Posted by michael from the apt-get-install-task-kde dept.
Frank writes "Here's a good interview with KDE League chairman Andreas Pour. He talks about the K desktop environment (KDE) 2.1, that will be Hitting the streets on Monday, February 26. He reveals info about some significant advantages over the old 1.0 platform, including a full-fledged browser and the upcoming KOffice suite of business applications."
This discussion has been archived. No new comments can be posted.

Interview: KDE League Chairman Andreas Pour More

Interview: KDE League Chairman Andreas Pour

Comments Filter:

  • Re:what What WHAT?!? (Score:1)

    by Anonymous Coward
    Yeah, pretty soon we're gonna see GNOME, Mozilla, and Lynx file a lawsuit in conjunction with the DOJ, claiming the KDE is a monopoly.
  • Interesting.

    I've always found KDE for 'weenies', those that really do not want to interface with UNIX the way it was meant: through a command-line interface or via a windowmanager like twm, fvwm or a light modern one like afterstep.

    KDE with it's Windows look-alikeness is therefore the solution for those who do not want to bother with 'arcane' CLI's and windowmanagers.

    But then, when I was at the OSDEM in Bruxelles quite a lot of 'smart' developers were using KDE, to my surprise. This made me think about it again and I'm now considering installing 2.x just to try it.

    --Rogier
  • Consider your history. Why are there now two desktop environments for Linux? Well, we have reached this state because of liscensing issues. The Gnome project formed purely because people were unhappy with the KDE qt liscense.

    Now however, these issues do not exist. So why keep tow different desktops? Why continue to divide out labor on two projects which both hope to achieve the same thing? Imagine how much more polished the Linux desktop environment would be if all effort were focused on just one. Twice as much effort would be expended on it every day. At present KDE and Gnome both have a somewhat beta-ish feel to them, but this would quickly disappear if there was only one desktop environment.

    What are the arguments against this? They are as follows:

    • Linux needs variety. Having two different desktops environments gives people a choice. For myself, I would say that this does not hold water. It is far better to have one desktop environment that works well, than to effectively repeat the same effort on two different incompatible desktops. Gnome and KDE are very similar anyway - they both hope to achieve the exact same thing. I could understand this argument if they were trying to acheive different things, in a different way, but they arent.
    • Incompatibility. One of the desktop environments would become redundant, and all its software would be rendered incompatible with the new one. My problem with this is that it happens already. KDE2 is not especially compatible with KDE1. If instead they had created bindings for the gnome desktop environment, and then joined it, we would all be much better off. It is not even an expecially big task - qt is only some 20000 lines of code, for example.
    I think that instead of working on KDE3 and Gnome2.0, we should instead be trying to build bridges, and reunifying this fork which has been scarring the Linux community for so long. It is time to extend the olive branch, and heal these old wounds.

    The developers may not like it, but it is in the interests of the user and of Linux as a whole.
    --
    Clarity does not require the absence of impurities,

  • So what if the browser is integrated with a desktop environment? The issue with MS was that it was integrated with the operating system. There is a big difference.

    -- Thrakkerzog
  • Get it now my friend, the version in CVS is 2.1 FINAL!!! I have it safely on my hard drive, so feel free to /. it now.

  • He reveals info about some significant advantages over the old 1.0 platform

    Of course, it wouldn't be as good PR to talk about the significant advantages over the old 2.0 platform, like stability. My best explanation for KDE 2.0 was that it was an olive branch after all the insults Gnome developers took over their "1.0" misrelease. I managed to get konqueror to crash within a minute of using it. I tried both compiling from scratch and prebuilt binaries before giving up. To be fair, I didn't try the 2.0.1 release or whatever came next; the bugs I saw may have been pounced on more quickly than I'm giving them credit for.

    Most of the problems seem to be gone now; in the 2.1 beta that comes with Red Hat fisher (yes! beta software squared!) I couldn't make any of the main components crash, and even koffice took some time and work to bring down. I hope the RH7.1 final is delayed long enough to slip KDE 2.1 final in; it's really worth a look now.
  • I guess your the kind of person that would put all your eggs in one basket?

  • If you want to work on this, I'm sure no one will object.

    They have already done quite a bit in terms of unification, though. They have a common .desktop file standard (although gnome can not handle UTF8 in them.. =/), xdnd, and a common window manager specification.

    What sorts of bridges do you want? Where exactly is the incompatability between the two? With kde's xparts, you should be able to run gnome applets in kicker (the kde panel). It would take a bit of coding, but it could be done.

    Anyway, I don't really see too much of an incompatability with the way things are done now. If the two projects were to merge, there would be less progress than there is now.

    I don't know about the rest of you, but kde 2.1 doesn't feel at all beta-ish to me. If you get random crashes for no reason, you probably have bad binaries from a poorly packaged rpm. (or deb) I've been compiling kde from source for a long time now, and have hardly any problems with things crashing. It is very stable now.


    -- Thrakkerzog
  • At present KDE and Gnome both have a somewhat beta-ish feel to them, but this would quickly disappear if there was only one desktop environment.

    I think experience has shown that, for better or worse, throwing more resources (people etc.) at a project doesn't necessarily solve its problems. Same here. I also had the opinion that two huge projects both pursuing the same goals would be a waste, but I think that the "competition" has helped increase the quality of both Gnome and KDE. They make sure that certain features are available, because the others have them already. They study each other's code to improve their own (not everybody, but some). Variety _is_ good!

    I'm not enough into this to know whether the efforts to make both projects more compatible to each other, share certain file formats / configurations etc. really worked out. That would be a step into the right direction.

    However, whether a single desktop environment would be good or not, I think there's not a chance in hell that one of the groups will drop development to join the other.
  • I've always found KDE for 'weenies',

    Well, yeah, KDE is for weenies. That doesn't mean it can't be for power users too.

    those that really do not want to interface with UNIX the way it was meant: through a command-line interface

    Take a look at the new konqueror, then, with it's option to open up a short terminal in the file manager window, and change directories in that terminal when you change them in the final manager or vice versa.

    Or if command line scripting's more your thing, take a look at "dcop", which lets you control any exported interface of a KDE application from the command line.

    or via a windowmanager like twm,

    This is a joke, right?
  • 2.0.1 was a lot more stable for me, and 2.1beta2 has been almost rock solid. Of course, I really only use konqueror on a daily basis, so I wouldn't know about the rest.
  • GNOME and GTK apps I've noticed ingegrate better
    with more window managers than do KDE
    apps,and there are a lot more of them.
    KDE is the better environment by far, but running all your non-KDE apps in it creates bloat and ugliness.

  • At least they admit that things can crash. Don't tell me you have never had netscape, mozilla, or explorer crash on you. KFM's web browsing code was very simple. What they have now is very complex, and is still not quite bulletproof. It's close, though. They are just being honest here.


    -- Thrakkerzog

  • I've always found KDE for 'weenies', those that really do not want to interface with UNIX the way it was meant: through a command-line interface or via a windowmanager like twm, fvwm or a light modern one like afterstep

    and what exactly is a "weenie"? I'd say KDE creates a far more cohesive, interoperative desktop. and, unless you're arguing an abstract case for UNIX or CLI "purity", there is the console (xterm, konsole, whatever) app for you

    KDE with it's Windows look-alikeness is therefore the solution for those who do not want to bother with 'arcane' CLI's and windowmanagers.

    personally, I haven't seen a popular desktop environment that didn't look like windows (gnome, kde, fvwm95, etc.) I'm not sure whether this means windows has it right, or most people are just grasping at a familiar look.

    But then, when I was at the OSDEM in Bruxelles quite a lot of 'smart' developers were using KDE, to my surprise. This made me think about it again and I'm now considering installing 2.x just to try it.

    I recommend it. I don't usually advocate projects all that much, but the 2.x series really impressed me. just wait until you fire up konqueror.


    sean

  • Shell Plugin Rocks! (Score:5)

    by KurtP ( 64223 ) on Saturday February 24, 2001 @06:05AM (#406013)
    I love the new shell plugin idea. Konqueror has been top-notch stuff, and adding the ability to conveniently execute shell programs and capture them to a terminal just rocks.

    I've been using the embedded terminal feature to do this in KDE 2, and having a way to do it without needing to pop open a shell in advance is just nifty. I bit of configuration lets me set up development directories that are extremely convenient to use.

    I've been hearing this fiction that KDE is not for serious Unix users, but this is just bull IMHO. Konqueror is easily the most productive programming environment I've ever worked with.
  • I have never much cared for KDE...(Mainly for my own stupid reasons of the WM portion not being custumizable enough ALA Sawmill or E)...However that being said, I played with 2.1beta the other day and I have to say that it pretty much knocked my socks off performance wise, stability wise, and it "felt" really good....Alas I went back to my Sawmill/Gnome Panel config shortly after -- I just think that some of these cool theme combos (GTK & Sawmill) that have been coming out lately are just DA Bomb...Plus I do not particularly care to launch a bunch of background processes like KDE does....

  • Speed? (Score:1)

    by Anonymous Coward
    I grew up on Windows but I'm now wanting to switch to Linux and KDE. The major problem is that KDE is a lot slower than Windows on my machine (Celeron 466, 64 meg ram).

    For instance, opening a Konqueror window on my home directory takes about 5 times longer than opening a Windows Explorer window (windows key + E).

    I'm sure this is partly due to Windows embedding certain GUI stuff into the kernel, but the fact of the matter is that KDE is still up against it.

    So, the question is: is there any scope for drastic performance increases in future releases?

    - Nick

  • >>or via a windowmanager like twm,

    >This is a joke, right?

    I use twm every day, and get everything I need out of it. KDE, Gnome, and the like are enjoyed by many and I'm glad they're out there, but if you don't need or like them it's good that there are other options.

    A wide variety of apps and interfaces is part of what makes unix great.

    Martin

  • Re:anti-unix? (Score:1)

    by Anonymous Coward
    Actually KDE is *a lot* about Unix and the command-line. It's currently the only graphical interface which is scriptable via the CLI.

    dcop kdesktop KScreensaverIface lock

    starts the screensaver in kde using the CLI. Also konqueror embeds the konsole nicely so that I can work on my webpage easily using emacs while previewing the webpage in the same window. And the best thing: the commandline follows the konqueror-views. If you like Unix-like shortcuts don't miss to choose the Unix-keyboard-scheme in KDE 2.1!
  • You state your performance with KDE is poor on a 466 Mhz Celeron w/ 64 MB ram.

    I recommend you upgrade to 128 MB RAM, which is really the standard nowadays and is essential with the nature of UNIX desktop environments -- they require a lot of libraries to be loaded ...

  • Did the fix the one major problem with KDE-2, namely the fact that it takes a minumum of 2-3 seconds to start *any* program, no matter how simple? Used to getting split-second response times from even the largest apps under BeOS, KDE-2 is basically unusable for me. KDE-1 was never this slow on my system, so what up with 2?

  • Would merging the two be the most effective cure for the "beta-ish feel"? Realistically, the developers would let their egos get in the way and have this second-circuit battle deciding which incumbent desktop gets to dominate the merge. Diversity is a good thing with desktops. Eventually, one will dominate. Perhaps they will become even more disparate.

    Manufacturers of non-clunky desktops have cognitive psychologists, physiologists, and experts in other interface-related fields at their disposal. As the open source movement gathers more momentum, it will have such resources working in symphony. Patience for now--We're living in what the historians will refer to as the end times of closed source dominance.

    One of the most popular habits of /. flamers is arguing over KDE/Gnome, vi/emacs, etc... It's amusing, but they have totally missed the point. The best we can ask for in the KDE/Gnome issue is mutual bindings.



    If you love God, burn a church!
  • fwiw, Qt 2.2.3 has 115455 lines of code in its src/kernel directory, as report by wc -l *.cpp *.h

    There are more loc, I didn't count widgets, extensions, or examples.

    Qt is big, KDE is several million loc, GTK/GNOME are equivalent or more in loc due to verbose C code.

    Unification is a pipe dream. Thank X11, and its toolkit wars for this.

    Posted from Konqueror in KDE 2.1 Release
  • Moderators sould get a clue!
    Heidi Wall is a trolling karma whore!!!!!!
    and you don't even want to know what she does
    with camels!
  • Oh no! Background processes. They only reason you're not using KDE is because of background processes and themes (who says Linux users aren't as style obsessed as the rest of us?) Right now, with no programs running, I've got 17 processes running on BeOS, some with over half a dozen threads. Having background processes really doesn't have any relation to system performance, particularly in the case of Linux, where context switching is very fast.
  • Are you under the impression that gnome does not start up 'a bunch of background processess'? I hate to break it to you, but running just the panel and the session manager starts up about a dozen processes!

    Of course, I don't use either gnome or KDE as my 'desktop environment', although I use a few apps from each camp (konqi, kghostview, gnumeric, and everybuddy)

    Try http://www.students.tut.fi/~tuomov/ion/ for a new idea in windowmanagers. I've been using it for a couple of months now, and it really boosts my productivity.
  • I've often wondered whether the time differentce is just having Explorer preloaded when Windows starts. I don't have Windows (or KDE 2.x) on my box right now, but I would be curious about speed comparisons between opening a new window when Konqueror is already open vs. creating a new Explorer window. If Konqueror shares resources, the new window should come up faster than from cold start. Of course, the Konqueror programmers may have decided to treat every window as a separate program instance, in which case no speed up would be observed.

    Does anyone have a way to test this? (Be sure to check that Konqueror *isn't* preloaded by KDE already.)

  • Merging KDE and GNOME (Score:3)

    by jregel ( 39009 ) on Saturday February 24, 2001 @06:30AM (#406026) Homepage
    It isn't going to happen - not for a long time anyway. Both KDE and GNOME are still developing their infrastructures and investing massive resources into their own respective projects. The thought that one project would abandon their work and merge with the other is extremely unlikely, especially considering the past animosity and considerable egos that some nameless core developers have (I won't say which project - I'm no troll).

    I wouldn't expect to see anything significant until KDE 4.0 / GNOME 3.0. Then we should see two mature component models, a large number of applications that make use of it's respective desktops features and things will have probably settled down a bit. At that point, it might be possible to see some sort of bridge developed between the environments at the object level.

    One day we might have a desktop that integrates Mozilla XPCOM, KDE Kparts, GNOME Bonobo, OpenOffice UNO (yeah, I know about the port to Bonobo) and possibly even COM/ActiveX via WINE. Who knows, maybe some people will get .NET working with the Linux desktop.

  • Alternative to merging (Score:4)

    by be-fan ( 61476 ) on Saturday February 24, 2001 @06:32AM (#406027)
    There is obviously a lot of talk here about merging KDE and GNOME. That is not a good idea. There is also a lot of talk to keeping things like it is. Also, not a good idea. The only real way to solve this issue is create a standard desktop API that KDE or GNOME backends can plug in to. I've already espoused the idea dozens of times, and if you want details, look at my back-posts, especially the recent Art of UNIX Programming Thread. If there was an ABI that apps had to follow, then we could open the desktop environment to competition in quality, stability, etc, while still having a consistant desktop, and without fragmenting the application base.
  • keep a konqueror window open, and press ctrl n.

    It should be about the same speed as on your windows box.

    You are not opening a konqueror window, but starting a konqueror process by running konqueror.


    -- Thrakkerzog
  • 64 meg of SDRAM can be bought for ~40.00 from crucial.com

  • [...] it is in the interests [...] of Linux as a whole.

    In this context, `Linux as a whole' sounds distinctly silly. You remind me of people living in Amsterdam or in Paris who tend to forget that there's more than one city in their country. What you seem to forget here is that Gnome and KDE are not desktops specifically for Linux. To illustrate: I have used both KDE and Gnome, but neither on Linux.

    Also (but this has been brought up by other people as well): what on earth is wrong with having more than one desktop to choose from? The same is true for any other piece of software.

  • > I think that instead of working on KDE3 and
    > Gnome2.0, we should instead be trying to build
    > bridges, and reunifying this fork which has
    > been scarring the Linux community for so long.
    > It is time to extend the olive branch, and
    > heal these old wounds.

    I think that friendly competetion between the two desktops is good. For one thing, it give users a choice. Secondly, it means the bar is continually being raised. The popular argument against Microsoft is that a monopoly stifles innovation. Why should the basic principle be any different for free software?

    I agree that there's been a lot of grief in the past. But that shouldn't prevent partisans in both camps from simply growing up and getting along.

  • Sure, why not ? If you can build bridges between the U.S.compatriots and the European ones, go ahead. My bet is you'll fail miserably, it's not an easier task as the unification, kiss and make-up of all races into one happy global familily. Sort of stops at the local level and that's were most of us live. :-)

  • Comment removed (Score:3)

    by account_deleted ( 4530225 ) on Saturday February 24, 2001 @06:59AM (#406033)
    Comment removed based on user account deletion
  • > Of course, the Konqueror programmers may have
    > decided to treat every window as a separate
    > program instance, in which case no speed up
    > would be observed.

    I think this may be the case. Very infrequently, I'll crash Konqueror. If I have multiple windows open, only the one that hit the error crashes. The rest are fine.

  • I would disagree that Gnome and KDE need to merge.

    Gnome and KDE have different design philosophies on a number of levels. For an example, witness Gnome's full-fledged CORBA approach, and KDE's lightweight CORBA subset approach. Which one is better? I can't say. They both have advantages and disadvantages. The best way to find out is put them both in the field and let the users decide. The beauty of it is, since both are open-source, the best approach is almost sure to win out, while the other will still be supported for compatibility.

    In the end, I expect that both will still be around, but the differences will be inconsequential and both's programs will be compatible with the other.

    "If I removed everything here that I thought was pointless, there would be like two messages here."

  • Re:Speed? (Score:3)

    by Fervent ( 178271 ) on Saturday February 24, 2001 @07:15AM (#406038)
    The dude is just right folks. Telling him to get "more memory" is not a viable solution.

    Windows (95 and 98) require less resources than Konqueror. Period. Windows 95 and 98 also came out 6 and 3 years ago respectively, so this can be taken with a grain of salt.

    I have 256 MB of RAM for my Win2000/Linux "box" (actually, it's a laptop) because I'm preparing for the future. RAM is cheap right now. Not everyone has this option though.

  • Why should they? (Score:5)

    by Carnage4Life ( 106069 ) on Saturday February 24, 2001 @07:16AM (#406039) Homepage Journal
    Consider your history. Why are there now two desktop environments for Linux? Well, we have reached this state because of liscensing issues. The Gnome project formed purely because people were unhappy with the KDE qt liscense.

    The origin of the projects is no longer important. So if MIT suddenly is given the source code for all the printer drivers in use on their campus, should RMS give up the Free Software Foundation? (click here [gnu.org] if that didn't make sense to you)
    Why continue to divide out labor on two projects which both hope to achieve the same thing?

    Because they plan to do this in completely different ways, also once they are mature the differences willbeself evident.

    Imagine how much more polished the Linux desktop environment would be if all effort were focused on just one. Twice as much effort would be expended on it every day.

    Anyone who has read Frederick Brooke's Mythical Man Month [ercb.com] knows that your statements are a big misconception. Doubling the number of developers on a project does not double the amount of time taken to finish the project because new developers have to be brought up to speed and the layers of communication increase which leads to more errorsoccuring due to miscommunication. Basically there is a certain level of complexity where throwing more developers at a product produces little net gain. KDE and GNOME are at that level of complexity.

    KDE is mainly C++, GNOME is mainly C (if you do not realize there is a fundamental difference in these languages then go to comp.lang.c [comp.lang.c] or comp.lang.c++ [comp.lang.c] and state this and see the responses you'll get). GNOME uses all sorts of CORBA stuff while KDE does not. GNOME uses OrBit while the few KDE developers who know CORBA used Mico. Both projects are extremely undocumented and very few, if any, have a complete grasp of the entire system in either case.

    Quite frankly,if KDE and GNOME merged the efforts involved in adjusting to the merger would slow down development a lot more than any perceived current lack of developers does. In addition, some functionality that was a part of one or the other system would be lost (because stuff always gets trimmed in a merger).

    A better suggestion is for KDE and GNOME to start actively pursing interoperability. Unfortunately this is one place were Open Source may fail. It is unlikely that GNOME interoperability is high on the list of any KDE developer's list of itches he/she wants scratched and vice versa. Thus since they are all simply volunteers they can't be made to do it like would happen in a professional development environment, where a manager can just assign a bunch of coders this task.


    Finagle's First Law
  • <i>For real Linux "buffness", you should use the command-line only. ALL THE TIME. No silly widgets and GUI Netscape. Terminals and Lynx for everyone.</i><br>
    Lynx? Lynx? If you're a real man, you telnet to port 80, dammit, and do things the HARD WAY.
  • I haven't seen any problem with memory bloat in KDE. But then again, I compiled everything myself to make sure everything's the way I want it.

    The biggest memory-sucker in KDE is a misconfigured QT. Many distros compile QT with exceptions enabled, which almost doubles the size of the library. To fix this, get the latest QT from TrollTech [trolltech.com] and use "-no-g++-exceptions" to the ./configure command. Then run "make symlinks sub-src sub-tools" to compile the stuff that you need and not the examples or tutorials you don't need. The file libqt.so.2.2.4 should be around 5.5 MB. Adjust the symlinks to point to the new QT and start KDE. I personally find KDE nice and zippy.

    Another thing that might get in the way is if debug code has been compiled into KDE, and that can only be fixed by recompiling the whole shebang, adding "--disable-debug" to the ./configure command.

  • Sure, let's add _yet_ another layer. No wait, let's not...

    Abstractions of abstractions does not solve problems. I don't know why people are so easily talked into thinking this is a good idea. That would be XML all over again, like, "let's define a wrapper that everyone uses, but let's not consider that everyone still needs to agree on what we're actually sending thru the wrapper"

    A common API on which KDE and GNOME could be developed is *already* there - it's X11R6 and POSIX. That's why you can start up GNOME *and* KDE on the same machine - clever, eh ?

    I don't know why you mention an ABI, maybe it's a typo and you meant to say API ? The ABI is standard already, and it would be a damn hard thing to re-define, and as I see it wouldn't make much sense to do either..

  • Many distros compile QT with exceptions enabled, which almost doubles the size of the library.

    Uh, isn't compiling without exceptions just asking for trouble if things crash later? Or am I not thinking clearly (is this exceptions for g++, or the actual KDE binaries you will be running?)

  • State of the GNOME project? (Score:3)

    by halk ( 139476 ) on Saturday February 24, 2001 @08:36AM (#406058)
    Sightly OT, but since the linked article talks a lot about GNOME too...

    It seems that their corparate ties with Ximian, Eazel and Sun are causing real trouble. Apparently they have lost nearly all of their voluntary work force after the GNOME Foundation was announced. Couple of quotes I saw in gnome-hackers list. These are core developers, not some random guys:

    Alan Cox:
    "...there are not enough people working on gnome infrastructure/site admin to keep up with the demands of these because most folks are busy working on their rival Ximian or Eazel projects and so the number of effective actual gnome core contributions has dropped massively rather than risen as might originally have been expected."

    link [gnome.org]

    Matthias Warkus:
    "Looking at the CVS logs, no one seems to be really working on the core anymore. Pretty much all of the code commits go into Nautilus, Gnumeric, Evolution and Eazel's and Ximian's supporting and surrounding technology and tools.

    I think we're at the point where we should ask ourselves whether the GNOME Project can still be considered a living entity at all. And whether it's a good move to, at this point, tie our next release to Nautilus, which, however cool, is essentially a third-party product with the main purpose of generating revenue for Eazel. If we go on "outsourcing" software that way, we might end up with a "GNOME desktop" which is not much more than lots of commercial free software bundled together haphazardly."

    link [gnome.org]

    Is their situation really this bad?

  • I think he is talking about a layer underneath the toolkit and DE environments where code could be shared. You know, compartmentalized, modularized tools done in the Unix way instead of a multitide of huge monolithic incompatible systems that you need to keep around to run all of your apps.

    Your attitude is sort of disturbing: "AT&T and The Open Group has bequethed to us POSIX and X11, and that is where the standard environment ends, now and forever, so sayth the lord". Well, this ignores the fact that commercial UNIX was a profound failure on the desktop, and the commercial UNIX players that devised this whole mess no longer have much interest in desktop computing at all.

    The future of desktop UNIX computing is now in the hands of Open Source projects, and they need to either work around the problems and legacy issues with the ancient 'standard environment' (particularly the gap between X11 services and DE services), or they need to move forward with defining an architecture that can maximize the utility of the system for the next 20 years.

    (Not to mention that your XML comment is entirely offbase.)
  • It is how X11 is defined. That's why I can use standard X apps with AcceleratedX or XFree without recompiling. If a standard API for the desktop environment was established (maybe pushed into X, maybe not. God knows that the XFree people have more clout than any of the commercial UNIX corps) then you could have all of the implementations and window managers and whatnot, without the incompatibiliy. Before GNOME and KDE, none of my apps cared what window manager I used. Starting with Enlightenment, apps started using DE-specific features, and the freedom to choose your environment went away.
  • Oh, real mature. Thanks for your insightful contributions to a problem plaguing the Linux desktop.
    "I can't think of a better idea than dozens of toolkits because my mind is too narrow to accept it. So I think I'll just trash an OS I don't understand!"
  • Right, I'm bitter. That's why I think that Gentoo Linux is the coolest thing since sliced bread, and that XFS is the creation of god. Get over it. I love BeOS, but Linux has so much potential, its just politics and small minds that's holding it back.
  • What are you talking about?

    A) It's BeOS, not BEOS.
    B) Win*dows* is multi-tasking and has better threading than Linux. Next question.
    C) BeOS has better use of threads and multiple processes than Linux as well.
    D) I have no clue what your point is. I said that background processes providing services don't necessarily degrade system performance. You just used it as an excuse to trash Windows and spread misinformation about BeOS.
    E) Do you know that your login-name is the same as the guy who wrote the famous Windows Programming Book (C. Petzold)
  • Its all subjective. Does an OS automatically become trash to you the first time you see the cursor jerk during a CPU intensive processes? I want to start and app and have it on my screen *now* no loading cursor, no nothing. KDE2 doesn't do that for me. While X overall is pretty slow, its not THAT slow.
  • Miguel explains [gnome.org] the apparent lack of activity:


    A lot of work is going into shifting towards the GNOME 2.0 platform,
    which is why there is a slowdown into hacking the "core" of the
    system. Most of the work is going towards making the 2.0 platform a
    great platform.
    --

  • You said: "..Both projects are extremely undocumented and very few, if any, have a complete grasp of the entire system in either case."

    How come? the KDE itself comes with a very good online manual, as well 52 languages localized version of all what appears on screens "menus, windows etc.."

    There is a book which you can either buy, browse on line or simply downloading it - to make KDE applications and the QT library itself has one of the best documentation I've seen outside Microsoft world - freely available.

  • A few comments. (Score:4)

    by miguel ( 7116 ) on Saturday February 24, 2001 @09:37AM (#406076) Homepage
    It seems that a few conclussions are drawn incorrectly in this interview.
    • Usability and toolkits. The fact that the GIMP has not a great user interface, does not mean it is caused by its use of Gtk+. Usability and good user interfaces are long tasks that require usability testing, reuse of good paradigms, and constant improvement. It is not a function of the toolkit as you like to present here.

      For instance, take Gnumeric: the best free spreadsheet available, the one with the most confortable user interface, pleasant to use and only surpased in functionality (but not in usability) by OpenOffice. Guess what? Gnumeric is fully written in Gtk+.

      Evolution is another good example: it has a great user interface, but some bits of usability are still not there, and we are working actively to do user testing to make sure we provide a better interface, but this has nothing to do with the underlying technologies (as you like to convenientnly present in your interview). It has to do with matching the "User view" with the application, rather than forcing the application model into users.

    • Bonobo and CORBA: I have repeated this a number of times, but it seems that people are not interested in facts, but more interested in doing marketing "their way".

      OpenParts (KDE's CORBA-based component architecture) failed for a number of things, few of which could be traced to CORBA, I will enumerate the ones i remember, for the sake of completeness:

      • The dependency on MICO: MICO was the biggest and slowest CORBA implementation around the block. GNOME used MICO for a few releases, and before GNOME 1.0, we had written our own thin and fast implementation to circumvent the problems of size and bloat associated with MICO. The KDE team chose to keep using it because MICO was "feature complete".

      • Incorrect programming practices: The C++ CORBA binding implemented by MICO is the one that uses the C++ exception mechanism to report errors during a Remote Procedure Call invocation. This is CORBA's way of telling you "there was an error while talking to the remote server, here is the reason...". The code in OpenParts and in KOffice at the time decided that it would make their code "ugly" if they had to check for exceptions, hence they ignored all exceptions, so code that should have looked like this:

        try {
        corba_object->method (x);
        } catch (...) {
        handle corba errors here;
        }
        Was actually written like this: corba_object->method (x); Of course you get "unreliable" code if you do not handle errors. (btw, notice that most security holes on BugTraq a few years ago were all caused because people did not handle boundary conditions correctly, nor handle errors from Unix system calls correctly.

      • Complex and big interfaces: The "base" interface in KOM had something between 17 to 23 methods, a pretty large interface. The "base" interface in Bonobo, COM, UNO and XPCOM is only three.

    • Bonobo and GNOME: Bonobo 1.0 is shipping as part of the upcoming GNOME 1.4 release. And it is the building block used by Nautilus and Evolution. Various applications support Bonobo already and they can integrate directly with Nautilus and Evolution (Indeed, OpenOffice integration with Bonobo is being demoed at every Linux show at the Sun booths where you can see Bonobo/OpenOffice integration being demoed).

  • Pentium II 350, 64MB RAM, KDE 2.1 CVS from 3 days ago..

    time konqueror:

    real 0m1.898s
    user 0m1.360s
    sys 0m0.030s

    Well, I consider it pretty fast thank you
  • Although I'm not a KDE developers, but at work we have a guy who is running KDE 2.1 on an old Toshiba Notebook - Pentium MMX 233 with 64MB RAM, and it runs pretty fast on it. Heck, he browses while he is compiling the other packages (kdemultimedia, kdenetwork etc)...

  • Re:State of the GNOME project? (Score:5)

    by miguel ( 7116 ) on Saturday February 24, 2001 @09:55AM (#406080) Homepage
    No, the situation is not as you picture it. I think you should have also put links to the various follow-up articles, in which we explain what is going on in GNOME.

    The following links might be interesting to read:

    1 [gnome.org], 2 [gnome.org], 3 [gnome.org], 4 [gnome.org].

    Nautilus --which has a large set of developers and a lot of work going towards it-- is really one of the core components of the desktop. I am sorry for Alan if there are not too many hackers working on new IRC clients, or on new color selectors, I think that overall, we are more focused on the problems of users than we were in the past.

    Components like Evolution [ximian.com] contain some killer features that will help a lot of people transition to Linux, and the kind of work and effort required to develop an application of this size is not trivial. Just supporting every feature correctly for IMAP and broken IMAP servers is a daunting task. Having the best syncronizing tool for PalmPilots and for syncing multiple devices is also an important feature not available anywhere else (not to mention vFolders, quick searches, great user interfaces and more).

    Both applications (Nautilus and Evolution) rely on very new technologies that are at the core of GNOME

    Also, look at things like the Ximian Setup Tools, which are just a set of GNOME applications (branded by my company, to get some credit for the work we are putting on it) that addresses the major problem of having a user-friendly unified system configuration for Unix (here [ximian.com])

    Our work on the Bonobo foundation is unparalleled. Once we started deploying it, many new ideas came out (like Monikers [ximian.com]) that have enabled extremely powerful mechanisms to be created.

    We sadly do not have white-papers for all of our technologies, but we are working towards documenting them. If you are interested in helping, get in touch with me.

    A few things we have recently done and are shipping as part of GNOME 1.4:

    • Bonobo 1.0 Ready to ship with GNOME 1.4

    • GtkHTML: An HTML editor and rendering engine.

    • EBrowser: A Bonobo component to do web browsing

    • Gnome Spell: A Bonobo component for doing spelling, suggestions, and dictionary lookups. All available to any application that supports Bonobo.

    • Gnome VFS: Access any resources on the network transparently.

    There are a lot more technologies comming down for GNOME 2.0, and you can read about some of them at: http://primates.ximian.com/~miguel/gnome-2.0

    Other things like Gtk from frame buffers and Pango are developed at the RHAD Labs (http://www.labs.redhat.com) and constitute part of the core technologies in GNOME 2.0

    Miguel.

  • Good interview - short and to the point, easy to read in 10 minutes.

    Anyway, here's my $0.10:
    Andreas Pour has got a good point about the development tools for KDE versus those available for GNOME. Have you guys seen KDevelop [kdevelop.org]? As someone who actually develops GNOME programs, i can tell you that KDevelop does look about 10 times better than GEdit - built in dialog construction tools (a la GLADE), a quick start (read: RAD) wizard, and more!

    Shit, i'd kill for this tool in GNOME/GTK...

  • Just out of curiosity: Are you actively working on either project?

    If you are, good for you, but if not ... If everyone on slashdot who insists on posting "Linux needs such-and-such" would actually start coding (or doing whatever else their skills permit), we'd have all the problems ironed out in no time.

    It seems to me that people who spend their time whining about open-source projects are missing the point. The programmers wrote this for themselves (in some manner, whether it's that they want the functionality, or just the prestige.) If you like what they've done, you're welcome to it, but if not, you're the one that should be doing the work.

  • There are several reasons for this speed difference. First Windows Explorer doesn't do a tenth of the stuff that Konqueror does. Combine Windows Explorer, Internet Explorer, make sure none of it is in kernel space and not already running in the background somewhere, give it an advanced widget library, and then see. I bet that Konqueror would kick Windows butt all day long.
  • If you're using binary packages from your distribution, most likely you are getting the lowest common denominator optimization. In other words, nothing.

    Recompile X, Qt and KDE optimized for your system. I use "-O2 -mpentium" for all of them, and --no-g++exceptions when configuring Qt. The speed improvements are amazing!

  • KDE2 makes a wonderful desktop (Score:3)

    by commander salamander ( 256114 ) on Saturday February 24, 2001 @10:25AM (#406087) Homepage

    I've been using KDE 2.01 (XF86 4.0.2) combined with kernel 2.4.1 for about a week now, and the combination far surpasses anything I've experienced on Windows or Mac. Its fast and stable (I compiled everything from source...those of you compiling QT 2.2.4, try ./configure --no-g++-exceptions, it speeds things up a lot), plus everything works the way one would expect. No nasty surprises like with GNOME...the KDE guys spent a lot of time on fit and finish, and it shows. My Matrox G450 does DualHead (using Xinerama) beautifully...plus, with Xine and libcss, I can even play DVD's!

    I'm really excited about where this project is headed. In my mind, the Windows 'standard' has already been surpassed.

    Click here for a DVD on Linux HOWTO [linux.com]

    --------------
  • Even if it was integrated into the kernel, so what? I'm sure I'll be labeled as a heretic (what else is new), but the DOJ's emphasis on integrating IExplorer into Windows was absolutely stupid. They could integrate MSOffice right into Windows kernel space and I wouldn't care.

    Microsoft's business practices are the problem, not their technology, and especially not their sophmoric attempts to improve it.
  • No, Motif forces you to use a standard implementation as well, not to mention the fact that its butt-ugly, and until recently, closed-source. There should be a standard API ala Motif, but not a standard implementation of that API (kinda like OpenGL, the actual implementation is system-dependant)
  • How said BeOS is better than Linux? I said "BeOS does threading better than Linux." If you've ever seen BeOS on an 8 proc machine, that's just plain true. BeOS also has quicker system response times, a faster graphics interface, a nicer, more consistant API, and innovative features up the wazoo (attributes, messaging, etc). Still, Linux has better (if not faster ;) desktop environments, a better filesytem (XFS: like BFS, but bigger and faster!), less limitation in the kernel (32MB add-on limit in BeOS, 256MB library limit), better networking, and just plain more *stuff* (features and programs).
  • The fact that the GIMP has not a great user interface, does not mean it is caused by its use of Gtk+.

    Amen! I was a bit stunned when I read Andreas mumbling on about GIMP. I am one of the biggest Qt bigots out there, but the problems with GIMP are not the fault of GTK+.
  • KDE-2 is faithful to the Unix philosophy. The command line is not taken away from you. You have a great terminal with Konsole, you can but a mini Konsole on the panel, pop up a mini Konsole with Alt-F2, attack a Konsole to Konqueror, and so on.

    Unix is about small tools doing one thing well that you can join together. This is still present in KDE. The window manager is small and simple and does just one thing. Ditto for the panel, the default editor, the terminal, etc. With KParts and DCOP you can start pluging them together in ways that Redmond can't even imagine. Konqueror is basically nothing more than a viewer with tons of plugins available for it.

    It is the *user* who decides how simple or complex the desktop will be.

    As for its "Windows look-alikeness", I don't know. Because I haven't used Windows since '95. And my desktop doesn't resemble or behave ANYTHING like Win95. Not at all. No way and no how. Sheesh...

  • efficency and new ideas (Score:4)

    by chompz ( 180011 ) on Saturday February 24, 2001 @10:49AM (#406097)
    I am often amazed by how quickly kde/gnome development occurs, considering how many developers there are and how many new ideas they implement.

    However, if these two projects were merged it would not work. They have many fundamental differences, differences that would nearly require one project to be completely dumped. We all agree that this would not be a good thing.

    I am a KDE user, and I am damn proud of it, but many of my friends use gnome, which is thier preference (its too slow for me).

    The competition between the two projects has had an effect on each of them, encouraging adoptation of similar ideas, and generation of new ideas, ideas which might not have made it into the source code otherwise.

    The competition between kde and gnome is a good thing, even if both groups didn't care about the existence of each other, it is nice to have more than one option.

    Those of you calling for a merging of kde and gnome, think about this, what if we merged the linux kernel and a bsd kernel. It probally wouldn't work for a few years. Think about it.

  • I don't like Ford cars. I don't like General Moters cars. I like Jaguars. Does this mean we should have totally seperate road systems for each type of car? Competing implementations + open, FORCED, standards (kinda like the road system?) is the best way to do things.
  • I'm not the original poster, but I want compatibility as in I can erase GTK and GNOME-libs and still use GIMP.
  • Ah, but all programs run on all shells. Using csh doesn't preclude me from running XFree86. Using KDE (and ONLY KDE) precludes me from running GIMP.
  • Ensure that the kernel was compiled for i686.

    Use hdparm to make your hard drive load faster. This is one of the most common problems. hdparm -d 1 turns on dma which is the most important. also fool with the -m parameter. so man hdparm for details

    64 megs of ram isn't that wonderful for KDE or GNOME, but i suppose there isn't much to do about that...

  • Comment removed based on user account deletion
  • Tell me: what extra functionality do I get when I use Gnome instead of editing files by hand? Mostly I can fetch a certain option faster in a config file than clicking through loads of windows?

    You state that the "standard nowadays" requires 128Meg. I think you're wrong.

    I'm completely productive, producing my documents in LaTeX or just plain text, editing files with Vim (which has neat syntax highlighting and loads of usefull features), and using Windowmaker as my windowmanager (which works perfectly, can't see any usefull improvements which could make it better).

    With all respect, I've been through a lot of horror learning all these tools, but I just know I work a lot more effective using only these tools.

    I was wondering: where is the UNIX spirit? You say UNIX desktop environment, but I can't see a use in going for them. And yes: the only thing I needed GNOME for was a divx player (which for some strange reason needed the GNOME libraries, while it would be much more effective when ran with GTK libraries).

    I'm using this configuration as my *primary* configuration for around one year (sometimes switched windowmanager, but never to KDE or GNOME).

    My daily stuff: mutt for mail, tin for news, ircii for irc, vim for editing, LaTeX for document processing, Gimp for editing, Blender for 3D content, Netscape (bloat) for websites, Windowmaker for keeping my windows apart, mpg123 for some music, apache for hosting our website and this all on 64 MB ram. Ah, did I mention Sendmail?

    Are these programs impossible to learn? IMHO, no. It just takes some time, and some programs have quite a high learning curve, but they can be learned. And it's really IMVHO that these tools are more flexible and productive than any KDE or GNOME app I've seen around.

    This is my bit of view on this subject, feel free to argue.
  • I'm using the RH6.2 binary packages for KDE 2.1beta2 and have experienced the same problems throughout my the kde2 releases. Very likely much of the core components were compiled without sufficient optimization but that can't really explain all of it. I noticed that URL type autodetection appears to be obscenely slow, specifying "kfmclient openURL http://slashdot.org text/html" appears to be faster.

  • It would be a problem if QT used exceptions. I'm not sure why it was written that way, maybe performance reasons, but it doesn't use them a all.

    It is most certainly for performance reasons. Every time you use a try{}/catch{}structure, the computer has to keep track of every possible exception that could possibly be thrown, know which ones are caught and which ones are passed up the call stack, and have code to jump to the exception handlers for every function call that could throw. It eats up a lot of memory, which causes performance problems in graphics libraries like Qt.

    Also, not all C++ compilers are equal. There are a lot of systems out there with older compilers that have buggy, slow, or nonexistant exception handling. Qt has to work on those systems as well.

  • Actually, I think Mozilla's performance is more related to the fact that the browser is actually written in JavaScript. Also, the scope of Mozilla is much, much bigger than Konquerer. Mozilla is its own XML-based development environment. It has its own object model, it's own widget set, etc. Whether this is a good idea or not, I don't know, but that is more of the cause of these problems than language choice. Also, the fact that Mozilla is extremely cross-platform, including its own portability library makes the fact that they've done so much in so little time, absolutely amazing.
  • I have it on good authority that the interview was edited (as is usual in these kinds of things).

    Do you honestly believe Andreas would have said something like "The whole desktop rarely crashes, but you'll have some applications crash, like the browser Konquerer, which is the centerpiece for KDE 2."?

    (as an aside, I can't remember the last time
    Konqueror crashed. it is no doubt the best of
    the best at this point.)
  • I want to erase GTK as well. I want to have a 100% KDE-only system. How can I do that?
  • I would complain. Apps shouldn't require a particular toolkit, but should require the services of that toolkit to be available. On Windows, no app depends on having MS-OpenGL available, but having SOME OpenGL implementation available. Qt provides all the services available in GTK+, so GIMP should work transparently on Qt. Whoa, what a concept! Too bad whoever made shared libraries thought it up first...
  • Actually - you don't need Xinerama with KDE 2.1 at all..

    DOwnload the Matrox driver for Linux for true dual head, and use KDE 2.1 - it got NATIVE support for Dual head, so all the popups windows comes in the screen that your application is running and NOT in the center of the screen like Xinerama does.

    Also, you'll get 30% speed increase (thats what Xinerama takes)
  • It's not the 10-20MB of diskspace that bothers me, its the 10-20MB of memory. All together, a fully loaded system takes up 30+MB (KDE-1, KDE-2, GNOME, and soon GNOME-2!) Even on a 128MB system, that's just too damn much for the OS to use up. The OS shouldn't use anything more than 10% of avaiable memory, after that its just sick. Not to mention the fact that while GNOME apps run on KDE, you don't get the full experience provided by a "desktop environment." While hacks to load KDE components on GNOME or run GNOME applets in KDE are available, they're just hacks, nothing more.
  • I was using the Mandrake packages. Plus, why do binaries all optimize for 386, with some exceptions optimized for Pentium? Given that everybody has at least a Pentium-class chip (and P6 chips have been around for five years) shouldn't -mpentiumpro be the standard optimization, with some special distros cataring to the 386 crowd? What moron runs KDE2 on a 486 anyway? Thankfully, distros like Gentoo exist (yea, my obsession of the day ;) that (will) optimize for Pentium Pro. Check them out at this site [gentoo.org]
  • It is not even an expecially big task - qt is only some 20000 lines of code, for example.

    The qt distribution is 506408 lines of c++. The core library is 351371 lines (Qt 2.2.3). You're off by a factor of 25.
    Just to compare: kdelibs + kdebase is 593924 lines of code. (week old cvs cnapshot). Qt is a fairly large library. Good thing it's welldesigned.

    Sheez. You clearly do not know what you're talking about.

    -henrik

  • I used to run a system with 64MB using Windowmaker capable of all those tasks. I was even using GNOME for awhile on the same system and didn't encounter many memory related problems, except Netscape would occasionally memory-leak (which plagues my current 128 mb system all the same.)

    If you can get by with your current setup, fine. I certainly wasn't saying and/or implying it's essential to run something like KDE or GNOME. Also, I agree there are not many useful apps specific to KDE or GNOME, Konquerer being the obvious exception. I do think, though, that people should try to be realistic. No one working with KDE code *can* make much of a change in the memory requirements. It's just the nature of KDE. There is a lot of overhead.

    128MB is pretty standard, anyway, and with memory prices what they are I don't think my suggestion was in anyway outrageous even with regards to the most conservative of spender.

  • I really want to know something. How are you posting at +2. I read /. @ +2 and I keep seeing you drivel all the time. I thought the mod system was meant to prevent this... Quit posting 20 times to a thread @ +2 when you have nothing useful to say.
  • There is another reason why the two will never merge that I haven't seen mentioned yet. There are technical reasons of course and they have been covered a lot but what about money?

    The biggest difference I can see between Gnome & KDE currently is: One is an open source project that accepts donations of programmers and hardware, the other is an opensource project coded mainly by companies with a large commercial interest.

    I don't want this to sound like flamebait but it does doesn't it? Sorry for that I re-wrote this twice and this is the best I could do. I'm not a zealot of either desktop enviroment and they both shine in certain aspects but I am worried about Gnome losing developers because of this.

    I'll put it another way; Ximian's core product will either be Ximian Gnome or very dependant on it. Ximian are a company and are out to make money, they will be making profit off other developers work. Is Gnome destined to become another Mozilla?

    Anyway, the biggest difference I can see is not technical but financial, this makes it very doubtful any merging would take place and maybe that's a good thing.

  • See, I don't know. I tried KDE 2.01 and I went back to GNOME. Why? KDE does not look and feel as good.

    The following points are only my observations and may only apply to me.

    1. All of its default icons are too big. We need *SPACE* between icons. The GNOME ones look right for me.

    2. Icons again. They look like they're created using 16 colours and they look too "hard" with all the hard borders and clear-cut colours. I'd like them with soft edges and a slight soften filter applied all over the icons. They're just easier on my eyes.

    3. The menu bar. Those menu buttons are too close together. Compare the menu bars on QT apps with those on Motif and GTK+ apps and you'll know what I mean.

    4. There are no real way to disable the maximize-minimize animations, which really suck - no, making them really fast doesn't count.

    5. Can I be given a windows manager which is more flexible and scriptable, like Sawmill? I do not like being given a set of fixed functionalities. I sometimes make my own to suit my needs. Does the wm in KDE 2 have a window matching feature? Maybe it's just me but I couldn't find anything like it.

    I'll use a desktop with more competent artists. GNOME is currently it.

  • You saw through me 100% it was just an attempt at flaimbait, it wasn't an effort to point something out that had not been mentioned. I didn't realise Ximian is a charity, I hope I haven't offended them.

    I am very jealous indeed, as you told me I don't contribute anything (really don't I?) all this time I've not been contributing and I've not got paid a penny for not contributing. No wonder I'm jealous.

    Now, sacasm over. I wonder what interests you have here, my post touched a nerve by making two statements that you highlight:

    "The biggest difference I can see between Gnome & KDE currently is: One is an open source project that accepts donations of programmers and hardware, the other is an opensource project coded mainly by companies with a large commercial interest."
    This is a true statment. Its fact.

    "Is Gnome destined to become another Mozilla?"
    Your comments reversed fit well here: ...just like Gnome is mostly written by Ximian employees, Mozilla is mostly written by Netscape employees but the fruits of their labor is available to all.

    Honestly, there is nothing in my post to warrent such a childish responce, intellgent debate maybe but not that rant and lame and plain incorrect personal attacks. Think for yourself, open your eyes, don't be a slave to your beleifs I must say it was entertaining as I laughed my head off at this "Miguel De Icacza founded GNOME and started a company just so he could afford to give away GNOME", I'm sure that is exactly what he told the venture capatists before they invested in Ximian.

  • Miguel, Every time the argument against CORBA on the desktop comes up you quote the same example from KDE. We've discussed this issue to death but you still seem to ignore the other side's argument. Your code example of is the correct way of responding to corba exceptions. The problem is that code like that becomes very tedious when you pretty much KNOW that you're indeed dealing with local host invocations. You still need to handle those stupid marshalling exceptions even when you know for sure that they will never occur because desktop objects are very rarely used in a remote context. Anyways I've had a few flamewars about this with you already and I'm not trying to start another one but like it or not CORBA was designed with distributed environments in mind and trying to use it on a local setup is stretching the technology.

    BTW. Last time I looked at Bonobo it looked much more like COM than CORBA. Sure it uses CORBA's IDL but all the QueryInterface stuff is a dot for dot clone of M$ COM. How much CORBA is there really in Bonobo?

  • From the same thread.


    Finagle's First Law
  • Manufacturers of non-clunky desktops have cognitive psychologists, physiologists, and experts in other interface-related fields at their disposal.

    A cognitive psychologist is someone that teaches you to change your thinking about something that you're miserable about. Do Microsoft have a special hotline to them when Windows BSODs for the 5th time that day?
  • At a certain level of karma you automatically post at +2, like I do, unless you choose not to.
  • Comment removed based on user account deletion
  • That's the biggest bunch of BS in the world. Wasted memory is wasted memory. I have no problem with Linux using 90% of my memory to cache my disk, but when it has to use 30-40% to cache the 30MB of graphics binaries, that's a problem. The problem isn't that Linux is caching those binaries, the problem is that the binaries are 30MB in size!
  • Widget libraries are ultimately the choice of the programmer.
    >>>>>>>>>
    That's the problem. If UNIX were really about empowering the user, developers shouldn't get to make these decisions. If developers were forced to write to a standard API (OpenGL, for example) then the user could use whatever implementation of it THEY wanted.

    The "right" widget library will depend on a range of factors, from what language you're going to use to the range of features you need.
    >>>>>>>>
    Easy to fix. Design the standard API well, and include lots of language bindings. OpenGL does both.

    There's nothing you can do to get programmers to standardise on a single library, because no single library, not Qt which is C++ specific or GTK* which has a much more procedural outlook, not the various other ones, will ever be the "perfect" catch all does all library.
    >>>>>>>>>>>>
    Sure you can. The X people seem to have done a pretty good job of tying everyone to X. You just have to make sure that all the nifty features are available through that toolkit only. If the standard API were added to X, most programmers wouldn't bother to use a seperate toolkit (just like most programmers don't bother to use toolkits like OWL on Windows.)

    PS> MFC realy isn't applicable here, it is more or less a "standard" API for Windows in addition to Win32.
  • Turning on P6 optimizations (on VisualC++) makes my graphics library run 20% faster. I'd say that's quite significant.
  • Comment removed based on user account deletion
  • 1. There have been three attempts to create standard widget libraries for X, Athena, OpenWindows and Motif. Of the three, the first quickly became obsolete as time wore on.
    >>>>>>>>>
    I said standard API. Not standard toolkit. Nothing precludes an API from growing and expanding, and having new toolkits implemented under it. OpenGL (and more so, DirectX) is an excellent example of a standard API that has evolved through many revisions and implementations.

    What makes you think that GQt, or whatever your hybrid interface is to be called, wouldn't suffer the same fate?
    >>>>>>>>>>>>
    Because it would be an API, not a toolkit. It would specify a certain set of services, and whatever toolkit the user wanted could supply those services.

    2. Saying that programmers should not be allowed to use toolkits other than the one you desire would, even if possible to implement, have a devastating effect on the programming community. You have to produce toolkits that do what programmers want out of them, or else face not having those toolkits available.
    >>>>>>>>>>
    Doesn't seem to be much of a problem on the Windows platform. Sure, there is MFC, OWL, VB, etc, but all of those wrap around the same set of Win32 services. An MFC app can exchange clipboard data, objects, whatever, transparently with a Win32 app. The same is not the case with the thousands of *NIX toolkits.

    3. MFC is relevent here. It's an alternative API. There are several APIs for programming Windows' GUIs, many of which originate from Microsoft themselves, and many of those are optional.
    >>>>>>>>
    MFC isn't relevant. Its not an alternative toolkit, but a wrapper over the same Win32 services.

    MFC is standard only insofar as the creator of the operating system has declared it such.
    >>>>>>>>>
    Believe it or not, that's a good way to make it "standard."

    It happens to be, according to most programmers I've talked to who use it, a very good API, and MS's Visual C++ encourages the use of it. It's become popular for that reason.
    >>>>>>>>>>>>
    MFC is a bloated piece of crud. Everyone I've talked to agrees, unless of course you're talking to the "wizard" crowd. (If you need something quick, use a quick language, but for god sakes don't use MFC!)

    In conclusion: It seems to me that the demand that programmers be forced to use a particular toolkit for all their GUI programming is unworkable, unreasonable, would contradict standard practice on every other platform
    >>>>>>>>>
    99% of Win32 apps call the same toolkit functions, whether they are wrapped OWL, MFC, etc is irrelevant. They are not incompatible in the way GTK+ and Qt apps are.

    And to what reward, the ability to save a small number of megs of RAM that, as a percentage of the whole OS, is practically insignificant? Much as I abhor code bloat, I have to say that the price is not worth paying.
    >>>>>>>>>>>>>
    A) Given the current situation with GNOME and KDE, your way doesn't seem to be working, does it?
    B) It's not just code bloat, its platform fragmentation. KDE/Linux is not the same OS as GNOME/Linux, at least not for a modern (ie. takes advantage of DE features) GUI app. MFC/Windows and OWL/Windows is. I'm not even saying that the Windows way is the best way to do it, though it's better than the UNIX way. The OpenGL way is the best way to do it. Define an ABI. Then, make both sides replacable. With OpenGL, I can use Java to call NVIDIA's implementation, or use Delphi to call ATI's. All while still having access to the same set of services, and all while interoperating perfectly with apps whose developers didn't make the same decisions as me. That's real good design.
  • Comment removed based on user account deletion
  • You're trolling aren't you?
    >>>>>>>>>
    Much as you'd like to belive that, I'm not.

    If MFC is "just a wrapper" for Win32, then GTK and Qt are "just wrappers" for X11.
    >>>>>>>>>>
    No, MFC really IS a wrapper. It doesn't do much processing at all. GTK and Qt do their own text drawing, (GNOME and KDE) manage their own clipboard, they have their own printing services, etc. MFC (and presumably OWL) is just a C++ wrapper just makes calls to Win32. It doesn't define any services of its own. The difference is that GTK and Qt implement their own services and define ones not part of standard xlib. MFC doesn't.

    Similarly, you can run an app under X written using GTK. It will happily share clipboard data with an app
    written using Athena. Or Qt. Or OpenWindows. Or whatever other standard widget set and toolkit you care to
    mention. And no, not any of these toolkits shares an API.
    >>>>>>>>>>>>>
    Let's see. I can implement a component written in VBScript into an application written in MFC. In the next iteration, the application could move to straight Win32, and the component could move to MFC. Everything still works, hell, I don't even have to know *what* language the component is programmed in. Let's see GTK+ and KDE do this (without hacks!)

    The API of MFC is not the Win32 API. It merely uses Win32 based operating systems to implement its
    functionality.The API of MFC is not the same as the VB API.The API of Qt is not the same as the XLib API. It runs over the top of it, making use of XLib to implement its functionality.
    >>>>>>>>>>>>
    Qt and GTK (and to a much larger extent GNOME and KDE, what this debate is about) implement their own features independant of XLib. Hence the X-less Qt and GTK ports. MFC doesn't do much of anything except make calls to standard Win32 functions.

    And, as if it needs to be said, Qt's API is not the same as the API of GTK. I don't see how you can argue that the situation with APIs and widget sets is any worse on X than it is on Windows. It's exactly the same.
    >>>>>>>>>>>>>>>
    A) The situation is different. See above cogitation.
    B) Even then, how is being the same as Windows remotely near being good?

    As for pulling OpenGL into everything, there are, as I said, standard APIs out there, normally defined as defacto standards, for X11. They include the three I've already mentioned. They are Athena, OpenWindows, and Motif. Of these, I've seen at least three Athena (the original, the 3d one, and the NextStep one) implementations, OpenWindows never really took off so never gained much support (and was open source anyway so there was little point in writing a new version), and Motif has at least two (Official Motif and Lesstif).
    >>>>>>>>>>
    Funny. OpenWindows "never really took off" yet its somehow a "standard"? No matter what, everything you've just mentioned is entirely irrelevant to Linux. None of the interesting apps coming out use Motif, Athena, or OpenWindows. Besides, decreeing "one standard toolkit" is not what I want. I want a binary standard for toolkits. Different APIs can plug into that binary standard and make calls to different implementations supporting that standard and everything just works. That's how OpenGL does it, and it is Good(TM). Maybe I should have made that point clearer.

    Trying to play with words and call them toolkits rather than APIs doesn't change the fact that they're as implementation independent, well defined, and open, as OpenGL is.
    >>>>>>>>>>>>
    But it also doesn't change the fact that people actually USE OpenGL, and (on Linux anyway) nobody *uses* the "standard" APIs. And while the toolkits maybe be implementation independant (theoretically) the one alternative implementation of the three toolkits you mentioned (Lesstif) lies in stark contrast to the dozens of (compatible!) implementations of OpenGL. There is really no comparison beyond the very basic.

    Finally, what do you mean by "your way doesn't seem to be working, does it?". I can run Qt apps and GTK apps
    on my machine without having to run GNOME or KDE.
    >>>>>>>>>>
    But do they look the same? Do they interoperate perfectly? Do they respond to the same configuration programs? Do they use the same themes? Do they work with the same applets? If so, please tell me what versions you're using!

    Response times are excellent, and this is on a 32 meg
    laptop.
    >>>>>>>>>>>>
    Then your standards are set to low. Nothing, not even QNX or BeOS, has "excellent" response times on a 32MB laptop. On my machine, (300MHz PII 128MB RAM) GNOME runs "decently." KDE-2 runs inexorably slow, NT-4 is snappy, and BeOS runs like a bat-out of hell.

    What definition of "working" are you using? Certainly, by most people's definition, being able to run two
    programs at once without, most of the time, even caring which widget set it uses, would appear to me to be
    "working".
    >>>>>>>>>>>>>
    Maybe I should have said "working well." Like most people, I make no distinction between the two.
    A) Strike "most of the time" from your vocabulary. I *never* have to worry what WRAPPER a Win32 program is written in (hell, I don't even have to worry what LANGUAGE its written in) and I should have to worry on a supposedly superior platform like Linux.
    B) I want it to interoperate perfectly. I want it to take zero memory. I want it to predict what I'm going to do. High standards yes, but right now Windows (and some other OSs) are a lot closer to it than GNOME/X/KDE/Tk/Athena/Motif/GTK/Qt/FLTK/GNU/Linux.

    As for your additional rantings, I get high quality software on Windows without running dozens of libraries. This is mainly because you're "right tool for the job" BS doesn't hold water, not on Linux as it is today. Qt and GTK (and GNOME and KDE), both progmatically and functionally equivilant. One may prefer one or the other, but one will develop appreciably better on one or the other. There is some use for some of the smaller toolkits, but in that case, methinks it would be better do get something like VBScript (isn't Linux supposed to get a Kylix port?) and keep the total toolkit count to an absolute minumum. The number of toolkits on UNIX is currently much larger than necessary to support "right tool for the job" and the inherent uninteroperability of the toolkits just exacerabtes the problem.

Slashdot Top Deals

"Confound these ancestors.... They've stolen our best ideas!" - Ben Jonson

Close