Hi All, I need some clarifications regarding this bug.
"Session nickname feature is unnecessary --> to be removed "
Is it done already? Because i don't seem to find any session nickname feature while using Saros.
Hi Stefan,
I checked the picture and bugs #848 & bugs #842.
I also spent time to understand what need to be fixed.
Then i got confused, because there is no feature to rename a session
participant, host can change her session color.
So should this feature be added? So that anyone can change session
participant's nickname on her local session?
There needs nothing to be fixed. The "bugs" related to this issues are not defects but the (unwanted) new behavior because this feature collides with the existing nickname assignment in your XMMP roster. Before this feature was introduced we used the nicknames that are stored in your roster (if present). While this works fine for 2 users it displays different results for more than 2 users.
E.G Alice, Bob, Carl
Alice nicknames are BobAlice, CarlAlice ..
Bob nicknames are AliceBob, CarlBob
Carl nicknames are AliceCarl, BobCarl
So in the session overview for Alice the other participants are displayed as:
Alice = your full JID as you cannot assign a nickname to yourself in the XMPP roster
Bob = BobAlice
Carl = CarlAlice
For Bob:
Bob = your full JID
Alice = AliceBob
Carl = CarlBob
As you may notices Carl is displayed differently for Alice and Bob.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To be sure: We are talking about the nickname marked in the attachment?
And this feature is to be removed completely with all references to the property?
He is talking about this feature. http://saros-build.imp.fu-berlin.de/gerrit/#/c/1619/
To remove it modify the User class and uncomment the getNickname method along with the nickname variable.
To remove this feature completely you can expect a "very nice" tour through many layers of the application.
Maybe you should browser through the Gerrit merge history as the feature was integrated through several patches (about 10 I believe).
As I explained in the discussion of [bugs:#848], we see no value in this feature, so yes, it is to be removed completely.
Related
Bugs:
#848Hi All, I need some clarifications regarding this bug.
"Session nickname feature is unnecessary --> to be removed "
Is it done already? Because i don't seem to find any session nickname feature while using Saros.
I've checked the feature : http://saros-build.imp.fu-berlin.de/gerrit/#/c/1619 and related bugs too.
See the picture posted by Christian. You cannot change the nickname of a session user because the session user chooses its own nickname.
See also discussion in https://sourceforge.net/p/dpp/bugs/848/
Hi Stefan,
I checked the picture and bugs #848 & bugs #842.
I also spent time to understand what need to be fixed.
Then i got confused, because there is no feature to rename a session
participant, host can change her session color.
So should this feature be added? So that anyone can change session
participant's nickname on her local session?
On Tue, Mar 31, 2015 at 9:28 PM, Stefan Rossbach kargor@users.sf.net
wrote:
Related
Bugs:
#849There needs nothing to be fixed. The "bugs" related to this issues are not defects but the (unwanted) new behavior because this feature collides with the existing nickname assignment in your XMMP roster. Before this feature was introduced we used the nicknames that are stored in your roster (if present). While this works fine for 2 users it displays different results for more than 2 users.
E.G Alice, Bob, Carl
Alice nicknames are BobAlice, CarlAlice ..
Bob nicknames are AliceBob, CarlBob
Carl nicknames are AliceCarl, BobCarl
So in the session overview for Alice the other participants are displayed as:
Alice = your full JID as you cannot assign a nickname to yourself in the XMPP roster
Bob = BobAlice
Carl = CarlAlice
For Bob:
Bob = your full JID
Alice = AliceBob
Carl = CarlBob
As you may notices Carl is displayed differently for Alice and Bob.
Thanks for the clarification. :)
Should be marked as fixed.
Feature never went live, so there is no need for testing that it was removed.