Hello Bazon,
After reading this thread I became curious and poked
around the suspend/resume stuff in glib. I put the
following bit of code in one of my extensions and
found that it worked to (1) notify of the suspend
sleep and (2) notify when the resume occurred.
const UPowerGlib = imports.gi.UPowerGlib;
.
.
. ...in a class init ...
this._upClient = new UPowerGlib.Client();
this._sigSleep = this._upClient.connect('notify_sleep',
Lang.bind(this, function() {
log("SLEEP.................");
}));
this._sigResume = this._upClient.connect('notify_resume',
Lang.bind(this, function() {
log("RESUME.................");
}));
.
.
.... in the class destroy ...
this._upClient.disconnect(this._sigSleep);
this._upClient.disconnect(this._sigResume);
You may be able to attack your problem as Simon
suggests: "The correct solution is to fix the extension
so it doesn't need reloading."
Avoid the error by changing the state of your extension
on "sleep" and re-store its state on "resume".
Hope this is useful.
Good luck,
Norman
On Thu, 2013-06-20 at 13:31 +0200, Bazon Bloch wrote:
> Aha, thank you.
>
> But then is the question:
> Why doesn't it reach Gnome-Shell? And what can be done to make it
> reach Gnome-Shell?
>
>
> Am 20.06.2013 13:15 schrieb "Simon McVittie"
> <simon.mcvit...@collabora.co.uk>:
> On 20/06/13 11:24, Bazon Bloch wrote:
> > I got the Error:
> > "GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The
> name
> > org.gnome.Shell was not provided by any service files"
>
> That doesn't necessarily mean it *should* be provided by
> a .service
> file, just that something tried to communicate with
> gnome-shell and
> didn't find one. Creating a .service file is a way to cause
> the service
> to be started automatically, which is often appropriate for
> non-GUI
> services - but attempting to run a new copy of GNOME Shell is
> not the
> right thing to happen here.
>
> > I still got the flat-CPU-graph-problem
> > with
> https://extensions.gnome.org/extension/120/system-monitor/
> after
> > resume from suspend. Thanks to this list, I now how to
> restart that via
> > dbus:
> > gdbus call --session --dest org.gnome.Shell --object-path
> > /org/gnome/Shell --method
> org.gnome.Shell.Extensions.ReloadExtension
> > system-moni...@paradoxxx.zero.gmail.com
>
> Right, that's a workaround. The correct solution is to fix the
> extension
> so it doesn't need reloading.
>
> One possible route towards achieving this would be to have the
> extension
> watch the system bus for a signal indicating a resume from
> suspend, and
> do what it would have done when the Shell disabled and
> re-enabled it;
> the next refinement of that would be to reduce what is done
> after 10
> seconds to the absolute minimum to make it work, which would
> hopefully
> indicate what was wrong in a specific enough way to be able to
> fix it
> correctly.
>
> > I would like to have this executed automatically about 10s
> after each
> > resume, and so I created a systemd service:
> ...
> > Environment=DISPLAY=:0
> > ExecStart=/usr/bin/sh -c "/path/to/reload-sys-mon.sh"
>
> System-level services connecting to a user session service are
> not
> something that is, or should be, supported. Something in the
> user
> session (like the extension itself) should monitor the system
> bus to
> detect a resume.
>
> > Process: 1548 ExecStart=/usr/bin/sh
> -c /path/to/reload-sys-mon.sh
> > (code=exited, status=0/SUCCESS)
> > CGroup:
> name=systemd:/system/resume@.service/resume@carl.service
> > └─1554 dbus-launch
> > --autolaunch=0b13b59cd91045ad9b746f7b36da8550
> --binary-syntax --close-stderr
>
> The system service is creating a tiny user-level D-Bus session
> containing nothing except your shell script, and trying to
> talk to a
> GNOME Shell instance in that session. Your GNOME Shell is in a
> different
> session, created when you logged in. Creating a .service file
> would
> result in your script trying to start a second GNOME Shell
> instance,
> sharing the $DISPLAY with the real one, but in a different
> login session
> - that's never going to work very well.
>
> S
>
> _______________________________________________
> gnome-shell-list mailing list
> gnome-shell-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-shell-list
> _______________________________________________
> gnome-shell-list mailing list
> gnome-shell-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gnome-shell-list
_______________________________________________
gnome-shell-list mailing list
gnome-shell-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gnome-shell-list
