By default, Bugzilla does not search the list of RESOLVED bugs.
You can force it to do so by putting the upper-case word ALL in front of your search query, e.g.: ALL tdelibs
We recommend searching for bugs this way, as you may discover that your bug has already been resolved and fixed in a later release.
Bug 744 - Some built-in desktop backgrounds don't work
Summary: Some built-in desktop backgrounds don't work
Status: RESOLVED FIXED
Alias: None
Product: TDE
Classification: Unclassified
Component: tdeartwork (show other bugs)
Version: 3.5.13 [Trinity]
Hardware: All Linux
: P5 trivial
Assignee: Slávek Banko
URL:
Depends on:
Blocks:
 
Reported: 2011-12-10 16:31 CST by ktbz.aoneshot.eliddell
Modified: 2012-06-01 20:53 CDT (History)
4 users (show)

See Also:
Compiler Version:
TDE Version String:
Application Version:
Application Name:

Attachments
Add libart support do CMake in tdebase (3.17 KB, patch)
2012-06-01 10:31 CDT, Slávek Banko 		Details | Diff
Updated patch for GIT (3.29 KB, patch)
2012-06-01 12:20 CDT, Darrell 		Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description ktbz.aoneshot.eliddell 2011-12-10 16:31:26 CST 
When selecting a background from those provided with kdebase/kdeartwork in kcontrol > Appearance & Themes > Background, some options appear not to work (can't be previewed or applied).  The problem backgrounds seem to be those supplied in .svgz format, such as Aurora and Celtic (there appear to be eight of these)--all .jpg backgrounds that I tested worked.

Normally, previews should show up when one of those backgrounds is chosen from the list, and it should appear on the desktop when Apply is clicked.

ksvg and gzip are on the system, if that matters.
Comment 1 Darrell 2012-04-04 19:27:21 CDT 
Confirmed in slackware 13.1 and latest GIT.

Something is broken because the svgz images work in my 3.5.10 system. :(
Comment 2 Slávek Banko 2012-04-04 19:35:25 CDT 
(Odpověď na komentář #1)
> Confirmed in slackware 13.1 and latest GIT.
> 
> Something is broken because the svgz images work in my 3.5.10 system. :(

Svgz images still work in Trinity 3.5.12. do not work until 3.5.13.
...after transition to cmake?
Comment 3 Darrell 2012-04-04 19:38:10 CDT 
Okay, thanks, that provides a clue where to start looking.
Comment 4 Darrell 2012-04-04 20:29:02 CDT 
Looks like kcontrol/background/bgrender.cpp tries to use libart as the svg rendering engine. libart was not merged into the GIT source tree until after 3.5.13 was released. This bug report is filed against 3.5.13, although the bug still exists in GIT.

The svgz images do not display in konqueror tooltip popups either. The problem likely is common to both and not specific to KControl.
Comment 5 Slávek Banko 2012-06-01 10:31:33 CDT 
Created attachment 636 [details]
Add libart support do CMake in tdebase

I looked at the problem in detail and I noticed that the CMake lack of support for libart. And that was the real reason why svg not work. The patch adds libart support to cmake. Please, look at it someone who knows CMake. Then I push it to git.

I tested it with 3.5.13.1 and it works!
Comment 6 Darrell 2012-06-01 12:20:12 CDT 
Created attachment 637 [details]
Updated patch for GIT

The original patch is for 3.5.13. I updated the patch for GIT.

I rebuilt tdebase and tested. Looks like the patch resolves the problem. I now see the same behavior in Trinity GIT as I see in 3.5.10.

Seems the updated version of the patch can be pushed to GIT and the original patch can be backported to 3.5.13.1. I will push the updated patch to GIT as I have another patch to push to GIT as well.
Comment 7 Timothy Pearson 2012-06-01 12:24:53 CDT 
Looks good, go ahead and push!
Comment 8 Darrell 2012-06-01 12:45:37 CDT 
Patch pushed to GIT in hash e3434a7d.

This resolves the bug report.

Thank you!
Comment 9 Slávek Banko 2012-06-01 19:08:14 CDT 
(Odpověď na komentář #8)
> Patch pushed to GIT in hash e3434a7d.
> 
> This resolves the bug report.
> 
> Thank you!

Thank you. Although I had a patch ready in my git clone, but you were faster. In the commit log but got funny typo - instead of bug 744 you wrote the number of attachment 637 [details]. It would be good to fix it? Or rather not touch on history?
Comment 10 Darrell 2012-06-01 20:53:35 CDT 
I amended the comment, but I don't know whether I updated correctly. A simple search on the web regarding how to do this results in a few thousand complicated dissertations and exceptions. My local git log shows two log entries: the old entry and the amended entry.