mumble-voip / mumble

Mumble is an open-source, low-latency, high quality voice chat software.
https://www.mumble.info
Other
6.26k stars 1.11k forks source link

LXDE: Ugly preferences window #3809

Open trudnorx opened 4 years ago

trudnorx commented 4 years ago

image

It shouldn't have these scroll bars. This doesn't happen for me on Windows with 1.3.0. On LXDE I'm using recent Git version. (Not sure if something changed with versions or it's related to LXDE). A few other tabs look weird too for example the edges of text for some options missing.

Krzmbrzl commented 4 years ago

Did you test LXDE vs Windows on the same machine or are these different PCs (that might have different screen resolutions, screen sizes, etc.)?

trudnorx commented 4 years ago

Different PCs but it shouldn't be happening. All these bars are too big and so on.

Krzmbrzl commented 4 years ago

but it shouldn't be happening

Not saying otherwise. I just wanted to find a possible cause for this (as the code producing the UI is the same on both platforms) and different screen properties could definitely be the cause for it.

Maybe it would be help others to replicate the problem if you could share the screen properties of your 2 screens (size + resolution) :thinking:

no-response[bot] commented 4 years ago

This issue has been automatically closed because there has been no response to our request for more information. With only the information that is currently in the issue, we don't have enough information to take action.

Please reach out if you have or find the answers we need so that we can investigate further (or if you feel like this issue shouldn't be closed for another reason).

trudnorx commented 4 years ago

This shouldn't be closed at all, no input is necessary my initial description describes the problem perfectly, if you're on LXDE the inner frame of the configuration window is too big so there's scroll bars that really shouldn't be there.

Krzmbrzl commented 4 years ago

@trudnorx I asked for the screen resolutions and you didn't respond to that. That's why it was labeled as needs-more-input

no-response[bot] commented 4 years ago

This issue has been automatically closed because there has been no response to our request for more information. With only the information that is currently in the issue, we don't have enough information to take action.

Please reach out if you have or find the answers we need so that we can investigate further (or if you feel like this issue shouldn't be closed for another reason).

trudnorx commented 4 years ago

The screenshot makes it clear something is wrong with the form, no more information is needed.

Krzmbrzl commented 4 years ago

Yeah but as long as you refuse to answer the questions and provide the needed info, I'll keep closing this issue.

trudnorx commented 4 years ago

@Krzmbrzl Needed for what? Why do you think screen resolution is relevant? Like I explained screen resolution is irrelevant, something is wrong with the form properties. I just tested several screen resolutions and it happens with every screen resolution, it just depends on the window size and you can know what the size is from the screenshot. The issue is that things like the sliders are way too big for some reason, even with a huge window size it requires scrolling. The minimum size of the window is the same for Windows (tested 1.3.0) and LXDE (tested Git version). But on Windows it doesn't result in large sliders or scrolling.

Maybe you should try to reproduce this issue.

ghost commented 4 years ago

I've tried but failed to reproduce. Current git version. In KDE + i3wm and Openbox. On my account and a brand new clean user. Looks like bug in your Qt library or window manager/qt handling. None of my environment allow to create so small, square-like window.

Krzmbrzl commented 4 years ago

@trudnorx I think it is relevant as screen resolution is important for the vast majority of UIs behaving weirdly while being perfectly fine on other machines.

The issue being reproducable with different screen resolutions is a valuable information and does indeed replace the specification of a screen resolution. However you haven't provided this information until now.

And I did try to reproduce but as @Reikion I have a KDE system and there I wasn't able to reproduce either.

trudnorx commented 4 years ago

Can you try with a Lubuntu virtual machine?

ghost commented 4 years ago

version 19.10?

trudnorx commented 4 years ago

@Reikion 18.04.3 LTS

Krzmbrzl commented 4 years ago

@Reikion were you able to try it on a VM already?

ghost commented 4 years ago

@Krzmbrzl Sorry, I've forgot a bit about it. But I've tested and reproduced issue indeed.

ghost commented 4 years ago

@trudnorx @Krzmbrzl Workaround: use a bigger monitor! Horizontal resolution >= 1600 Vertical resolution >= 1024 Bug exists at least since 1.2.19 :<

ghost commented 4 years ago

It looks like this: https://paste.reik.pl/m-mhoOh/

Krzmbrzl commented 4 years ago

@Reikion thank you very much!

So it does depend on the screen resolution after all...

I assume that the preference window is set to take x% of the screen by default and if the screen is too small, it'll display scrollbars.

On the other hand the minimum size specified for the window seems to be dependent on this as well. So maybe we are setting this programmatically somewhere? If so that might need some adjustments...

trudnorx commented 4 years ago

So it does depend on the screen resolution after all...

It doesn't matter whether it depends on the screen resolution or not, what matters is that the form properties are wrong. No scroll bars should be displayed when the window is displayed at minimum size, as occurs on Windows.

Krzmbrzl commented 4 years ago

@trudnorx you know what? Go fix the bug yourself! I've had enough of you

trudnorx commented 4 years ago

I fail to see the purpose of the last comment other than pointless conflictiveness/hostility. In case it's not clear, I will make it clear: I'm picking no fight whatsoever here, I'm helping clear up a misunderstanding in the dynamics of the problem. The issue is fixed in a collaborative way, and it's impossible to fix the issue if it is not clearly understood.

@davidebeatrici Do you think there's anything wrong with stating that the objective cause of a problem is not the user's screen resolution, but rather the way that the form is reacting inconsistently between platforms relatively to its minimum specific window size, and that while the issue is only most symptomatic on certain resolutions, we should focus on the root cause?

Krzmbrzl commented 4 years ago

Okay I guess I should explain my view of things here as it seems that there has been a misunderstanding. To me it wasn't clear that you thought that I misunderstood the problem. It seemed as if you were trying to just repeatedly blame Mumble for having a bug and by doing so neglecting all attempts of my side to try and debug where it might be coming from. That's why I reacted the way I did.

As this apparently wasn't the case though I want to apologize for my tone here. Hopefully we don't run into such a misunderstanding again :)


Back to topic:

This seems to be where the minimum size of a ConfigWidget is being set: https://github.com/mumble-voip/mumble/blob/d945acb883186135143121ee2a9fcc501f3c52f7/src/mumble/ConfigDialog.cpp#L73-L75 Therefore I guess the problem lies in the implementation of minimumSizeHint() of the respective settings page.

Are all settings pages affected or only some?

streaps commented 4 years ago

Are all settings pages affected or only some?

I can only reproduce it in the "Audio Input" settings. Tested on Raspbian Buster, LXDE.