Alternate Path Sorting

[joshbarrass]

I've recently been using this software and it has mostly done everything I have needed. However, whenever I import a DXF file, the paths seem to be sorted by their length, rather than by path ID, with the shortest paths at the top of the list and the longest paths at the bottom. This generally makes the resultant gcode very inefficient, especially when the original path ordering is quite efficient. For files with a small number of paths, these can be re-ordered by hand, but if hatching is used I can often be dealing with several thousand paths, with no easy way of fixing this. Would it be possible to add a button or something to sort the paths by their ID instead?

[panzergame]

Hello, thank you for your feedback. Somehow i didn't receive notifications for issues…

I introduced path sorting by length recently for a personal purpose that I wrongly though generic.
I understand your situation. Do you think conditioning the path sorting in a config option (defaulted to false) is appropriate for your usages ? Or a popup asking at each file opening ?

[joshbarrass]

An option in the config would be perfect! I'm using this software for a pen plotter and my paths are pretty much universally drawn in the order they should be plotted (several very small lines and the long movements between them can cause the pen to dry out faster and reduce the quality), so it would be more convenient, at least in my case, to just disable it "permanently" via the config.

[joshbarrass]

In the end I've just patched out the sorting behaviour in a fork of this repo (https://github.com/joshbarrass/dxfplotter). I attempted to do it based on the latest version of the program, but your library choices seem to have changed between v1.3.1 and v1.3.2 and I can no longer run the application on Ubuntu 20.04.

If this ever does get implemented as a config, I will probably try and port it into my fork, but my needs are met and I would currently be unable to run the updated version.

[panzergame]

I setup the option in commit 02a74e5

About dependency, I think you meant qt6 ? I switched to this version for the WASM project, but currently I went back to qt5 for ubuntu 20.04 or for other stable system (8a6b950).

[joshbarrass]

Awesome! Thanks for adding that!

The main the dependency problem I encountered on 20.04, at least for the v1.3.2 app image on the releases page, is the glibc change. Based on the error message, it seems this appimage depends on glibc >= 2.35. Naturally this would be quite difficult to fix globally. It's probably possible to work around this by installing a newer glibc to a prefix and setting LD_LIBRARY_PATH, but this defeats the point of the appimage a little :^)

[panzergame]

I got the point. I'm looking to go away from glibc dependency but AppImage seems to not a support it easily :(

Thanks a lot for you report, don't hesitate if you think of an improvement.

[joshbarrass]

Yeah, AppImages are great but they can really be a pain sometimes.

The v1.3.3 AppImage seems to work for me now, though :) Thanks for fixing that and for adding this config option!