If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Comment

Something I've never gotten is WHY each desktop environment feels like needs to build a terminal off of their libraries. Why isn't there an non-desktop linked standard terminal so we can all move on?

So which would you choose? Xterm? Rxvt? Rxvt-Unicode? Roxterm? Or one of the many other terminal emulators?
Why not extend the question to other software? Why is there a text editor for any DE? Why do we not all just use Vim or Emacs? And do we really need more than one mediaplayer? Isn't pure MPlayer enough?

Comment

On Arch Linux trying to pacman -Rnsc glib2 or pacman -Rnsc cairo results in removal of the whole KDE desktop

Yeah, in hindsight, it's probably impossible to get a KDE desktop sans glib/gtk dependency these days without compiling everything yourself. QtCore will try to build with glib based mainloop support by default, and I think the gtk style for QtWidgets comes by default as well.

Comment

Something I've never gotten is WHY each desktop environment feels like needs to build a terminal off of their libraries. Why isn't there an non-desktop linked standard terminal so we can all move on?

A stand alone terminal will need to duplicate a whole lot of functionality the GUI tool kits already implement. i.e. If you wanted a stand alone Terminal, you'd need to write a font rendering library, an abstraction around the native APIs (X and Wayland for linux, USER\MFC\.Net\Metro for Windows...), something for concurrency, something to handle mouse input, audio output for the beeps and such, maybe an image library to go beyond vt100... Essentially, you'll be writing a fair sized GUI Tool Kit even before starting.

Historically, GTK started in much the same way: it originates from GIMP as the widgets were fractured out into a library. Only Qt was conceived as a C++ GUI Tool Kit right from the start. Similarly, EFL originates from the Enlightenment developers who, after the original DE, decided they need to start from the libraries and work their way up.

Currently, all the libraries are now mostly capable separate entities that offer a whole suit of functionalities. e.g. They all have an internal threading approach\implementation. And they all abstract the native APIs completely so in principle it's possible to write cross platform applications.