[Konversation-devel] [Bug 107667] Get my nick back

[Lars DIECKOW]

------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
         
http://bugs.kde.org/show_bug.cgi?id=107667         




------- Additional Comments From lars.dieckow googlemail com  2007-07-03 04:12 -------
Created an attachment (id=21021)
 --> (http://bugs.kde.org/attachment.cgi?id=21021&action=view)
recover nick and identify

The attached program sort of does what is requested. It is assumed
that the nick defined first in each identity is the primary nick you
want to set. (->[0] means "first" in the program.)

The program looks at each connected server's current nick. If it is
equal to one of the identities' primary nick, no action is taken.
Else it looks at each identity's other nicks to find out which
identity the current nick could come from.

This is very hackish and can pick an unexpected primary nick if you
reuse nicks across identities. I did it this way because currently
there is no DCOP interface to determine the identity associated with
a connected server, only the nicks.

If it cannot determine a suitable identity, no action is taken. This
is the case if you manually change your nick to something that is not
in any identity's nicks.

Then the current nick is changed to the primary nick and the program
starts over for the next connected server.

You have to edit the source to edit passwords for Services. I would
have attempted to make integration with kwalletmanager, but the
assignee in bug 94311 can't get his arse off the ground.

The Services passwords are associated with regular expressions
describing the server name. Again, this is due to a shortcoming in
the DCOP interface, I am unable to query the server names associated
with the identities. By choosing regexp instead of strings for server
names, I give you more flexibility. But also it lies in your own
responsibility to make sure the expressions do not match several
connected server names and accidently pick the wrong one, since the
matches are done in an undetermined order.

We are still lacking the hooks to calls programs on reconnect events,
or schedule events regularly, as this bug's submitter suggests.