Awesome, thanks for all the help!! giovanni++ I seem to have it working now with no clear, visible errors, however I'm not sure about the style. When I look at other extensions it seems like most wrap their extension in a class. Is this required? or is there a specific reason for doing this? The example 'Hello World' extension doesn't seem to do it so I'm not sure.
Anyway, thanks again and feel free to take it up for a spin. I'm going to do a little bit more testing before submitting it to the extensions site. On Tue, May 13, 2014 at 1:16 AM, Giovanni Campagna < [email protected]> wrote: > The object will see a g_object_unref right after the signal, that's why > you can't do most calls on it. > On May 13, 2014 1:13 AM, "Diego Fernandez" <[email protected]> > wrote: > >> Ok.. it seems easier to just connect to all windows and keep track of >> those (since in my opinion the window should still stay in the same >> workspace even if it gets moved while in a single monitor setup). Do I >> have to explicitly disconnect from the window after it gets the 'unmanaged' >> signal, or will the object get deleted? >> >> >> On Mon, May 12, 2014 at 5:23 PM, Giovanni Campagna < >> [email protected]> wrote: >> >>> 2014-05-12 23:00 GMT+02:00 Diego Fernandez <[email protected]>: >>> > Hmm, so I'd have to listen for the 'unmanaged' signal for every single >>> > window and keep track of that? seems like it'll add a bit of >>> complexity but >>> > I guess I can manage. >>> > >>> > For the 'window-added' and 'window-removed' signals in MetaWorkspace, >>> do >>> > those behave like 'window-left-monitor' and 'window-entered-monitor' in >>> > MetaScreen? i.e. if a window leaves one workspace and goes to another >>> will >>> > that be a 'window-removed' and a 'window-added' event? >>> >>> Yes, but you also need to keep the list of workspaces as they're added >>> and removed. >>> You can check the code in js/ui/workspace.js or >>> js/ui/workspaceThumbnails.js that deals with window-added/removed on a >>> single workspace, and js/ui/workspacesView.js for keeping the >>> workspace list up to date. >>> >>> Giovanni >>> >>> > >>> > On Mon, May 12, 2014 at 4:47 PM, Giovanni Campagna >>> > <[email protected]> wrote: >>> >> >>> >> 2014-05-12 22:42 GMT+02:00 Diego Fernandez <[email protected] >>> >: >>> >> > Hey all, I'm currently messing around with making my first extension >>> >> > https://github.com/aiguofer/return-to-monitor. The idea is to be >>> able >>> >> > to >>> >> > return windows to their original monitor if you plug a monitor back >>> in. >>> >> > >>> >> > Right now I have the extension mostly working. I keep track of all >>> open >>> >> > windows and update the list only when more than one montior exists >>> and >>> >> > on >>> >> > any 'window-left-monitor' and 'window-created' events. >>> >> > >>> >> > The problem I'm having is the case when a saved window gets closed >>> while >>> >> > in >>> >> > a single monitor setup. If that happens, shell breaks when I try to >>> >> > return >>> >> > the windows after plugging a monitor back in. I need to be able to >>> >> > listen >>> >> > for any window-close event to remove the window from the list... is >>> >> > there an >>> >> > easy way of doing this? >>> >> > >>> >> > I noticed that 'window-left-monitor' catches windows closing, but it >>> >> > seems >>> >> > hard to check what caused the signal. >>> >> >>> >> You can use the 'unmanaged' signal on the window, if you're careful >>> >> and not call anything at that point - only the identity of the object >>> >> is valid. >>> >> Alternatively, MetaWorkspace has window-added and window-removed >>> signals. >>> >> >>> >> Giovanni >>> > >>> > >>> > >>> > >>> > -- >>> > Diego Fernandez - 爱国 >>> >> >> >> >> -- >> Diego Fernandez - 爱国 >> > -- Diego Fernandez - 爱国
_______________________________________________ gnome-shell-list mailing list [email protected] https://mail.gnome.org/mailman/listinfo/gnome-shell-list
