Re: GS 3.9 affectsInputRegion



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.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]