Hi Norman,
now I got time to try what you proposed:
const UPowerGlib = imports.gi.UPowerGlib; # in the declaration part of
the extension.js
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 init() (I also tried enable())
and
this._upClient.disconnect(this._sigSleep);
this._upClient.disconnect(this._sigResume);
in disable() of the extension.js.
But it didn't work. I got no "SLEEP................." or
"RESUME................." messages in my log (which I called by
journalctl -b /usr/bin/gnome-session --since=today ).
I suppose, that's because of running systemd here?
Anyway, thanks! Let's hope the authoer of the extension finds the mistake...
(...I also tried to find it, but didn't succeed until now.)
Cheers
Bazon
2013/6/20 Norman L. Smith <nls1...@gmail.com>:
> 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
