Slashdot is powered by your submissions, so send in your scoop

 



Forgot your password?
typodupeerror
GNU is Not Unix

Richard Stallman On KDE/GNOME Cooperation 411

Posted by timothy
from the getting-along-is-the-whole-point dept.
Karma Sucks writes: "For the first time that I remember, RMS is encouraging collaboration between the GNOME and KDE projects. He offers a concrete idea: Unifying the themes between KDE and GNOME. Matthias Ettrich once went far enough to propose a default unified 'Linux' theme that both Qt and GTK+ could support."
This discussion has been archived. No new comments can be posted.

Richard Stallman On KDE/GNOME Cooperation

Comments Filter:
  • kde-look.org (Score:4, Informative)

    by The Great Wakka (319389) on Monday February 18, 2002 @05:34PM (#3028861) Homepage Journal
    I've never heard of it before. I would have posted themes.org as the link. But that's me. kde-look is a very nice website, but is there a GNOME equivalent?
  • Hoping (Score:2, Insightful)

    by TheMatt (541854)
    I really hope this will happen. There are so many apps that each has, that a KDE-Gnome work-together would be great. For example, I would love Konsole in Gnome and Galeon in KDE...with the stability they have in their native setting.

    Plus, it always seems KDE looks better than Gnome, though I don't know why. Just my opinion.
    • Re:Hoping (Score:3, Informative)

      by avalys (221114)
      Why would you have stability problems running KDE apps in gnome, and vice-versa? They're only X-Apps - konsole, gimp, and the rest couldn't care less what window manager/desktop environment/file manager/web browser you're using.

    • "For example, I would love Konsole in Gnome and Galeon in KDE..."

      Did you... ever try Mandrake? I think your dream has been a reality for a while.
    • KDE has supported GTK themes for a long time now.

      http://www.kde.org/announcements/k3c-announce.ht ml

      In addition to native KDE2 themes, we are pleased to announce that KDE now supports pixmap GTK themes. For importing a GTK theme into KDE, you just need to use the 'klegacyimport' wizard, available as a little standalone GUI application. However, while GTK themes are displayed faster and more efficiently than even native GTK itself, we do not recommend using this format for creating new themes. Theme developers should prefer KDE2's native widget theming which yields superior results both in terms of quality and speed. A nice HowTo and some documentation on KDE2 theming is available here.
  • Woah (Score:3, Funny)

    by mosch (204) on Monday February 18, 2002 @05:38PM (#3028876) Homepage
    Woah now, I know RMS is considered to be an important fellow, but this is a crazy idea. Come on, cooperation between KDE and GNOME? What crazy idea is next, a free flow of information and help between BSD and Linux?

    Oh wait, my bad, this idea is so obvious it's rediculous. Does anybody have a valid reason why it hasn't happened already?

    • Re:Woah (Score:2, Troll)

      by scott1853 (194884)
      I think the answer to your last question can be summed up in one word. Ego.

      Yes ego. It's not just for the criminally monopolists =)

    • Oh wait, my bad, this idea is so obvious it's rediculous.
      Then why haven't you patented it already? Hurry, before someone else does!!
  • by gadfium (318941) on Monday February 18, 2002 @05:38PM (#3028877)
    Ideally, I'd like to see as many applications as possible running under both environments. With most Linux distributions currently, the libraries for both environments are supplied. I'd like to see this become standard, and I'd also like to see an interface library developed in collaboration which will translate calls to either gnome or kde, depending on which is running. This library would have to be primarily written in C++ to suit the existing QT/KDE application base, but would also need to have C and other language bindings.
  • Wow (Score:2, Insightful)

    by mikeage (119105)
    I honestly fail to see how anyone could disagree with this. A common interface to help newbies, and retaining the customization power that makes linux great... just don't make it another OS X ripoff.. PLEASE!
    • Re:Wow (Score:2, Informative)

      by Yorrike (322502)
      I'll say.

      Yes, the whole "my desktop is liquid" look is trendy at the moment, but I think there definitely needs to be a super-sexy not-found-elsewhere none-ripoff default theme for both KDE and Gnome.

      Just take a brose through something like the GUG galleries ( This for example [sunsite.dk]) and imagine these works as entire themes.

      In the same way that flashy graphics make people buy video games, KDE and Gnome need to attract the masses with sex appeal.

    • Re:Wow (Score:4, Interesting)

      by zhensel (228891) on Monday February 18, 2002 @06:25PM (#3029137) Homepage Journal
      Actually, there's a pretty simple argument against this. Standardizing the desktop stagnates innovation. With a standard "Linux" desktop, all distributions for a good amount of time will have to follow that standard or face alienating their users. Look at how little the MacOS interface changed before OSX and how only with Windows XP has Windows had a major interface revision - and even now it is still heavily rooted in the framework of prior revisions.

      Personally, I agree with you and think a standard would be a good idea. Taking a step away from rapid developement and making a single stable interface would do wonders for acceptance. Besides, you can always have easily accessible information on configuring your interface how you like it. Still though, the arguement against this is pretty obvious.

      I'd probably say that the best idea would be for some group to go and dedictate a year or so to making the be-all-end-all of interfaces. Not some wierd hybrid of previous interfaces like most distros ship now, but something that is simple, elegent, etc. Other people have said it, and I'll repeat - like the OSX interface. I'm not saying it's the most efficient, but it consistently does what you intuitively expect it to do. That's what a defacto Linux "theme" would need to do. The only other option, I suppose, is just to copy Windows or OSX or another highly developed/researched interface. There simply exists nothing right now that would make sense to call the default desktop.
      • "how only with Windows XP has Windows had a major interface revision - and even now it is still heavily rooted in the framework of prior revisions"

        Somebody doesn't remember Program Manager.
      • by hexix (9514)
        Just out of curiosity, did you read RMS' post?

        He was not talking about a standard look, he was talking about a standard for writing themes. So that a theme written for gtk+ would work fine with qt, and vice versa.

        This would fix the problem of some programs looking different then others. Well, most programs.

        • I was replying to this -
          "Matthias Ettrich once went far enough to propose a default unified 'Linux' theme that both Qt and GTK+ could support."

          There wasn't any link provided to back that up, so I took it as is.

          And no, I didn't read the RMS post. That's why I didn't comment on it.
      • by maggard (5579)
        Look at how little the MacOS interface changed before OSX

        Really? Actually there were many changes into the Mac UI. There were watershed events like the introduction of the Platinum look but along the way many tweaks were rolled out also:
        (apologies if I don't know the proper terms)

        • Collapsable "Windowshade" widget and action
        • Drag-to-a-bottom-tab windows
        • Tear-off task switcher
        • Pop-open folders for drilling-down
        • Navigation Services
        • Heirarchical Apple Menu
        • The still-born Themes & sound-sets
        • The applet-bar (blanking completely on the name)
        • Adoption of Alt-Tab for task switching
        • The fully keyboard-navigatable desktop
        While they weren't jarring in-your-face changes they were all significent changes and certianly not symptomatic of a moribund UI.

        • Yes, there were a heaping handful of incremental changes that admitedly vastly improved the UI. The fact remains though that the original UI was painstakingly designed so that it didn't need a really major revision until just now. I don't think that anything exists like that now for Unix (unless you count work heavily derived from an existing UI).

          I suppose that my comments on the Windows and Mac UIs could easily be seen as saying that they are horribly outdated, but that's not what I intended. I meant that if you decide on a standard now, you'd better be willing to stick with it for five or more years. It should have the extensibility that the win95 and original macOS UIs had as well so that it could evolve over time yet still retain the same basic methods for achieving different things - the same metaphores if you want to follow Stephanson...
      • I'd probably say that the best idea would be for some group to go and dedictate a year or so to making the be-all-end-all of interfaces.

        Yeh, designing the be-all, end-all interface would only take about a year for a group of hobbyists, wouldn't it? Because basically, all that UI-design stuff is just art fag stuff which is no problem for "hackers" who are "often highly creative artistically" ([c] Eric Raymond). Those psychologists, ergonomists and designers can't be contributing anything interesting, because they don't have computer science degrees. Hell, "psychology" even sounds like it might be a liberal art! All that's needed is for some "engineers" to set up a mailing list and swap ideas and soon we'll have something much better than the Mac. I mean, c'mon people, this isn't exactly kernel hacking.

        Bill Gates must love hopelessly overambitious, ill-thought-out "conquer the desktop" efforts like these.

  • by rjamestaylor (117847) <rjamestaylor@gmail.com> on Monday February 18, 2002 @05:43PM (#3028901) Journal
    I use KDE but prefer Mozilla. I am *sick* of the incompatible clipboards that KDE/GTK use. As a matter of fact, I just complained to my co-worker about this and said, "This is why a monopoly is a good thing: someone to declare 'clipboard functions work this way or no way'". Damn I hate this.
    • Yea, verily.

      Sure, let KDE and Gnome start on the surface with themes that provide a common lool `n feek.

      But then, start digging down to the lower level inter object communications layers to get exchange of data at that level, even if it's something that's slower than molasses between KCOP and Bonobo. As long as it works!

    • You have pinpointed the absolutely biggest strength with Windows. You will always have the same controls, things will be where you assume them to be, the clipboard will work, COM works, DirectX works, there is one win32(64) etc etc etc.

      So how come diversity is bad in this case? Because it's confusing and counterproductive. It uses a lot of development time that could have been better spent on one better solution that is taken to a mature state.

      If KDE/Gnome wants to make certain protocols etc comming, that's nice as long as nobody is left out. But I would never accept two desktopsystems on my computer. I'd rather see more work on KDE/QT.

      If you want Linux to be sold with home computers, this is what you need:

      1. One desktop with a good set of standard applications and tools
      2. A good office suite
      3. Good support 24/7 that you can trust
      4. A much better packaged product
      5. All subsystems should have the same release proceedueres as KDE, this more than anything includes the kernel. It absolutely has to be stable and be as free from bugs and holes as possible at each release point. The system won't be updated if it requires compiling the kernel and configing it.
      6. A dead simple upgrade/patch system. Use Konqi, have a little blinking thing on the screen saying "new stuff" and make everything upgradable.
      7. Kill off all diversity in formats for configuration files, add a reposatory (done the right way, think of it as a database. And put everything in files instead of one huge one, it forced me to reinstall my XP, pissed me off to no ends) and make it simply to configure. If I know what I want to change I shouldn't have to read the help.
      8. Write help files for everything in the system. And that includes everything from "how do I set the keyboard to Swedish" to "I want to know what this obscure error message from g++ means".

      There you go, there you have a list. A lot of the ground work is done, and some of the work is being done as I sit here and wriet. But now it just requires more work, people disagreeing, people agreeing and much much more work (see why we don't want five more GUI systems etc etc).

      See it as a MacOS X killer if you want to ^_^ Heck, I wished I had time to do this myself. Guess you should mail me if you can muster a 1,000 coders, including the kernel and KDE people. Should sell it (and support people) to Compaq, HP, Dell, etc to include in their new spiffy computers. Including a DVD with all the binaries and source (eat that M$!).

      • 1. We have that. It's called "KDE" or "GNOME," or even "Window Maker with ROX."

        2. Uhm... It's coming?

        3. You *are* seriously joking, right? Red Hat. Linuxcare. There are *lots* of others, including SUSE, Mandrake, and IBM.

        4. What do you mean? Do you mean the CDs should have purty holograms on them? Or should the installer tell you how much better global warming will be once you've got everything installed? If you mean an easily-installed product that works right out of the box, I suggest SUSE. It installs better, easier, and faster than MS-Windows.

        5. Rrrriiiiggghhht. Which release procedures should the kernel follow? And *who* has ever forced you to upgrade your kernel? I'm not even sure what you are getting at here.

        6. apt-get update && apt-get upgrade (this assumes you use Debian, which negates SUSE, as suggested in 4. But SUSE has its own upgrade system. I use Debian.)

        7. Yeah! And let's kill off support for alternative processors, too! All those subdirectories under /usr/src/linux/arch frighten and confuse me. Seriously, though, use webmin if you don't want to learn all about the strange and wonderful world of diverse configuration files. It does what you want, without you telling developers how to do their job.

        8. man, info, /usr/doc, HOWTO, and my favorite, Google. It's there, man. It's there.

        The only problem that exists in your list is #2, and it's a doozy. Abiword, Gnumeric, Koffice, and Open Office are coming along, but they still have some ways to go. They are good enough for me, but I don't use many office apps. Personally, I think office apps tend to suck slime, in concept and execution. But that's just me.

        Now, please explain: you don't have time, but if someone can get 1k programmers together, they should call *you*? Whatever for?

      • You have pinpointed the absolutely biggest strength with Windows. You will always have the same controls, things will be where you assume them to be, the clipboard will work, COM works, DirectX works, there is one win32(64) etc etc etc.

        I take it you don't do alot of Windows development. COM most certainly does not always work, and when it fails it isn't terribly helpful at finding the problem. DirectX is extremely dependent upon independent hardware developers to provide high quality drivers, a task they're not all up to. As for the Win32 API, there are multiple versions with many incompatibilities. You might find Microsoft's list of incompatibilities between versions of Windows [microsoft.com] interesting reading.

    • by grungeKid (4260) on Monday February 18, 2002 @06:19PM (#3029111) Homepage
      Actually, the X has a fairly sophisticated clipboard
      model, maybe a little bit too sophisticated. Hence it has traditionally been poorly understood and badly implemented in apps and toolkit.

      Gnome does the Right Thing with respect to clipboards, while QT2/KDE2 uses a more limited clipboard model. The good news is that QT3 and thereby KDE3 will do the Right Think and therefore interoperate a lot better with Gnome (as well as properly written X apps such as XEmacs)

      These comments are somewhat enlighening: http://dot.kde.org/1013076354/

      Also read this for a backgrounder about clipboard and X: http://www.jwz.org/doc/x-cut-and-paste.html
      • Actually, the X has a fairly sophisticated clipboard model, maybe a little bit too sophisticated. [...] Also read this for a backgrounder about clipboard and X: http://www.jwz.org/doc/x-cut-and-paste.html [jwz.org]

        Gee, that's nice. Care to explain how to make that "sophisticated [catalog.com]" clipboard model work with something other than plain text?

        • Re:Not quite. (Score:2, Informative)

          by dietz (553239)
          Gee, that's nice. Care to explain how to make that "sophisticated" clipboard model work with something other than plain text?

          It's explained (high-level) right there in that same article [jwz.org] that you didn't bother to read.

          Better luck next time.
      • Gnome does the Right Thing with respect to clipboards,
        Yes, it's a nice copy of the way MS used to do things. Other people have other ideas and implement them in other ways - the right thing is usually just what the author thinks is the right thing. Until there is an ISO standard, there isn't going to be a "right thing", and even then extensions are good. Ultimately, the right thing in X is to support the X clipboard - everything else is an extension.
      • Actually, the X has a fairly sophisticated clipboard

        And that's where the problems start. Thee is nothing about storing smallish pieces of data temporarily that needs to be part of any gui or windowing toolkit - it's not a visual thing in any way. It should be a system service that can be used by any gui. That way X, gnome and KDE program would all do the same right thing.

  • by Anonymous Coward
    what is needed more is interopability of the component and document models, heck both desktops can't even handle non x clipboards in a compatible way. The first thing a normal desktop user who uses Linux for the first time would ask, why he can't drag a file from konqueror into evolution and why he cant paste his gimp picture into kword over the clipboard!
    Heck even e copy from a galeon the copy paste menu way would never generate a paste in kedit!
    I'm sure a user would care less about a common L&F than about a precise and normed app interoperability, which should be possible!
  • by Anonymous Coward on Monday February 18, 2002 @05:47PM (#3028927)
    Personally I think KDE and GNOME should chuck it all in and start to work together on a unified desktop taking the best elements from both and combining them.

    KDE is so much nicer to develop for than GNOME imho but I prefer to use GNOME, I'm sure that others have differing opinions about what they like and hate about each environment, but working together to provide maybe the ultimate desktop experiance would be brilliant!

    I know this opinion is a little radical and not likely to happen, but if I had my eutopia, that would be it!

  • by SteelX (32194) on Monday February 18, 2002 @05:48PM (#3028932)
    We'll soon get GNU/KDE and KGNOME?
  • by pyrrho (167252) on Monday February 18, 2002 @05:50PM (#3028952) Journal
    People forget, RMS is not for competition. Take for example Xemacs, he does not see this as driving improvments in Emacs or vice versa, but as a waste of effort.

    In fact, this makes a great deal of sense. The benefit of competition in capitalistic based development comes from the fact that things are thrown together to a schedule, things are sold based on delivering the result at a certain date. This leads to rapid development, but also compromise. The competition between products is meant to compensate for that fact, and largely does (if a monopoly doesn't form).

    In the case of open software, programmers tend to do things the way they would like them. Bad designs made this way (as in, you wanted the wrong thing) die out under their own weight. But if you have two products competing that both have coherent designs (empirically speaking: they survive to provide their initial versions and are actually used significantly), and they are open source, you might just be wasting effort by no cooperating. The reason: since the source is available, if the product is missing something, and it's design is strong enough to support expansion, you don't have to "defeat" it just to add the feature you feel is missing, instead you simply add the feature.

    The story is simply based on the common knowledge of RMS emnity toward KDE. But suprise!, RMS really did mean it when he said he didn't like KDE because of Qt's license. That's been fixed. RMS thus wants to see the stuff made in common. He's a very consistent fellow.

    People with strong principles can be difficult, because their principles can not be exactly the same as yours. But they are also very valuable. And if they are CONISTENT, and their values don't change (for example, when it's time to line their pocket or get recognition), they are invaluable.
    • I like what you're saying. But a couple of nits. Sure, if you feel a product is missing features, you can add them. But what if you want to *remove* a feature? This problem exists in the current situation also, of course. But if one side of the other becomes too bloated, it's easier to say "hey, it really doesn't have to be that way".

      Here's another question I have. Now that we can all be happy about KDE's license, we can merge the code and philosophies to have a grand unified desktop. We don't want to duplicate any effort, after all. So maybe we should also merge the hurd and linux kernel projects. I say this tongue in cheek. Does anyone expect support for this idea? No. They are premised on different ideas. As are Gnome and KDE. Just for starters, the choice of language comes to mind.

      I think there's a little more to all of this than a prosaic desire to eliminate redundant effort. This is nothing more than a hunch, but I think perhaps RMS is turning a corner. No, he's certainly not abdicating his principles. He wants software to be free. And he want free software to be available for *everyone*. From the GNU Manifesto:

      Once GNU is written, everyone will be able to obtain good system software free, just like air.

      I.E., I'm thinking we're seeing an honest to god concern about free software's popularity. Multiple different desktops, with their myriad ways of doing things, confuse people.

      Moreover, I'm not so sure the thought of Gnome getting in bed with Microsoft doesn't play into this. There are other ways to affect the direction of software projects than by being elected to the board of directors. But that's really just rampant speculation on my part.

      Rampant speculation is fun.

      Personally, I think the competition between these projects has contributed enormously to their rapid evolution. In general, I'm a much bigger fan of code forks than merges. Don't think of it as wasted effort. Think of it as putting your money where your mouth is. The proof is in the putting. Or is it pudding? ;)

      To conclude my rant, why do you think the competition between KDE and Gnome is not "capitalistic"?

  • by koh (124962) on Monday February 18, 2002 @05:52PM (#3028965) Journal
    Flamewars like the Gnome/KDE one have always been a side-effect on free projects that have the same final purpose (and on free projects in general ;), but it's true that the rivality between developpers of such important components has to disappear. The idea is good, and given its originator it may have a considerable impact on future GUI development aims.

    But I'm not quite sure if a compatible theme engine is the way to go... Many people still consider themed desktops as a waste of time and space, and sometimes you can find really awful things on themes.org ;)

    Another direction may be the component object model itself. There has been, IIRC, at least one attempt to start an uniform interface between ORBIT and the KDE object model, and others may be under way.

    IMHO, this would be a much better challenge for Gnome/KDE integrators, and provide a broader signal to the GUI community.

    Microsoft has made COM first, then made XP skinnable. Of course, the Linux themes.org effect was not present then (IIRC), and maybe it was sheer luck. It worked for them anyway.

    But I'll sure fancy some skinnable icons while drag/dropping objects between Gnome and KDE apps :]

    • Flame wars can sometimes be pretty good. Forces people to have to explain what they mean etc, which is good. Just go find an article with Linus and see what he has to say. I can't remember it correctly, but if I remember correctly he was pretty stern and didn't accept anything without a good explaination.

      So disagreeing can be very good (as long as personal feelings aren't involved. That is never good), but getting two products might not...
  • Yay! (Score:3, Interesting)

    by Frag-A-Muffin (5490) on Monday February 18, 2002 @05:54PM (#3028978) Homepage
    This is good news! What's next? An abstraction of the widget sets so that programmers can code to a neutral API that can be deployed on both GTK and QT (Or Gnome and KDE) at once?!?! When are we going to see that? :)
  • This is probably the most singular unifying architechture change that will propel Linux to the top of all the markets, server, desktop, and embedded.

    YEAH RIGHT !

    Ok, Im suprised RMS said something without demanding, frothing, or berating. But in the whole scheme of things is this really worth the bits its typed with ?

    Some architechtural changes in the next version of each twoard additional compatility would be nice. But aside from that they are different systems, written by different people, with different needs and different goals, as well as different philosiphys on how to achieve what they want. To this end I dont really see what good compatible themes are gonna do for the rest of the projects...
  • Starting with something simpler, eg theme, is a reasonable idea to me. Believe it or not, trivia like why paste is Ctrl-V in one program but Ctrl-Y in another have stopped many people from migrating away from Windows.

    But, in the longer term, they really need to enable the basic components to talk to each other. Clipboard is an obvious target. Linux won't boom on desktop before something equivalent to OLE has been fully implemented and *widely* accepted by all the different camps involved.
  • Progress (Score:2, Insightful)

    by grrae (558854)
    Here, in a quote from This Letter [gnome.org], RMS says,

    "...The ill feelings that linger between GNOME developers and KDE developers are not good for the community, and it is very useful to help calm the antagonism."

    Let's here from a few who are (accepted to be) wiser than ourselves:

    "Reasonable people adapt themselves to the world. Unreasonable people attempt to adapt the world to themselves. All progress, therefore, depends on unreasonable people." -George Bernard Shaw (emphasis, mine!)

    "Honest disagreement is often a good sign of progress." -Mahatma Gandhi

  • Well... (Score:4, Interesting)

    by Microlith (54737) on Monday February 18, 2002 @06:04PM (#3029041)
    I don't know about anyone else, but I always thought it was funny how the Open Source community yelled about "standards," yet we have so many damn standards that there aren't any.

    Now that license issues are cleared up, RMS has a chance and he's gonna take it. Eliminate two, create one. This isn't a bad thing, since you STILL have the source.

    We have options for customization, and a lot of freedom, but what we lack is any real consolidation (IE eliminating redundant standards), thus creating a plethora of pitfalls for software developers.

    This is one thing I think the Linux Standards Base should cover. More than just one boring, rather useless "base," it should cover MANY bases, and specify standard APIs, installations, and specifications for systems/software. Hell make Linux Standard Base certification like that damn Made for Windows XX logo.

    Theory:

    LSB defines a desktop base, a server base, and an embedded base.

    On the desktop base you have modules (not necessarily compatible), say Gaming Module which includes all necessary packages and auto-detection and config info, a Network client module that automatically loads remote config utilities and any necessary client software, and a workstation module that adds it's required things.

    Same for server and embedded.

    Also have the LSB supply standard definitions for the GUI APIs. Standard Themes, fonts, what have you.

    If you can build a solid foundation for your system and get it under control (community control, it's still ours), then you'll attract users. I think that's a bit of what RMS is trying to do here.
    • Re:Well... (Score:3, Funny)

      by Yarn (75)

      More than just one boring, rather useless "base," it should cover MANY bases

      All our bases? (Sorry)

  • by sl956 (200477) on Monday February 18, 2002 @06:22PM (#3029126)
    Back in November 2001, when RMS was candidate to the GNOME Board of Directors, there was a discussion [slashdot.org] on /. about the reasons why he applied.
    Just a couple days before, he had said during a conference in Paris that his primary reason to apply to the board was to support cooperation between GNOME and KDE (see my post [slashdot.org]), eventhough it wasn't clearly stated in his answers [newsforge.com] to the GNOME board candidacy questionnaire.
    I'm really happy to see that it was not only electoral bulls**t.
    Maybe he is the last person you could have think of for such a task (especially knowing his position toward the KDE team in the old days of the QPL), but here he comes with this simple (as in not heavily political) practical (as in usefull) first step... so let's try !
  • Since we're ushering this new era of KDE/Gnome friendliness, I have one simple request...

    Can one (or both) of these two desktops allow me to scale the title bar on the windows? I can change all of the other fonts to a bigger size, but when I change the title bar font it just gets cut off vertically. Sorry, but some of us try to run high resolutions on smaller monitors.

    By the way, here's cool theme from KDE-Look.org (one of the few ones that didn't rip off some pre-existing OS (majority were XP/MacOS X)):
    Gorilla @ KDE-Look.org [kde-look.org] (preview [kde-look.org])

    Notice how small the title bar font is... just think the joy you could bring to small children if that scaled with the font size! It would be perfect on this theme...
    • Actually that's a rip off of a Gnome theme that was meant to test the Vector capabilities of nautilus.
      Not necessarily a rip off though....its named the same. I guess just a port.
  • by Chanc_Gorkon (94133) <gorkon@noSPAM.gmail.com> on Monday February 18, 2002 @06:28PM (#3029154)
    Debian is close to releasing and they are talking about a unified Linux desktop theme. Hell most have frozen over or this is a sign of the apocalypse!
  • Better C++! (Score:5, Interesting)

    by Otter (3800) on Monday February 18, 2002 @06:34PM (#3029175) Journal
    To my mind, the single most important thing RMS could do to help out KDE is to push for better C++ support in GNU. Advantages are:
    • It will address what's generally felt to be KDE's biggest drawback.
    • Do the same for Mozilla and every other C++ project, free and non-free, running on GNU systems.
    • Point up the importance of the GNU contribution to what's generally referred to as Linux. (Not that I'm thrilled to see him getting more ammunition to pester us on that score, but it's not until I was cursing out the FSF for making C++ apps run so slow that I realized he's actually got a good point.)
    Besides, it's something he's in a position to actually do, and which doesn't require anyone to sacrifice existing work.

    (Poor guy -- he's like Alan Greenspan, where every public utterance is turned into a grand policy question.)

  • Here at the office, we are finding that a lot of GNOME apps are far more usable for day to day tasks. Most of our employees are moving to Evolution - they absolutely love the calendar, task lists, and contacts. (I only use the email portion, myself.) Also, Galeon is a faster and stabler browser than Konqueror. But as a desktop, GNOME just won't cut it for production use. (Two of my coworkers switched to Ximian GNOME for a few weeks, and declared it practically unusable.) So we're definitely going to stick with KDE as the environment now, but for apps...Gnumeric, Evolution, and Galeon are all better than their KDE equivilents.

    Some better interoperation (cut-n-paste, default browser & mail clients, themes) would really make our lives a whole lot easier. In the meantime we will hobble by.

    I suppose that both desktops are shooting to someday have enough apps that it is not necessary to mix-and-match quite so much. But in the meantime...
  • Now if we can get them all working together with an xserver, say XFree... and have the whole gui/graphics driver thing settled once and for all...

    And then we get them to work with the Kernel developers, and after that the other peripheral developers... and then we can shrink wrap the whole thing and sell it, lets say, for $99 bucks.

    doh!
  • ...that when I bring up the subject of cooperation among similar projects [slashdot.org], I'm rated a troll, yet RMS stands before us like a demi-god because he can't seem to figure out what exactly he believes in.

    If anyone ever tells you "Don't shoot me, I'm just the messenger" -- shoot him.

  • If I have to reconfigure ONE more window manager to do focus-follows-mouse-sloppily, I'll have to change my email address to chris@loonybin.org.

    I advocate an XML-based prefs format that is shared by many WMs, with less-capable ones simply ignoring the features they can't understand.

    In .wmrc:

    <keyboard>
    <focus>
    <follow/>
    <sloppy/>
    </focus>
    <repeat>
    <speed value=6 scale=10/>
    </repeat>
    <clicksound value=false/>
    </keyboard>

    or something like that.
  • Inventing a whole new theme will require a lot of time and arguing about how it should look/work/etc. Don't go there. Instead:

    IMHO there should be a GNOME/Gtk theme called "KDE" which exactly mimics the most-default KDE theme, and a KDE/Qt theme called "GNOME" which does vice-versa.

    Unless of course this is a stpuid idea, in which case, forget I brought it up...
  • Right now, KDE has an enormous lead over GNOME with ordinary users. The reason for this is pretty simple: KDE has a unified web/file/desktop browser that is fast, clean, intuitive, and full-featured. Non-technical users, especially prior Windows users, have come to expect this in an interface. They are used to a high degree of object oriented design and a consistent 'look' to the interface. Nautilus is highly lacking in this regard. It is very slow, has clunky web browsing support, is very lacking in basic features / configurability, and does not have a clean unified feel. Because of this, users must switch back and forth between Nautilus and Mozilla/galeon. And Nautilus downright sucks for any sort of GUI file management, thus requiring yet another utility if one desires such functionality. So now you have Nautilus for your desktop icons, Mozilla for web browsing, and something else for file-management. And none of them talk to each other.

    In my opinion, if GNOME and KDE want to cooperate in the future, they need to decide on a single object model, a single RPC/IPC mechanism, and a single clipboard system. Judging by KDE's proven success in this area, it only makes sense to use it as the standard rather than break both and start from scratch. Unfortunately, it seems the GNOME people are extremely stubborn about switching to C++. The reason of course, is historical: the old rule of thumb that C is more efficient than C++.. or more accurately, that C++ compilers are slow. This is beginning to change, and no doubt, g++ would be improving much faster if more people were using it.

    Or we can just keep going about re-inventing each others' wheels. Pretty silly if you ask me. One other note, the human aspect, is another advantage KDE has. GNOME needs some better unified leadership and goals. Compare, for instance, kdelibs to the dozens of library packages needed to compile GNOME. Having unified releases is a good thing for everyone.
    • Amazing. Two morons modded the parent down because they didn't like my (valid) opinion that Nautilus sucks. Lamers. Well, here you go, you idiots: a real troll. Go ahead and waste your mod points on this one too! ahhahaa.. that's one less point you'll get to hurt another thoughtful post because you don't agree with it! ahhahaha.. Mod this down!!! GNOME sucks!!! KDE RULEZ!!! Do you like this approach better?

      I rate all negative moderations as unfair.
  • Why a common theme (Score:4, Insightful)

    by maggard (5579) <michael@michaelmaggard.com> on Monday February 18, 2002 @07:34PM (#3029430) Homepage Journal
    Lots of folks are crying: "I want my custom desktop" and "This will stifle innovation".

    Why?

    Nobody is suggesting anyone be locked into these. Nobody is suggesting these be graven into stone never to become v.2 as progress marches on.

    What this would do would be provide a common basis for new folks, a baseline for support folks, a universal look for screen-shots and documentation. If along the way some solid UI design were applied, usability testing done and minimal esthetics incorporated then so much the better.

    Tweak away, replace, bend, fold, spindle, mutilate. But at least folks who are bewildered and lost could go to a common default and see something reasonable and trivially relate it to the documention or support folks. A simple menu option of "Default" would do wonders and all the better that it be consistant across toolkits.

    Of course the next question is "What?" Here's where I think a good process of involving folks who are knowledgable in this area along with things like testing and feedback and skills in UI-standards-making would be incredibly valuable. Nothing against the coders but frankly, and many would agree, many desktops today are bad Windows reimplementations, wannabe-MacOS X looks or terrible pistaches of any number of good-ideas-running-into-eachother. A committee of KDE and Gnome AND others working on a timeline with a budget and a set of goals and opportunity for community feedback would be ideal, something with conflict-resolution built in from the beginning.

    And if it stinks up the place it gets ignored. Or fixed in v.2. But at least we'll have taken the chance of a basic common UI gtting a shot and possibly accruing the benefits that would accrue from such. As for those looking to use something different, more innovative, more complex, more suited to them - go right ahead.

      • Menus. Red Hat's /etc/applnk and Debian's menu system already solve this problem to a limited extent, but not everyone (or anything close to it) uses these mechanisms. One directory, in /etc (read the FHS as to why) should be used by both. Flags to hide certain things (gnome control center) in certain environments should be a part of this.

      • Display manager session types. As someone who manages a large amoutn of packages for my office, it annoys me that I have to repackage enlightenment, twm, pwm, qvwm95 and everything else to add the correct entry for the sessions in two locations, one for KDM and one for GDM (our office uses GDM, but I like doing things properly).

      • Mime types. File type editors in both desktops are already tragic enough without adding the hassle of having to add apps twice. Again, packagers must account for both sets of configs

      • Applets. Less of a concern, but its hard explaianing to users that you can runevery GNOME app you want in KDE, except for the applets, which won't work in the KDE taskbar (and vice versa).
  • If I said this or most people saying this they would have most likely been ignored.

    Good job RMS,

    Matt
  • by qweqwe (104866) on Monday February 18, 2002 @08:23PM (#3029655) Homepage
    The main reason for the split, is the widget set dependence of GNOME and KDE. Until this issue is resolved, deeper interoperability issues won't likely be resolved.

    You *should* be able to use Qt write a complete GNOME application that obeys GNOMEs theming rules, uses Bonobo, GConf and other GNOME technologies.

    You *should* be able to use Gtk+ write a complete KDE application that obeys KDE's theming rules, uses KParts, DCOP and other KDE technologies.

    Yes, it may be *easier* to write KDE applications with Qt, and GNOME applications with Gtk+, each desktop/platform shouldn't be *tied* to these widget sets.

    That's not the way it works now. At the moment, I believe that GNOME's technologies (at least the one's in GNOME 2) are more decoupled from the widget set than KDE's. For instance, it's possible to write a Qt application that uses GConf2, Orbit2, GStreamer, and Bonobo2 without linking in any Gtk+. If you *really* work at it, you should also be able to integrate with GNOME's accessibility framework by hooking Qt components to the appropriate ATK+ options. That's a fair chunk of GNOME already. But there are many other GNOME features that Qt applications can't take advantage of.

    • work is already in progress.

      KDE can import GTK/GNOME themes.
      And, the other day, launching my favorite GNOME app using KDE, the systray icon/menu went in the right place.

      Well, you may smile at such things, but it works, and it's a beginning....
  • Even more interesting than the KDE/GNOME thing is what you find when you dive down a couple of follow-ups in the email chain. Here's an RMS response to a part of a post explaining why the poster thought that the KDE/GNOME cooperation thing wouldn't happen:

    Uraeus linuxrising org:
    > And as the free software saying goes,
    > a itch that don't itch a developer,
    > doesn't get scratched.

    RMS:
    That was said by Eric Raymond who belongs to another movement, and it reflects the spirit of that movement. The spirit of the free software movement is to do projects because they are important for the community and for our freedom. They don't have to "scratch an itch".

    Is this really an accurate portrayal of (one of) the differences between "open source" and FSF sanctioned free software? Open source developers are out to do what's best for themselves (and maybe helping out others as a by-product by releasing their code), while free software developers are motivated only by love of their fellow (hu)man. I'm not really heavily involved in either development community, and didn't realize that there was such a sharp divide (if it actually exists outside of RMS head). Can some free software/open source developer types weigh in on this? Why do you write code?

  • We Had To (Score:3, Interesting)

    by cluge (114877) on Monday February 18, 2002 @10:06PM (#3029799) Homepage
    "....we had to attack it [KDE] to make people aware of the threat"

    The attacks were vehement, nasty and for the most part unwarranted. I never saw KDE as a "threat" and considering it a threat did nothing but waste a lot of energy (IMHO). Especially considering where the software was headed and the fact that EVERYONE KNEW that QT would have an open source license eventually.

    While I endorse the idea of some interoperability I tend to take a step back and look for other motives. Members of the KDE team have long tried to get some interoperability between the 2 desktops and were repeatedly rebuffed. It's a nice idea, but considering some of the mudslinging thats gone on over the past few years, I'm with holding judgment.

    Hopefully the axe is buried, considering there are some admin's out there running open relays because it was the right thing to do in 1990, I expect to see it dug up a few more times. That's the problem with religious wars where you unfairly vilify the enemy it makes it hard to work with them when they are on your side. I'm glad some people are starting to consider the big picture.
  • by Afrosheen (42464) on Monday February 18, 2002 @11:24PM (#3030148)
    Version after version, distro after distro, app after app, I still don't have a unified clipboard to simply copy and paste between apps.

    Give me a unified clipboard, or give me death.
    • Version after version, distro after distro, app after app, I still don't have a unified clipboard to simply copy and paste between apps.

      You may find this funny, but I became a Linux coder last years after a long time on windows. To me this clipboad fiasco is both frustrating and symptomatic of what's wrong with windows.

      I'm mostly coding using xemacs, but to ward off flamewars I also drop into vi from time to time.

      First, what's wrong:
      There is no unified clipboard. I can to Ctrl-k ctrl-y to cut and paste in Xemacs, but it doesn't work across different xemacs windows. I can use the Xemacs toolbar buttons labeled "cut", "copy" and "paste". These do work across xemacs instances, but do not interact with the ctrl-k ctrl-y buffers, and if I should close the source window before pasting, the copied text vanishes. Then there is good-old x-windows swip & middle-click. This works in most everything, but is completely unrelated to the other two mechanisms. I use 3 different, incompatible, uninteroperable clipboards on a daily basis. Unix = simple orthogonal tools my arse.

      A solution:
      Have a service/damon that stores ckips. It doesn't need to be part of any gui. It doesn't need to be linux-specific, it can be generic unix, and run on BSD too. It just needs a simple API (yes, like windows has) that supports multiple clips, perhaps taged by creating app and data type. Give it lots of config options like max size & number of clips to store, if it should persist them on HD when the system shuts down, query functions to find out what's there etc.

      This, for me would be great. Apps that guard thier own clipboard jeolously could use thier own space on the clip server. Apps that want to look at other clips could do so. You could cut in KDE, restart and paste in Gnome.Heck, you could cut in emacs and paste in vi. It would be nerdvana. Why is this so hard?

  • by Kymermosst (33885)
    It may have been mentioned before, but the real reason is that RMS can't stand to not have the FSF in charge of anything that has the GPL as a license and is also successful.

    This is NOT flamebait, it's the truth, at least as I see it. When a GPL'd project is unsuccessful or new, RMS dismisses it along the lines of "this will substitute until we finish" whatever. When it becomes successful he's right there trying to claim it. Such as the whole GNU/Linux thing. I hate to break it, but GNU got a boost with Linux, not Linux a boost with GNU. It could have just as been the BSD tools that ended up in the first Linux distros, and there are still people working toward a "low-GPL" linux distro.

    What RMS is looking for here is a merge, or a way to give the edge to GNOME.

    Don't get me wrong, GNOME is a great project, but so is KDE, and we NEED this competition. It's necessary for innovation, and we should NOT let RMS mangle KDE into one of the FSF's projects.

    My question is, when he fails to get control of KDE in this way, will he instead insist on calling it GNU/KDE because it builds on top of GNU tools?

    Don't moderate me flamebait because you disagree with my opinion. You'd do better to rebut my argument instead.

  • You know. This has always been an interest of mine, unifying the handling of application settings to configuration files through a generic, modular, and extensible structured data parsing interface. Ultimately, one should not need a grand, "swiss army knife" parser that does everything, you just need to be able to add tools to the "knife" as they are required. Of course, we would want to do this all without the use of the dreaded "metadata file".

    Quick example. Let's say I write an application that uses an *.ini style config file. There are a number of generic function calls that I'm going to want to make through the program, one of which might be readconfig(file*,parser*,confdata*). The challenge is coming up with something simple enough to make it easy to use while flexible enough to support structured data trees.

    Disclaimer: I haven't put a whole lot of thought into this. Such a level of API may be useful, but in some cases may not be pratical to implement. Regardless, it is a fun problem to stew over.

  • Could be good (Score:3, Insightful)

    by nagora (177841) on Tuesday February 19, 2002 @04:09AM (#3030775)
    If it reduces the number of teams copying MS's mistakes from two to one. Think what useful work the other team could get on with. I vote for a good DTP package.

    TWW

  • If the goal is to make KDE and Gnome/Gtk themes compatible, I think the right way to make this happen would be to create a new theme system that could be compatible with both systems.

    There are several exciting theme systems out there now: both PicoGUI [picogui.org]'s theme system and Enlightenment's Ebits [enlightenment.org] are theme systems based on a database, capable of storing data for the windowing system, the widget toolkit, and all the applications. If a system like this were implemented in the major GUI toolkits and window managers on the desktop, it should give a way for all applications, toolkits, and window managers to be consistant and completely under the user's control.

  • While we're at it, why don't we merge emacs and vi development?
  • ...who doesn't understand the fascination with "themes"?

    I can think of many areas of cooperation between Gnome and KDE -- and themes are pretty low on that list. This isn't a troll, but an honest question: What's so important about themes?

    My computers are for programming, writing, and web browsing; why would I waste CPU time and memory on fancy wallpapers and pretty rounded corners and all this "stuff" that fascinates some people so much? If I want pretty pictures, I'll frame'm on the wall, where I can see them when the computer is off!

    Can someone explain theme-mania to me, please?

Today is a good day for information-gathering. Read someone else's mail file.

Working...