<div dir="ltr"><div><div><font color="#000000">Hi,<br><br>Whilst trying to keep updated the 
dash-to-dock extension for  Gnome-Shell 3.9 I stumble on the 
removing of the affectsInputRegion parameter.  I'm wondering if the 
solution suggested by Vadim -</font> using the private method 
layoutManager._trackActor instead of layoutManager.trackChrome to force 
the tracking of an actor whose parent is not tracked - is correct or not. Can doing this cause any problem?<br><br> 
<div>Michel<font color="#000000">e<br><br></font></div>on 10/072013 22:56:00 -0500 <font color="#000000">Vadim wrote:</font><br><br><font color="#000000">>Hi Jasper,<br>
    ><br>
    >Yes, I kind of do. The parent actor is GenericContainer, and its
    position is fixed. Its children are placed inside the parent at some
    positions. I just searched through my installed extensions and found
    out that, for example, Dash to Dock uses similar concept to position
    the dash: there is St.Bin with a child positioned vertically at
    center, and St.Bin is added using addChrome with affectsInputRegion
    = false, while for its child trackChrome with affectInputRegion =
    true is called.<br>
    ><br>
    >Probably, it is the right decision to simplify the whole thing about
    input regions. May be if, for example, trackChrome could add a
    region that is a descendant of Main.uiGroup but has no tracked
    ancestors, that would solve the problem.<br>
    ><br>
    >As I can see right now when trackChrome(B) is called, it looks for
    B's ancestor A that is already being tracked. Then the only thing I
    see how A is used is to copy A's params to B -- those that are not
    specified for B directly. Is there another thing I am missing why
    trackChrome would require such ancestor?<br>
    ><br>
    >Vadim.<br><br></font></div></div></div>