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-requ...@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-requ...@gnome.org > > You can reach the person managing the list at > gnome-shell-list-ow...@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 <mic...@gmail.com> > To: gnome-shell-list@gnome.org > Subject: Re: GS 3.9 affectsInputRegion > Message-ID: > <CAHdGF6Kk9NgmCH1QUK-6dF-mtPQOrC3QcfNZ-w=cp-fzoks...@mail.gmail.com> > Content-Type: text/plain; charset="iso-8859-1" > > Hi, > > A small update: > On 13 Sep 2013 01:35, "Michele" <mic...@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 > *********************************************** _______________________________________________ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
