All I can say is that it takes a large subset of
kdelibs/kdebase to do
that:
$ ldd konqueror |grep trin
libkdeinit_konqueror.so => /opt/trinity/lib/libkdeinit_konqueror.so
libkonq.so.4 => /opt/trinity/lib/libkonq.so.4
libkutils.so.1 => /opt/trinity/lib/libkutils.so.1
libkparts.so.2 => /opt/trinity/lib/libkparts.so.2
libkio.so.4 => /opt/trinity/lib/libkio.so.4
libkdeui.so.4 => /opt/trinity/lib/libkdeui.so.4
libkdesu.so.4 => /opt/trinity/lib/libkdesu.so.4
libkwalletclient.so.1 => /opt/trinity/lib/libkwalletclient.so.1
libkdecore.so.4 => /opt/trinity/lib/libkdecore.so.4
libDCOP.so.4 => /opt/trinity/lib/libDCOP.so.4
libkdefx.so.4 => /opt/trinity/lib/libkdefx.so.4
libtqt.so.4 => /opt/trinity/lib/libtqt.so.4
All of these are included in kdelibs, therefore not requiring kdebase at
all.
All I can say is that it is not a simple proposition. One person wants
konqueror, another wants konsole and kate, yet another will want something
else. Disk space is pretty cheap. It seems like a lot of work for little
advantage.
I am aware that it does drag in a hefty bit of libraries. Here is a quote
from a user who mentioned this on reddit today:
"So? Start with Trinity, strip away everything that isn't needed for
Konqueror 3 functionality, and package it? I don't *care* if the end result
is half a Gig in size - that doesn't matter. The functionality does"
Essentially Konqueror doesn't need the rest of tdebase, and most of what it
depends on is from tdelibs. What it does depend on can be packaged in with
it.
Konqueror on my machine pulls in 72 different libraries, as a comparison,
firefox pulls in at 57 and mplayer at 142
I think it might be worth considering,
Calvin Morrison
Besides, through modularizations we allow users to choose what
actually goes in their system.
I think it's a good idea.