Re: %20 in URLs

On Sunday 01 July 2007 01:52, Wolfgang Illmeyer wrote:
> Am Samstag, 30. Juni 2007 09:22 schrieb Trejkaz:
> > > I click
> > > on "http://example.com/This%20is%20a%20test" and my browser
> > > opens "http://example.com/This". Is anybody experiencing the same
> > > problem?
> > >
> > > Besides Psi-0.11-RC1 I use gentoo, with x86-kde and firefox-bin.
> >
> > Doesn't happen here.  Psi-0.11-RC on Gentoo with KDE and Konqueror.
> >
> > Bug in Firefox perhaps?
>
> Hmm... Another funny thing: When I click on the URL above in KMail, firefox
> opens ist correctly....

What would be interesting is to see what Psi is actually passing to the 
browser.  In the past I've done this by making a script which logs the URL to 
a file before calling the web browser, and then pointing Psi at that script 
instead of the real web browser.  Might be harder to do these days, but must 
still be possible.

TX

--

-- 
             Email: trejkaz@...
         Jabber ID: trejkaz@...
          Web site: http://trypticon.org/
   GPG Fingerprint: 9EEB 97D7 8F7B 7977 F39F  A62C B8C7 BC8B 037E EA73

new systemwatch_unix

Hi.
I wrote SystemWatch for unix class, which enables posibility of 
disconnecting on hibernate with standard unix signals. I'm now sure how 
standard behaviour it is, but it doesn't conflict with rest of the 
system. I decided to use SIGUSR1 (user-defined signal 1) and 
SIGPWR(power failure) on suspend and SIGUSR2 (user-defined signal 1), 
SIGIO (I/O now possible) and SIGURG (high bandwidth data is available) 
on resume.

Regards,

--

-- 

Marek Jarycki (emdej)
Wroclaw University of Technology
website: www.emdej.com
JID: emdej@...
mobile: +48693649623

Hi.
I wrote SystemWatch for unix class, which enables posibility of 
disconnecting on hibernate with standard unix signals. I'm now sure how 
standard behaviour it is, but it doesn't conflict with rest of the 
system. I decided to use SIGUSR1 (user-defined signal 1) and 
SIGPWR(power failure) on suspend and SIGUSR2 (user-defined signal 1), 
SIGIO (I/O now possible) and SIGURG (high bandwidth data is available) 

Re: new systemwatch_unix

> I wrote SystemWatch for unix class, which enables posibility of
> disconnecting on hibernate with standard unix signals. I'm now sure how
> standard behaviour it is, but it doesn't conflict with rest of the
> system. I decided to use SIGUSR1 (user-defined signal 1) and
> SIGPWR(power failure) on suspend and SIGUSR2 (user-defined signal 1),
> SIGIO (I/O now possible) and SIGURG (high bandwidth data is available)
> on resume.

Thanks.

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?

cheers,
Remko

Re: new systemwatch_unix

> 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.

Regards,

--

-- 

Marek Jarycki (emdej)
Wroclaw University of Technology
website: www.emdej.com
JID: emdej@...
mobile: +48693649623

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

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

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 

[BUG] Wrong trayicon tooltip after reconnect

Hello everyone,

I've noticed that if I disconnect with a status description (either 
manually or I hibernate my notebook) and later reconnect without setting 
a status description (by resuming my system, for example), then Psi's 
trayicon tooltip contains the status description which was set when 
going offline.

Please note that none of my accounts has status description set by then.

Regards,

--

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

new user...

hi.

i'm considering using jabber (client/server) as a basis for a
(one-many/many-one/many-many) application. given that jabber appears to be a
well designed protocol, it might fit with what i'm considering.

are there channels/sites/etc... where i can post my questions (however far
reaching they might be!!), and are there places where i might talk to
developers if i was looking to potentially get a developer.

keep in mind, that this is a relatively small project that i'm considering.

thanks

-bruce
bedouglas@...

Re: new user...

On 7/6/07, bruce <bedouglas@...> wrote:
> i'm considering using jabber (client/server) as a basis for a
> (one-many/many-one/many-many) application. given that jabber appears to be a
> well designed protocol, it might fit with what i'm considering.

Ask away.  Plenty of knowledgeable people here, and you may also want
to try JDEV (http://mail.jabber.org/mailman/listinfo/jdev).

--

-- 
Psi webmaster (http://psi-im.org)
im:hal@...
http://halr9000.com