Babble - A Chat Plugin

(James Kiesel) #107

Adding user preferences is a bit trickier than I’d like, but there’s a couple user preference related requests so I’ll likely get to it at some point.

One approach for today might be to create a theme component with

.babble-sidebar-component,  #babble-icon { display: none };

in it, and allow users to select their theme based on whether they want Babble to appear or not
(Ie, you could have Vincent (with chat) and Vincent (without chat) as selectable themes)

(Makary Gołosz) #108

So, I’d love if you could remove them from RSS feeds, especialy in my case from discourse.url/posts.rss feed, as we use it to display latest posts on our homepage, and would like to exclude chat messages from them :wink:

I was wondering… If I understand correctly, user-to-user mechanism at this moment works this way:

  • creates new user group
  • creates for it new Babble channel
  • messages on this channel
    Wouldn’t it be easier to utilise built in Discourse PM mechanism?
    Don’t get me wrong, I’m don’t know tiniest bit of Ruby, it just seems logical :slightly_smiling_face:
    Cheers ant thank’s for all the good work!

(Gary McPherson) #109

There’s another plugin that does exactly this:

(Makary Gołosz) #110

I am well aware of Angus’s plugin, i use it with pleasure, but thanks :slight_smile:

(Theportablegeek) #111

Hey All! Sorry if this has already been answered, but if I wanted to add a hyperlink that would open babble, could anyone give me some direction?

(Andrew Waugh) #112

Line wrap seems to be hit and miss. One user who tried it was seeing correct line wrap as he typed, but after hitting return they were only partly visible. I thought this might be a result of having a particularly long user Name, but this was unrelated. Strangely, his posts started line wrapping correctly after 5 or so posts.

(James Kiesel) #113

Could you create a github issue here with a screenshot of the unwanted behaviour?

Okay I’ve got a fix for this and will push with the next update.

We already have two completely separate sets of permissions for determining whether you can see a chat, one for groups and one for categories. It’s about at the edge of unwieldiness that I’d like to see. So I opted for re-using the existing group logic, rather than having to go down three paths to determine whether you can view / respond to a topic or not.

(Theportablegeek) #114

Did this ever get sorted?

(Makary Gołosz) #115

Thanks, that makes sense :slight_smile:

(James Kiesel) #116

Alright, I’ve been chipping away at some things today. Here’s a list of stuff I did:

  • Added individual user settings for disabling Babble and enabling notification sounds (default off)
  • Removed chat posts from search results and rss feeds (this change will also prevent people from receiving badges based on their chat activity)
  • Fix for user being unable to log in on latest stable
  • More assertive CSS to make it harder to steamroll Babble from within theme components
  • Moved the audio tag, which I believe has fixed the OAuth login trouble (@Genyus could you help me confirm this? I can login via Facebook on the sandbox just fine at the moment.)
  • Add fix for long words not wrapping correctly sometimes
  • Pushed a locale update (yay German and Dutch!)

Let me know what other requests you have?

(James) #117

Great work! I noticed that every chat that gets sent in Babble shows up in the latest topics on the sidebar plugin.


I’m the maintainer of the sidebar blocks plugin, and, sad to say, but this is less of a Babble issue and more of a “Discourse Sidebar Blocks” plugin issue. (Unless this is something that changed recently, but I doubt it…)

(Gary McPherson) #119

Sorry for the delay, James. Tried to test this yesterday but was blocked a coincidental bug in Discourse itself:

With that issue fixed, I’ve re-tested but am still seeing the same behaviour.

(James Kiesel) #120

It seems like there’s something wrong with your setup, for example visiting results in a 404, whereas sends the notification audio file. Any reason you can think of that this might be the case? What other plugins, or customized code on the server side, might be interfering?

(Gary McPherson) #121

Apologies, when I was testing before, I disabled the plugin to see if it still behaved the same way as previously — whereby it tries to load the .mp3 URL, but as the plugin is disabled, it renders the 404 page instead of downloading the file. I’ve re-enabled it now.

(James Kiesel) #122

Hm, so the bug exists when Babble is present, but disabled, and someone logs in with OAuth?

I’ve just pushed a fix so that the notification file is not loaded unless a) Babble is enabled b) there are chats for the current user to participate in c) the sound option is enabled for that user, which I’m hoping will clear up most of the use cases here. We still have to check though that users who are loading the mp3 are able to sign in with OAuth. :confused:

(Gary McPherson) #123

Correct. If the plugin is enabled, then the browser downloads the .mp3 file on login. If it’s disabled, it still attempts to open that URL, but it fails and renders the 404 page instead.

(Joel Zaslofsky) #124

Incredible, James. Just freakin’ incredible! You’ve put so much into Babble in these last couple of weeks and it’s getting better and better. :fireworks:

For those of you who didn’t follow the previous Babble mega thread, the fact that James is pouring so much into Babble is all the more admirable when you read his context here.

Alright. Now for test results, James. I just did a round of testing with Babble 4.0.3 and there are some things that don’t work the way that I expect. I thought I’d send you a PM with the details, but others may be experiencing the same things, so I thought I’d put them here instead.

Sound Notifications Aren’t Working in a Specific Scenario

Let’s start with how I believe this should work:

I know you developed this feature specifically for my community (thanks!). It’s just not working the way I expect so far.

Here’s the scenario:

I tested this across browsers, mobile/tablet/desktop, and with Babble toggled open and closed. The result was always the same.

The good news is that 1:1 DMs within Babble and @ mentioning someone does generate the notification sound.

Side note: If you have multiple Discourse tabs open, the sound cascades across the tabs every 3-10 seconds. It’ll play in one tab, then another tab a few seconds later, then another tab a few seconds later, and so on.

User Level Babble Options Not Available When a User Isn’t a Moderator or Admin

A user doesn’t see the new Babble options at unless they have either Moderator or Admin privileges as defined at Without Moderator or Admin set to Yes, they don’t see the “Disable Babble chat completely” or “Enable browser sound for new chat notifications” at all.


Perhaps this is by design. If it were me, I’d give access to the user level Babble options regardless of admin or moderator status and regardless of trust level. I don’t see the point of restricting the options.

Closing Babble on Mobile and Left Behind Animation Grayness

This could be due to the more assertive CSS changes you made so I can’t steamroll Babble as much or due to our unique Puttytribe community CSS.

  1. Scroll down on a page
  2. Toggle Babble open
  3. Select a chat room
  4. Toggle Babble closed

Following those steps, it leaves a gray horizontal line leftover from where the closing animation failed to seemingly finish.

(James Kiesel) #125

Thanks for the excellent bug reporting; I’ve pushed some fixes for these.

  • Sound notifications should be much more reliable now, and trigger when you a) have a chat open and receive a message, or b) are directly messaged or mentioned somewhere. I’m thinking about splitting these into two separate user preferences, since if it were me I might be interested in the setting where I’m told someone’s trying to talk to me, but not every time someone decided to post an emoji in the random channel I have open.

  • I’ve fixed the user level babble options so they appear for everyone

  • I’ve also patched up the adaptive height setting, which I believe was causing your issue. I think it’s a much less erratic setting now, and now calculates the height of the chat on resize / scroll based on the difference between the bottom of the header element (.d-header), and the bottom of the screen

(Gary McPherson) #126

So sorry, James. I don’t know how I managed to reply to the first half of your message and somehow glaze over the second half where you mentioned that you’d pushed an update for this :man_facepalming:t5:

I just tested with and without notifications enabled and experienced no issues; all OAuth options now work as expected. :tada: Thanks so much for your diligence on this and apologies again for the delayed feedback.