PredatH0r / ChanSort

TV channel list editor for Samsung, LG, Sony, Hisense, Panasonic, Philips, Sharp, Toshiba and MANY more.
842 stars 115 forks source link

High DPI problem regarding columns width #237

Closed zoelechat closed 2 years ago

zoelechat commented 3 years ago

What currently occurs is correctly described here already: https://supportcenter.devexpress.com/Ticket/Details/T638965/column-width-increases-each-time-a-layout-is-restored-on-highdpi-screens Ending in "super-sized" columns after few sessions and the urgent need to frequently best fit all columns ^^ Even "best fit" option itself is not accurate, and looks to apply correct width * systemwide zoom factor (much larger than expected here on 4K @250%). Now my fix is to use Windows compatibility options and scaling override, at the expense of overall looking quality loss ;)

PredatH0r commented 3 years ago

Thanks for pointing this out!

Despite the claims of DevExpress, their suggested solution does not work. The grid always writes "scaleFactor=1.0" to the XML data, regardless of the actual scaling (1.5 in my test case). And thus scales the saved widths up again when loaded the next time, over and over.

In the latest update, 2021-05-01_1615 I added a manual workaround by saving the real scale factor myself to the config file and then scaling the columns down by that factor. At least in my tests this worked fine for 100% and 150% scaling.

zoelechat commented 3 years ago

Looks alright about columns width, they're kept amongst sessions, though I guess same recipe should be applied to left/right panes size (actually the left one becomes smaller and smaller, forgot to mention). Just a particular case, when you have 2 screens with different DPI, and switch app from one to another during session, on next launch app expectedly stays "where it was" but applies scale factor of wrong display. So, probably scale factor of current screen on program exit should be stored in config for workaround to be fully relevant (hope it's clear :D )

Apart from that, some columns still look to "best fit" quite oddly: image Nothing critical as long as user defined widths are now staying :)

PredatH0r commented 2 years ago

This should be fixed now.

The "column auto width" also includes the column header when determining the optimal size. Therefore I added hard line-breaks into the header to reduce the width.

Window, pane and column sizes are stored "normalized" in 96 DPI values in the config and scaled up to whatever the current monitor has. The new version also prevents that the window exceeds the current screen's bounds.

I also tested per-monitor-DPI configurations with 100% and 150% scaling and everything works fine now. The dialog that appears after loading a list to select between the edit options is now also scaled.

zoelechat commented 2 years ago

I confirm everything looks, behaves, and remains as expected now, even switching on-the-fly screen with different scale (that indeed still had some bounds and positioning issues before newest version). At least as far as I could torture it ;)

Thanks a lot!

upintheairsheep commented 1 year ago

Hello zoelechat, can you reupload all the Tizen filesystem dumps to the internet archive please? The original MEGA links were taken down.

zoelechat commented 1 year ago

Hello zoelechat, can you reupload all the Tizen filesystem dumps to the internet archive please? The original MEGA links were taken down.

LOL message in a bottle? Better ask on the right forum I guess... Don't have them all anymore, but reuploaded the only one I still had anyway. Where you know ;)