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?
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.
