Don't highlight messages as new in a different window with the same split(s) as the current one

[hemirt]

Having two tabs with the same channel split inside would highlight the other window as receiving a new unknown message, despite it coming from the same channel that is already being viewed in the current tab.

[pajlada]

This makes sense - I don't see it needing an option either, the behaviour you're talking about should just be the default.

If you have 3 tabs, 2 contain your channel. you're currently in the tab not containing your channel. A new message comes in on your channel.
Both tabs containing your channel should highlight, right?
When you select one of those tabs, should both tabs containing your channels be marked as unread (assuming the message in your channel was the only new one)?

[hemirt]

hopefully I understand it correctly, I think reading the message in one tab should mark all others tab containing this message as already read

whilst ofcourse if youre not in a tab with your channel, all tabs containing that channel should highlight

so all tabs should remember which channel made the tab show the unread notification, and if you go into another tab that contains some channels, all other tabs should remove those unread flags, and only keep the unread notification if there are other channels with unread messages

[hemirt]

same for mentions or other highlights

[hemirt]

Is there a way to know which channels (/splits) does the current tab (NotebookTab / Notebook) contain? I tried looking at how to implement this feature and the best I could figure out is to know who is causing the highlightState change of a NotebookTab (via the invoke slot), so I could add who is causing highlight changes (actors) to a NotebookTab but I could not find a way to figure out which splits are currently displayed, i.e. which highlight changes actors I should ignore -> i.e. 1) not highlighting other tabs due to actors already being viewed in current tab.

I would presume that 2) unhighlighting other tabs on tab change based on actors in the newly being viewed tab, would come out of that easily.

I think then a Notebook, which has its multiple NotebookTab s, would be a good place to do it.

Therefore how I think this could be implemented:

1. chatterino2/src/widgets/splits/SplitContainer.cpp

   Line 220 in 85a7f4a

   this->tab_->setHighlightState(state);

   would add a parameter defining itself (i.e. split name, twitch channel name, split memory address, or just some other pointer)
2. Notebook would know currently being viewed actors and NotebookTab s could query this (via this->notebook_) and ignore highlightState change requests from these actors.

   chatterino2/src/widgets/helper/NotebookTab.cpp

   Lines 361 to 382 in 85a7f4a

   	void NotebookTab::setHighlightState(HighlightState newHighlightStyle)
   	{
   	if (this->isSelected())
   	{
   	return;
   	}
   	if (!this->highlightEnabled_ &&
   	newHighlightStyle == HighlightState::NewMessage)
   	{
   	return;
   	}
   	if (this->highlightState_ == newHighlightStyle ||
   	this->highlightState_ == HighlightState::Highlighted)
   	{
   	return;
   	}
   	this->highlightState_ = newHighlightStyle;
   	this->update();
   	}

3. On NotebookTab selection, other tabs would be processed to remove actors from the newly selected tab, and if it was a last actor (i.e. the list of actors causing highlightStateChange is empty), it would unhiglight itself.

   chatterino2/src/widgets/helper/NotebookTab.cpp

   Lines 305 to 312 in 85a7f4a

   	void NotebookTab::setSelected(bool value)
   	{
   	this->selected_ = value;
   	this->highlightState_ = HighlightState::None;
   	this->update();
   	}

So as I mentioned, is there a way to get the currently being viewed splits/channels?

[Nerixyz]

So as I mentioned, is there a way to get the currently being viewed splits/channels?

Yes, using SplitNotebook::getSelectedPage.

What about message highlights in /mentions (#1185) and message highlights in general? The main issue I see with unhighlighting /mentions if the source channel is selected is that we don't know if the user is in front of their PC. If you leave for a few minutes while viewing a fast chat and get mentioned, /mentions should be highlighted (as the message might get lost in chat). But if you're actively reading the chat and get mentioned (i.e. you see the mention), /mentions shouldn't be highlighted. We can't really detect that. For new-message highlights, this isn't an issue.

which highlight changes actors I should ignore

What's a highlight actor? A TwitchChannel? A TwitchChannel + filters? Ideally, these actors can be compared efficiently, since there could be a lot of comparisons (for each "duplicate" actor - 1, for each window, for each split in the selected tab).

[hemirt]

So as I mentioned, is there a way to get the currently being viewed splits/channels?

Yes, using SplitNotebook::getSelectedPage.

I see, I only saw a

chatterino2/src/widgets/Notebook.hpp

Line 112 in 85a7f4a

QWidget *getSelectedPage() const;

What about message highlights in /mentions (#1185) and message highlights in general? The main issue I see with unhighlighting /mentions if the source channel is selected is that we don't know if the user is in front of their PC. If you leave for a few minutes while viewing a fast chat and get mentioned, /mentions should be highlighted (as the message might get lost in chat). But if you're actively reading the chat and get mentioned (i.e. you see the mention), /mentions shouldn't be highlighted. We can't really detect that. For new-message highlights, this isn't an issue.

I think /mentions should probably just be left of its own (i.e. not doing anything for it in regards to unhighlighting) - since there's probably a reason you even have this tab open.

which highlight changes actors I should ignore

What's a highlight actor? A TwitchChannel? A TwitchChannel + filters? Ideally, these actors can be compared efficiently, since there could be a lot of comparisons (for each "duplicate" actor - 1, for each window, for each split in the selected tab).

Thats what I was asking for, since it's the split's channelView signal

chatterino2/src/widgets/splits/SplitContainer.cpp

Lines 216 to 222 in 85a7f4a

	conns.managedConnect(split->getChannelView().tabHighlightRequested,
	[this](HighlightState state) {
	if (this->tab_ != nullptr)
	{
	this->tab_->setHighlightState(state);
	}
	});

, then it makes sense for it to be the channelView.channel() (or maybe if hasSourceChannel == true then sourceChannel (I believe these are like popup windows or sth)), comparing pointer shouldn't be a performance issue -> although I see it could be a problem with plenty of them, granted I dont think there would be a lot of comparisons done for it to cause issues, but instead some signal slots could be used, should it be an issue, such signal slots would get updated accordingly on new split / changed channel / deleted split.

What's a highlight actor? A TwitchChannel? A TwitchChannel + filters?

No idea what filters are, highlight actor in the end, is the one causing the highlightState to change, and as far as I could see, it was only this

chatterino2/src/widgets/splits/SplitContainer.cpp

Line 220 in 85a7f4a

this->tab_->setHighlightState(state);

and Notebook::duplicatePage

chatterino2/src/widgets/Notebook.cpp

Line 216 in 85a7f4a

tab->setHighlightState(newTabHighlightState);

[hemirt]

I looked at filters and I see the possible issue you eluded to. Those should probably be independent, in my opinion, whilst the direction from filtered channels to unfiltered is fine and probably expected, the other direction from unfiltered to filtered is probably not expected, as again as with mentions, you probably have a reason to have filters.

That is, since if a message appears in filtered channel, it most certainly has appeared at the same time in the underlying channel, therefore from filter to underlying channel it should unhighlight.

But the other way from underlying channel to filter, it should not.

(Ofcourse being completely independent is another possible choice)

[hemirt]

#5649