trinity-users@lists.pearsoncomputing.net

Message: previous - next
Month: January 2013

RE: [trinity-users] EXE GNU/Linux distrowatch

From: "Timothy Pearson" <kb9vqf@...>
Date: Thu, 24 Jan 2013 15:50:12 -0600
>> > I am currently looking into methods of using the improved KDE4
>> > components to enhance portions of TDE (e.g. Konqueror) while keeping
>> > the same stability and usability we currently have.  Stay tuned. :-)
>> >
>> > Tim
>>
>
> Tim,
> While I agree that some KDE4 apps are better than the TDE version (Dolphin
> is the first example of it, mostly because it appeared at the end of the
> KDE3 era), I fear that TDE will loose it's memory footprint over current
> KDE, which is in my opinion, the main reason to use TDE.
<snip>

I do understand your concern.  I will not be replacing any TDE component
that is still superior to its KDE counterpart; for a KDE component to be a
candidate for replacement it must:
1.) Provide all the functionality and configurability of its TDE counterpart
2.) Be better than its TDE counterpart in at least one respect
(performance, stability, compatibility with new file formats, etc.)
3.) Not use an appreciably higher amount of CPU or RAM, even in non-GPU
accelerated rendering modes
4.) Not drag in any system services or libraries which violate Point #3
above; this intrinsically excludes the entire KDE PIM suite due to the
bloated indexing services required for operation

The only items that I am aware of that might fit this list of criteria are
kwin, a handful of kcontrol modules, and possibly some smaller KDE
applications such as Okular.  kwin is my current focus, and so far seems
to work very well without increasing the memory or CPU footprint.  kwin
also satisfies Point #2 above by presenting a much smoother action in high
resolution TDE sessions when compared with twin due to its integrated
compositing engine.

Mozilla has explicitly stated that it will not support embedding Firefox
sessions in any third party application, and has removed all programming
hooks needed for doing so.  This leaves TDE with three long-term options:
1.) Use Webkit (preferred)
2.) Investigate embedding a Chromium instance
2.) Completely remove the KHTML kpart (not recommended)

I would prefer to embed a Webkit browser kpart, as I expect website
compatibility with Webkit to increase in the future, and a full-featured
Webkit widget already exists.

Now that some KDE components are finally stabilising and becoming true
replacements for their KDE3 counterparts, we should be attempting to
reintegrate this new and improved technology into TDE where appropriate.

Thoughts are of course welcome on these topics!

Tim