Narrow columns on HiDPI displays

[SukkoPera]

Version

1.42.0-alpha3 (why does it say alpha2 everywhere, BTW???), but the same issue was present in alpha1

Operating system type + version

Slackware Linux -current

Behavior

I have a HiDPI display (2560x1600) and the Slic3r GUI does not adapt to it. In particular the right column of the Plater and the Print/Filament/Printer settings column are too narrow and get partially cut.

See the attached screenshots for a better understanding of the problem.

I have worked around the problem by changing the panel proportions, but I'm not sure how it will look on a standard monitor with my changes. Patches are attached anyway. I think it would be better if the columns were made freely resizable.

spe_hidpi.diff.txt

(Patch against -alpha1 is here in case anybody is interested)

With my patch applied:

[paulbovbel]

+1 to making the columns resizable

[Panayiotis-git]

Of course the column size preferences should be persisted, so the user should not have to define the widths every time he opens the application.

[vojtechkral]

cf. #1641

[deejay2]

Same issue here with HiDPI

[gromain]

Same issue for me:
Exist on alpha4 and a HDPI screen under Manjaro Linux, KDE version.

This is the entire Slic3r window as shown, resizing does not change the fact that a part on the right side is missing.

Also, in the settings tabs, the left column is not wide enough.

[gromain]

I believe @SukkoPera patch should solve the issue for most users. Maybe a small tweaking in proportions is needed but overall the solution seems clean and scalable.

[gromain]

@vojtechkral do you want a PR for this issue? This solution should also solve #1644 (whereas #1641 is a feature request).

[bubnikv]

I am afraid https://raw.githubusercontent.com/SukkoPera/slackmatic-ports/7abc6916dad27a56407730e16a944400149a41ee/slic3r-prusa/spe_hidpi.patch is too simplistics. We can test it on more platforms, but most likely we will need a more complex solution, based on DPI reported from the windowing system, based on system font sizes etc.

[gromain]

I don't agree it's too simplistic. It locks the relative size of the different parts of the window to one another. This should make the window resize immune to changes.

I do agree though, it needs more testing on different platforms, however this can be done quite fast.

[bubnikv]

It will not work correctly for somebody with large display, good eye sight and small fonts. In that case the right column will be too wide.

[gromain]

I agree but this seems to me like a corner case compared to the number of users with Hidpi displays.

[gromain]

Also, according to the Dev, the best practices really are to use relative sizing for the displayed elements and not absolute pixel values. https://forums.wxwidgets.org/viewtopic.php?t=41603

[SukkoPera]

My patch was only meant to be a temporary and personal workaround, I agree it's simplistic, but it was born on a "it works for me" basis.

Anyway, why not just make the columns freely adjustable? That's simple and effective, and it works for everyone, IMHO.

[gromain]

I don't know how easy it is to create adjustable columns in wx.

I agree it would be a good long term solution, but this sounds like this would be something for an ulterior release, not 1.42.

In the meantime, this simple fix would make Slic3r usable again (for me, alpha4 can barely be used because of this problem).

[SukkoPera]

It doesn't seem too hard using the SplitterWindow class.

[SukkoPera]

For the record, my patch still seems to work fine with -alpha5.

[gromain]

Any chances of integrating this fix before 1.42 release @vojtechkral ? alpha5 is basically unusable on my computer... As I said, the best practices really call for a relative sizing of elements, not absolute.

[vojtechkral]

@gromain @YuSanka has a solution implemented. I think it's not a 100% perfect fit for everything, but I believe most obvious problems should be solved... So yeah, should be part of the next release I believe.

[gromain]

Thanks! This is great news!
I can't wait to test that!

[bubnikv]

This issue has been fixed in the current master, alpha7 is due soon.
Closing