revolution-irc
revolution-irc copied to clipboard
MCMrARM
Don't open notices in their own new tab
Add an option to disable opening new tabs for notices. Just print them in the window the user is currently looking at using - notice - or something similar
This behaviour ought to depend on the type of notice, such as a notice sent to a channel vs one sent directly to a user.
Notices sent directly to the user would make the most sense in their own tab, as there's no concept of an origin channel, just a server. Alternatively, they could be shown in the server tab of the server that the notice originated from.
Showing a direct notice in whatever tab you happened to have open could cause some confusion as to the source, and so doesn't quite make sense to me. If someone sent you a direct notice on a server other than the one you're currently looking at, where then should it appear? Certainly not in your current tab.
Notices sent to channels should obviously appear on the channel it was sent to, but marked clearly as such.
Just my $0.02 on the matter.
Well, a notice is usually used to send a short message to another person without opening up a private window so that it will attract the users attention. I agree that if someone sends you a direct notice on another server, it should not display in the current tab but rather send a notification about the event.
https://tools.ietf.org/html/rfc1459#section-4.4.2
The NOTICE message is used similarly to PRIVMSG. The difference between NOTICE and PRIVMSG is that automatic replies must never be sent in response to a NOTICE message.
Possibly related to this, when a user is kicked from a channel, it would be helpful to display that in the channel rather than in the server tab.
Should be noted that PRIVMASG is the same for both user messages as well as channel messages. If we take the original spec, NOTICEs are to be treated the same as normal messages, just without any automated reply. So if you get a direct notice, it should be consistent with a direct message. If you get a channel notice, it should be consistent with a channel message (aka no explicit notifications either).
RFCs notwithstanding, reasonable heuristics can be more useful than blindly sticking to the RFC.
Notifying messages by recognising their sender, privmsg/notify status, and/or content is preferable to all-or-nothing.
the RFC does not say it needs to be all-or-nothing, it says it should be consistent with PRIVMSG. We don't treat those all-or-nothing, so I don't see why we should treat NOTICEs like that either.
"Blindly following the RFC" sounds like an excuse to throw it out the window, no offense :-)
I mean, distinguishing based on privmsg vs notify may be appropriate in some cases
Even though the RFC says something else I find it far more convenient to get notices in the same tab that I'm in. One of the advantages of this is that it makes bot interaction and service interaction far more easier and pleasant. If this could be added as an optional behavior that'd be great.
NOTICEs are used by bot game (like UNO game) to message users their Cards, its very "hard" if you have to swipe back to PM tab to look what cards i have and then swipe to channel to play a card.
I believe that the behavior of directing messages prefixed with [#channel] to the channel is plain wrong, but well, whatever. I'll add that as a configurable option for the next release.
i need this feature. so my user who play game on irc like UNO can use this apps.
It seems like there are multiple requests here:
@sotengboy wants notices to appear in the currently-displayed tab regardless of context
Others (including me) want a [#channel] prefix to be honoured but otherwise to keep notifications in their current locations.
Notices in the currently displayed tab won't ever be implemented, as I'm completely opposed to the idea and believe it's 100% wrong. If anything I might add a dismissable 'preview' message buffer showed above the send message box with this, but this would require some thought of how it should be implemented.
I also believe that sending notices as [#channel] message is wrong, because it requires implementing additional parsing code for a random client invention and trusting the client that it can send a message to the specified channel. I find it highly unfortunate that this has found widespread use, forcing me to implement this garbage.
I agree that throwing random stuff into the "current" tab is crazy.
The problem with [#channel] is that IRC doesn't provide a standardized mechanism within the protocol layer to send a message addressed to an individual that relates to a particular channel.
IRC relies on people knowing rules and voluntarily abiding by then, so it's important that a newbie will see channel policy notices when they first join a channel, and preferably get reminders fairly often.
It used to be normal to show the topic upon entering and when it changes, but it seems most clients no longer do that, or make it optional, so channels now have to have a bot that sends channel policy reminders and status updates.
I guess a "proper" solution would be for the server to convert a [#channel] prefix into channel notice that's only sent to the target client's TCP connection(s).
But good luck getting that implemented.
So overall I will implement this, but this raised a few concerns.
- I believe these messages should be tagged. A malicious actor could send a notice to a user and make a person reply to a message only he sees. I'm unsure how the tag should be shown.
- I think only users that are member of a channel should be able to send a notice to it, with the particular exception of ChanServ and other services. This is because this can be used to bypass the channel mode which forbids sending messages w/o being a member (maybe the mode should be queried first, as well?)
Another option is to disable this by default, permitting only services to show messages, and then have the user manually enable this option, which would show a warning dialog first.
If you plan on having a list of service nicks (chanserv, memoserv, nickserv, etc) then a user could add their own, and have check box for "anyone" with a big fat warning.
Should this be per server or per channel?
like @target111 says at the beginning of this issue, @target111 want (including me) notice display in currently opened. Same with other IRC Client such as mIRC XChat etc. As i known NOTICE is only for information or whisper and not necessary to reply so need to display in currently viewed tab, and PRIVMSG is for chat to other user in private place, so you can read chat history and focus to reply the msg, and if your friebd forget to reply PRIVMSG you can use NOTICE to remind them. Thankyou
I suggest the issue of [#channel] tagging is covered by #65 and so this issue can be for implementing some sort of 'preview' of messages from another buffer.
Some possible approaches to showing "urgent" messages include:
- a pop-up that's dismissable;
- a slide-in or side-bar area;
- a unified view of multiple channels & PMs in a single tab, so that it's clear that it's not a single-channel (or PM) tab.
Are there other feasible approaches?
Does anyone have a clear idea of which approach would suit the greatest range of use cases?
A unified view might be an interesting way to suit the need of the people of who want this feature, and I think it'd allow a lot of cool stuff, like allowing a 'Mentions' pseudo-window.
Here's a concept for the dismissable buffer I was talking about earlier:
Note that the time is completely separate and this would probably not be "fixed" - as in, if you scroll up, this will stay at the bottom and not stay visible (but you can scroll back down to it). This would store a few messages at maximum. I'm not sure whether I actually like this idea - it sounds pretty complex and the usability is limited - a heads-up notifications works much better, IMO.
As for a slide-in buffer, any ideas how could you slide it in?
I like your proof image, but I would probably put the out-of-context messages at the top rather than the bottom, they're not next to the keyboard.
I'm thinking of having a split view, where you have a view of a channel or pm you can send to, and above that a second view which is read-only and can be configured to show
- some or all of your current channels
- some or all of your current PMs
- optionally all subsequent new channels
- optionally all subsequent new PMs
And with "all messages" or just "only notices".
In a simple case it could just obverse one other channel or PM.
Potentially there could be multiple such views, though only one would be active at once.
Some open questions:
- Should adding a channel to a view should be retroactive, or only show subsequent messages?
- How big a buffer should be provided? Obviously it could get very big very fast.
- Should its updates be deprioritized to conserve battery?
I guess all four edges are already taken, so a button would be needed to enable this view.
It would be nice if the second view was fully interactive, with hyperlinks and text copying.
A unified view might be an interesting way to suit the need of the people of who want this feature, and I think it'd allow a lot of cool stuff, like allowing a 'Mentions' pseudo-window.
Here's a concept for the dismissable buffer I was talking about earlier:
Note that the time is completely separate and this would probably not be "fixed" - as in, if you scroll up, this will stay at the bottom and not stay visible (but you can scroll back down to it). This would store a few messages at maximum. I'm not sure whether I actually like this idea - it sounds pretty complex and the usability is limited - a heads-up notifications works much better, IMO.
As for a slide-in buffer, any ideas how could you slide it in?
Looks great! but can you make notice like privmsg but make different in brace (eg:
Thank You!
I agree with the OP. Notices are not "meant" to open a window. The most usual thing in irc clients is: notices appear on active window if you are viewing the network it came from. If you are viewing an other network, it should appear on the network it originated from, in its status window. However since people are different i think it'd be good if we had the option to switch from active window to its own window.
