Meta-observation: There are three primary applications everyone wants fairly uniformly. Firefox, LO, and VLC.
It is really interesting from an integration perspective to consider all three:
* Firefox pulls in gtk3 and gtk2 dependencies.
* VLC pulls in Qt and sdl1.
* LO pulls in Python.
Of note, both Firefox and VLC use ffmpeg, which is nice.
But my macro point - the most popular applications for Linux right now all use pretty much entirely different infrastructure. All three pull in at least a dozen library or package dependencies each, there is little overlap, and between them you have the entirety of GTK and Qt. On top of that, they are about 130MB, 50MB, and 400MB installed respectively.
I'm not going to make conclusions about how this relates to the desire to write composable software, or how these various monolith projects are also the most desired. It is just interesting that just from the big three staples you are looking at more space used on installation media than a CD just from them and their immediate dependencies. Qt alone is around 400MB including webengine. Gtk is another 90MB. So you are looking at over 1GB of binaries, libraries, and art assets to run 3 programs, and at runtime they will all be pulling these respective libraries into resident memory with almost no overlap.
Its foolishness to try to find a whole list of apps that use the same gui toolkit instead of the best apps, python is installed by default on every linux system under the sun, and you can't just convert from installed size to memory usage. The universe just doesn't work that way.
Its not installed size to memory usage. Its shared common libraries vs unshared libraries. Pulling in Qt means every Qt app will load so's for all the same things the core GTK libraries do, and take up memory that in a purely GTK environment would never be used because all the apps shared the same libraries in memory. This also dramatically affects the performance of app switching and opening new apps.
This is how Android has a tiny memory footprint - one gui toolkit, one runtime, one way to do everything. You really notice on Android when you open an NDK app that isn't using the Android Frameworks GUI components because they take a long time to open.
This is also why Windows in general is a bloated mess - depending on what software you are running it might be Windows Forms or XDA or their new app frameworks (Metro and/or 10) or .net or Qt or the old style COM API from the 95-98 days. Or worse, nowadays, you can get an Electron app that starts up its own browser rendering engine and doesn't share anything with the Chrome instance you have running at the same time despite using the same libraries. None share fundamental primitives, so opening programs from each toolkit eats memory alive. And then every program you install pretty much has to assume you don't have any library dependencies installed as well, so they pull down their entire toolkit in some .Z patch version that is incompatible with any other app using it so almost the same library gets loaded multiple times.
It is really interesting from an integration perspective to consider all three:
* Firefox pulls in gtk3 and gtk2 dependencies.
* VLC pulls in Qt and sdl1.
* LO pulls in Python.
Of note, both Firefox and VLC use ffmpeg, which is nice.
But my macro point - the most popular applications for Linux right now all use pretty much entirely different infrastructure. All three pull in at least a dozen library or package dependencies each, there is little overlap, and between them you have the entirety of GTK and Qt. On top of that, they are about 130MB, 50MB, and 400MB installed respectively.
I'm not going to make conclusions about how this relates to the desire to write composable software, or how these various monolith projects are also the most desired. It is just interesting that just from the big three staples you are looking at more space used on installation media than a CD just from them and their immediate dependencies. Qt alone is around 400MB including webengine. Gtk is another 90MB. So you are looking at over 1GB of binaries, libraries, and art assets to run 3 programs, and at runtime they will all be pulling these respective libraries into resident memory with almost no overlap.