Automatically launch with GDK_SCALE for HiDPI support

[nbenitez]

Similar to other Java apps in flathub[1], use the xgetres
binary to automatically retrieve current DPI of our X session
and so launch the java command with a proper GDK_SCALE value.

[1] like these:
com.github.mgropp.PdfJumbler
com.itextpdf.RUPS
net.sourceforge.pdfchain
io.sourceforge.Pixelitor
com.diy_fever.DIYLayoutCreator
org.verapdf.veraPDF

[flathubbot]

Started test build 54030

[flathubbot]

Build 54030 successful
To test this build, install it from the testing repository:

flatpak install --user https://dl.flathub.org/build-repo/51978/org.openstreetmap.josm.flatpakref

[nbenitez]

Btw, motivation for this PR originated from this post.

[muelli]

cool! Thanks!

Can you use a commit, in addition to the tag for xgetres? Because concept of a "tag" in git is surprisingly volatile and may change. The commit hash is less likely to change.

Have you thought about making this a shared-module? It seems there is a non-trivial number of flatpaked Java apps and having the highdpi stuff put in a more central place may benefit existing and new apps.

[nbenitez]

cool! Thanks!

Can you use a commit, in addition to the tag for xgetres? Because concept of a "tag" in git is surprisingly volatile and may change. The commit hash is less likely to change.

Ok I'm adding commit (which can be added alongside tag, and both will be verified).

Have you thought about making this a shared-module? It seems there is a non-trivial number of flatpaked Java apps and having the highdpi stuff put in a more central place may benefit existing and new apps.

I'm currently proposing features like this to be added in openjdk11 extension, see this issue, but maybe you're right and shared-module could be a good home for some of these.

[flathubbot]

Started test build 54083

[flathubbot]

Build 54083 failed

[flathubbot]

Started test build 54084

[flathubbot]

Build 54084 failed

[muelli]

I'm currently proposing features like this to be added in openjdk11 extension, see this issue, but maybe you're right and shared-module could be a good home for some of these.

yeah, I don't mind which place, but my feeling says that this is non-trivial enough to warrant some common place s.t. apps can re-use the work.