Closed minj closed 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.
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
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
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?..
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:
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.
It is on by default now.
@AndrioCelos I thought that too, but if that's the case, how @minj had it disabled?
@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
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
@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.
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
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 sorry, I used the AUR versioning. In any case it's the hash that matters. I commented on the styling bug
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
System information
built from https://aur.archlinux.org/packages/kvirc-git/
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.