fyne-io / fyne

Cross platform GUI toolkit in Go inspired by Material Design
https://fyne.io/
Other
25.24k stars 1.4k forks source link

Ability to turn off re-scaling when a window moves between monitors #5164

Open dweymouth opened 2 months ago

dweymouth commented 2 months ago

Checklist

Is your feature request related to a problem?

See the details here - https://github.com/dweymouth/supersonic/issues/489 some users of Fyne apps find the auto-scaling when windows move between monitors jarring and would like to be able to disable it.

Is it possible to construct a solution with the existing API?

No response

Describe the solution you'd like to see.

An API or environment variable setting for disabling re-scaling of windows when moved between monitors. They should keep the same pixel size.

andydotxyz commented 1 month ago

They should keep the same pixel size.

To be progressed further this needs to be nailed down. What is the right pixel size - the one on the origin monitor, the one on the primary monitor or a simple 1:1 hard coded size?

dweymouth commented 1 month ago

Maybe @ccoenen (reported the issue in Supersonic) would like to weigh in?

ccoenen commented 1 month ago

I realize this is probably a preference thing, but personally I'm very used to windows changing their visible sizes across very different monitors (while at the same time keeping their physical-pixel size the same). I've been running two monitors since CRTs were standard. Personally, I would run this at "same pixel dimensions" even if the monitors were quite far apart in pixel-per-inch.

I'm not arguing that this must be the default or anything. But in the ticket I also mention that setting FYNE_SCALE=1.0 ENV-var doesn't change this behaviour for me.

In my current setup, both monitors have the same 1.0 scale factor set in GNOME. One is a 34" monitor with 3440x1440 pixels, one is a 14" monitor with 1920x1080 pixels. Yes they have different pixels per inch. No I do not mind. When I move the window across the dividing line, this is how that looks in a screen recording:

It looks pretty similar to what Windows does when two monitors are set up with different scale-settings.

andydotxyz commented 1 month ago

while at the same time keeping their physical-pixel size the same

I am not certain we are talking about the same thing - the "pixel size" is in the hardware, we cannot keep it consistent across displays - we adapt to try and "fake" a consistency.

Can I check with this illustration to check we are talking same thing. A screen that is 1080p and a 4k, where both are the same size (27"). When you drag a window from one screen to the other should they:

1) be the same physical size 2) be 1/4 the area when dragged from 1080p to 4k?

I wonder if the window size and content scaling are being considered separately. Just ensuring we are consistent with terminology so we don't try to figure out a change on the wrong aspect.

ccoenen commented 1 month ago

I'm talking about the number of rendered pixels. I'm aware that these pixels will physically have different dimensions and that the window will therefore appear visually at different sizes.

Effectively: I want a 500x500 pixel thing to be 500x500 pixels, which would visually appear slightly larger on my slightly lower PPI screen and slightly smaller on my slightly higher PPI screen. It is fine that this is visually slightly different. I know that pretty much any window I drag across these two monitors will visually appear differently.

I don't want my 500x500 pixel window to be displayed at some odd number of pixels on one of them. I MOST OF ALL don't want it to make jumps in size the instant I drag it over the dividing line.

In short: For me, it should be 2.

Yes, I'm aware you probably put a lot of work in the automatic resizing. I just would prefer not to use it. I don't want you to throw it away or change anything dramatically, I just want to opt out.

andydotxyz commented 1 month ago

Thanks for the clarity - I know we are on the same page now. It's not something we can support in the general sense as most OS just don't work that way, but I suspect we can squeeze a Linux/Unix specific user override to turn off the scaling.

ccoenen commented 1 month ago

I am not sure we are on the same page, because what I'm asking is the default behaviour for literally every other software that I use? I have never encountered another program that does these kinds of jumps on any of my setups?

The most closely resembling thing would be windows with different scale factors on different monitors - there it performs a somewhat similar jump in size. But I'm not on windows AND my monitors are set to the same scale factor.

andydotxyz commented 1 month ago

But I'm not on windows AND my monitors are set to the same scale factor.

OK, so the "scale factor" is not a standard linux feature - but it is available to query as a standard on macOS and Windows, this is the main difference. Fyne scaling is aiming to keep your apps consistent - like other operating systems do. This is not standard for linux apps as there is not a standard.

Depending on your desktop there will be different defaults - and apps from a different system will not necessarily respect the same defaults. Can you be more specific with details of what desktop system you are using, how you have set up these scaling factors, and which apps you are referring to which behave as expected?

ccoenen commented 1 month ago

This is a pretty boring Fedora 40 Install with Gnome 46.

Built in Laptop monitor

grafik

External Monitor

grafik

(I, personally, would say: scaling absolutely is a standard on GNOME, even if it's not a standard on linux as a whole. But this could probably be said for any given feature that's not part of the kernel or coreutils. Moving on.)

Other than these two screenshots and the video all the way up at the beginning, I really don't know what else to say. Fyne tries to do some magic. I don't want that magic. I want the most boring possible application window. One that is not aware of ppi, one that is not aware of screen size. One that just simply keeps to being a certain internal physical pixel size, regardless of the apparent size observable to the user.

In short: just like any other gui application that I'm currently looking at.

Here's what every software does on my (again: very boring) setup, this is represented by the default gnome calculator. And then it's compared to what fyne is doing, this is represented by the music player supersonic:

https://github.com/user-attachments/assets/7b23e66e-06d9-4041-90ca-436a710d9745

To make sure there is no misunderstanding: this is a screen-recording, so it records the physical pixels. It is not a video I shot of my monitors.

andydotxyz commented 1 month ago

(I, personally, would say: scaling absolutely is a standard on GNOME, even if it's not a standard on linux as a whole. But this could probably be said for any given feature that's not part of the kernel or coreutils. Moving on.)

I think you're missing the FreeDesktop.org standards that we match for most of our desktop configuration options on Linux - scaling is not one.

Add to this the peculiar decision that GNOME made to only ever support int scaling (claiming that fractional is "impossible" for X11) whilst others have moved on and try to do float scaling to get exactly the output desired. We need to balance all of these factors, and it may result in having different behaviour for each window manager, but clearly that's something we would like to avoid if possible.

In short: just like any other gui application that I'm currently looking at.

As before is it possible to confirm what sorts of apps these are? Are they all GNOME apps? I would strongly suspect that things like "xterm" (no toolkit) and maybe even Qt based apps (respecting KDE settings) may not actually match this "any other app" summary in terms of scaling behaviour. Linux is fragmented and we need to understand all the different configurations and expectations this can lead to.

As above I do think that an "Turn off the auto-scaling" option would resolve it for you. But this is Linux specific and I don't think it should be default.

ccoenen commented 1 month ago

Yes, I do mean all other programs. Here's

https://github.com/user-attachments/assets/36fa178a-e28f-43fc-b511-2126a235a387

I could go on. Here's a list of all the software I use on this machine, and really none of them do this jump in sizes on my system. https://alternativeto.net/lists/40087/what-s-on-my-2024-linux-laptop/

But this is Linux specific and I don't think it should be default.

as per my first post in this issue

I'm not arguing that this must be the default or anything. But in the https://github.com/dweymouth/supersonic/issues/489 I also mention that setting FYNE_SCALE=1.0 ENV-var doesn't change this behaviour for me.

I'm not argueing for defaults. I would even have been fine with a rather hidden, advanced way of achieving this, like an ENV-var.

ccoenen commented 1 month ago

I will also add, that I used Debian for a couple of years and then Ubuntu for a couple of years before now using fedora for a couple of years (yes, all of them are effectively Gnome desktop environments). In over a decade of Linux on (my) computers, I cannot remember a single software that I used that had this behaviour. I use a lot of software, certainly not limited to gnome software.

andydotxyz commented 1 month ago

Yes, I do mean all other programs. Here's

Firefox xterm gnome calculator (again) kdenlive (a KDE application)

Thanks it is good to have confirmation on the types of software. I do not get the same results with Xterm, I guess I'll have to set up a new GNOME desktop and learn how they apply settings into the Xserver to assert scaling. For me the font on Xterm is half the size of other apps!

and really none of them do this jump in sizes on my system

Thanks. I was not meaning that they all jump in size - more that I was surprised that apps not coded for Gnome understand the monitor configuration that gnome asserts (because it's not an X11 configuration to my understanding).

I'm not argueing for defaults.

Thanks that is good to know as well, I think I misunderstood some of the more recent messages. We can just go ahead with the simple override proposed earlier.