16 Aug
2011
16 Aug
'11
9:58 p.m.
<snip>
No. There is an API stub and some initial work in the Qt3 GIT that has
not yet been functionally tested, and probably will not be until after
Trinity 3.5.13 is released.
<snip>
I don't like to call anyone a troll. Simply asking for clarification and
stating your reasons for keeping the KDE3.5.10 plugin version would have
avoided this entire flame war. In the future please ask a question and/or
state your reasoning for needing something a certain way before making the
types of strong statements that you made in this thread.
No offense intended!
Something else entirely--the class names buried within the shared object
files. Google it. :-) Specifically, if there are two different versions
of a class such as "QWidget" the C++ linker cannot decide which one to
use, both at compile time and at runtime. This makes it impossible to use
Qt3 and Qt4 together in a single application, and is something that is
being corrected with the migration to TQt.
No crashes for more than a year here.
Crashes sporadically on every version of KDE from 3.5.10 to the latest
Trinity 3.5.12 for me. It probably has something to do with my heavy use
of the filter bar on directories with lots of files; this makes perfect
sense, as the underlying cause of the problem is a race condition caused
by Trinity not having access to certain internal Qt data members.
One of our goals is to add new
methods to Qt3 in order to clean up the hacks in the Trinity source,
thereby stabilizing the system.
Good endeavor.
One of the bugs causes a crash sporadically when
the filter bar is used
in
icon mode. The cause is a missing visibility set feature in QIconView.
The only resolution is to fix Qt3. There are other examples, but I hope
you get my drift.
Good. Is this patch already included in 3.3.8c? By the way if Robert would advance in packaging
Trinity we
would
consider using Trinity now.
Robert, please advise here. I think we have been having more friction
than neccessary between OpenSUSE and Trinity due to the lack of RPM
packages. I noticed a lot of commits to the Trinity packaging GIT
recently; how are things progressing?
Be careful what you say if you don't want to
be judged.
I just do not bother with your offenses. By the way, if you continue to use the Qt C++
namespace you will run
into
problems eventually. Technically you are stepping on the toes of Qt4
and
any applications built with Qt4, which is not a good thing to do.
Sorry I do not understand this. Which collisions are you speaking about?
Collisions of filenames or something else? OK. I just do not understand why it is necessary to
link with tqtinterface
non-KDE and non-Qt3 applications such as LO.
LO *is* a KDE/TDE *and* Qt3 application as soon as you set that
--enable-kde configure flag. Granted, the only files that will be
compiled/linked against Qt3 and KDE/TDE are the file picker and themer,
but they are still part of LO and still part of the resultant LO
installation. If all the other Trinity source uses the TQt C++ classes,
then the TDE portions of LO are among the only applications preventing
usage of Qt3 and Qt4 together.
As I said, I am looking into the LO build system in detail now, and will
advise later on as to what I think is feasible. For now we will use the
old KDE3 integration present in LO 3.x.
Tim