5 ms·

GNOME is not necessary anymore. It was in the past, not today. We have Qt that really works, much much better, and with LGPL license. You can run stellarium,

GNOME is not necessary anymore. It was in the past, not today. We have Qt that really works, much much better, and with LGPL license. You can run stellarium, VLC or Marble in Mac or Windows without problems. If you try to use gimp or inkscape in mac it opens x11, copy and paste does not work(in inkscape it copies pixmaps instead of vectors!!), what a botched job. In windows you will have a lot of problems too. GTK support for OpenGL, OpenCL was terrible, having to low code everything, while in Qt works as well as with cocoa. Let GTK die and improve(or fork) Qt.

martey 14y ago
Your comment seems to be talking about GTK (the user interface library, which like Qt, is also LGPL licensed), while the original post is about the GNOME desktop environment. Since the latter does not run in Windows or OS X, your comment is sort of off-topic.
shaunxcode 14y ago
Hey I think the copy behavior in inkscape is on purpose. "duplicate" now does what you would expect copy to do?
exDM69 14y ago
> GTK support for OpenGL, OpenCL was terrible, having to low code everything, while in Qt works as well as with cocoa. OpenGL support sucks in GTK and QT equally. Especially if you want a more recent version of GL. OpenCL does not depend on your widget toolkit in any way. > Let GTK die and improve(or fork) Qt. Qt is not really as great as you seem to suggest. It's a bloated "batteries included" framework that has everything from it's own string type to wrappers for things like threads and sockets. GTK is a widget library that is a lot leaner and meaner in comparison. These massive platforms that try to wrap everything in the underlying operating systems to a common API use only the least common denominator of the systems that it runs on. The easy 80% works quite well but things tend to fail miserably when you enter the 20% realm. Things like memory mapped files or asynchronous socket i/o tend to be missing from these wrapper platforms. And Qt is still using an old non-standard conforming version of C++ to achieve portability to things like Symbian. And their own C++ extensions that require you to use their build system and pre-processing tools. So you can't really use Qt without going all the way to Qt land.
- sparkie 14y ago
  Probably worth adding that Qt being C++ is itself a problem - as it makes it inaccessible to the majority of programmers, due to the lack of ABI compatibility with C++ and any other languages. Gtk+ on the other hand, is almost universally accessible, because any language worth using can bind C APIs. Of course, the downside here is that all the Gtk+ bindings to other languages are based on the Gtk+2 API. Gtk+3 hasn't gained much popular support.
  - exDM69 14y ago
    > Probably worth adding that Qt being C++ is itself a problem Yep. C++ is what I call a "dead end" language. If you write your code in C++, it will be only usable from C++. If you want to use it from Python, Ruby or whatever, you'll need a C shim in between. If it were written in C, you could use ctypes and other similar means to do FFI quickly. Unfortunately, most languages other than C are more or less a dead end.
    - maigret 14y ago
      > Unfortunately, most languages other than C are more or less a dead end. Except for Java, where you can reuse code directly with JVM-compiling stacks like Clojure.
      - exDM69 14y ago
        Well that is arguable. If you stay within JVM, you can use your Java code from other languages like Clojure and Scala. To some extent you can use Scala and Clojure code from Java. But you can't really use Java code from Python or Ruby unless you work with Jython or JRuby. So, I'd put Java in the "dead end language" bin. You can use C code from Java (via JNI) but it's not practical to do it the other way.
    - UK-AL 14y ago
      Not always. See boost python.
pkmays 14y ago
I'm not a fan of KDE, but I do like Qt. Qt seems to suffer from kitchen sink syndrome, but the core GUI API is well designed. If someone did for Qt what XFCE/LXDE did for GTK+, I think it could catch on.
- priomsrb 14y ago
  RazorQt is a lightweight Qt desktop environment

martey 14y ago

Your comment seems to be talking about GTK (the user interface library, which like Qt, is also LGPL licensed), while the original post is about the GNOME desktop environment. Since the latter does not run in Windows or OS X, your comment is sort of off-topic.

shaunxcode 14y ago

Hey I think the copy behavior in inkscape is on purpose. "duplicate" now does what you would expect copy to do?

exDM69 14y ago

> GTK support for OpenGL, OpenCL was terrible, having to low code everything, while in Qt works as well as with cocoa. OpenGL support sucks in GTK and QT equally. Especially if you want a more recent version of GL. OpenCL does not depend on your widget toolkit in any way. > Let GTK die and improve(or fork) Qt. Qt is not really as great as you seem to suggest. It's a bloated "batteries included" framework that has everything from it's own string type to wrappers for things like threads and sockets. GTK is a widget library that is a lot leaner and meaner in comparison. These massive platforms that try to wrap everything in the underlying operating systems to a common API use only the least common denominator of the systems that it runs on. The easy 80% works quite well but things tend to fail miserably when you enter the 20% realm. Things like memory mapped files or asynchronous socket i/o tend to be missing from these wrapper platforms. And Qt is still using an old non-standard conforming version of C++ to achieve portability to things like Symbian. And their own C++ extensions that require you to use their build system and pre-processing tools. So you can't really use Qt without going all the way to Qt land.

sparkie 14y ago
Probably worth adding that Qt being C++ is itself a problem - as it makes it inaccessible to the majority of programmers, due to the lack of ABI compatibility with C++ and any other languages. Gtk+ on the other hand, is almost universally accessible, because any language worth using can bind C APIs. Of course, the downside here is that all the Gtk+ bindings to other languages are based on the Gtk+2 API. Gtk+3 hasn't gained much popular support.
- exDM69 14y ago
  > Probably worth adding that Qt being C++ is itself a problem Yep. C++ is what I call a "dead end" language. If you write your code in C++, it will be only usable from C++. If you want to use it from Python, Ruby or whatever, you'll need a C shim in between. If it were written in C, you could use ctypes and other similar means to do FFI quickly. Unfortunately, most languages other than C are more or less a dead end.
  - maigret 14y ago
    > Unfortunately, most languages other than C are more or less a dead end. Except for Java, where you can reuse code directly with JVM-compiling stacks like Clojure.
    - exDM69 14y ago
      Well that is arguable. If you stay within JVM, you can use your Java code from other languages like Clojure and Scala. To some extent you can use Scala and Clojure code from Java. But you can't really use Java code from Python or Ruby unless you work with Jython or JRuby. So, I'd put Java in the "dead end language" bin. You can use C code from Java (via JNI) but it's not practical to do it the other way.
  - UK-AL 14y ago
    Not always. See boost python.

pkmays 14y ago

I'm not a fan of KDE, but I do like Qt. Qt seems to suffer from kitchen sink syndrome, but the core GUI API is well designed. If someone did for Qt what XFCE/LXDE did for GTK+, I think it could catch on.

priomsrb 14y ago
RazorQt is a lightweight Qt desktop environment