Project

General

Profile

Bug #1408

Nick with the dot character are not visible in the UI

Added by Seb-Solon about 1 year ago. Updated about 1 year ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Category:
Quassel GUI (Qt)
Target version:
-
Start date:
05/26/2016
Due date:
% Done:

0%

Version:
0.12.4
OS:
Any

Description

Hi there,

I did not find any issue in this tracker reporting this issue so I am assuming it is still the case upstream.

I am using quassel client : Quassel IRC: v0.10.0 (dist-575f27e), package debian : 1:0.10.0-2.3+d amd64.

I noticed that when a user has a dot in his/her nickname, the nickname does not appear on the left panel when I am chatting with in MP (query).
My case is that people use to take nick as <firstname>.<lastname> so it's pretty hard to chat with them + I am missing conversation as they does appear in the list. The only way to check if I have new message is to double click their nick in a chan so that it resume the buffer.

The bug is not present in the Android application so I believe it is "just" a display issue as my phone is able to retrieve query and show it to me.

Regards,

History

#1 Updated by Seb-Solon about 1 year ago

I found a way to fix this. In my opinion it's a dirty patch because I've just remove a piece of code "randomly"

diff --git a/src/uisupport/bufferviewfilter.cpp b/src/uisupport/bufferviewfilter.cpp
index 189e177..47e1a24 100644
--- a/src/uisupport/bufferviewfilter.cpp
+++ b/src/uisupport/bufferviewfilter.cpp
@@ -342,10 +342,6 @@ bool BufferViewFilter::filterAcceptBuffer(const QModelIndex &source_bufferIndex)
     if (!(allowedBufferTypes & bufferType))
         return false;

-    if (bufferType & BufferInfo::QueryBuffer && !_showServerQueries && sourceModel()->data(source_bufferIndex, Qt::DisplayRole).toString().contains('.')) {
-        return false;
-    }
-
     // the following dynamic filters may not trigger if the buffer is currently selected.
     QModelIndex currentIndex = Client::bufferModel()->standardSelectionModel()->currentIndex();
     if (bufferId == Client::bufferModel()->data(currentIndex, NetworkModel::BufferIdRole).value<BufferId>())

I don't really understand what is sourceModel()->data(source_bufferIndex, Qt::DisplayRole).toString().contains('.') but I understand that it filters my query because of the '.'.
If someone knows why query with "DisplayRole" containing string should be filtered can answer that would be great ;)

Hope it will help somebody, someday :)

Regards

#2 Updated by EgS about 1 year ago

  • Category set to Quassel GUI (Qt)
  • Status changed from New to Confirmed

Hi,

you are perfectly right that it is just a display issue. Unfortunately, there is no clean fix. Let me elaborate: if you ever receive a message from an IRC server (not from another user), we try to show the message in the status buffer. But there is no technical way to distinguish between servers and regular users. Except for the fact that servers use their hostname (e.g. orwell.freenode.net) as the sender string. So at the time being, we simply check if the sender contains a dot and, if this is the case, assume it is a server and redirect the message to the Status Buffer.

There is one easy workaround: in the interface settings of Quassel, simply select the "Default Target" check box for "Server Notices". The only downside is that you will have a new query buffer for each server, from now on.

There are two actual possible solutions:
1.) We explain that issue in the interface settings and perhaps even change the default.
2.) Someone comes up with a more sophisticated plan to distinguish hostnames from usernames containing a dot.

Cheers,
Marcus

#3 Updated by Seb-Solon about 1 year ago

Hi,

Thanks for the reply! The workaround is working for me. At least I don't have to recompile my custom quassel version :).

1 - The dot is forbidden in the nick for Freenode (maybe for all standard IRC server). My case is that I'm using quassel client to connect to non-IRC server (Slack - Gitter). What's the place to document that? The redmine wiki?

2 - Is there a way to get the server name (host field you fill for connecting) in this context? I know they don't match but we could infer it's a server if we have XXX.freenode.net and we connect to YYY.freenode.net. Another option may be to be able to specify it manually. For example on Gitter the servername is gitter so I received as a query. In this case gitter matches a part of the hostname I am connected to (irc.gitter.im)

#4 Updated by EgS about 1 year ago

  • Status changed from Confirmed to Rejected

Hi again

I checked again if we have some easy means in Quassel to distinguish between servers and clients with a dot in their nick. Unfortunately, there isn't. This is because queries are identified by the corresponding nick name in the storage backend and nothing else. That decision was made since anything else (the username and the hostname) can vary over time.

Also, after checking with the IRC RFC, I found that dots are not allowed in nicknames:
<nick> ::= <letter> { <letter> | <number> | <special> }
<letter> ::= 'a' ... 'z' | 'A' ... 'Z'
<number> ::= '0' ... '9'
<special> ::= '-' | '[' | ']' | '\' | '`' | '^' | '{' | '}'

While it would be nice to support nicks with dots and obviously the RFC is quite old, I currently do not see any nice method to distinguish them from servers. Therefore, I am closing this bug report.

However, I do suggest to make this known for other users who might encounter this issue with non-RFC conforming IRC servers. A good place for that would indeed be the wiki. At least, there is now this bug report, which should show up if someone searches for this problem.

Cheers
Marcus

#5 Updated by confluence about 1 year ago

This has been driving me crazy for weeks! I am also using Slack IRC gateways, and exactly one contact's chat window has inexplicably been missing from the UI (but when I looked in the database the buffer entry seemed completely normal). Today I finally figured out that it's the only contact with a dot in their nick.

Thanks for the workaround -- it works for me!

Since dots are not actually permitted in the standard, I believe that this should be filed as a Slack bug -- other gateways (e.g. Bitlbee) rewrite nicks to eliminate dots. I will attempt to report this.

Also available in: Atom PDF