Language Selection

English French German Italian Portuguese Spanish

comparing "KDE 4" and "GNOME 3"

Filed under
KDE
Software

There is small trend currently to write a blog entry or article comparing "KDE 4" and "GNOME 3". Now, I'm not involved in the least with the GNOME 3 efforts (no big surprise there, I'm sure) so I can't and won't comment on what they are doing now or in the future (they can do so themselves quite well), but there are two interesting points I keep seeing raised that I really do want to address ... and I don't feel like commenting on every blog post out there. Wink

KDE 4 .. or the KDE Workspace?

What these blog entries are usually comparing is not "KDE 4" with "GNOME 3" but two of the KDE 4 workspace components, Plasma and KWin, with gnome-shell. Little more than that is compared in most of them when the topic is "KDE 4 or GNOME 3?". This is unfortunate because KDE 4 is a lot more than just the KDE Workspace, which is just one product that comes from KDE, just as GNOME 3 will be more than just gnome-shell.

A primary example is the KDE development platform. It consists of KDE's libraries built on top of Qt, Akonadi, Nepomuk/Strigi and others and represents one of the most important products we create. This platform started back in the 90s as a means to an end: getting the KDE desktop workspace functioning and sharing code and functionality efficiently between KDE apps in a way that guaranteed some consistency. These days, while it has kept this same set of purposes as an important part of its mission, the KDE development platform has taken on a much bigger role and a life of its own.

I'd love to see some thoughts that extend beyond Plasma/KWin out there and look at things such as the maturity of KDE's development platform compared to what others are offering right now or, as in the case of GNOME 3, in the near future.

Rest Here




Gnome 3

I sure hope Gnome developer don't mess up Gnome like the KDE developers did with KDE.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

More in Tux Machines

Kernel Space/Linux

Red Hat News

openSUSE Tumbleweed: A Linux distribution on the leading edge

So, to summarize: openSUSE Tumbleweed is a good, solid, stable Linux distribution with a wide range of desktops available. It is not anything particularly exotic or unstable, and it does not require an unusual amount of Linux expertise to install and use on an everyday system. To make a very simple comparison, in my experience installing and using Tumbleweed is much less difficult and much less risky than using the Debian "testing" distribution, and it is kept much (much much) more up to date than openSUSE Leap, Debian "stable", Linux Mint or Ubuntu. I don't say that to demean any of those other distributions. As I said at the end of my recent post about point-release vs. rolling-release distributions, if your hardware is fully supported by one of those point-release distributions, and you are satisfied with the applications included in them, then they are certainly a good choice. But if you like staying on the leading edge, or if you have very new hardware which requires the latest Linux kernel and drivers, or you just want/need the latest version of some application (in my case this would be digiKam), then openSuSE could be just what you want. Read more Also: Google Summer of Code 2017

Graphics in Linux

  • 17 Fresh AMDGPU DC Patches Posted Today
    Seventeen more "DC" display code patches were published today for the AMDGPU DRM driver, but it's still not clear if it will be ready -- or accepted -- for Linux 4.12. AMD developers posted 17 new DC (formerly known as DAL) patches today to provide small fixes for Vega10/GFX9 hardware, various internal code changes, CP2520 DisplayPort compliance, and various small fixes.
  • libinput 1.7.0
  • Libinput 1.7 Released With Support For Lid Switches, Scroll Wheel Improvements
    Peter Hutterer has announced the new release of libinput 1.7.0 as the input handling library most commonly associated with Wayland systems but also with Ubuntu's Mir as well as the X.Org Server via the xf86-input-libinput driver.
  • Nouveau TGSI Shader Cache Enabled In Mesa 17.1 Git
    Building off the work laid by Timothy Arceri and others for enabling a TGSI (and hardware) shader cache in the RadeonSI Gallium3D driver as well as R600g TGSI shader cache due ot the common infrastructure work, the Nouveau driver is now leveraging it to enable the TGSI shader cache for Nouveau Gallium3D drivers.