Bug 8085

Summary: gconf plugin breaks action options by writing but not reading them as a single entity
Product: xorg Reporter: Ján Kľuka <jan.kluka>
Component: App/compizAssignee: David Reveman <reveman>
Status: RESOLVED FIXED QA Contact: Xorg Project Team <xorg-team>
Severity: normal    
Priority: high CC: wtanaka
Version: unspecified   
Hardware: x86 (IA32)   
OS: Linux (All)   
URL: http://bugs.compiz.net/view.php?id=44
i915 platform: i915 features:

Description Ján Kľuka 2006-08-31 04:50:56 UTC
The most-often encountered manifestation of this bug is this:
If you change the setting of both the key and the edge activating an action, the
edge setting is reset to the default (the value set up during the initialization
of the corresponding plugin) when compiz restarts.

This bug has been discussed in several topics of compiz.net forums, because it
manifests itself by breaking settings of several plugins. One of the discussions
(http://www.compiz.net/topic-2091-1.html) contains steps to reproduce the bug
with the scale plugin (http://www.compiz.net/viewtopic.php?pid=28158#p28158).
The bug has been reported, analyzed, and two solutions (a long-term one and a
transitional one) has been proposed in compiz.net bugtracker at
http://bugs.compiz.net/view.php?id=44 . A copy some bits from there follows:

ulph's analysis of the issue:

When gconfInitOption is called for an option of type CompOptionTypeAction there
are four calls to gconfGetOptionValue with the entries for key, button, bell and
edge (in that order). Suppose gconfGetOptionValue is called for the key entry
and that the key entry is set in gconf. Now gconfGetOptionValue will locate the
data structure for the action. This data structure holds the configuration for
both key, button, bell and edge. Next gconfGetOptionValue will update the data
structure to reflect the key configuration for that action. Finally it will call
gconfSetDisplayOptionForPlugin that will notify the plugin of the change and
write back the action to gconf with gconfSetOption. Since gconfSetOption writes
back the entire action data structure to gconf, the button, bell and edge keys
that haven't been read into our action data structure yet, will be overwritten.

ulph's long-term proposal

I propose that the gconf-structure should be changed so that actions are in
separate directories where all entries are read (and written) at once. That way
it would be easy to distinguish an action from some other key. The current way
that actions are retreived from gconf is kind of awkward. Also, this problem
would be easier to resolve. Do you think this is a good idea?

My (crankyjack's) transitional proposal

Putting [actions] into separate directories is logical, plus it will make [them]
look much neater in gconf-editor. The trouble is that this change is almost as
big as the move to the action system was. It will break current settings, and
requires new gconf schemas. So "Plan B" would be to change gconfGetOptionValue
so that it loads the four action options together. The change could be done as

    1. Move the ugly "heuristics" which determines plugin and option name in
lines 387--473 of gconfGetOptionValue to gconfKeyChanged.

    2. Merge gconfInitOption and the remainder of gconfGetOptionValue into a new
function gconfGetOption. It should take the same arguments as gconfInitOption
and load actions as a single entity. The function will have to synthesize the
gconf path to keys (the initial part of gconfInitOption) and call

    3. Call the new gconfGetOption from gconfKeyChanged, and replace calls to
gconfInitOption with gconfGetOption.

I think this makes sense, because gconfGetOption will do what its name says, and
will better mirror gconfSetOption. What it does in the current state is better
described as "gconfGetKey". Moreover, the function will not change much when
(later) actions will get separate gconf directories.
Comment 1 David Reveman 2006-10-11 15:51:55 UTC
Transitional proposal sounds good. If you're able to write a patch for this,
that would be much appreciated.
Comment 2 Ján Kľuka 2006-10-12 00:37:58 UTC
(In reply to comment #1)
> Transitional proposal sounds good. If you're able to write a patch for this,
> that would be much appreciated.

No, I'm sorry I can't afford to spend the time on this. It seemed that ulph had
started working on the transitional fix, but he didn't say he had finished it.
What is now called Beryl has moved from gconf to its own settings management
shortly after reporting this bug, so this no longer an issue there. I'm sending
an e-mail to ulph asking him to look over here.
Comment 3 Daniel Stone 2007-02-27 01:33:24 UTC
Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Comment 4 Danny Baumann 2007-09-25 00:52:26 UTC
Edges, keys and buttons are separate options now, so this problem should be solved implicitly.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.