Psi development discussion, mainly of the UI and roadmap

textshell | 3 Jul 2007 22:35

Re: new systemwatch_unix

On Tue, Jul 03, 2007 at 03:15:48PM +0200, emdej wrote:
> 
> > Now that I see the code, I noticed that someone wrote this patch
> > before. We didn't commit it at the time, because 'SIGUSR' doesn't
> > sound like 'The signal emitted on sleep on all Unices', but rather 'A
> > custom signal, which happens to be the one emitted on sleep on a few
> > platforms'. Is this the signal used on all unices to signal sleep? And
> > why is it called SIGUSR? Is there really no *real* signal?
> >
> SIGUSR1 and SIGUSR2 are signals that can be used by any application and 
> have application-defined-meaning. I've added them to make 
> disconnect-on-suspend available for users how can't use other signal for 
> any reason. This signal is never emitted by system! In fact linux don't 
> send any of the signals (AFAIK), they are used by unix or BSD, but can 
> be sent by userspace script called hibernate, which suspends the 
> machine. I've no idea if suspend2 developers would like to change the 
> factory version of hibernate script, I can't get answer from them. I've 
> simply heard from users that it's needed feature (I've the same 
> feeling), so it makes disconnect-on-hibernate possible for them.
> I'm not sure if this version is the one you should apply to official Psi 
> but I know some users would use this patch.
> 

This patch is a nice stopgap for now, but I'd rather not have custom
signals for this in psi in the long term. I hope for 0.12 there will be
enough DBus infrastructure in place in psi to implement it one way or
the other with DBus.

I'm not sure if there is already a standard for this using DBus, or
if there is only the defacto interfaces power manager uses, but in the

(Continue reading)

headers

Michał Jazłowiecki | 3 Jul 2007 22:44

Re: new systemwatch_unix

textshell wrote:

> This patch is a nice stopgap for now, but I'd rather not have custom
> signals for this in psi in the long term. I hope for 0.12 there will be
> enough DBus infrastructure in place in psi to implement it one way or
> the other with DBus.

What about Unices other than Linux? *BSD systems and Solaris for 
example. There are quite a few Psi users running those systems. I 
believe (please correct me, if I'm wrong) that those systems do not 
provide DBus infrastructure (and its development is way behind the one 
on Linux), but still take advantage of signals (AFAIR, some signals were 
renamed on Solaris, like SIGUSR_1 and SIGUSR_2, with underscore and 
SIGPOWER instead of SIGPWR).

I would prefer Psi to implement one way to support power events on all 
Unices (that we officially and semi-officially support) than to create 
Linux-only implementation, then another FreeBSD-only implementation, and 
another Solaris-specific implementation, and NetBSD-specific... (yes, I 
do exaggerate now, but you know what I mean). Maybe it's better to 
implement a generic "work everywhere" solution and try to detect whether 
a better solution is available.

Regards,

--

-- 
Michał Jazłowiecki (michalj)
Psi Forum & Wiki Moderator

(Continue reading)

headers

textshell | 3 Jul 2007 23:26

Re: new systemwatch_unix

On Tue, Jul 03, 2007 at 10:44:45PM +0200, Michał Jazłowiecki wrote:
> 
> What about Unices other than Linux? *BSD systems and Solaris for 
> example. There are quite a few Psi users running those systems. I 
> believe (please correct me, if I'm wrong) that those systems do not 
> provide DBus infrastructure (and its development is way behind the one 
> on Linux), but still take advantage of signals (AFAIR, some signals were 
> renamed on Solaris, like SIGUSR_1 and SIGUSR_2, with underscore and 
> SIGPOWER instead of SIGPWR).

I don't know a lot about non linux unices, but DBus will work on those too.
I'm not sure how much DBus is standard on those, but i'd expect it to be
mostly as standard as it's on linux for most of them (Sun is a big Gnome-
supporter, so it will work on solaris, *BSD support Gnome too and will
have DBus in the ports tree also). Unless somebody knows more about those
systems and has convincing arguments why DBus wouldn't work there, I don't
see why we should use something different. Much less something hacky like
signals, DBus is the freedesktop.org way for things like that, and that's
the closest thing to a standard body in X11 desktop space that matters.
(i even think psi should use DBus on the non X11 platforms, because i'd
like an uniform remote control api, but maybe OS X has something native
that's worth to support....)

> 
> I would prefer Psi to implement one way to support power events on all 
> Unices (that we officially and semi-officially support) than to create 
> Linux-only implementation, then another FreeBSD-only implementation, and 
> another Solaris-specific implementation, and NetBSD-specific... (yes, I 
> do exaggerate now, but you know what I mean). Maybe it's better to 
> implement a generic "work everywhere" solution and try to detect whether

(Continue reading)