`i'GMT` as as viewer compainion to `GeophysicalModelGenerator`

[joa-quim]

Hi,

This not a feature request nor a bug report but a info about an alternative viewer for your models. I have not announced it formally yet, but I have been working in a VTK+Qt GUI for GMT.jl (and others to come). I call it for short i'GMT though its true Julia package name is InteractiveGMT. It is not registered in general registry and probably will never be. For fun I asked Claude to port some of your tutorials to be used in it. See https://www.generic-mapping-tools.org/InteractiveGMT/dev/67-moho-spada/ and several other to have an idea of what it can do and how. Note tat those are purely automatic Claude conversions and a manual revision can certainly make the the code in them look more elegant. Since it share a lot with paraview (the VTK+Qt engines), I believe this may an interesting alternative for the GeophysicalModelGenerator pakage, but ofc I'll leave that for you judgment.

Joaquim Luis

[boriskaus]

That's really cool - great work and looks very useful. You should certainly register this!

Note that we just removed GMT as a dependency of GMG because we have many dependency conflicts with other codes (latest version of GMT cannot be installed with teb latest version of GeophysicalModelGenerator.jl and LaMEM.jl). Most of that seems to come from (too?) tight version requirements of other packages such as GDAL_jll within GMT_jll. I may make a PR for this if I have time at some stage.

[mthielma]

I also think this is really cool. I would like to add that I have also been thinking about the possibility to create maps with GMT from the GeophysicalModelGenerator data, so having it in 3D is even better.

[joa-quim]

Nice that you liked it (I think it's a quite remarkable work of me and ... Claude). The reason why I cannot register it is because Julia does not guarantee a fixed directory address (each package directory name has a hash in it that keeps changing) and completely kills the possibility of having a desktop icon driving the program calls. I had to resort to a trick to have it installed as a dev version where directory names are permanent. I also am a bit fed up with the _jll dependencies permanent conflicts and I'm thinking to, at least on windows, drop the GMT_jll in favor of the classical system wide installation, but for it to work smoothly I still need improve the mechanism of binary updates.

@mthielma see the "File -> Plot with GMT.jl". Not all displayed things will be possible to plot with GMT but many already are. And automatically.

[boriskaus]

I also am a bit fed up with the _jll dependencies permanent conflicts and I'm thinking to, at least on windows, drop the GMT_jll in favor of the classical system wide installation, but for it to work smoothly I still need improve the mechanism of binary updates.

I hope you don't because that was the initial problem to start with. What about using Claude to make the _jll dependencies as broadly as possible to minimuize potential conflicts?

[joa-quim]

I hope you don't because that was the initial problem to start with.

Yes, I remember how it was and the work you done with GMT_jll and certainly don't want to break it. But the _jll has limitations that I don't know how to overcome. For example I have now both MB-system and GMTSAR built as GMT supplements meaning that we can call them from Julia but don't know how to integrate them with GMT_jll. And not to mention that The _jll have no MSVC builds and I build everything on Windows with it.

And regarding the issues with dependencies. the only two in GMT.jl that may cause any issues are

GDAL_jll = "302.1000.0 - 999"
XLSX = "0.10.4 - 0.99"

But that's pretty broad, no? GDAL.jl it self has GDAL_jll = "305.1300"

[boriskaus]

JuliaPackaging/Yggdrasil#14977 should solve it

[joa-quim]

Thanks. I guess I will never understand how compat works. I thought that by having (for GDAL) compat="304.1200" that would work for all version >= of that. But apparently not. So, there will be a time when compat="305.1300.301" will do the same as 304 did.