On 08/28/2012 07:01 PM, Darrell Anderson wrote:
> I suspect the KDE3 and Trinity camps could work together --- but the
> proverbial olive branch is to strip the TQ interface from Trinity. Basically,
> that interface layer is why certain developers left Trinity. I appreciate
> that if we want to use Qt4 tools we must avoid symbol collisions. A
> fundamental question is whether using Qt4 tools is sufficient reason to keep
> the two camps separated. If that layer was removed and we merged forces, will
> we all collectively be better off? Or is going our separate ways, which is to
> eventual project deaths, the preferred option?

The benefit in joining forces with Ilya's effort at openSuSE, is that not only
do they have a lot of talent with current tde experience (Serghei, Robert, Ilya,
etc...), but they also have a couple of the original KDE3 developers serving in
advisory capacity (Stephenson, primarily...). The value in that type of
experience cannot be understated in helping quickly narrow down issues, but also
in providing direction for solutions to those problems that work kde/tde wide
without integration problems.

Simply trying to keep up with the insane core compiler and library changes in
the past 4 months have been a nightmare, starting with HAL, libpng, gcc, ffmpeg,
and the list goes on ...  None that difficult to handle in isolation, but
combined, and combined with the attempt to advance R14 at the same time, it is
simply overwhelming.

Smaller bites at the apple are called for during times of rapid change. There is
nothing wrong with stabilizing R14 and releasing it HAL based while tdehwlib
incubates a bit longer. The HAL replacement will take a great deal of work and a
great deal of time to implement. HAL does so many different and varied things
that TDE relies on, that expecting to simply replace it in a couple months time
will lead to nothing but more frustration.

Since SuSE is in the same boat, it just makes sense to work together to craft a
replacement that works for KDE/TDE. Those are the only two project that will
care about the end product of the effort, but both will have equal stake in it
being a reliable and robust replacement for HAL.

Whether it is called tdehwlib or HAL2 doesn't matter. The fact of the matter is
both need a HAL2.

So the options are to either join forces and jointly develop a replacement, or
each separately attempt to invent a replacement. The latter will take a great
deal longer and simply interject additional incompatibility in two different
versions of kde3.

-- 
David C. Rankin, J.D.,P.E.