Version: 1.3.1 (using KDE 4.6.5) OS: Linux two channel-tabs show the others channel name see: http://www.abload.de/image.php?img=konversation_gone_mad066b.png in the screenshot, looking at the tab, i am in #newsid, but really i am in #aptosid.de, to the left of it. so, both tabs show the wrong name. after closing and rejoining, both tabs are named right Reproducible: Didn't try Steps to Reproduce: this is the first time i see this. no idea if it happens again Expected Results: channel-tabs should show the right channel name
Created attachment 62693 [details] Screenshot of tab problem Attach image directly so it won't get lost.
Whoa, that's really funky - the code that's handling tab naming has been virtually unchanged since 2006, and something like that has never been reported or sighted before. Hm, had you done anything interesting in the session, like switch between the normal tab bar and the treeview version of the tab bar?
Hi Eike, I know its funky, never heard or seen anything the like. The box had been runnig for 4 days at the time, and so was Konversation. My settings are unchanged for years, and for sure i did not play with the tab bar. The only change in my settings was due to [Bug 279456], which i had filed the other day. My guess (and hope) is, it will not happen again. I just thought i'd file it out of curiosity. greetz Ferdinand 2011/8/9 Eike Hein <hein@kde.org> > https://bugs.kde.org/show_bug.cgi?id=279693 > > > Eike Hein <hein@kde.org> changed: > > What |Removed |Added > > ---------------------------------------------------------------------------- > Status|UNCONFIRMED |NEEDSINFO > CC| |hein@kde.org > Resolution| |WAITINGFORINFO > > > > > --- Comment #2 from Eike Hein <hein kde org> 2011-08-09 11:43:49 --- > Whoa, that's really funky - the code that's handling tab naming has been > virtually unchanged since 2006, and something like that has never been > reported > or sighted before. > > Hm, had you done anything interesting in the session, like switch between > the > normal tab bar and the treeview version of the tab bar? > > -- > Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You reported the bug. >
I'm seeing a similar thing happen. I'm on Debian unstable, using KDE 4.6.5 and Konversation 1.3.1+ #4092. I update my machine every week or so, usually involving a reboot. I started seeing this weirdness about a week ago, and thought a reboot would fix it. A reboot (or even a restart of Konversation) does put all the tabs back into order again, but I think(!) that changing the order of the tabs (with the mouse - dragging them to a new position) confuses most or all of the tab names (not just the ones that I moved). I'm attached to two irc servers - freenode and a company internal server. I have one channel open on freenode, and 5+ on the internal one. Curiously on my tabs I see that the colour-dots are sane - the blue tabs reflect server contents, though they are both named wrong (one is named by the other server name, the other is named as a channel name). Red-dots are accurately identifying private chats, but are also named improperly. Happy to do some exploring if you can think of a good test. I suppose removing all my (nicely tweaked) konversation configuration files would be a good start. I shall report back if I discover anything useful.
Good someone not related to me in any way sees this bug as well. And yes, you are right, it does happen when tabs are moved by drag and drop as opposed to rightclick move left | move right. I never seen it happen there. I have ~ 25 channeltabs, all but one on OFTC, the one is on Freenode greetz Ferdinand 2011/9/14 <jedd@progsoc.org> > https://bugs.kde.org/show_bug.cgi?id=279693 > > > jedd@progsoc.org changed: > > What |Removed |Added > > ---------------------------------------------------------------------------- > CC| |jedd@progsoc.org > > > > > --- Comment #4 from <jedd progsoc org> 2011-09-14 12:07:18 --- > I'm seeing a similar thing happen. I'm on Debian unstable, using KDE 4.6.5 > and > Konversation 1.3.1+ #4092. I update my machine every week or so, usually > involving a reboot. > > I started seeing this weirdness about a week ago, and thought a reboot > would > fix it. A reboot (or even a restart of Konversation) does put all the tabs > back into order again, but I think(!) that changing the order of the tabs > (with > the mouse - dragging them to a new position) confuses most or all of the > tab > names (not just the ones that I moved). > > I'm attached to two irc servers - freenode and a company internal server. > I > have one channel open on freenode, and 5+ on the internal one. Curiously > on my > tabs I see that the colour-dots are sane - the blue tabs reflect server > contents, though they are both named wrong (one is named by the other > server > name, the other is named as a channel name). Red-dots are accurately > identifying private chats, but are also named improperly. > > Happy to do some exploring if you can think of a good test. I suppose > removing > all my (nicely tweaked) konversation configuration files would be a good > start. > I shall report back if I discover anything useful. > > -- > Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email > ------- You are receiving this mail because: ------- > You reported the bug. >
Thanks, the drag'n'drop bit was the missing puzzle piece. Without having looked at the code, I think this might be a regression from someone enabling document mode on the tab bar recently thus allowing left-click drag reordering (normally it's middle-mouse in KDE tab widgets) and that type of dragging bypassing the drag restrictions that enforce channel tabs staying grouped behind their respective server status tab. We'll look into it.
OK, we've found the cause now: This is actually a bug in kdelibs, uncovered by recent code changes in Konversation. In Konversation commit e8a7b459 David Faure ported the method call that makes tabs draggable from the old, deprecated KTabWidget::setTabReorderingEnabled() to Qt's equivalent setMovable(). The problem is that this doesn't work well in conjunction with the call to setAutomaticResizeTabs() made when the "Limit the size of the tab labels to fit all on screen" checkbox is enabled in Konversation, because KTabWidget maintains a copy of the tab names and is oblivious to the drag reorder done inside Qt. The result is that when the tab bar moves between showing full labels or eliding the labels as well as possibly some other circumstances, the labels get replaced with what they were before dragging. There's a couple of things to do now: a) File a bug against KTabWidget, which I will do and reference here shortly. b) We could go back to the deprecated setTabReorderingEnabled() for now to avoid the bug. c) You guys could either switch to the unaffected treeview version of the tab bar (by placing tabs on the left) or disable "Limit the size of the tab labels to fit all on screen" in the config dialog.
See bug 282017.
Eike - thank you so very much - this is just amazing service! Will disable the 'limit the size of tab labels' now - I've tested it and confirmed that it protects me from the label confusion bug.
Thanks for your report, being able to reproduce a bug is often 95% to getting it fixed :).