Version: 1.3.1 (using KDE 4.5.1) OS: Linux On many open source channels, there are frequent join/part messages, often to the point that actual conversation can get lost if you're away from the IRC window for more than a few minutes. Obviously there is a "hide join/part/nick requests" option, but this is not perfect, because it is often useful to know that someone has left (ie. if you're part way through a conversation with them). What we need is a way to reduce these messages, without blanket killing them off. I can think of three ways, with some pros and cons. I don't know which would be more difficult to implement, and there might be better solutions, but here they are: 1) Add a "toggle join/part/nick messages" switch to a menu, with a keyboard shortcut. If J/P/N messages are on, toggling this would hide them, but NOT delete them, and un-toggling would unhide them. It might also be useful to have a "hidden messages" symbol in the IRC channel view. 2) Message folding: each block of J/P/N messages could be "folded", á la Kate's code folding, by clicking an appropriate symbol next to the first or last line in the block. Even nicer would be to have the folded view show a summary of the folded lines, something like: "Joined: User5, User6, User7; Parted: User2, user7, user4; Nicks: User1->John", perhaps just showing the most recent 3-4 of each, or something. 3) Only show last X J/P/N messages: After X (customisable) J/P/N messages have displayed, the X+1th message causes the 1st message to be deleted, so there are never more than X J/P/N messages displayed. This would work reasonably well even on small screens - even on my netbook, I could display the latest 10 J/P/N messages and still have 2/3 of the screen left for actual conversation. My personal preference would be for #2, but I imagine it's also the hardest, and I would be very happy with these, or anything like them. Reproducible: Didn't try OS: Linux (i686) release 2.6.35-28-generic Compiler: cc
The development version has the ability to only show the events for people who have been seen speaking in the same channel within a configurable amount of time (1 hour, 1 day or 1 week).
That would probably be good enough for me, though I'll probably wait for a stable release. I assume you mean that you can select X (hours|days|weeks)? If not, that would definitely be preferable, I think something like 4-6 hours would be optimal for me, for such a scheme - 1 day would capture the conversations from the day before. If so, please feel free to mark this as resolved.
I just tried pulling from git and compiling, and the stated feature is there, but isn't working correctly: the drop down next to "except for watched nicks..." is empty - I can't select anything. It'd be nice if this was a numerical text-input and a drop down for units (minutes, hours, days).
Git commit 6d08665b17c5b958389ac1be97762f9bd98251cf by Eike Hein. Committed on 16/03/2011 at 09:02. Pushed by hein into branch 'master'. Fix a regression from 1efec14 causing the combobox to remain empty. CCBUG:268176 Plus make the comments on the entry strings a bit more direct. M +9 -4 src/config/chatwindowbehaviour_config.ui http://commits.kde.org/konversation/6d08665b17c5b958389ac1be97762f9bd98251cf
Fixed, thanks for testing. The entries are currently 10 minutes, 1 hour, 1 day and 1 week. I'm hesitant about moving to a two-field version because of UI layout concerns in the context of the current config dialog design, but we'll take your request under advisement.
Appears to be set to 1 hour, and working nicely. Can't wait for customisability :)
Sorry, that comment was supposed to come before yours. Tried the latest git. works nicely. I think that's definitely good enough for me. Of the original request, I still think toggle would be nice, but it is probably overkill, and unnecessary.
FWIW we do like your toggle request and have actually been thinking along those lines for a while as well, also with regard to things like the ignore system and netsplit handling. Merely hiding data so it's still around and can be shown on demand as opposed to throwing it out for good definitely seems superior. We've got a rewrite of the text display widget we use in the works right now and pulling off these kinds of dyamic filtering behaviors is a design consideration that.
The current solution does not work perfectly: join events are all blocked. For example, if I am talking to someone, and their connection drops out, the will part/disconnect, and then probably re-join in a minute or so, when their connection is back up. This join even is valuable to display. Obviously later join events are not as important, but considering how well the current solution works in dealing with part events, I doubt the number of re-joins would be very annoying, so they should be dealt with in the same way as part events. Cheers ned
Hiding instead of discarding the J/P/N data that isn't needed has an added benefit: If someone starts talking, you could immediately unhide their most recent join event, if you have it, so you could see whether they'd been around for a while, or just joined.