<snip> > 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? 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. > 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. No offense intended! > >> 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? 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. > 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