Tim, Darrell, All,
In the process of attempting to get the khelpcenter documents all collected in
one spot in 3513-sru, I have found a simple setting that will allow both R14 and
3513-sru to standardize their document locations. The primary issue is that the
base document path is hardcoded in tdelibs/kdecore/kstandarddirs.cpp on lines
1041-1042:
1041 if (!strcmp(type, "html"))
1042 return "share/doc/kde/HTML/";
All autotools build packages, on the other hand, set the equivalent path to:
return "share/doc/HTML/";
During April (10 & 11), Darrell fixed the R14 document locations. At that time
there was no focus on 3513-sru as a branch. Instead of changing the hardcoded
location in tdelibs to remove ../kde/.. to match all autotools package locations
and changing the CMake files as originally envisioned, hundreds of individual
patches were submitted to change all autotools acinclude.m4 files to move
helpcenter docs from:
kde_htmldir='\${datadir}/doc/HTML'
to
kde_htmldir='\${datadir}/doc/tde/HTML'
That works fine for R14, but interjects incompatibility between R14 and 3513
essentially requiring 2-sets of hundreds of patches just to change the
kde_htmldir to '\${datadir}/doc/tde/HTML' (in the case of R14) and to
'\${datadir}/doc/kde/HTML' (for 3513).
Why not fix this once and for all, fix tdelibs, and just set:
kde_htmldir='\${datadir}/doc/HTML'
for all??
That way, instead of patching hundreds of autotools packages, the original
location in tdelibs is standardized where it should be in 'kstandarddirs.cpp',
the CMake files are corrected to match the original kde_htmldir locations in
their sources, and all future CMake migration can go forward without every set
of files having to set kde_htmldir and reset it for 3513 in another set of
patches... (this stuff should be standard anyway -- there is absolutely no need
to have 'kde' or 'tde' in the middle of kde_htmldir)
This would eliminate hundreds of patches required to change to 'tde' for R14
and to 'kde' for 3513 and move all sources back closer to their pristine state.
This couldn't have been envisioned in April, but if we are serious about
providing a 3513-sru branch and R14, then I think this is the right way to do it.
See: http://www.trinitydesktop.org/patches/ The set of commits at issue are
between the following:
398ef116 2012-04-10
4e430ec6 2012-04-11
Thoughts?
--
David C. Rankin, J.D.,P.E.
I created and tested a patch to add an option in kpdf Settings->General to control whether kpdf stores viewing metadata files.
http://bugs.pearsoncomputing.net/show_bug.cgi?id=1215
The patch works for me in R14 GIT. I'd be grateful if somebody else would test the patch.
I believe the patch is backwards compatible with 3.5.13.1, although not necessary for 3.5.13.1.
Darrell
I created and tested a patch to add an option in kcontrol->privacy to delete kpdf metadata files.
http://bugs.pearsoncomputing.net/show_bug.cgi?id=1216
The patch works for me in R14 GIT. I'd be grateful if somebody else would test the patch.
I believe the patch is backwards compatible with 3.5.13.1, although not necessary for 3.5.13.1.
Darrell
With most Trinity packages, testing is straightforward: run the apps. Not so with tdebindings.
To those who are familiar with how tdebindings works, please consider helping with writing a short wiki article for testing tdebindings. Or, help create a collection of scripts and prebuilt executables that demonstrate they bind/hook into Trinity.
Thanks!
Darrell
Hello,
I currently have ubuntu oneiric.
Can I upgrade to their newest desktop and still use trinity? I need to
access newer library calls for work.
Calvin
Hi,
when I update a package koffice-i18n I realized that it is necessary to carry
out rebranding Krita => Chalk. Please, can make it done someone who has more
experience in this?
Many thanks
Slavek
--
Tim,
I noticed that for R14 is in build-deps ready "better" version of
sudo-trinity. I wanted to put this into v3.5.13.1, but there is a problem
with the version number. Previous package sudo-trinity had a version derived
from the original package sudo - for example 1.7.2p7-1. New package has
version 1.0, but this making it the "older" than previous package.
It would be possible to increase the number of "epoch" in package - for
example to package version 1:1.0-1?
Slavek
--
If I understand correctly, kpdf uses xpdf as a base rendering engine. The xpdf code in the Trinity source tree uses 3.02 from February 2007, which has been patched for security reasons several times since then.
There also is a patch to improve a scrolling speed bug that is caused by more recent gcc versions.
The most recent version of xpdf is 3.03.
Many distros have these patches applied or use 3.03.
* Does compiling kpdf use an existing installed xpdf from the distro or does the build process only use the xpdf code that is in the kpdf source tree?
* If the latter, then should we be patching the Trinity version of xpdf? Or updating to the latest release of xpdf?
* If the latter, what is needed to change the build process to use an existing installed xpdf rather than the stale version in the Trinity sources?
Darrell
Considering the original volume of changes needed, we're about as okay as we can expect, but --- we still find branding issues. For example, today I found some more and I am pushing patches.
To resolve remaining branding issues we need the following:
* Some really smart person to grep the system properly looking for corrupt image files (png, xcf, jpg/jpeg, whatever else might be out there). We can't inspect those images for branding issues. For whatever reason, seems many of the images got corrupted with CR/LF issues. We have found most of the corrupt files (walch.martin found most of them --- I only pushed clean files), but I don't know of a good way to search the sources for corrupt image files.
(Note: Corrupt image files do not block building packages, but they cause usability issues that reflect badly on us).
* Some really smart person to grep the system looking for text strings containing KDE. I haven't figured out a slick way to search the sources for these branding issues. Again, I think we have found most but we continually find more, albeit a smaller number of these strings appear each time. The challenge is we *cannot* do a blind global search-and-replace. We are at the point where we have to review each potential suspect string in context to ensure we are updating human-viewable text strings and not code strings.
* Some really smart person to figure out how the fifteenpieces applet About dialog is sucking in a KDE3 branded image (bug report 1052). I don't know whether the problem is limited to fifteenpieces or whether the image being used is a global default About image. One way or another we need to find that image and update.
* Internationalization (tde-i18n) files are beyond me. I nonetheless have patched many of these files. Most of the changes have been in the nature of KDE->TDE, but I suspect that in those patches occasionally I presumed incorrectly and changed something that changed contextual meaning. I don't know how we are going to resolve the differences between the tde-18n files and the parent files in the main source tree (po files, *.desktop files, *.docbook files, etc.)
Darrell
