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.