Decide where notices should be displayed
Currently, all notices are displayed in the status buffer. In my experience, this is quite annoying, because for example, if I request something from a bot in a channel, I have to switch to the status buffer to read the reply. I think, it would be much more convenient to display this in the current buffer.
The question remains, if the backlog should store this appropriately, or if - on backlog reply - notices always go to the status buffer. Obviously it would not make much sense to show all notices stored in the backlog in the now selected buffer. It might make sense though to display them in the same buffer they were displayed originally - but there is no way for the backlog to know this, since this is a GUI thing... one could always transmit a BufferId back to the core and update the backlog, though. Which is not particularly clean.
Also, what happens if we have multiple connected GUIs with different buffers open? Or no buffer open at all?
Feedback on this strongly requested.
#1 Updated by EgS about 16 years ago
First of all I think this should be user configurable. And I think the question applies only to notices which don't have a channelname as the target.
1.) The most obvious solution would be - as it is now - to determine by the first param (the target of the notice) where to display the message. But as Mentioned this is might not be desirable. (i.e. bots tend to send notices to a user who just joined a channel).
2.) the current buffer. This doesn't need much explanation I guess. Not preferred by me but why not?
3.) the status buffer of the network. In general I do like this option. Seems like a good place to collect the notices. maybe trigger a highlight?
#2 Updated by Sputnick about 16 years ago
I think notices usually have your own nick as target, and not a buffer. At least that's how it is implemented right now; I did not check the raw message...
Ok, we could make this an option - but for users like me, who'd like to see notices in the current buffer, there is still the problem where to display on backlog replay. Well, then the status buffer is probably ok...
#3 Updated by EgS about 16 years ago
Regarding the backlog issue when displaying NOTICEs on the active channelbuffer (btw: where should it be displayed if your active buffer is a query?):
I'd save it in the backlog of that channelbuffer aswell. When replaying the user should be able to make sense of that NOTICE in the channelbuffer - if not it's not my problem. But this fact should at aleast be noted in the options dialog.
But this leads to a not so trivial implementation issue: how should the core know which buffer is currently beeing displayed by the gui? The core could request the active buffer before emiting the Message::Notice but since it's asychronous I don't feel very comfty with this solution...
#4 Updated by Sputnick about 16 years ago
As I said earlier: "...but there is no way for the backlog to know this, since this is a GUI thing... one could always transmit a BufferId back to the core and update the backlog, though. Which is not particularly clean."
So that would be the only possibility I see. But the thing is, "current buffer" is not as clearly defined as one might think. In particular, what happens if we have two GUIs connected, and they display different buffers? Which one should determine the "active buffer" and transmit this information to the backlog?
So probably, the best thing would be to store notices in the status buffer of the network. The display-in-active-buffer-thing is mostly a convenience. Usually such notices arrive as reply by a bot (think service bots or quiz/fun bots). It is quite annoying to switch between the channel and the status buffer all the time, especially if it's kind of a dialogue between you and the bot. But on backlog replay I really don't care where the bot's replies are displayed... they're no longer interesting anyway.
#5 Updated by EgS over 15 years ago
There are settings in the client which state where the message should go.
Those settings can be applied on replay aswell, or another set of settings for the backlog can be introduced.
Discussion about this topic is therefore this discussion is irrelevant -> close