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 335 - Konqueror Icon Activation Effect
Summary: Konqueror Icon Activation Effect
Status: RESOLVED FIXED
Alias: None
Product: TDE
Classification: Unclassified
Component: system (show other bugs)
Version: 3.5.13 [Trinity]
Hardware: All All
: P1 normal
Assignee: Timothy Pearson
URL:
: 389 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-10-03 13:00 CDT by Darrell
Modified: 2012-10-19 15:28 CDT (History)
2 users (show)

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


Attachments
Fixes the Konqueror icon activation effect in tree/list view (771 bytes, patch)
2011-12-03 21:50 CST, Darrell
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Darrell 2010-10-03 13:00:01 CDT
When selecting a file or directory in the Konqueror file pane, the icon momentarily grows and flashes just like the same effect with the desktop and panel icons.

Check box options for enabling/disabling icon activation effects were added for the desktop and panel icons. No such option exists for Konqueror.
Comment 1 Timothy Pearson 2010-10-03 13:10:01 CDT
The desktop icon activation effect checkbox also controls Konqueror, as the desktop is merely a fixed Konqueror view.  You should be able to deactivate the Konqueror icon activation effect by going to KControl->Appearance & Themes->Icons->Advanced and deselecting "Show icon activation effect".
Comment 2 Darrell 2010-10-03 13:21:54 CDT
Nope, not here. I toggled both check boxes and restarted Trinity. Icons in Konq still activate.
Comment 3 Timothy Pearson 2010-10-03 13:38:48 CDT
Figures.  The first glitch for 3.5.13...
Comment 4 Darrell 2011-11-23 00:10:35 CST
In kdeglobals config file, ShowKonqIconActivationEffect=false yet there is still a slight blinking when I select a file to open.

I manually changed the setting to true. I saw no difference. Same slight blink.

The blinking is not of the same level as the desktop or panel icons. Yet in 3.5.10 there is no blink at all.

Where is the KControl setting for this activation? Is this part of the Icon activation check box that also affects desktop icons? Should the two be separate controls?

If they are one and the same, there is no desktop icon effect when I have the option disabled.
Comment 5 Darrell 2011-11-23 00:11:45 CST
This is related to bug report 389. :)
Comment 6 Darrell 2011-12-03 21:50:03 CST
Created attachment 209 [details]
Fixes the Konqueror icon activation effect in tree/list view

Patch attached. Problem solved!

KControl->Appearance & Themes->Icons->Advanced controls both desktop and Konqueror icons.

The problem: the activation effect is enabled all the time in list views.

The desktop icon effect is quite noticeable. The effect functions as configured in KControl, although I need to restart TDE for the change to occur. Refer to bug 643. This patch does not fix that bug.

I always use tree view. The Konqy icon effect is a slight blink. In tree view the Konqy icons blink all the time whether the effect is enabled or disabled. Not the noticeable effect of the desktop icons, just a blink.

I changed Konqy view to icon view and the blinking then obeyed the setting and was more noticeable like the desktop icons.

So the bug seems limited to tree view, which is a list view.

I notice kdebase/konqueror/listview/konq_listviewwidget.cc is configured like this:

KIconEffect::visualActivate(viewport(), rect, pix);

Whereas kdebase/libkonq/konq_iconviewwidget.cc is configured like this:

if (KGlobalSettings::showKonqIconActivationEffect() == true) {
    KIconEffect::visualActivate(viewport(), rect, item->pixmap());
}

In other words, there is no test as to whether activation effects are enabled. The activation occurs all the time, which is what I am seeing.
Comment 7 Darrell 2011-12-21 21:55:59 CST
*** Bug 389 has been marked as a duplicate of this bug. ***
Comment 8 Timothy Pearson 2012-01-07 23:26:31 CST
Fixed in GIT hash 398f6a1.

Thanks for reporting, and for the patch!