You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
||2 years ago|
|admin@68f23556e6||2 years ago|
|cmake@74654feb3b||2 years ago|
|qtinterface||2 years ago|
|.gitmodules||10 years ago|
|AUTHORS||11 years ago|
|CMakeLists.txt||3 years ago|
|COPYING||11 years ago|
|ConfigureChecks.cmake||3 years ago|
|Makefile.am.in||11 years ago|
|NAMING||11 years ago|
|README||11 years ago|
|TODO||11 years ago|
|configure.in.bot||11 years ago|
|configure.in.in||3 years ago|
|configure.in.mid||3 years ago|
|tqtinterface.lsm||6 years ago|
In this file:
* About tqtinterface
* Common Mistakes
* Compile Problems
* More Info
This is version 3.5.12 of the Trinity Qt Interface
This package includes libraries that abstract the underlying Qt system from
the actual Trinity code, allowing easy, complete upgrades to new versions of Qt.
It also contains various functions that have been removed from newer versions of Qt,
but are completely portable and isolated from other APIs such as Xorg. This allows
the Trinity project to efficiently perform certain operations that are infeasible
or unneccessarily difficult when using pure Qt4 or above.
The man Qt interface library. Any Qt functions you wish to use
need to be prefixed with a T. For example, QTimer becomes TQTimer.
We will handle all required Qt calls. Do not touch your television.
We will adjust it for you. ;-)
The libraries themselves have been covered (since Tuesday, June 29, 2010)
by the GNU General Public License (GPL). Any other programs (such
as the examples) are covered by the GNU General Public License (GPL). All
the gory details for the LGPL reside in COPYING.LIB, and for the GPL reside
When in doubt, check the individual file, they should all have license
headings and other identifying marks.
If configure claims Qt cannot be found, look at http://www.trolltech.com
to get a copy of Qt, version 3.3.0 or newer. If you have peeked there
already, grab the SVN module qt-copy from anonsvn.kde.org, or a snapshot
thereof. Alternatively the svn module qt-copy from svn.kde.org can also be
You can use --enable-debug with the configure script, if you want to have
debug code in your Trinity libs. If you have the space and can stand code that's
somewhat slower, this is worth it. The extra information really
helps debugging and thus bugfixing.
On the other hand, --disable-debug removes all debug messages, leading
to a faster and cleaner desktop.
See also the file DEBUG.
Often, Trinity compile failures are not Trinity's fault but the one of the
compiler or the distribution used. For that reason, please have a look at
http://developer.kde.org/build/compilationfaq.html for known issues in certain OS
environments before reporting bugs or going mad :).
gcc 3.0/3.0.1 is not yet able to compile all of Trinity without errors, mostly
due to bugs in this version of the compiler. Some older version of gcc 2.96
also have problems compiling Trinity due to compiler bugs. Even though
compilation may not report errors with these compiler, the usage of these
compilers may cause crashes when using the resulting executables.
If you are running a FreeBSD system, you will need to make sure that LIBS
is set to "-Wl,-export-dynamic". The easiest way to do this is to prefix
configure with it, i.e.: LIBS="-Wl,-export-dynamic" ./configure. Thanks to
Will Andrews <will@FreeBSD.org> and Arun Sharma <email@example.com>
for identifying what needed to be done, and how to do it, and such.
If you get odd error such as:
as: Error: /var/tmp/ccK1Cfxa.s, line 2827: Truncating token:
and you're using egcs, try re-compiling all your C++ libs with -fsquangle,
and then recompiling whatever you were working on with -fsquangle. It
should help, and more information about this is available on the egcs FAQ
available at http://egcs.cygnus.com
How to report
Reporting bugs is an art. Why? Because bug reports can help and hinder.
They hinder if the developers are just buried in an avalanche of bug reports.
They spend hours figuring out which bug reports are valid and which aren't,
which bug reports are due to bugs or due to installation problems.
They can be of tremendous help to notify developers on problems in areas that
they normally don't have access (e.g. Trinity on AIX) to.
So, here are some tips on bug reporting:
* make sure your bug is due to Trinity ... and not due to a packaging problem of
your Linux distributor. For example, most "I can not install the XYZ.rpm"
problem are due to packaging issues. Refer with such questions to your
Linux Distributor and his appropriate mailing list or bug reporting tool.
* The chance is high that your bug has already been dealt with ... so look
if there is a newer version of tqtinterface available. Reporting bugs for
older, deprecated versions usually don't get that much attention :-)
* Also the chance is high that another one experienced your problem. The
bug report wizard at http://bugs.pearsoncomputing.net will help you to
find out if your problem has already been reported.
* The best bug report for a project based on voluntary work is of course one
that comes with a patch that solves the problem. :-)