kvirc / KVIrc

The KVIrc IRC Client
http://www.kvirc.net/
GNU General Public License v2.0
244 stars 74 forks source link

CAP server-time support appears to be broken #2113

Closed minj closed 8 years ago

minj commented 8 years ago

Expected behavior

znc buffer playback should show the actual message timestamps

Actual behavior

all timestamps correspond to the moment of playback

both http://wiki.znc.in/Timestamps#KVIrc and 298cc5c8277a6100f109b77be48455b7aaea75a5 suggest it should work?

Steps to reproduce the issue

  1. setup and configure znc v1.6.0 on a server
  2. setup kvirc to connect to it
  3. leave kvirc offline and wait for buffers to fill
  4. connect to view buffer playback
  5. notice the message timestamps

    System information

built from https://aur.archlinux.org/packages/kvirc-git/

KVIrc 4.9.2 'Aria'

Runtime Info:
System name: Linux 4.7.0-0-MANJARO
System version: #1 SMP PREEMPT Sun Jul 24 23:30:32 UTC 2016
Architecture: x86_64
Qt version: 5.7.0
Qt theme: 

Build Info:
Build date: 2016-08-18 12:33:10 UTC
Sources date: 20160817
Revision number: git-6942-g66bf05d
System name: Linux-4.7.0-0-MANJARO
CPU name: x86_64
Build command: /usr/bin/cmake
Build flags: 
   MANDIR=share/man
   CMAKE_INSTALL_PREFIX=/usr
   LIB_SUFFIX=
   Threads=POSIX
Compiler name: /usr/lib/hardening-wrapper/bin/c++
Compiler flags: -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector-strong 
Qt version: 5.7.0
Features: IRC, IPv6, Crypt, SSL, IfAddr, IPC, KDE, OSS, Transparency, Phonon, Webkit, DCCVoice, Perl, Python, Enchant, Qt5, KVS

This is the first time I tried building kvirc >4.2.0. Perhaps this is just a configuration issue? Any pointers would be appreciated.

For what it's worth 298cc5c8277a6100f109b77be48455b7aaea75a5 build was failing due to 934fa2e1e2c52f3ede2b815d8df5a95c5f5bfa3c etc but while 934fa2e1e2c52f3ede2b815d8df5a95c5f5bfa3c builds it has the same server-time issue. Since I do not have a working commit I cannot provide a regression range if indeed it exists.

un1versal commented 8 years ago

Thx... will need feedback from other people who are familiar with this, but Ill keep an eye out with view to confirming this.

un1versal commented 8 years ago

Well... Im not really seeing any issue for instance,,, a channel playback..

this is from a private channel so the nicks and server details have been edited

[06:43:58] <***> Buffer Playback...
[06:43:58] username [08/18/16 - 17:04:03] going off to the beach in 5 minutes.
[06:43:58] <&DOORMAN> [08/18/16 - 21:39:11] WELCOME TO #CHANNELNAME CHANNEL!
[06:43:58] <***> Playback Complete.

A query playback...

[06:43:58] Common channels for username [username@name.servername.com]: ~#channel-a, ~#channel-b
[06:43:58] <username> [08/18/16 - 19:10:44] hey there.

the timestamps on the left belong to KVIrc not ZNC thats the time I login and auto join the channel/query and the messages were played back in KVIrc

ZNC adds the specific date and timestamps that these messages were sent after the nickname and before the message

to me this is how it always has worked, I cant see anything wrong there,

note that Im not using http://wiki.znc.in/Timestamps#KVIrc as I dont really see the need

minj commented 8 years ago

Please read the znc guide. In my understanding, those timestamps after the nick name are just a stop gap for "ancient clients". They are shown only when both of the following are true: PrependTimestamp=true and client does not support server-time.

This is not how it's supposed to work with kvirc that reportedly has support for server-time.

TBH I am not that familiar with the IRC spec but I've tried sending (using /raw or otherwise) /CAP REQ :server-time on connect, on login and manually and in all cases server response was:

Capability change denied: server-time
DarthGandalf commented 8 years ago

Toggle "Request extended capabilities" to ON in server settings. KVIrc will then request the capability correctly.

ZNC uses the name znc.in/server-time-iso since 1.2, but server-time only since 1.7 which is not released yet. KVIrc handles this automatically.

PS. Why that setting is not ON by default?..

minj commented 8 years ago

Toggle "Request extended capabilities" to ON in server settings. KVIrc will then request the capability correctly.

Wow, now I feel stupid :laughing:

PS. Why that setting is not ON by default?..

Good question :smile:

un1versal commented 8 years ago

I dont know any reason why that is not on by default

Query extended capabilities on connect is the name of setting.

Ill propose the change to enable that by default we will see if theres any reason not to then.

AndrioCelos commented 8 years ago

It is on by default now.

DarthGandalf commented 8 years ago

@AndrioCelos I thought that too, but if that's the case, how @minj had it disabled?

minj commented 8 years ago

@DarthGandalf simple, I created those connections using v4.2.

I am now using 4.3.2.r5631.934fa2e-1 which still has it off by default.

GTK theming seems to be completely broken in a more recent build (4.3.2.r6943.66bf05d) where extended capabilities are on by default

un1versal commented 8 years ago

GTK support has been broken forever... And its been blamed on GTK for equally as long, however I have tons of other applications that work just fine, but their Qt implementation is completely different from ours. https://github.com/mbunkus/mkvtoolnix/tree/master/src/mkvtoolnix-gui

Also GTK support requires you to configure with -DWANT_GTKSTYLE=1 Im pretty sure it was forcibly disabled in https://github.com/kvirc/KVIrc/commit/889e898ab02feb84e128130df7153ce123027515

I need to update the docs.... mmm

Your version is not 4.3.2 its 4.9.2

DarthGandalf commented 8 years ago

@un1versal option certainly doesn't mean "forcibly disabled". What do you even mean by Qt implementation? It's the same Qt from upstream Qt. Did you mean the way how we use Qt?

The version looks like done this way by AUR.

un1versal commented 8 years ago

option certainly doesn't mean "forcibly disabled".

I meant it is disabled https://github.com/kvirc/KVIrc/commit/889e898ab02feb84e128130df7153ce123027515 thats what that means.

What do you even mean by Qt implementation? It's the same Qt from upstream Qt. Did you mean the way how we use Qt?

Yes, I meant the way we "use" or have implemented that Qt support... Really only to say that Their GTK support works flawlessly and is always enabled as far as I can tell. We are the (only?) ones who seem to not work well with GTK apparently

un1versal commented 8 years ago

GTK theming seems to be completely broken in a more recent build (4.3.2.r6943.66bf05d) where extended capabilities are on by default

See, I have to disagree with that...(after some testing) I suspect this depends heavily on the Desktop you use and how well the GTK support is implemented in that Desktop environment. especially if this means Dark Themes.

For instance Im running Ubuntu Xenial (Ubuntu 16.04LTS minimal ISO) install via expert option with added Gnome Desktop only.. I then added Cinammon 3..x ppa and am running Cinnamon Desktop with Mint-Y-Dark controls/Desktop and Numix Window borders.

The only issues I noticed so far are few and hardly what Ide call critical or serious or even a reason not to use it.. 1- Server connect button is unstyled 2- Groupbox boundaries on settings menus arent visible, 3- Menu separators arent visible.

(this is my initial observation) but everything else seems to work just fine.

Ill be opening an issue on GTKSTYLE report in a bit you can comment there after.

un1versal commented 8 years ago

@minj https://github.com/kvirc/KVIrc/issues/2117

minj commented 8 years ago

@un1versal sorry, I used the AUR versioning. In any case it's the hash that matters. I commented on the styling bug