> > I just think it's a bit silly that there are multiple
> > KDE3 forks. I don't see how our project has any incentive to keep our
> > code the same. Since the changes are nominal, a quick search and
> > replace will probably make it usable with other kde3 versions.
> 
> One of the reasons behind the multiple forks is the TQt VS
> Qt issue. That's why it is important to have a good motivation and
> explanation around this. Especially if you consider multiple forks silly
> and you want to work towards more unification.
> 
> I understand that TQt inside the Trinity source was part of
> an approach that is replaced partly now by another approach on the
> library side. I hope Timothy can be a bit more clear about all the details.
> 
> At one point there was the question of compiling Trinity
> code against either Qt3 or Qt4 with TQt. Now there seems to be the
> approach to combine Qt3 and Qt4 usage in a single application (but I
> also see TQt mentioned then). Right now it has become a bit unclear for
> most people which things serve exactly which purpose. Maybe there is
> also already some documentation on this that I'm overlooking?

There are no technical papers at the wiki explaining the benefits, reasons, or how the TQt layer functions. Without this information, TQt becomes a "black box" or more crudely, a pain in the butt because nobody understands the vision or the technical functionality in order to embrace a positive attitude.

My personal view is if TQt adds value to the existing KDE3 code base, then let's push some technical papers to the wiki. Good information tends to quiet people and helps them understand the vision.

A few people have left or reduced participation with Trinity because of the TQt debate. I am aware that some people with OpenSuse are keeping KDE3 alive. Yet I am unaware of other KDE3 forks. Where are these projects?

Significant effort was put into TQt. Yet there have been times in my computer projects when I faced the reality that previous time and energy invested was not going to provide perceived long-term benefits and I abandoned the idea. If TQt is becoming one of those types of projects then let's get this in the open and discussed. If TQt is a non negotiable then this project becomes little different from other notable software projects --- unless there is information available explaining the vision and functionality.

If TQt is a good idea but can't be supported long-term because of a lack of manpower, then we make a hard decision to remove TQt and move on.

If removing TQt encourages people to become involved and unifies the various KDE3 continuation efforts, then I believe we need to consider that avenue.

If TQt is alienating people and causing KDE3 forks, then we all have lost and the other desktops prevail by attrition and splintering. I'm sure that tickles the hell out of some people who never wanted KDE3 extended in any way.

Darrell