On Wednesday 15 February 2012 21:08:09 Timothy Pearson wrote: You right, but better method to avoid conflicts is to prefix all relevant libraries with tde- or trinity-, like tde-kdecore.so or trinity-kdecore.so, etc. At least is consistent and predictable. Even if all changes are documented, coding become harder anyway, because we programming with qt/kde for years, and is hard to change our coding style. My free time is very limited, so I won't waste it learning new syntax, I want just to code, to add value to trinity project. So, if trinity project still need my help, it should maintain a more conservative line. Sorry for my critics, right now i'm angry because I waste few minutes to understand why my ksocketdevice.h disapeared :) -- Serghei.

I understand the frustration with the renaming. I too am sometimes frustrated by the renaming or the tqtinterface layer, especially when tracking bugs and needing to compare code to 3.5.10. Yet this is a frustration I'm willing to tolerate. As a long-term project goal, I would like to see everything renamed for the simple reasons that Trinity never would conflict with KDE4 and could be installed in /usr. Several bug reports I have submitted are related to installing Trinity in a non standard location or needing to use full pathnames to avoid KDE3/KDE4 apps of the same name. As a team we don't test for these conflicts. A complete renaming avoids potential legal issues too. I do have some grasp of the enormity of renaming everything. Currently I am editing and updating the user guides and just about every paragraph and web link needs attention. The same comprehensive approach would be needed to a complete renaming. I'm in favor of adding a complete renaming effort to the R15 goals. Many apps and shared library files can be renamed by transposing the "k" prefix with "t" or "kde" with "tde." I realize some apps do not lend well to that renaming (konqueror, kate, konsole, etc.). We likely will have to find a new name altogether. I understand and appreciate the adjustments all of us would have to make to rewire our minds to the new names. Not to mention exhaustive testing. Yet I think in the long run renaming everything is better. Darrell

On Wed, 15 Feb 2012 23:26:01 +0200 Serghei Amelian <serghei(a)thel.ro> wrote: Do we really need to rename the .so files ? On my system: dd@darkstar:/usr/lib$ ls -l libkdecore* lrwxrwxrwx 1 root root 15 Dec 21 23:08 libkdecore.so -> libkdecore.so.5* lrwxrwxrwx 1 root root 19 Dec 21 23:08 libkdecore.so.5 -> libkdecore.so.5.4.0* -rwxr-xr-x 1 root root 2431824 Apr 11 2011 libkdecore.so.5.4.0* dd@darkstar:/usr/lib$ cd /opt/kde3/lib dd@darkstar:/opt/kde3/lib$ ls -l libkdecore* -rw-r--r-- 1 root root 754 Nov 4 20:22 libkdecore.la lrwxrwxrwx 1 root root 15 Nov 4 21:03 libkdecore.so -> libkdecore.so.4* lrwxrwxrwx 1 root root 19 Nov 4 21:03 libkdecore.so.4 -> libkdecore.so.4.2.0* -rwxr-xr-x 1 root root 2889852 Nov 4 20:42 libkdecore.so.4.2.0* We could have the libkdecore.so default (for example) to the KDE4 libkdecore.5.4.0, but still if we compile something against Trinity the dynamic linker would still use the libkdecore.so.4 file. It is/has been already done for libc and libstdc++, for example on my system: dd@darkstar:/usr/i486-slackware-linux/lib$ ls -l total 1944 lrwxrwxrwx 1 root root 18 Aug 8 2011 ldscripts -> /usr/lib/ldscripts/ -r-xr-xr-x 1 root root 272136 Feb 13 2010 libstdc++-3-libc6.1-2-2.10.0.so* -r-xr-xr-x 1 root root 274948 Feb 13 2010 libstdc++-3-libc6.2-2-2.10.0.so* lrwxrwxrwx 1 root root 31 Aug 8 2011 libstdc++-libc6.1-2.so.3 -> libstdc++-3-libc6.1-2-2.10.0.so* lrwxrwxrwx 1 root root 31 Aug 8 2011 libstdc++-libc6.2-2.so.3 -> libstdc++-3-libc6.2-2-2.10.0.so* lrwxrwxrwx 1 root root 18 Aug 8 2011 libstdc++.so.4 -> libstdc++.so.4.0.0* -rwxr-xr-x 1 root root 702796 Feb 13 2010 libstdc++.so.4.0.0* lrwxrwxrwx 1 root root 18 Aug 8 2011 libstdc++.so.5 -> libstdc++.so.5.0.7* -rwxr-xr-x 1 root root 732224 Feb 13 2010 libstdc++.so.5.0.7* Is there a gcc/ld option to tell it to link to libkdecore.so.4 if libkdecore.so points to libkdecore.so.5 ?

Yes we do. :-) Otherwise we are cutting off access to an entire suite of libraries that could otherwise be used to help the TDE project, for example WebKit or Qt4's multitouch handlers. And by the way, I have finally been able to compile a TQt3 application with Qt4 code in it as of today! This should open up interesting new doors; stay tuned. :-) Tim