Bug: Some binding descriptions overlap the diagram of the mouse

[leviport]

Some binding descriptions are long enough that they overlap the image of the mouse. The longest ones are display brightness up/down and move to workspace above/below.

[WatchMkr]

@christian-salgado @maria-komarova please take a look at how we might improve this.

[maria-komarova]

I was actually wondering about it and I thought we should set a character limit and show full descriptions on hover.

[ids1024]

I was wondering if it should show on multiple lines, but there isn't really space for that.

It's a bit awkward to address because currently each label has a hard-coded coordinate for the end of the line. I guess it would need to also specify coordinates for the other end.

[WatchMkr]

The longest descriptions aren't too far off from the mouse outline. What do you think about extending the beginning of the line so they'd fit? Are there other consequences to that?

[maria-komarova]

It's a bit awkward to address because currently each label has a hard-coded coordinate for the end of the line. I guess it would need to also specify coordinates for the other end.

Yeah, probably. Talking to @christian-salgado and thinking about it more we might not be able to rely on character limit either considering other typefaces can have a different character width. So we will need to restraint the length of the button. We can go a different route and place all the labels on one side of the mouse which would give us more length for the labels and maybe less custom coordinates although I'm not entirely sure about the latter. But then that would mean more changes overall and more tweaking of button placement.

If we limit the length we might also want to adjust the hover state. We have a hover state in the app already but I wonder if that needs to be refined in terms of styling. @ids1024 would it be possible for us to get a bit more padding around the labels in GtkButtons without loosing the placement?

I was wondering if it should show on multiple lines, but there isn't really space for that.

I was wondering about that as well but I agree, doesn't seem to be space there and might look weird in any case if we do that.

[maria-komarova]

The longest descriptions aren't too far off from the mouse outline. What do you think about extending the beginning of the line so they'd fit? Are there other consequences to that?

More implementation for @ids1024, there will be a need to move things around again and adjust the coordinates. Plus the alignment of widgets like the dropdown above. Primary reason why we didn't increase the length. Another consideration is it might not ensure all typefaces will behave equally. Unless changing the typeface for the system in Tweaks won't change it for this app.

[maria-komarova]

I don't know if we're going to have a translation for the app either. If that is not a concern, then that won't have an effect. But if we plan to have it, then labels can get longer in other languages. For example, "Move to workspace above" is only 23 characters in English but 36 in Polish (running it through the quick translator).

[WatchMkr]

Good point.

[maria-komarova]

We can increase the length of lines and adjust the coordinates to cover our defaults and English better but we'd still need to restrict the length of the buttons to account for possible edge cases.

[christian-salgado]

Should we just simplify the text? Workspace Up, Workspace Below, Brightness Up, Brightness Down.

[maria-komarova]

I think this is too cryptic. We need indicate what exactly happens with workspaces and what brightness we mean.

[WatchMkr]

That could work with some adjustment... "Display Brightness Up" and "Display Brightness Down" are a little shorter. "Workspace Up" and "Workspace Down" are good.

Separate but something to consider, with COSMIC DE, we'd like to enable vertical or horizontal workspaces which makes the language tricky. We may want to use "Workspace Next" and "Workspace Previous" or similar to start making it orientation agnostic,

[christian-salgado]

Are we able to define the define the text alignment inside the buttons? Use set_alignment for the buttons so they're right-aligned on the left side, and left-aligned on the right side. Using the white space on the sides to our advantage, we could have a high character limit.

https://docs.gtk.org/gtk3/method.Button.set_alignment.html

An example of it -

Here's an alternative with the shortening the svg lines and centering the buttons with the lines.

[ids1024]

Are we able to define the define the text alignment inside the buttons? Use set_alignment for the buttons so they're right-aligned on the left side, and left-aligned on the right side.

That's kind of how it already works, but reversed. Currently the labels on the left side are positioned based on their bottom left corner, while the ones on the right are positioned based on their bottom right. This way it would be aligned by the other side, and vertically centered (I think https://docs.gtk.org/gtk4/enum.ConstraintAttribute.html#center_y will do that).

For the current version, I kind of awkwardly manually adjusted the positions of labels in code until they seemed right (specifying the position of the end of each line as a percentage of width and height)... I guess I should see if that can be done in a better way if we need to change them all.

[ids1024]

I guess I should see if that can be done in a better way if we need to change them all.

Okay, it looks like this can cleanly be done by pixel positions, after multiplying by pixel height/width (there were issues with how positioning worked in earlier versions, but it seems I got it to work in a sane way).

I think that alternate version should work. I'll need the the svg and the x/y positions for the end of each line, as shown in Inkscape.

[maria-komarova]

If we go this route, there are two smaller considerations, mostly visual:

• Alignment for the sake of readability - having a staircase always makes people's eyes hunt for what they need.
• Window resizing. Currently the window stop resizing when it reaches content boundaries. If we continue to do the same while allowing the labels to grow outwards from the diagram, then we can end up with a large window that won't size down.

For the first one we can at least make sure all the lines start in the same spot on each side. For window resizing, not sure what we can do. But that's probably less of a concern unless we do have translations for this app.

[christian-salgado]

(Updated to reflect the new alignment so there's so staircase affect.) Here's the x/y position for the alternative version as well as the SVG if we decide to go with it.

Left Click - x294 y234 Middle Click - x515 y187 Right Click - x565 y234 Left Scroll - x294 y267 Right Scroll - x565 y267 Forward - x262 y348 Super - x262 y377 Back - x262 y406

[ids1024]

Those coordinates don't seem to be quite right...

[christian-salgado]

I highlighted the point in Inkscape and got the coordinates, unless I miss understood. I can give you the Figma coordinates instead-

Left Click - x121 y64 Middle Click - x342 y17 Right Click - x392 y64 Left Scroll - x121 y97 Right Scroll - x392 y97 Forward - x89 y178 Super - x89 y207 Back - x89 y236

[ids1024]

Not sure why you were seeing different values in Inkscape, but anyway, https://github.com/pop-os/mouse-configurator/commit/55fccae33c321288e9cc912accbcf78dbb40885e updates this:

I guess to match the mockup there should be some padding on the sides of the labels to space them from the lines (which is easy to add), but I kind of like it like this.

[christian-salgado]

That was odd, not sure either. But I would add an 8-pixel padding from the line.

[ids1024]

[ids1024]

Closing as resolved, since we seem to be happy with this design.