Announcement

Collapse
No announcement yet.

KDE vs GNOME

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #61
    silly

    Originally posted by nanonyme View Post
    I ownder what the purpose of this kind of gallups is anyway. Get Gnome and KDE to mimic each other so you won't know the difference anymore?
    I use some apps from both, and for the most part, they seem pretty much identical to me. There are a few differences, but they generally seem to result from themes (both have great themes and horrid themes) or differences in particular apps (so the same app reimplemented using the other toolkit would probably be more or less the same).

    The amount of hot air wasted on this subject is absurd....

    [Well, actually since some time ago, there's a bug in kde/libqt font-rendering that drives me nuts -- it somehow mis-handles ~/.fonts.conf, applying condtional settings in it to all fonts instead of just the specified ones. I definitely prefer a toolkit without that !@#$ bug!]

    Comment


    • #62
      ms-worship

      Oh, btw, while I think both projects are technically quite close, the the gnome project's continual dalliance with MS is quite annoying. If gnome tossed Miguel and the other MS-worshippers, it would be a huge breath of fresh air for the project.

      How much time have they wasted with the idiot mono project?
      Last edited by snogglethorpe; 17 August 2009, 12:09 AM. Reason: add title

      Comment


      • #63
        Originally posted by snogglethorpe View Post
        How much time have they wasted with the idiot mono project?
        There's something wrong about adding support for additional programming languages? (well, programming frameworks more like. anyway)

        Comment


        • #64
          Originally posted by AdrenalineJunky View Post
          KDE's package manager is kpackagekit (as mentioned above), though whether its used as defualt in a distribution is up to the devs of that particular distro. synaptic was orriginally a deb thing but has also been ported to RPM based distro's.
          Kpackagekit is a Packagekit project and is in KDE playground. Playground is not part of the main KDE at all.

          KDE is an open community of friendly people who want to create a world in which everyone has control over their digital life and enjoys freedom and privacy.


          KDE-Playground: Similar to KDE-Extragear, this pseudo-package also contains software not part of the main KDE release.

          Comment


          • #65
            You can find what packages that constitutes as KDE here.

            Learn how to install KDE Software on your device.

            Comment


            • #66
              Originally posted by krazy View Post
              It's innovative and brings options to gnome programmers that C can't directly provide. If few people find it useful then it will die out, but you can hardly call it 'antisocial'.
              Do you really believe that? To the first point, I challenge you to show me one thing about it that's particularly innovative compared against the entire spectrum of modern programming languages. And to the second, I again invoke the multitude of other languages that are out there already for just this sort of thing. Why not just align with one of the extant programming language communities instead of reinventing the wheel (again)?

              As a Free Software project, isn't this kind of meritocracy what it's all about?
              "Meritocracy" is being awfully generous in this case. There is no merit to radically changing policy and paradigm without thorough consideration of the wider implications. Consider the unlikely event of Gnome switching to Vala exclusively: You now need to preprocess every source file before compiling, you have another gapingly huge and poorly tested vector for bugs to creep in, and anyone seeking to join your development community must now learn your unspecified boutique language that no one else uses and can change at any time due to the whim of these "crowds."

              This is bad software design and will not be tolerated by people who actually cares about sane coding standards and system architecture.
              Last edited by Wyatt; 17 August 2009, 11:44 AM. Reason: Clarity

              Comment


              • #67
                Originally posted by Wyatt View Post
                Do you really believe that? To the first point, I challenge you to show me one thing about it that's particularly innovative compared against the entire spectrum of modern programming languages. And to the second, I again invoke the multitude of other languages that are out there already for just this sort of thing. Why not just align with one of the extant programming language communities instead of reinventing the wheel (again)?
                It is a language that makes it easy to write GObject apps. It has the performance of C++, the simplicity of C, while doing the hand-holding and safety-measures of Java.
                "Meritocracy" is being awfully generous in this case. There is no merit to radically changing policy and paradigm without thorough consideration of the wider implications. Consider the unlikely event of Gnome switching to Vala exclusively: You now need to preprocess every source file before compiling, you have another gapingly huge and poorly tested vector for bugs to creep in, and anyone seeking to join your development community must now learn your unspecified boutique language that no one else uses and can change at any time due to the whim of these "crowds."

                This is bad software design and will not be tolerated by people who actually cares about sane coding standards and system architecture.
                It's just a programming language. Do you think that any programming language other than C is wrong? GNOME is not going to switch to Vala-only any time soon. There are just going to be programs that happen to be written in Vala. Just like there are programs that happen to be written in Python, or Mono, or Java. For completely different reasons, I don't like Mono programs, but the languages itself are not a problem.

                GNOME appreciates any language:

                Developer-friendly

                Developers are not tied to a single language with GNOME. You can use C, C++, Python, Perl, Java, even C#, to produce high-quality applications that integrate smoothly into the rest of your Unix or GNU/Linux (commonly referred to as Linux) desktop.

                Comment


                • #68
                  As far as I understand it, Vala is actually C (the Vala compiler takes Vala source code and converts it to C, which is then simply compiled with GCC). So in effect it's still C. So where's the problem? It's not much different than Qt (and therefore KDE) which extends C++ using moc (which in turn generates C++ code, like Vala does with C).
                  Last edited by RealNC; 17 August 2009, 12:20 PM.

                  Comment


                  • #69
                    I also have to point out that it's impossible to use Qt without MOC, while both Vala and GObject are entirely optional when programming with GTK.

                    Comment


                    • #70
                      Originally posted by Remco View Post
                      It is a language that makes it easy to write GObject apps. It has the performance of C++, the simplicity of C, while doing the hand-holding and safety-measures of Java.
                      The tradeoff being an extra compilation cycle that has no specification or measure of thorough testing and it only targets GObject. I guess that is pretty...erm, innovative.
                      It's just a programming language. Do you think that any programming language other than C is wrong?
                      Where did you pull that from? Please don't put words in my mouth.
                      GNOME is not going to switch to Vala-only any time soon. There are just going to be programs that happen to be written in Vala.
                      I sort of assumed "unlikely event" would be the clue that this was a hypothetical situation used as an example. And by getting hung up on that, you ended up missing the actual point anyway. Accepting just any language is, in fact, the very sort of poor policy decision I was tearing into when I said, "There is no merit to radically changing policy and paradigm without thorough consideration of the wider implications."

                      If you're designing software that you want serious developers to get involved with; that you want many people to use, it is imperative that you enforce at least some level of sanity on the design, or you wind up with seven million lines of unmaintainable spaghetti spread across eighteen different languages. Coding standards exist for a reason and cover more than just trivial things like indentation style. Code needs maintenance. The fewer languages' idiosyncrasies you need to account for, the fewer specialists in those languages you need to keep your project afloat when obscure bugs turn up (and they will).

                      And don't forget, this is a full desktop environment. No single app exists in a vacuum, and because of the scope, many apps will be projects unto themselves. I would level the same complaints at Plasma, currently, which seems to have support for three languages or so.

                      As far as "it's not like its all that different from MOC" goes...it is, actually, for the same reasons I'm railing about Vala being dangerous. MOC's development was sponsored by a company that hired real engineers to work together in a team to design a sane way to use C++ with a real specification, and QA requirements. MOC still had and has bugs, but it has also far more than the word of a scant few people saying "this seems to work."

                      You know, I love open source software and the community of good people within, but the lack of attention to good engineering practise is really glaring sometimes. "Merit" can only come in light of many different factors.

                      Comment

                      Working...
                      X