Replace QObject, QWidget, QImage, QPair, QRgb, QColor, QChar, QString, QIODevice with TQ* version #29
Merged
MicheleC
merged 1 commits from replace/qobjects
into master
7 months ago
Loading…
Reference in new issue
There is no content yet.
Delete Branch 'replace/qobjects'
Deleting a branch is permanent. It CANNOT be undone. Continue?
As per title.
Don't get fool by Gitea when reviewing .diff files.
It looks like quite bold to make changes in the diff file, although they are just for testing. Are you sure we want to do it?
Next to this, there are some comments about changes in history records.
And there are renames in parts that relate to Qt4/KDE code.
* Use DCOP stubs to access the methods of the cvs DCOP service
* Added new method update() and checkout() to DCOP service
* Use TDEProcess::operator<< instead of QString::operator+= to
* Use TDEProcess::operator<< instead of TQString::operator+= to
Does it make sense to edit history records?
Feb-04-2001 - Kurt Granroth (v1.0.3)
o Converted App::load method to use KURL instead of QString in kapp
o Converted App::load method to use KURL instead of TQString in kapp
Does it make sense to edit history records?
Sep 22, 2003 : Otto Bruggeman
* Added openStdin() to KompareShell
* Fixed stupid implicit conversion from QString to QStringList in kompare_part.cpp
* Fixed stupid implicit conversion from TQString to QStringList in kompare_part.cpp
Does it make sense to edit history records?
end
document printq4string
Prints the contents of a Qt QString
Prints the contents of a Qt TQString
The code is probably related to Qt4, renaming seems not appropriate.
end
document printq4stringdata
Prints the contents of a Qt4 QString::Data
Prints the contents of a Qt4 TQString::Data
The code is probably related to Qt4, renaming seems not appropriate.
shows {d = 0xdeadbeef} for a QString, i.e. the qstringdata address
instead of the QString object itself.
shows {d = 0xdeadbeef} for a TQString, i.e. the qstringdata address
instead of the TQString object itself.
The code is probably related to Qt4, renaming seems not appropriate.
In one line, unwanted renaming was resolved, remaining in the second line 😉
ah yes, my bad. I missed the second one. PR updated.
# Bad implementation, requires a running process.
# Needs to be refined, i.e. figuring out the right void* pointers casts.
# Simon says: each Node contains the d pointer of the QString.
# Simon says: each Node contains the d pointer of the TQString.
The code is probably related to Qt4, renaming seems not appropriate.
elseif a:ident =~ 'QListBox.*'
return '<qlistbox.h>'
elseif a:ident == 'QChar' ||
elseif a:ident == 'TQChar' ||
This file seems to be concentrated on Qt/KDE code and no renaming changes have been made. Making little renaming now makes it inconsistent.
It will look inconsistent for a while, but overtime we will need to replace all those Q* object names with TQ* ones. The vim macro looks for an include file based on the type name, so using Q* types will not work with TQt3.
There it seemed to me that the renames for the time being passed this file and that it was consistently old. But as I see, some renaming was done, so the file is really already in an inconsistent state. So ok, other inconsistency does not make the condition worse.
(qvalidator.h QIntValidator QDoubleValidator QRegExpValidator)
(qlistbox.h QListBoxItem QListBoxText QListBoxPixmap)
(qstring.h QChar QCharRef QConstString)
(qstring.h TQChar QCharRef QConstString)
This file seems to be concentrated on Qt/KDE code and no renaming changes have been made. Making little renaming now makes it inconsistent.
Likewise, we will be renaming more and more over time as we progress the Qt -> TQt conversion.
cbf17787e6
tod6fa23bc92
7 months agoPR updated for all resolved points.
d6fa23bc92
to0ffe839d6e
7 months agoAll seems good.
0ffe839d6e
into master 7 months agoReviewers
0ffe839d6e
.