mumble icon indicating copy to clipboard operation
mumble copied to clipboard

LXDE: Ugly preferences window

Open trudnorx opened this issue 5 years ago • 25 comments

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.

trudnorx avatar Sep 23 '19 10:09 trudnorx

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

Krzmbrzl avatar Sep 23 '19 14:09 Krzmbrzl

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

trudnorx avatar Sep 24 '19 00:09 trudnorx

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:

Krzmbrzl avatar Sep 24 '19 07:09 Krzmbrzl

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).

no-response[bot] avatar Feb 15 '20 17:02 no-response[bot]

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.

trudnorx avatar Feb 25 '20 03:02 trudnorx

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

Krzmbrzl avatar Feb 25 '20 06:02 Krzmbrzl

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).

no-response[bot] avatar Mar 26 '20 07:03 no-response[bot]

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

trudnorx avatar Apr 07 '20 17:04 trudnorx

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

Krzmbrzl avatar Apr 07 '20 17:04 Krzmbrzl

@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.

trudnorx avatar Apr 07 '20 17:04 trudnorx

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.

ghost avatar Apr 07 '20 18:04 ghost

@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.

Krzmbrzl avatar Apr 07 '20 19:04 Krzmbrzl

Can you try with a Lubuntu virtual machine?

trudnorx avatar Apr 07 '20 19:04 trudnorx

version 19.10?

ghost avatar Apr 08 '20 13:04 ghost

@Reikion 18.04.3 LTS

trudnorx avatar Apr 08 '20 19:04 trudnorx

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

Krzmbrzl avatar Apr 16 '20 16:04 Krzmbrzl

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

ghost avatar Apr 16 '20 18:04 ghost

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

ghost avatar Apr 16 '20 18:04 ghost

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

ghost avatar Apr 16 '20 18:04 ghost

@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...

Krzmbrzl avatar Apr 17 '20 08:04 Krzmbrzl

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.

trudnorx avatar Apr 20 '20 12:04 trudnorx

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

Krzmbrzl avatar Apr 20 '20 13:04 Krzmbrzl

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?

trudnorx avatar Apr 21 '20 06:04 trudnorx

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?

Krzmbrzl avatar Apr 29 '20 07:04 Krzmbrzl

Are all settings pages affected or only some?

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

streaps avatar Apr 29 '20 10:04 streaps