Awn

awn does not update itself when glass colors change in gconf

Bug #253417 reported by José M. López-Cepero
2
Affects Status Importance Assigned to Milestone
Awn
Fix Released
Low
haytjes

Bug Description

The AWN bar does not redraw itself when the gconf keys /apps/avant-window-navigator/bar/glass_step_1 and ..._2 are changed. As a result of that, changes to the glass color made by means other than awn-manager do not show unil the bar is redrawn for any other reason (such as changing the desktop or by writing a key which does trigger a redraw, such as .../rounded_corners).

Tested in current PPA (avant-window-navigator-trunk-0.3.1~bzr427-hardy1-1), hardy 64. I have not tested in depth if there are any other keys with similar behavior.

Why I know: I'm making an utility which automatically changes the background to a random image, updating the theme colors as it goes. It does so by analyzing the background image to find dominant colors, then writing to the appropriate gconf keys. With awn, the changes do not show immediately; I am writing to the rounded_corners key (which does force an update, even if its value does not change) as a workaround.

haytjes (h4writer)
Changed in awn:
assignee: nobody → h4writer
milestone: none → 0.3.2
status: New → Confirmed
Revision history for this message
haytjes (h4writer) wrote :

I think the problem is:
- All these settings are in AwnSettings and get updated when in AwnSettings itself when it change in GKeyFile or Gconf.
- To know if the bar should repainted there is another awn_config_notify_add to that key
- The function of the last awn_config_add get's first launched
- Then AwnSettings get the his notify that it should update the key.
So the bar gets repainted with the old values.

There are several ways to fix it, but in general the value should first get updated and afterwards the bar should repaint.
- In the request to repaint the bar also adjust the value in AwnSettings. This sounds rather ugly, because the value gets set two times.
- Make sure the function first added in awn_config_notify_add gets called first. (So FIFO). Because now it is LIFO. Should solve this problem, because the awn_config_notify_add in AwnSettings are added first.
- Make a notify system in AwnSettings. That way you don't use awn_config_notify_add, but ask AwnSettings to notify if a key is updated in AwnSettings. That way the values are already updated before the notifies in AwnSettings get called.

More input from the devs is required to solve this bug...

Revision history for this message
Michal Hruby (mhr3) wrote :

This would be pretty big change for 0.3.2, so moving the milestone to 0.4, where it should work properly.

Changed in awn:
importance: Undecided → Low
milestone: 0.3.2 → 0.4.0
Revision history for this message
Mark Lee (malept) wrote :

It works for me in the 0.4 branch.

Changed in awn:
status: Confirmed → Fix Committed
moonbeam (rcryderman)
Changed in awn:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.