Re: GS 3.9 affectsInputRegion (Michele)

[Vadim <vadim dbfin com>]

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.

Vadim.


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
>       https://mail.gnome.org/mailman/listinfo/gnome-shell-list
> 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
> Message-ID:
>       <CAHdGF6Kk9NgmCH1QUK-6dF-mtPQOrC3QcfNZ-w=CP-fZokScvw mail gmail com>
> Content-Type: text/plain; charset="iso-8859-1"
>
> Hi,
>
> A small update:
> On 13 Sep 2013 01:35, "Michele" <micxgx gmail com> 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.
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <https://mail.gnome.org/archives/gnome-shell-list/attachments/20131016/14ec019e/attachment.html>
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> gnome-shell-list mailing list
> gnome-shell-list gnome org
> https://mail.gnome.org/mailman/listinfo/gnome-shell-list
>
>
> ------------------------------
>
> End of gnome-shell-list Digest, Vol 60, Issue 6
> ***********************************************