Re: GS 3.9 affectsInputRegion (Michele)

Thanks, Michele, for update.

As far as I understand, this is exactly what happened when an actor was
added using affectsInputRegion==affectsStruts==false. It would be
connected to update regions whenever something that changes its "region"
happens, but would be ignored in the cycle that creates new input region.

There are several signals that might indicate changing region. Besides
notify::allocation, the pre-3.10 GS versions connected to
notify::visible and parent-set. You should probably consider connecting
at least to the first one as well, so that it will update regions when,
for example, the dash hides when a fullscreen app is open/closed. In my
case it just happens that the parent actor changes its allocation/size
only when a child changes its allocation within the parent and/or its
size. Nevertheless, that might be a good idea for me to connect to those
signals as well (just in case -- so that I won't forget to do this if
something in the logic changes).

In any case, thanks again for this comment. I believe, it clarifies why
trackChrome requires a parent to be tracked.


On 10/16/2013 07:00 AM, gnome-shell-list-request gnome org wrote:
Send gnome-shell-list mailing list submissions to
      gnome-shell-list gnome org

To subscribe or unsubscribe via the World Wide Web, visit
or, via email, send a message with subject or body 'help' to
      gnome-shell-list-request gnome org

You can reach the person managing the list at
      gnome-shell-list-owner gnome org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of gnome-shell-list digest..."

Today's Topics:

   1. Re: GS 3.9 affectsInputRegion (Michele)


Message: 1
Date: Wed, 16 Oct 2013 03:34:32 +0100
From: Michele <micxgx gmail com>
To: gnome-shell-list gnome org
Subject: Re: GS 3.9 affectsInputRegion
      <CAHdGF6Kk9NgmCH1QUK-6dF-mtPQOrC3QcfNZ-w=CP-fZokScvw mail gmail com>
Content-Type: text/plain; charset="iso-8859-1"


A small update:
On 13 Sep 2013 01:35, "Michele" <micxgx gmail com> wrote:

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:

Lang.bind(Main.layoutManager, Main.layoutManager._queueUpdateRegions));

I thought this could be of help,


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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>


Subject: Digest Footer

gnome-shell-list mailing list
gnome-shell-list gnome org


End of gnome-shell-list Digest, Vol 60, Issue 6

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