Make the chat window less obtrusive

[sthenos]

Hi all,

The chat window can be a little annoying at times and gets in the way or sometimes, because it's a seperate window you can minimise it and forget its open, this can cause some confusion for newbies, but also I find it a little annoying that it keeps popping up when a message appears.

I'm not sure what the solution is, because perhaps for those that are not interested in having it pop up when you load jamulus or when messages occur, that there is a way to indicate that it remains hidden unless specifically clicked?

Or better yet. If someone clicks the close button on the chat window and a new chat appears then instead of popping the window open, the chat button can flash or have a different colour to indicate a new message? Also when you join a new server, I don't need the chat window to pop open every time.

[pljones]

It must pop up when a message appears. How else are you going to know someone without a vocal mic is trying to talk to you? Do you mute everyone else so you can't hear what they're saying?

Similarly, your rights to using a server may well be displayed on the chat window. If it doesn't display to you, you won't be aware what these are.

[gilgongo]

There was a discussion about using the OS's messaging facility for this, but an advantage of the way it works now is that you get to see the full contents of the message without having to interact with your computer. So you can make a decision about whether to reply to the message or not.

Incidentally, one of the fantasy UI redesigns I did for Jamulus uses a panelled approach, and puts the chat in a panel to one side for this reason.

[sthenos]

@pljones Yes I understand that the acceptance of license may be the one thing that needs to popup, could it conditionally popup when a license request is received.

For the usecase of a person without a mic trying to talk to you, that is why I'm saying flash the chat button led or change it's colour so we know someone is trying to talk. But for many other situations, for instance when it constantly pops up when you're trying to mix a choir of 30 people, is incessentantly irritating!

[sthenos]

@gilgongo I like the idea of the chat panel being to one side, which makes it less obtrusive by design.

[gilgongo]

@sthenos I think any large changes to the UI like that would need considerably broader consideration though, and may well involved a fork - so I wouldn't necessarily encourage it :-)

EDIT: At the risk of stating the obvious, you can I think just size the chat window to be next to the main window and achieve a similar thing. Low elegance score, I'll grant you.

[pljones]

@gilgongo I like the idea of the chat panel being to one side, which makes it less obtrusive by design.

EDIT: At the risk of stating the obvious, you can I think just size the chat window to be next to the main window and achieve a similar thing. Low elegance score, I'll grant you.

Indeed, and window positions and sizes are remembered. If you want it to the side, put it to the side. Organised and personalised exactly how you want, without imposing on anyone else.

[sthenos]

Hmm, this doesn't help us for the sound engineering desktop for Worldjam where we have maybe 10 jamulus clients runnning, with the additional chats popping up constantly it's a right pain.

[JcKlomp]

I'm using a tiling window manager on linux and the chat window behaviour can be very annoying.
Currently these are the options:

• closed chat window: all the windows get rearranged on a chat message popup, so windows with lyrics or tabs are suddenly somewhere else possibly ruining the song
• have the chat window opened: waste of space
• have the chat window opened but minimised: chat messages are noticed at least half an hour late or at the end of a session

The last state is where one naturally ends up, which makes the whole chat functionality not as useful as it could be.
I know, part of the deal when using tiling window managers but to some extent this issue also applies to normal window managers because due to the popup on the server welcome message it is quite likely for users to minimise the window and forget about it.

Having the chat button flash on new messages (maybe just for a little while) instead of popping up the chat window sounds like a great and simple idea?

[gilgongo]

Having the chat button flash on new messages (maybe just for a little while) instead of popping up the chat window

Or an "unread messages" icon next to it that would be dismissed on maximising the window? Or trigger an OS notification, as is more usual for chat apps, perhaps? Probably harder to implement though I guess.

[dingodoppelt]

I simply leave the chat window open and just minimize it. When a new message arrives it stays minimized and doesn't pop to the front anymore.

[corrados]

for the sound engineering desktop for Worldjam where we have maybe 10 jamulus clients runnning

Wow! For what reason do you need that many clients running?

Are you running the engineering desktop under Windows or Linux? If it is Linux, you may consider running Jamulus as a headleass client, e.g., for the monitors.

[sthenos]

Running in linux. We run a few headless, but need the gui's open for tweaks on faders in various rooms, plus the reassurance that they are in fact running.

Anyway for the moment, I've automated the closing of chat popups by using wmctrl -i -c [win id] for the time being. But it's a bit of hack.

[sthenos]

Here's the jack routing I use. Plenty of jamulus clients!

[chrisrimple]

A few thoughts...

• On Mac, the user can enable Tabs, so popups appear as tabs in the active Window. In Jamulus, this manifests as 3 tabs: Settings, Chat, and Mixer. Personally, I love that, but it does mean that I'm not aware when a new chat message arrives, because I never look at that tab.

• I think a better solution would be to eliminate the Chat window and add it as a fixed-width portion on the right side of the Mixer window, perhaps with expand/collapse control to show/hide it, and maybe the ability to drag it out to a separate window, but re-dock it when needed (or maybe on restart).

[corrados]

@sthenos Are you still using a Jamulus client to send the audio signal to the broadcast server?

[sthenos]

Yes @corrados we are. We tried a number of different ways to get the audio to the broadcast desktop using ffmpeg, rtp, rtsp, vlc. All of them result on audio sync drift, sometimes resulting in audio out of sync with zoom sometimes up to 20 seconds. We abandoned and went back to using a Jamulus client which is 100% reliable, although results in an additional 2 opus encodes.

[dingodoppelt]

@sthenos:
haven't you tried jacktrip? it should do the job just fine, as long as buffersizes are the same on both jack servers.

[corrados]

All of them result on audio sync drift, sometimes resulting in audio out of sync with zoom sometimes up to 20 seconds.

I am not sure if VLC or the others are really causing this drift. I have not tried it myself but it seems in VLC you can choose a fixed maximum length of the buffers. So 20 seconds sounds a lot to me. Maybe someone experienced with VLC audio streaming could comment on that.

haven't you tried jacktrip

Yes, this is also an alternative. Should give you low latency and does not use audio coding.

[corrados]

Coming back to the topic:

I've automated the closing of chat popups by using wmctrl -i -c [win id] for the time being.

As another workaround you could make the window as small as this:

And put these small windows of all your Jamulus clients on your Worldjam engineering desktop at, e.g., the top right edge of the desktop. So all chat windows of the individual Jamulus clients overlap at that place.

[nefarius2001]

#699 (comment)

@gilgongo I like the idea of the chat panel being to one side, which makes it less obtrusive by design.

Same here. How about making it dockable (QDockWidget), showing/popping up at the right side of the sliders by default? That is minimal change, flexible and leaves the opportunity to resize it to minimum if ignored ;)

[gilgongo]

Hi all - there are a number of UI-related discussions going on, so I'd like to move that over into that section so that designers can keep to to date on them as part of what may be a proposal to re-engineer the UI.