Hi all.
As you probably noticed, I tried to solve the problem with style QtCurve. One of the problems was compiling with Qt3 instead of TQt3. Unexpected problem is the automatic substitution TQt => Qt that performs moc-tqt / tmoc. It affects not only the classes and names from TQt3/Qt3, but all - in this case also TQtCurveStylePlugin, TQtCurveStyle, TQtCurveConfig. But tqt.h of course does not care nothing about these classes. And thus bringing into conflict results 'moc' and source files 'h' and 'cpp'.
Therefore I wanted to ask if anyone would have any objections if I'll revert all classes TQtCurve* back to QtCurve*?
Slavek --
Hi all.
As you probably noticed, I tried to solve the problem with style QtCurve. One of the problems was compiling with Qt3 instead of TQt3. Unexpected problem is the automatic substitution TQt => Qt that performs moc-tqt / tmoc. It affects not only the classes and names from TQt3/Qt3, but all - in this case also TQtCurveStylePlugin, TQtCurveStyle, TQtCurveConfig. But tqt.h of course does not care nothing about these classes. And thus bringing into conflict results 'moc' and source files 'h' and 'cpp'.
Therefore I wanted to ask if anyone would have any objections if I'll revert all classes TQtCurve* back to QtCurve*?
Slavek
I think the upstream QtCurve project is progressing for Qt4 and KDE4; wouldn't the proposed rename bring our version into naming conflict with their version?
Tim
Hi all.
As you probably noticed, I tried to solve the problem with style QtCurve. One of the problems was compiling with Qt3 instead of TQt3. Unexpected problem is the automatic substitution TQt => Qt that performs moc-tqt / tmoc. It affects not only the classes and names from TQt3/Qt3, but all - in this case also TQtCurveStylePlugin, TQtCurveStyle, TQtCurveConfig. But tqt.h of course does not care nothing about these classes. And thus bringing into conflict results 'moc' and source files 'h' and 'cpp'.
Therefore I wanted to ask if anyone would have any objections if I'll revert all classes TQtCurve* back to QtCurve*?
Slavek
I think the upstream QtCurve project is progressing for Qt4 and KDE4; wouldn't the proposed rename bring our version into naming conflict with their version?
Tim
I should mention that I am not opposed to renaming the classes, I am just wondering if there might be a better name that won't conflict with a different project.
Tim
On Saturday 01 of September 2012 04:15:53 Timothy Pearson wrote:
I should mention that I am not opposed to renaming the classes, I am just wondering if there might be a better name that won't conflict with a different project.
I believe that it is useful consensus to use name QtCurve because also gtk2-engines-qtcurve refer to the same name QtCurve. Without having had anything to do with QT3 / QT4 / KDE. And in same manner also our tde-style-qtcurve refer to the same style name QtCurve.
Renaming TQtCurve* classes to QtCurve* is a simplification of a technical problem with the automatic renaming TQt=>Qt during build along with Qt3.
Slavek --
On Saturday 01 of September 2012 04:15:53 Timothy Pearson wrote:
I should mention that I am not opposed to renaming the classes, I am just wondering if there might be a better name that won't conflict with a different project.
I believe that it is useful consensus to use name QtCurve because also gtk2-engines-qtcurve refer to the same name QtCurve. Without having had anything to do with QT3 / QT4 / KDE. And in same manner also our tde-style-qtcurve refer to the same style name QtCurve.
Renaming TQtCurve* classes to QtCurve* is a simplification of a technical problem with the automatic renaming TQt=>Qt during build along with Qt3.
Slavek
OK, works for me with the justification given above. Rename away. :-)
Tim
-
Slávek Banko -
Timothy Pearson