When reviewing the source code, sometimes I see Qt:: prefixed and sometimes TQt::.
Which is correct? If both are correct then how does one determine appropriate context for each?
Thanks.
Darrell
When reviewing the source code, sometimes I see Qt:: prefixed and sometimes TQt::.
Which is correct? If both are correct then how does one
determine appropriate context for each?
Thanks.
Should be TQt::
Then when I find Qt:: in the source code I should patch?
Second, what, if any, kinds of bugs might result from using Qt:: rather than TQt::?
Darrell
When reviewing the source code, sometimes I see Qt:: prefixed and sometimes TQt::.
Which is correct? If both are correct then how does one
determine appropriate context for each?
Thanks.
Should be TQt::
Then when I find Qt:: in the source code I should patch?
Yes.
Second, what, if any, kinds of bugs might result from using Qt:: rather than TQt::?
None really--it's a readability issue only.
Tim
Timothy Pearson wrote:
Second, what, if any, kinds of bugs might result from using Qt:: rather than TQt::?
None really--it's a readability issue only.
Just a question out of interest. Wouldn't keeping Qt:: instead of using TQt:: make source compatibility with other KDE3 forks easier (regarding patches and so on)?
On Sat, Apr 14, 2012 at 5:19 PM, Julius Schwartzenberg julius.schwartzenberg@gmail.com wrote:
Timothy Pearson wrote:
Second, what, if any, kinds of bugs might result from using Qt:: rather than TQt::?
None really--it's a readability issue only.
Just a question out of interest. Wouldn't keeping Qt:: instead of using TQt:: make source compatibility with other KDE3 forks easier (regarding patches and so on)?
Agree. No reason for extra TQt spreading.
On 04/16/2012 12:02 PM, Aleksey Midenkov wrote:
On Sat, Apr 14, 2012 at 5:19 PM, Julius Schwartzenberg julius.schwartzenberg@gmail.com wrote:
Timothy Pearson wrote:
Second, what, if any, kinds of bugs might result from using Qt:: rather than TQt::?
None really--it's a readability issue only.
Just a question out of interest. Wouldn't keeping Qt:: instead of using TQt:: make source compatibility with other KDE3 forks easier (regarding patches and so on)?
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.
But seriously, can't we just pool our resources together and not split up? That's the problem with many splinter groups, they keep splintering up and up until there is nothing left and nobody is happy.
Calvin
Calvin Morrison wrote:
On 04/16/2012 12:02 PM, Aleksey Midenkov wrote:
On Sat, Apr 14, 2012 at 5:19 PM, Julius Schwartzenberg julius.schwartzenberg@gmail.com wrote:
Timothy Pearson wrote:
Second, what, if any, kinds of bugs might result from using Qt:: rather than TQt::?
None really--it's a readability issue only.
Just a question out of interest. Wouldn't keeping Qt:: instead of using TQt:: make source compatibility with other KDE3 forks easier (regarding patches and so on)?
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?
Julius
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
On Mon, 16 Apr 2012 13:23:05 -0700 (PDT) Darrell Anderson humanreadable@yahoo.com wrote:
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.
The intention as I understand it is to be able to use QT3 and QT4 in the same program. The use for this that's most often mentioned is replacing Konqueror's aging KHTML rendering engine with Webkit.
*However*, a closer examination of Webkit itself suggests that, if this is the only real use case for QT3 and QT4 being in the same program, we may be better off writing a QT3 port of Webkit and forgetting about QT4. More than half of the Webkit <-> QT4 glue code seems to consist of trivial one-line functions, and there's no reason to believe a QT3 version would need to be more complex.
Can anyone suggest other uses for QT3 and QT4 together? Does the new QT4 styling engine require this?
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?
Serghei said he was attempting a fork. So that's two.
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.
But seriously, can't we just pool our resources together and not split up? That's the problem with many splinter groups, they keep splintering up and up until there is nothing left and nobody is happy.
Life 101: People disagree. The challenge is letting everybody live in peace despite disagreeing.
With that said, I think we all can work together rather than splinter. To get there we need to know why everybody has splintered. That there are other KDE3 groups is news to me, but perhaps I live a sheltered life. :)
Darrell
-
Aleksey Midenkov -
Calvin Morrison -
Darrell Anderson -
E. Liddell -
Julius Schwartzenberg -
Timothy Pearson