Hi Tim,
For what reason "ksocketdevice.h" have been renamed to "ksockssocketdevice.h" ? Looking strange and redundant.
On Wednesday 15 February 2012 20:34:57 Serghei Amelian wrote:
Hi Tim,
For what reason "ksocketdevice.h" have been renamed to "ksockssocketdevice.h" ? Looking strange and redundant.
Actually, I find the entire process of renaming useless, inconsistent and frustrating. Now I should remember to link to tdecore-shared and kio-shared. One prefixed by "t", another by "k".
The same thing, tqtinterface. One more layer, which do not add any value to code. Just force me to remeber every time to prefix qt clases with TQ and pollute namespace.
For these reasons, few times I considered to join to Ilya's project, because is more conservative. After all, we are using a fork of a KDE3 because we are conservative, right?
On Wednesday 15 February 2012 20:34:57 Serghei Amelian wrote:
Hi Tim,
For what reason "ksocketdevice.h" have been renamed to "ksockssocketdevice.h" ? Looking strange and redundant.
That is a mistake and should be corrected.
Actually, I find the entire process of renaming useless, inconsistent and frustrating. Now I should remember to link to tdecore-shared and kio-shared. One prefixed by "t", another by "k".
The same thing, tqtinterface. One more layer, which do not add any value to code. Just force me to remeber every time to prefix qt clases with TQ and pollute namespace.
For these reasons, few times I considered to join to Ilya's project, because is more conservative. After all, we are using a fork of a KDE3 because we are conservative, right?
-- Serghei.
Without renaming TDE must always exist in /opt on a system with Qt4, KDE4, or any KDE4 applications, and will never be able to be incorporated into any major distribution's main archives as a result. Furthermore, we have received explicit requests for some of the renaming from the original project's authors, and as I am not a lawyer I do not want legal trouble from using a name that belongs to a different project. Additionally, it can be very confusing to have libraries with identical names and completely different functionality; e.g. kdecore (TDE) vs. kdecore (KDE4).
I know it can be a pain; I have put an Etherpad up that details exactly what has been renamed to try to make it a bit more bearable.
Tim
On Wednesday 15 February 2012 21:08:09 Timothy Pearson wrote:
Without renaming TDE must always exist in /opt on a system with Qt4, KDE4, or any KDE4 applications, and will never be able to be incorporated into any major distribution's main archives as a result. Furthermore, we have received explicit requests for some of the renaming from the original project's authors, and as I am not a lawyer I do not want legal trouble from using a name that belongs to a different project. Additionally, it can be very confusing to have libraries with identical names and completely different functionality; e.g. kdecore (TDE) vs. kdecore (KDE4).
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.
I know it can be a pain; I have put an Etherpad up that details exactly what has been renamed to try to make it a bit more bearable.
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 :)
Tim
On Feb 15, 2012 2:33 PM, "Serghei Amelian" serghei@thel.ro wrote:
On Wednesday 15 February 2012 21:08:09 Timothy Pearson wrote:
Without renaming TDE must always exist in /opt on a system with Qt4,
KDE4,
or any KDE4 applications, and will never be able to be incorporated into any major distribution's main archives as a result. Furthermore, we
have
received explicit requests for some of the renaming from the original project's authors, and as I am not a lawyer I do not want legal trouble from using a name that belongs to a different project. Additionally, it can be very confusing to have libraries with identical names and completely different functionality; e.g. kdecore (TDE) vs. kdecore
(KDE4).
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.
The question is, will that be enough for the KDE people who are requesting the rename? I think your suggestion might be fine whilst R14 is in development, but I'm not so sure about when it's released. It's best to either ask to be sure, or to continue renaming. Besides, as I understand it (I haven't been paying close attention), the rename has been planned since before the git migration, or at least shortly after, so the new names should not be a surprise :-)
Without renaming TDE must always exist in /opt on
a system with Qt4, KDE4,
or any KDE4 applications, and will never be able
to be incorporated into
any major distribution's main archives as a
result. Furthermore, we have
received explicit requests for some of the
renaming from the original
project's authors, and as I am not a lawyer I
do not want legal trouble
from using a name that belongs to a different
project. Additionally, it
can be very confusing to have libraries with
identical names and
completely different functionality; e.g. kdecore
(TDE) vs. kdecore (KDE4).
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.
The question is, will that be enough for the KDE people who are requesting the rename? I think your suggestion might be fine whilst R14 is in development, but I'm not so sure about when it's released. It's best to either ask to be sure, or to continue renaming. Besides, as I understand it (I haven't been paying close attention), the rename has been planned since before the git migration, or at least shortly after, so the new names should not be a surprise :-)
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 Wednesday 15 February 2012 23:13:54 Darrell Anderson wrote:
Without renaming TDE must always exist in /opt on
a system with Qt4, KDE4,
or any KDE4 applications, and will never be able
to be incorporated into
any major distribution's main archives as a
result. Furthermore, we have
received explicit requests for some of the
renaming from the original
project's authors, and as I am not a lawyer I
do not want legal trouble
from using a name that belongs to a different
project. Additionally, it
can be very confusing to have libraries with
identical names and
completely different functionality; e.g. kdecore
(TDE) vs. kdecore (KDE4).
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.
The question is, will that be enough for the KDE people who are requesting the rename? I think your suggestion might be fine whilst R14 is in development, but I'm not so sure about when it's released. It's best to either ask to be sure, or to continue renaming. Besides, as I understand it (I haven't been paying close attention), the rename has been planned since before the git migration, or at least shortly after, so the new names should not be a surprise :-)
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
I'm not against renaming libraries or executables. But they should be renamed in a consistent manner. I'm pretty sure that renaming kdecore.so to trinity-kdecore.so should be enough.
Also, I want to keep untouched the name of header files and function names. We really want to have applications which use Qt3 and Qt4 at same time? I can't imagine this kind of mess :)
On Wed, 15 Feb 2012 23:26:01 +0200 Serghei Amelian serghei@thel.ro wrote:
On Wednesday 15 February 2012 23:13:54 Darrell Anderson wrote:
Without renaming TDE must always exist in /opt on
a system with Qt4, KDE4,
or any KDE4 applications, and will never be able
to be incorporated into
any major distribution's main archives as a
result. Furthermore, we have
received explicit requests for some of the
renaming from the original
project's authors, and as I am not a lawyer I
do not want legal trouble
from using a name that belongs to a different
project. Additionally, it
can be very confusing to have libraries with
identical names and
completely different functionality; e.g. kdecore
(TDE) vs. kdecore (KDE4).
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.
The question is, will that be enough for the KDE people who are requesting the rename? I think your suggestion might be fine whilst R14 is in development, but I'm not so sure about when it's released. It's best to either ask to be sure, or to continue renaming. Besides, as I understand it (I haven't been paying close attention), the rename has been planned since before the git migration, or at least shortly after, so the new names should not be a surprise :-)
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
I'm not against renaming libraries or executables. But they should be renamed in a consistent manner. I'm pretty sure that renaming kdecore.so to trinity-kdecore.so should be enough.
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 ?
Also, I want to keep untouched the name of header files and function names. We really want to have applications which use Qt3 and Qt4 at same time? I can't imagine this kind of mess :)
On Wednesday 15 February 2012 23:38:38 /dev/ammo42 wrote: [...]
Is there a gcc/ld option to tell it to link to libkdecore.so.4 if libkdecore.so points to libkdecore.so.5 ?
Can be done, if we pass absolute path to linker. But i'm not sure that is good idea.
I'm not against renaming libraries or executables. But they should be renamed in a consistent manner. I'm pretty sure that renaming kdecore.so to trinity-kdecore.so should be enough.
Also, I want to keep untouched the name of header files and function names. We really want to have applications which use Qt3 and Qt4 at same time? I can't imagine this kind of mess :)
-- Serghei.
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
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,
As I am revising the user guide, I came across refrences to the following environment variables:
KDE_FORK_SLAVES KDE_HOME_READONLY KDE_NO_IPV6 KDE_IS_PRELINKED KDE_UTF8_FILENAMES KDESYCOCA KDE_LANG
My guess is they should be renamed to "TDE_" to avoid potentil conflicts with KDE3/KDE4 installations.
I have not looked at the sources to see whether those variables have been renamed. I'm throwing them out here so I don't forget now that the topic of renaming has surfaced. :)
Darrell
-
/dev/ammo42 -
Darrell Anderson -
Kristopher Gamrat -
Serghei Amelian -
Timothy Pearson