starred/mumble-mumble-voip

Fork 0

mirror of https://github.com/mumble-voip/mumble.git synced 2026-03-03 00:46:56 -05:00

Add help icons/buttons #1900

New issue

Open

opened 2026-02-20 21:18:10 -05:00 by deekerman · 11 comments

deekerman commented

2026-02-20 21:18:10 -05:00

Owner

Originally created by @toby63 on GitHub (Jun 10, 2020).

Context:
Related to https://github.com/mumble-voip/mumble/issues/4127

Description:
I suggest adding help icons/buttons to the configuration UI.
This way we can describe more complex features like the echo cancellation in a better way than tooltips can (longer text, no disappearing of text etc.).

Concept Examples:
I added a push button with a simple question mark in Qt Creator.
Example 1
Example 2
Example 3

Additional context:
Issue for graphical icon: https://github.com/mumble-voip/mumble-theme/issues/26

Originally created by @toby63 on GitHub (Jun 10, 2020). **Context:** Related to https://github.com/mumble-voip/mumble/issues/4127 **Description:** I suggest adding help icons/buttons to the configuration UI. This way we can describe more complex features like the echo cancellation in a better way than tooltips can (longer text, no disappearing of text etc.). **Concept Examples:** _I added a push button with a simple question mark in Qt Creator._ [Example 1](https://github.com/toby63/stuff/blob/master/mumble/button1.png) [Example 2](https://github.com/toby63/stuff/blob/master/mumble/button2.png) [Example 3](https://github.com/toby63/stuff/blob/master/mumble/button3.png) **Additional context:** Issue for graphical icon: https://github.com/mumble-voip/mumble-theme/issues/26

deekerman added the

client

feature-request

labels

2026-02-20 21:18:10 -05:00

deekerman commented

2026-02-20 21:18:12 -05:00

Author

Owner

@Krzmbrzl commented on GitHub (Jun 11, 2020):

If we are going to do this, I vote for doing it as in Example 1. One help button per category and when opened, it'll open a help page that documents all settings (or all important ones) within that category.
This way we don't have to add a huge amount of help icons that clutter the UI and require space.

@Krzmbrzl commented on GitHub (Jun 11, 2020): If we are going to do this, I vote for doing it as in Example 1. One help button per category and when opened, it'll open a help page that documents all settings (or all important ones) within that category. This way we don't have to add a huge amount of help icons that clutter the UI and require space.

deekerman commented

2026-02-20 21:18:14 -05:00

Author

Owner

@toby63 commented on GitHub (Jun 11, 2020):

The technical details of the window (that opens when clicking the help button) are also important to note.
I think it should be possible to do two things:

Move the window around, so that it is not blocking visibility of the configuration window.
The user should be able to "focus" the configuration window (and change/click/adjust things inside it) while the help window is still open.

This way the user can adjust settings, while they can also read the content of the help window at the same time.

I vote for doing it as in Example 1. One help button per category and when opened, it'll open a help page that documents all settings (or all important ones) within that category.
This way we don't have to add a huge amount of help icons that clutter the UI and require space.

🤔 I am still not so sure about that.
While it might seem like the best looking option (literally), it is not so convenient for these reasons:

Potencially to long text for the whole category.
Text is not focused on the exact feature the user wants to know something about.
Only some features need explanation, so only those might need a help button.
A whole line is blocked just for the icon (maybe it's possible to change that).

So I tend to implement example 2 and/or 3 from above.

@toby63 commented on GitHub (Jun 11, 2020): The technical details of the window (that opens when clicking the help button) are also important to note. I think it should be possible to do two things: 1. Move the window around, so that it is not blocking visibility of the configuration window. 2. The user should be able to "focus" the configuration window (and change/click/adjust things inside it) while the help window is still open. This way the user can adjust settings, while they can also read the content of the help window at the same time. > I vote for doing it as in Example 1. One help button per category and when opened, it'll open a help page that documents all settings (or all important ones) within that category. This way we don't have to add a huge amount of help icons that clutter the UI and require space. :thinking: I am still not so sure about that. While it might seem like the best looking option (literally), it is not so convenient for these reasons: 1. Potencially to long text for the whole category. 2. Text is not focused on the exact feature the user wants to know something about. 3. Only some features need explanation, so only those might need a help button. 4. A whole line is blocked just for the icon (maybe it's possible to change that). So I tend to implement example 2 and/or 3 from [above](https://github.com/mumble-voip/mumble/issues/4279#issue-636559509).

deekerman commented

2026-02-20 21:18:14 -05:00

Author

Owner

@Kissaki commented on GitHub (Jun 12, 2020):

We have control, label, hover tooltip, and help action extended tooltip. And this suggestion suggests adding yet another?

I think adding a help icon button mainly duplicates the extended help text that can already be shown with the help action.

Generally I there is also reasonable opportunity to add some intro and description texts that provides context without hiding it behind actions or hover.

I think making the help action the default tooltip would also be feasible and preferable to help buttons.

If help buttons were to be introduced I would want them to shoe the same help text as the already existing help action. We should not duplicate the help text (a third time with varying detail).

@Kissaki commented on GitHub (Jun 12, 2020): We have control, label, hover tooltip, and help action extended tooltip. And this suggestion suggests adding yet another? I think adding a help icon button mainly duplicates the extended help text that can already be shown with the help action. Generally I there is also reasonable opportunity to add some intro and description texts that provides context without hiding it behind actions or hover. I think making the help action the default tooltip would also be feasible and preferable to help buttons. If help buttons were to be introduced I would want them to shoe the same help text as the already existing help action. We should not duplicate the help text (a third time with varying detail).

deekerman commented

2026-02-20 21:18:14 -05:00

Author

Owner

@toby63 commented on GitHub (Jun 12, 2020):

@Kissaki You seem to ignore what I already said. This is intended to further explain functionality, like what echo cancel option to use.
This can't be explained in one short sentence, so this is no short description.
So tooltips or directly visible texts are insufficient for this scenario, because:

tooltips are only visible when you hover over them and they disappear after some seconds.
always visible texts are disturbing, because they will be too long; a help button can be triggered by those who want help, others are not disturbed by the text, because it will not be visible by default.

And the help action (if I understand correctly you refer to "Help -> Whats this?") is also insufficient, because:

it cannot show details inside the configuration window.
This function is unknown (I simply assume that)
It's not easy to use and not directly visible.

To be very honest, I would rather get rid of tooltips etc., because they always only explain what is already obvious, but that is a different topic.

@toby63 commented on GitHub (Jun 12, 2020): @Kissaki You seem to ignore what I already said. This is intended to further explain functionality, like what echo cancel option to use. This can't be explained in one short sentence, so this is no short description. So tooltips or directly visible texts are insufficient for this scenario, because: 1. tooltips are only visible when you hover over them and they disappear after some seconds. 2. always visible texts are disturbing, because they will be too long; a help button can be triggered by those who want help, others are not disturbed by the text, because it will not be visible by default. And the help action (if I understand correctly you refer to "Help -> Whats this?") is also insufficient, because: 1. it cannot show details inside the configuration window. 2. This function is unknown (I simply assume that) 3. It's not easy to use and not directly visible. To be very honest, I would rather get rid of tooltips etc., because they always only explain what is already obvious, but that is a different topic.

deekerman commented

2026-02-20 21:18:14 -05:00

Author

Owner

@Kissaki commented on GitHub (Jun 12, 2020):

Our extended tooltips already are more than one line.

For example

@Kissaki commented on GitHub (Jun 12, 2020): Our extended tooltips already are more than one line. For example ![image](https://user-images.githubusercontent.com/93181/84535020-413c8a00-aceb-11ea-8ba9-29cb1905e6d2.png)

deekerman commented

2026-02-20 21:18:14 -05:00

Author

Owner

@Kissaki commented on GitHub (Jun 12, 2020):

You seem to ignore what I already said. This is intended to further explain functionality, like what echo cancel option to use.

You never made a concrete example to show the need for more help functionality. You only suggest that it could be added without providing the context of why we need it.

A concrete example can help discuss concrete needs and limitations. Without context of what we would want to add talking about how to add it is kinda… missing substance. Everyone can have their own idea of what we are talking about. As I said I do agree though that more elaborate help would be useful.

@Kissaki commented on GitHub (Jun 12, 2020): > You seem to ignore what I already said. This is intended to further explain functionality, like what echo cancel option to use. You never made a concrete example to show the need for more help functionality. You only suggest that it could be added without providing the context of why we need it. A concrete example can help discuss concrete needs and limitations. Without context of what we would want to add talking about how to add it is kinda… missing substance. Everyone can have their own idea of what we are talking about. As I said I do agree though that more elaborate help would be useful.

deekerman commented

2026-02-20 21:18:14 -05:00

Author

Owner

@toby63 commented on GitHub (Jun 12, 2020):

Our extended tooltips

Never saw those, how are they activated?

You never made a concrete example

I think it's obvious.
There are some options that need explanation:
like https://github.com/mumble-voip/mumble/issues/4127

@toby63 commented on GitHub (Jun 12, 2020): > Our extended tooltips Never saw those, how are they activated? > You never made a concrete example I think it's obvious. There are some options that need explanation: like https://github.com/mumble-voip/mumble/issues/4127

deekerman commented

2026-02-20 21:18:14 -05:00

Author

Owner

@Kissaki commented on GitHub (Jun 13, 2020):

Windows shows the help action button at the top right

I’m sure in the past SHIFT+F1 also worked to activate this cursor. But it doesn’t work for me right now.

Anyway, once you activated this help cursor you can click on controls and it will show extended information/help text if available.

I’m not sure how KDE or Gnome/Qt on those provide this functionality.

@Kissaki commented on GitHub (Jun 13, 2020): Windows shows the help action button at the top right ![image](https://user-images.githubusercontent.com/93181/84572614-8fa96180-ad9b-11ea-874c-b6d3b3246974.png) I’m sure in the past SHIFT+F1 also worked to activate this cursor. But it doesn’t work for me right now. Anyway, once you activated this help cursor you can click on controls and it will show extended information/help text if available. I’m not sure how KDE or Gnome/Qt on those provide this functionality.

deekerman commented

2026-02-20 21:18:14 -05:00

Author

Owner

@toby63 commented on GitHub (Jun 13, 2020):

I’m not sure how KDE or Gnome/Qt on those provide this functionality.

Thats the difference then, it is not visible for me.
Cross platform problem.

Still I would prefer help buttons, they are directly in place, so no need to move a cursor somewhere etc.

That said, the main idea is to provide information about specific features, if that works well in a different way, I won't dissent.

@toby63 commented on GitHub (Jun 13, 2020): > I’m not sure how KDE or Gnome/Qt on those provide this functionality. Thats the difference then, it is not visible for me. Cross platform problem. Still I would prefer help buttons, they are directly in place, so no need to move a cursor somewhere etc. That said, the main idea is to provide information about specific features, if that works well in a different way, I won't dissent.

deekerman commented

2026-02-20 21:18:14 -05:00

Author

Owner

@Krzmbrzl commented on GitHub (Jun 14, 2020):

Thats the difference then, it is not visible for me.
Cross platform problem.

I'm using KDE Plasma and I see them just fine. Not in the MainWindow, but the settings window has it as expected.

@Krzmbrzl commented on GitHub (Jun 14, 2020): > Thats the difference then, it is not visible for me. Cross platform problem. I'm using KDE Plasma and I see them just fine. Not in the MainWindow, but the settings window has it as expected.

deekerman commented

2026-02-20 21:18:14 -05:00

Author

Owner

@toby63 commented on GitHub (Jun 14, 2020):

I use Xfce and I don't see anything.

I think buttons would be a more secure option, as no plattform will ignore them.

@toby63 commented on GitHub (Jun 14, 2020): I use Xfce and I don't see anything. I think buttons would be a more secure option, as no plattform will ignore them.