Font tiny on high DPI screen (3840 x 2160) in Windows 10 (v 19.2)

[dr3x]

Unusable on my default display setting; have to reset the display to use it.

Pulled the source to see if I could tweak the settings but didn't have everything needed to compile.

Is there a pom.xml file for this project? I'm not a Java guy but don't you need some config to bring in all the dependencies?

Was able to get one of the forks to compile but they created a pom file and also relocated tim/prune under a src folder so the structure is different.

[ptanov]

Hi @dr3x,
I successfully managed to build the project using this bash script some time ago:
https://fossies.org/linux/gpsprune/build.sh (it should be on the same level with tim/) - you can easily translate it to Windows shell commands.
You need to add MANIFEST.MF as well:

Manifest-Version: 1.0
Main-Class: tim.prune.GpsPrune

the resulting file will be here: GpsPrune/dist/gpsprune_19.2.jar

[activityworkshop]

The issue about the high-dpi screens sounds very similar to issue 16: #16 - maybe you can find some suggestions in there. Currently I don't know how to solve it (but I don't think that supporting map tiles of two different sizes is the right approach).

Regarding a "pom.xml", I believe that's something to do with Maven, is that what you are using? If you're familiar with Maven and are able to create such an xml file then I'd be delighted to publish it. I don't believe it would be very complex, because GpsPrune only has one build-time dependency to Java3d. So it would either just specify "Java3d please" or it would specify "j3dcore, j3dutils and vecmath jars please". If you can tell me which "one of the forks" you mean which supplies a pom.xml then maybe I can adapt theirs. Or if you don't want the 3d parts then just cut them out and you shouldn't need anything in your pom.xml I'd have thought.

As ptanov says, there is a build script available too, included in the source tarball, but this only finds the jars in your classpath so may need to be manually extended to include the three 3d jars, depending on where you have them and what they're called.

If you need more details on how to build, please supply details about your system (I guess Windows 10?), which JDK and whether or not you have java3d installed.

[dr3x]

I was able to get it working with a (slightly modified) pom.xml that I found on a fork of your code (https://github.com/ta-apps/GpsPrune). That fork has tim/prune relocated under the src folder. I put my code out on the working branch of my fork (https://github.com/dr3x/GpsPrune/tree/working) in case anyone is interested. It may not be simple to just pull in that pom.xml due to the changed directory structure. Since I was able to run the app with my modified source (and it didn't have unusable tiny font) and do what I wanted (fixup my Strava data for one event) I didn't go further with it. I may try @ptanov 's technique of bash script + manifest in the future. But I think if you update the master to make it easier to pull down and compile from source you may get more contributions. Thanks!

My environment: Windows 10 Pro, Visual Studio Code v1.33.1, JRE build 1.8.0_201-b09, Open JDK 11.0.2, and no Java3d

[ptanov]

Hello again,
I created a merge request that enables maven, keeping the original directory structure in the same time:
#20.
You can build it with mvn install and import it to eclipse (mvn eclipse:eclipse) - please, check the readme file in the commit.
I hope this will help maintaining the project and keeping your good work! Thank you for the project!

[activityworkshop]

I was able to run the app with my modified source (and it didn't have unusable tiny font)

@dr3x that sounds great, could you please point me to the bit(s) of your changes which solve the font issue for you? It would be great if I could merge this fix somehow. I'm hoping there's a way to make the display readable for everybody, no matter what their dpi is.

[activityworkshop]

I created a merge request that enables maven, keeping the original directory structure in the same time

@ptanov that also sounds very interesting (and maybe this should be a separate issue). I know nothing about Maven, so some of these questions may sound foolish, sorry in advance!

When I read about Maven on wikipedia, it explains that all projects have to follow a certain folder structure, with all code under src/main/java/ and all resources under src/main/resources/. Yet @dr3x has it working with code under src/ and you have shown that it also works with code at the root. So what is necessary for Maven, and what is recommend / usual? None of the other ways to build GpsPrune (throwing code into an IDE, running a .sh, using ant) care about the folder structure this much. Does Maven also want the translation files (resources) under src/main/resources rather than under prune/lang/ ? I would be keen to avoid introducing extra build problems for other builders who don't use Maven, of course.

When I tried your xml, Maven downloaded java3d stuff from the maven repositories, even though I already have java3d installed - that's not a big problem but quite a difference to other build methods. Then I get a jar file, but when I run that with "java -jar" it can't find those java3d bits which maven downloaded, so I get no java3d at runtime. Is there a way around that, or do I have to manually specify the location of where maven downloaded the requirements from? Do I have to run GpsPrune through Maven?

And lastly, in your pom.xml you have what look like thirteen different version numbers specified for various plugins with the comment "lock down plugins versions to avoid using Maven defaults", is this going to cause a maintenance issue when so many version numbers need to be maintained? I would expect the pom.xml to be almost trivially simple, just saying "I need java3d version x".

I haven't tried the eclipse:eclipse method yet, I'll try this out and see what happens. Thanks again for this great contribution!

[dr3x]

@activityworkshop to be clear I'm not a Java/maven guy; it has been years since I've worked with those technologies. I was able to build from the fork after commenting out one reference to a library that I didn't have access to (and it built successfully without it). When I ran it, it no longer had the tiny font issue. So I didn't actually make any changes related to the font issue.

Here's a response to my questions I got from a member of the team that created the pom.xml on the fork:

Is there some tool that can scan all the dependencies?
No, pom.xml files are generated by-hand.
Though we usually use an IDE that makes creating these files easier.
Intellij is the current most popular IDE today, but we probably used
Eclipse to make those files in 2011.
Many java users have moved from pom.xml (Maven) to build.gradle
(gradle).

[dr3x]

@ptanov cloned and built your pull request and it works for me (except for 3d but that might just be my config)

@activityworkshop can you point me to how to enable 3d? I get the message "This function requires the Java3d library" when I invoke 3d from the menu. I installed Java 3d 1.5.1 (latest, didn't find the 1.3.1 listed in the pom)

[ptanov]

@activityworkshop

So what is necessary for Maven, and what is recommend / usual?

• recommend/usual - as you mentioned the default is src/main/java and (almost) everyone uses this structure
• necessary - nothing, you can explicitly specify the resources, e.g:

<resources>
	<resource>
		<directory>${project.basedir}/</directory>
		<includes>
			<include>tim/prune/gui/images/*</include>
			<include>tim/prune/lang/*</include>
			<include>tim/prune/function/srtm/srtmtiles.dat</include>
			<include>tim/prune/*.txt</include>
		</includes>
	</resource>
</resources>

So this is a quick workaround - Maven is introduced without breaking the backward compatibility. Although I recommend using src/main/java we can use the proposed change as a temporary solution before the next step - fixing build scripts, etc.

but when I run that with "java -jar" it can't find those java3d bits which maven downloaded

The problem with java3d is that it contains native libraries that need to be available in the host. There are few options:

• download and install them from https://www.oracle.com/technetwork/java/javasebusiness/downloads/java-archive-downloads-java-client-419417.html#java3d-1.5.1-oth-JPR on the host machine
  • in this case we don't need to include j3d-core, vecmath and j3d-core-utils in the resulting jar
• distribute native libraries with the jar
  • in this case we need to distribute libraries for all OS/platforms/architectures (arm, 32bit, 64bit, .dll (for Windows), .so (for Linux/Mac), etc.) which is not a good option (at least because of the license agreements)
• something other

Actually I haven't tried 3D functionality in GpsPrune. Unfortunately the version 1.3.1 is not available at https://www.oracle.com/technetwork/java/javasebusiness/downloads/java-archive-downloads-java-client-419417.html#java3d-1.5.1-oth-JPR so I changed the Java 3D version to 1.5.1 (pom is updated). Now I can use the 3D functionality in GpsPrune using mvn clean install exec:java (before doing that I have configured LD_LIBRARY_PATH to point to the folder where the .so is extracted, e.g. export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:path-to-file-libj3dcore-ogl.so). As you can see j3d-core, vecmath and j3d-core-utils are not included in the resulting jar (because they were not included using build.sh too). I can configure the build process to include them using Maven build profiles (e.g. mvn clean install -P include-j3d) or by default if you think that this is a good idea.

Back to the problem when I run that with "java -jar" it can't find those java3d bits which maven downloaded - as mentioned above currently they are not included in the jar, but I don't know why it can't find already installed java3D on your machine? Can you compare the content of the jar that is created using maven and using build.sh (I expect that they should be almost the same?). Please also log the exceptions in tim.prune.threedee.WindowFactory.isJava3dEnabled() so we can check whether the problem is in the native library or in missing java classes (comments that you left in the catch).

Do I have to run GpsPrune through Maven?

No, running using Maven (mvn exec:java) is just for development purposes (like running the project in Eclipse).

And lastly, in your pom.xml you have what look like thirteen different version numbers specified for various plugins with the comment "lock down plugins versions to avoid using Maven defaults", is this going to cause a maintenance issue when so many version numbers need to be maintained? I would expect the pom.xml to be almost trivially simple, just saying "I need java3d version x".

These are versions of the Maven plugins that are used for building the project, not the versions of the libraries used by the project itself. They are used to configure different aspects of the build (how to store resources in the resulting jar, what to execute by default when java -jar is executed, what to execute using mvn exec:java, how to configure Eclipse project, etc.). While I'm almost sure that the newer versions of the plugins will work too (because we don't use something uncommon/complex here (except custom paths)) the good practice is to explicitly specify these version for reproducibility and to avoid problems with backward compatibility when a new version is set as default. For more information please check Automatic Plugin Version Resolution:

When a plugin was invoked without an explicit version given in the POM or on the command line, Maven 2.x used to pick the latest version available where the latest version could either be a release or a snapshot. For the sake of stability, Maven 3.x prefers the latest release version over the latest snapshot version.
Given the threat of non-reproducible builds imposed by automatic plugin version resolution, this feature is scheduled for removal as far as plugin declarations in the POM are concerned. Users of Maven 3.x will find it output a warning when missing plugin versions are detected to encourage the addition of plugin versions to the POM or one of its parent POMs. The Enforcer rule requirePluginVersions can be used additionally check for missing plugin versions in the POM.

@dr3x

@ptanov cloned and built your pull request and it works for me (except for 3d but that might just be my config)

hmm, probably the problem is not on your side (...sorry :( ) - check the comments above (I have updated the pom).

[dr3x]

@ptanov tried with the updated pom and it compiles and runs but Java 3d still not working.

I do have the Java 3d v1.5.1 (x64) installed on my system. Let me know if there's anything else to try

[ptanov]

Hi @dr3x,
is it working if you build it using build.sh? If not - maybe it is a problem with your installation of java 3D?

You can add logging (e.g. e.printStackTrace()) to every catch in tim.prune.threedee.WindowFactory.isJava3dEnabled() so we can check the exact problem.

How did you installed Java 3D on you machine? There are installation instructions (https://download.java.net/media/java3d/builds/release/1.5.1/README-download.html) but I can't test it (I don't have Windows).

[activityworkshop]

For me the use of Maven would be useful for two purposes - building a jar which then works including its dependencies, and possibly also constructing an Eclipse project also connected to its dependencies. For me, Maven does neither of those things properly. This could be just my unfamiliarity with it of course!

As noted above, if it builds the jar using its own downloaded java3d packages (which it put in its own "M2" repository), then to run it I would have to also specify those "M2" jars. But as you say those aren't connected to native code (I don't think) so instead I would have to run the jar together with my installed java3d components. Which may or may not be compatible. But Maven can't specify those in the jar manifest because it doesn't know anything about them, that's why it uses its own versions. So I'm not sure how this is supposed to work properly.

Then I tried the "eclipse:eclipse" target to create an Eclipse project, but this project fails to build with errors like "Unbound classpath variable: 'M2_REPO/java3d/j3d-core/1.3.1/j3d-core-1.3.1.jar' in project 'GpsPrune-master'" so I guess some configuration is missing? In any case it's much easier to just create a project in Eclipse, throw the GpsPrune code into it and then add the java3d jars as dependencies, so I don't think Maven is helping me very much here.

For runtime linking to java3d you can use the jars created by Debian or Ubuntu as a reference, they include the classpath to the installed java3d libraries in the manifest.mf file of GpsPrune. But this is possible because Debian and Ubuntu know where the java3d components are installed to. For obvious reasons I don't do this with the jars which I publish, because I've got no idea where the java3d components are on the target machine.

[ptanov]

Hi @activityworkshop,

I'm not sure whether I understand you correctly about jar creation. Maven can be configured to include all jars or/and configure the classpath in manifest.mf (to points to external resources, e.g. /usr/share/java/j3dcore.jar). Unfortunately maven can't deal with the native libraries (dll/so). At least this is not straight forward - license agreements to bundle specific library should be taken into account, different files (dll/so) per OS/architecture, e.g. classifier tag and -Dclassifier=win32, etc., more information here: http://web.archive.org/web/20120627025240/http://www.buildanddeploy.com/node/14, http://web.archive.org/web/20120308042202/http://www.buildanddeploy.com/node/17, https://www.adamh.cz/blog/2012/12/how-to-load-native-jni-library-from-jar/. They are better provided by the "installer" - per OS/architecture or by the OS itself. If you know how the jar/jars should looks like (e.g. with manifest.mf that includes Class-Path: /usr/share/java/j3dcore.jar /usr/share/java/j3dutils.jar ... or something else) - I will configure maven to produce it/them. The current one produces jar similar to that of build.sh. Btw I can configure it to copy java 3D jars to target/libs/ and add Class-Path: libs/j3d-core-1.5.1.jar libs/vecmath-1.5.1.jar ... in manifest.mf so if LD_LIBRARY_PATH points to the folder of libj3dcore-ogl.so java 3D will work (e.g. using java -Djava.library.path=path-to-folder-of-libj3dcore-ogl.so -jar gpsprune_19.3-SNAPSHOT.jar).

About Eclipse - sorry I forgot to mention M2_REPO environment variable - the M2_REPO variable is usually always set (because of the previous projects that are in the same workspace), if not - you can set it either using the command mvn -Declipse.workspace="path-to-eclipse-workspace" eclipse:configure-workspace or manually (Windows > Preferences > Java > Build Path > Classpath Variables > New... (add M2_REPO that points to ~/.m2/repository). There is also M2Eclipse plugin for Eclipse.

Btw one benefit of using Maven is that it is a common tool for Java development, developers are familiar with it and as @dr3x mentioned:

I think if you update the master to make it easier to pull down and compile from source you may get more contributions.

[activityworkshop]

Btw one benefit of using Maven is that it is a common tool for Java development, developers are familiar with it and as @dr3x mentioned: "I think if you update the master to make it easier to pull down and compile from source you may get more contributions."

I completely agree.
From what you both commented in this issue thread, I understand that there are three things I can do to help:
(1) - Move the source code to src or src/main or src/main/java. This would have two benefits, one to please Maven and make it easier to build, and secondly to make merges and patches easier for those who needed to move their source code.
You helped demonstrate that Maven is also happy with the source under src, so I moved the code there. I didn't move the resources (although this could certainly be a future step) because I was keen not to cause unnecessary problems for existing build scripts.

(2) - Provide a pom.xml for Maven. For those already familiar with Maven this should make it easier for them to build.
You provided me with a suitable pom.xml file and I've added it to the buildtools directory. To use it, you have to move it up to the parent directory first, but I'm hoping that this is an acceptable requirement. Similarly if you choose to use ant instead as your build tool, you would select the ant files (build.xml and version.properties) and move them to the parent directory instead. Hopefully then all are happy.

(3) - Support gradle for those who use that. Again, this would make it easier for those who are already familiar with gradle to get building immediately.
I don't have a suitable gradle file because I know nothing about gradle. But I've mentioned it in the accompanying .txt file and have expressed my hope that somebody somewhere can provide one.

I decided not to take the proposed edits to the readme.txt file, as this is shown to the user of GpsPrune in the gui at runtime, and I assume that the user is in general not going to be particularly interested in build details. I'm hoping that by putting the information in the buildtools directory this will be easily discoverable by people who want to build it, without distracting those who just want to run it.

So now I think I've addressed all the concerns about making it easier for people to build and contribute. If you have any other concerns or suggestions along those lines then please send them in, perhaps using a new issue.

The original subject of this issue was fonts being tiny on high-dpi screens, which I haven't been able to address at all yet - any help on this would be very welcome!

[activityworkshop]

I think most of the issues discussed here are resolved, apart from the high-dpi screen issue which is covered by #16 .
So I'll close this now, and if you have more suggestions regarding build problems, maven, gradle or other such tools, please raise them in a separate, specific issue.