Hi, A small update: On 13 Sep 2013 01:35, "Michele" <<a href="mailto:micxgx@gmail.com">micxgx@gmail.com</a>> wrote: > > Hi, > > 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 - 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? There is at least a drawback of this approach. Input regions are updated when tracked actors allocations change. If the parent actor is not tracked as this solution suggests and its position changes causing in turn the movement of the tracked child, input regions are not updated correctly. As far as I understand the clutter logic, the child allocation doesn't change and so the 'notify::allocation' signal is not triggered. The wrong input region is then defined. I had this problem in my extension. I solved it by manually connecting the signal of the child actor: childactor.connect('notify::allocation', Lang.bind(Main.layoutManager, Main.layoutManager._queueUpdateRegions)); I thought this could be of help, Michele > > Michele > > on 10/072013 22:56:00 -0500 Vadim wrote: > > >Hi Jasper, > > > >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. > > > >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. > > > >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? > > > >Vadim. >