27 Jun
2012
27 Jun
'12
8:04 p.m.
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
28 Jun
28 Jun
7:05 p.m.
New subject: [trinity-devel] R14.0.0 Branding issues
On 06/27/2012 03:04 PM, Darrell Anderson wrote:
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).
This is tricky. Using 'file' to test even the corrupt jpeg images will return a
valid jpeg header in most cases and miss the fact that the image is corrupt. I
don't mind grepping or running find tde/main -type f -name "*.jpg" -execdir
<what> '{}' \;, but I need to know what <what> will do the trick.
Ideas?
* 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.
I'll give it a go. It will take either a recursive grep with an exclude or some
global find with an -exec that uses file to test for searchable files -- or some
combination of the two. Do you have any examples of what doesn't work so I don't
reinvent a nonworking wheel :)
* 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.
Fun... I think I still have the old threads.
* Internationalization (tde-i18n) files are beyond me.
(+1)
--
David C. Rankin, J.D.,P.E.
7:07 p.m.
New subject: [trinity-devel] R14.0.0 Branding issues
On 28 June 2012 15:05, David C. Rankin <drankinatty(a)suddenlinkmail.com>wrote;wrote:
On 06/27/2012 03:04 PM, Darrell Anderson wrote:
use an image program to open the image that will error out and close if the
file is corrupt. Check the return value of the program, if it exits with
an error, then echo "blah blah blah" or something.
Calvin
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).
This is tricky. Using 'file' to test even the corrupt jpeg images will
return a
valid jpeg header in most cases and miss the fact that the image is
corrupt. I
don't mind grepping or running find tde/main -type f -name "*.jpg"
-execdir
<what> '{}' \;, but I need to know what <what> will do the trick.
Ideas?
7:21 p.m.
New subject: [trinity-devel] R14.0.0 Branding issues
On 06/28/2012 02:07 PM, Calvin Morrison wrote:
use an image program to open the image that will error
out and close if the
file is corrupt. Check the return value of the program, if it exits with an
error, then echo "blah blah blah" or something.
Ahh 'feh' comes to mind... Thanks :)
--
David C. Rankin, J.D.,P.E.
7:58 p.m.
New subject: [trinity-devel] R14.0.0 Branding issues
use an image program to open the image that will error
out
and close if the file is corrupt. Check the return value
of the program, if it exits with an error, then echo
"blah blah blah" or something.
I thought about something like that, but I haven't figured out how to work around and
trap the eventual error dialog.
We could use kuickshow or kview to test png, gif, and jpg/jpeg images; gwenview to test
svg/svgz images; and the safest bet for xcf is gimp.
I haven't run any tests to see what kind of exit code those apps produce for success
and failure.
A script run during the night would be nice:
test_tde_image () {
for i in `find $GIT_SOURCES -name *.$FILE_TYPE`; do
$IMAGE_APP $i
# How to trap and close error dialogs? &>/dev/null?
# Allow time for images to load?
sleep 5
# How to close the app?
EXIT_CODE="$?"
if [ "$EXIT_CODE" != "0" ]; then
echo "$i failed to open without error." >> $LOG_FILE
fi
done
}
GIT_SOURCES=/path/to/GIT/sources
LOG_FILE=/path/to/corrupt-tde-image.log
touch $LOG_FILE
FILE_TYPE="png"
IMAGE_APP=kuickshow
test_tde_image
FILE_TYPE="gif"
IMAGE_APP=kuickshow
test_tde_image
FILE_TYPE="jpg"
IMAGE_APP=kuickshow
test_tde_image
FILE_TYPE="jpeg"
IMAGE_APP=kuickshow
test_tde_image
FILE_TYPE="svg"
IMAGE_APP=gwenview
test_tde_image
FILE_TYPE="svgz"
IMAGE_APP=gwenview
test_tde_image
FILE_TYPE="xcf"
IMAGE_APP=gimp
test_tde_image
Or something like that.
Darrell
4 Jul
4 Jul
10:03 a.m.
New subject: [trinity-devel] R14.0.0 Branding issues
On 28 Jun 2012, Calvin Morrison uttered the following:
use an image program to open the image that will error
out and close if the
file is corrupt.
Or use ImageMagick's identify(1), which will quit in both success and
failure cases with different exit codes.
--
NULL && (void)
28 Jun
28 Jun
7:18 p.m.
New subject: [trinity-devel] R14.0.0 Branding issues
On Thu, 28 Jun 2012 14:05:10 -0500
"David C. Rankin" <drankinatty(a)suddenlinkmail.com> wrote:
On 06/27/2012 03:04 PM, Darrell Anderson wrote:
Check to see if <CR> appears separately anywhere in the file, without a trailing
<LF>? If we're seeing a binary <-> text mode corruption problem, there
won't
be any separate <CR>s. Any file that's flagged as only containing the
<CRLF>
sequence should then be checked manually in an image viewer to make sure it's
okay.
(I don't know how to do the above with grep etc., but the actual match takes
1 line in Perl.)
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).
This is tricky. Using 'file' to test even the corrupt jpeg images will return a
valid jpeg header in most cases and miss the fact that the image is corrupt. I
don't mind grepping or running find tde/main -type f -name "*.jpg"
-execdir
<what> '{}' \;, but I need to know what <what> will do the trick.
Ideas?
7:48 p.m.
New subject: [trinity-devel] R14.0.0 Branding issues
Check to see if <CR> appears separately anywhere
in
the file, without a trailing <LF>? If we're seeing a binary <-> text
mode corruption problem, there won't be any separate <CR>s. Any file
that's flagged
as only containing the <CRLF> sequence should then be checked manually in an image
viewer
to make sure it's okay.
(I don't know how to do the above with grep etc., but the
actual match takes 1 line in Perl.)
I was about to open khexedit and study a few image files when I realized that not all
corruption errors will be caused by CR/LF issues. I'm thinking Calvin's approach
might be best?
Darrell
7:59 p.m.
New subject: [trinity-devel] R14.0.0 Branding issues
On 28 June 2012 15:48, Darrell Anderson <humanreadable(a)yahoo.com> wrote:
Use image magicks tool called identify:
identify -v image-name | grep corrupt
if there is corruption it wil say something like "Corrupt Image" so just
grep for it
Check to see
if <CR> appears separately anywhere in
the file, without a trailing <LF>? If we're seeing a binary <-> text
mode corruption problem, there won't be any separate <CR>s. Any file
that's flagged
as only containing the <CRLF> sequence
should then be checked manually
in an image viewer
to make sure it's okay.
(I don't know how to do the above with grep etc., but the
actual match takes 1 line in Perl.)
I was about to open khexedit and study a few image files when I realized
that not all corruption errors will be caused by CR/LF issues. I'm thinking
Calvin's approach might be best?
Darrell
Try this:
8:05 p.m.
New subject: [trinity-devel] R14.0.0 Branding issues
Try this:
Use image magicks tool called identify:
identify -v image-name | grep corrupt
if there is corruption it wil say something like
"Corrupt Image" so just grep for it
Ah yes, great thinking. :-) I had forgotten about imagemagick.
Good boy! Roll over! Get biscuit! :-)
Darrell
8:42 p.m.
New subject: [trinity-devel] R14.0.0 Branding issues
On 28 June 2012 16:05, Darrell Anderson <humanreadable(a)yahoo.com> wrote:
On a OT note. ImageMagick rocks! It's ridiculously versatile. Right now I
am using it to calculate the mode (most frequently occuring number in an
array) by creating a histogram of each individual pixel across 18,000
images to generate a common background. Imagemagick does the heavy lifting
in parts of it.
Calvin
Try this:
Use image magicks tool called identify:
identify -v image-name | grep corrupt
if there is corruption it wil say something like
"Corrupt Image" so just grep for it
Ah yes, great thinking. :-) I had forgotten about imagemagick.
Good boy! Roll over! Get biscuit! :-)
Darrell
16 Sep
16 Sep
12:05 a.m.
New subject: [trinity-devel] R14.0.0 Branding issues
Hi all,
On Thu, Jun 28, 2012 at 8:48 PM, Darrell Anderson
<humanreadable(a)yahoo.com>wrote;wrote:
Sorry to dig this up. Has this been properly fixed? Also, has anyone found
out when and why the corruption was introduced in the files? Could be
necessary to adopt policies to further prevent that.
Best regards,
Tiago
Check to see
if <CR> appears separately anywhere in
the file, without a trailing <LF>? If we're seeing a binary <-> text
mode corruption problem, there won't be any separate <CR>s. Any file
that's flagged
as only containing the <CRLF> sequence
should then be checked manually
in an image viewer
to make sure it's okay.
(I don't know how to do the above with grep etc., but the
actual match takes 1 line in Perl.)
I was about to open khexedit and study a few image files when I realized
that not all corruption errors will be caused by CR/LF issues. I'm thinking
Calvin's approach might be best?
Darrell
---------------------------------------------------------------------
To unsubscribe, e-mail:
trinity-devel-unsubscribe(a)lists.pearsoncomputing.net
For additional commands, e-mail:
trinity-devel-help(a)lists.pearsoncomputing.net
Read list messages on the web archive:
http://trinity-devel.pearsoncomputing.net/
Please remember not to top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
12:34 a.m.
New subject: [trinity-devel] R14.0.0 Branding issues
Sorry to dig this up. Has this been properly
fixed? Also, has anyone found out when and why the
corruption was introduced in the files? Could be necessary
to adopt policies to further prevent that.
Yes, these all were fixed long ago. How the corruption happened is a guess and nobody
tried to investigate in any meaningful way.
Darrell
3:10 a.m.
New subject: [trinity-devel] R14.0.0 Branding issues
On Sun, Sep 16, 2012 at 1:34 AM, Darrell Anderson
<humanreadable(a)yahoo.com>wrote;wrote:
Tks. I'll look into it sometime.
Tiago
Sorry to dig
this up. Has this been properly
fixed? Also, has anyone found out when and why the
corruption was introduced in the files? Could be necessary
to adopt policies to further prevent that.
Yes, these all were fixed long ago. How the corruption happened is a guess
and nobody tried to investigate in any meaningful way.
Darrell
---------------------------------------------------------------------
To unsubscribe, e-mail:
trinity-devel-unsubscribe(a)lists.pearsoncomputing.net
For additional commands, e-mail:
trinity-devel-help(a)lists.pearsoncomputing.net
Read list messages on the web archive:
http://trinity-devel.pearsoncomputing.net/
Please remember not to top-post:
http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
30 Jun
30 Jun
4:56 p.m.
New subject: [trinity-devel] R14.0.0 Branding issues
* 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).
Regarding corrupt images, I believe we have that problem now behind us. Using a
combination of find/xargs/identify I think I spotted any remaining suspects. There are
thousands of image files in our repository, but I believe all now are viewable. Of course,
the only sure-fire way to know would be to manually view each image file. :-)
That does not mean there are no branding issues with some images. Just yesterday I
stumbled across one such image for ksysguard. There remains the mystery of the image in
the fifteenpieces About dialog. Therefore images needing branding attention still exist.
Thank you everybody who have been helping with updating the images. I marvel at how
quickly you folks update these images. :-)
Darrell
4234
days inactive
4315
days old
14 comments
6 participants
participants (6)
-
Calvin Morrison -
Darrell Anderson -
David C. Rankin -
E. Liddell -
Nix -
Tiago Marques