Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When "Listening" to a channel (#4011), text messages should also be delivered #4539

Closed
kripton opened this issue Oct 21, 2020 · 5 comments
Closed
Labels
feature-request This issue or PR deals with a new feature

Comments

@kripton
Copy link
Contributor

kripton commented Oct 21, 2020

Context

  • User resides in ChanA and listens to ChanB
  • Audio in ChanB is delivered to user thanks to the feature implemented in Channel Listeners #4011

Describe the feature you have in mind

  • Text messages / chat that occurs in ChanB should also be delivered to user

I plan to work on this myself but of course if someone else is faster, that would be awesome. I do have the build system working for Linux and I do have some experience with Qt-based apps. However, the mumble source code and protocol are new to me.

@Krzmbrzl
Copy link
Member

I'm not entirely sure that this is something that a user would/should expect when listening to a channel 🤔

On the other hand there is probably not much that actually speaks against doing so in any case 🤷
And I do see some value in scenarios where e.g. someone references a link that (s)he has posted in chat that currently a listener won't be able to see.

However, the mumble source code and protocol are new to me.

No problem. if you have any questions (which you probably will), just let me know. I'm happy to help :)

I think the implementation is actually rather straight forward: When receiving a text-message on the server, relay them to all listeners of a channel, that don't receive the message already (due to links, or simply due to being in that channel).

@Krzmbrzl Krzmbrzl added the feature-request This issue or PR deals with a new feature label Oct 21, 2020
@kripton
Copy link
Contributor Author

kripton commented Oct 21, 2020

I think the implementation is actually rather straight forward: When receiving a text-message on the server, relay them to all listeners of a channel, that don't receive the message already (due to links, or simply due to being in that channel).

Are you referring to Channel Links as documented here: https://wiki.mumble.info/wiki/ACL_and_Groups#Mumble_Access_Control_Vocabulary ? That feature was new to me, thanks for pointing it out :) However, I did a quick test and even with linked channels, the chat messages are not shared to all users in that link group (text messages are only given to the users in the channel they appear in, not to the users in other channels of the same link community). Do you think this should be done as well for consistency? Should that (and the case that I requested for the Listeners (I'd call them Ears because of the icon ;)) be discussed somewhere else than here as well?

kripton added a commit to kripton/mumble that referenced this issue Oct 21, 2020
The "Channel Listeners" (mumble-voip#4011) feature allows users to hear the audio
from a channel without joining it. This commit also delivers text
messages to all users who are "listening to" a channel this way.

Implements mumble-voip#4539
kripton added a commit to kripton/mumble that referenced this issue Oct 21, 2020
The "Channel Listeners" (mumble-voip#4011) feature allows users to hear the audio
from a channel without joining it. This commit also delivers text
messages to all users who are "listening to" a channel this way.

Implements mumble-voip#4539
kripton added a commit to kripton/mumble that referenced this issue Oct 21, 2020
…nels

The "Channel Listeners" (mumble-voip#4011) feature allows users to hear the audio
from a channel without joining it. This commit also delivers text
messages to all users who are just "listening to" a channel this way.

Implements mumble-voip#4539
@Krzmbrzl
Copy link
Member

Yes I am referring to exactly that.

Okay then we only have an open feature requests for text-messages to be relayed from linked channels: #1719
I wasn't sure whether this is already implemented or not.

Do you think this should be done as well for consistency?

Well if you want to, that'd be nice 👍

Should that (and the case that I requested for the Listeners (I'd call them Ears because of the icon ;)) be discussed somewhere else than here as well?

Here's fine (your PR works just as well).
Yeah I kinda switch between Listeners (due to the name of the action) and Ears 🤷

@kripton
Copy link
Contributor Author

kripton commented Oct 22, 2020

Ops, I forgot to search for similar tickets. I'll implement the "text messages to linked channels" after PR #4540 is done.

kripton added a commit to kripton/mumble that referenced this issue Oct 22, 2020
…nels

The "Channel Listeners" (mumble-voip#4011) feature allows users to hear the audio
from a channel without joining it. This commit also delivers text
messages to all users who are just "listening to" a channel this way.

Implements mumble-voip#4539
kripton added a commit to kripton/mumble that referenced this issue Oct 23, 2020
…nels

The "Channel Listeners" (mumble-voip#4011) feature allows users to hear the audio
from a channel without joining it. This commit also delivers text
messages to all users who are just "listening to" a channel this way.

Implements mumble-voip#4539
Krzmbrzl added a commit that referenced this issue Oct 23, 2020
…ers only listening to channels

The "Channel Listeners" (#4011) feature allows users to hear the audio
from a channel without joining it. This commit also delivers text
messages to all users who are just "listening to" a channel this way.

Implements #4539
@kripton
Copy link
Contributor Author

kripton commented Oct 23, 2020

Implemented by #4540. Thanks for merging so quickly!

@kripton kripton closed this as completed Oct 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request This issue or PR deals with a new feature
Projects
None yet
Development

No branches or pull requests

2 participants