Future of IGP 3.0

[SabrePenguin]

Hi, sorry for reaching out this way.

I'm currently working on a transfer of IGP to Qt6 and plan to add a couple other features to the project. Since it has been 9 years, I'm curious as to what your plans are for the future with it. Do you want to keep this as a separate repository since Qt6 is Win 10+, and have me split off, or do you have a different plan?

[SkepticRaven]

Qt4.8 (what I originally wrote this in), is no longer supported, so it's a good idea to upgrade it to Qt6 to make it software that people can still use.

I'm not actively doing any work on this, but I'd be glad to pitch in with ideas/brief troubleshooting. It's been a couple years since I've done in-depth c++ coding, but am still pretty knowledgeable with the python bindings for Qt6. I've also thought about rewriting this software in python (and using PySide instead of QT, so that compiled versions could be distributed without a license conflict w/ Qt - which uses the infectious LGPL). I don't see any time in the near future doing that, and I would probably simply update the readme here and start a different repo (e.g. IGP-python).

As for where it resides, it doesn't matter to me. I'm aware of a couple options, so let me know what you're interested in:

1. I can add you as a collaborator with write permissions to this repo.
2. You can fork it and submit pull requests for me to have your updates be reflected in this repo.
3. You can fork it and just develop it independently (I can update the readme here to direct over there).

[SabrePenguin]

I'd be good with either 1 or 3. If we did number 1, I'd probably want to create a tag or branch for the Qt4.8 version for older OSes that can't run Qt6, at least until I add Qt5 specific code for compatibility. If I did number 3, then we wouldn't need to worry about a temporary tag or branch.

[SabrePenguin]

Sorry for the delay. I think 1 works best. While not many people use the software, having multiple versions on Github can lead to confusion, especially when one is a logical progression of the other (Qt4 to Qt6, why would they be different repositories?). It also makes it a bit easier for me to reach out to you with questions.

On another note, I did a bunch of research on LGPL and MIT and it looks like compiled versions can be released, so long as a few other items are also made available.

[SkepticRaven]

Invited as a collaborator.

As for the license discussion -- Yeah, they're compatible (e.g. this code can remain in MIT), there's just some work to make sure there isn't a conflict (e.g. distributions must be unmodified dlls or dynamically linked, copy of Qt license + usage added). This is already open source, so that hits the hardest requirement.

[SabrePenguin]

I was looking into the work needed to avoid a conflict, and here's what I have figured out so far. If a binary is released, it needs the source code, README, and the 2 licenses. If a static binary is released, then the original library files used must be provided in some way (tarball with relevant files seems easiest. A link is acceptable, but we can't guarantee anything about a link). If a dynamic binary is released, then we just need to send them users to a location to obtain the dlls, and the README should be expanded.

The current README already covers linking and using Qt, so that's covered.