Upgrade to Qt Creator 4.10

[iohanaan]

Address issue #386

[Levi-Armstrong]

Thank you for your contribution. The only request I have is just refactor the code to use FilePath instead of using FileName = class utils::FilePath.

[vincent-hui]

Hi @Levi-Armstrong , would you mind telling us why not submit ros_qtc_plugin to codereview.qt-project.org to get automatic update?

[Levi-Armstrong]

@iohanaan Thank you for your contribution.

[Levi-Armstrong]

@vincent-hui If someone wants to sign up for addressing all of the requested changes from the Qt Creator developers then I would, because right now my time is focused on Tesseract and TrajOpt repositories.

[vincent-hui]

Hi @Levi-Armstrong ,

I think after you submit ros_qtc_plugin to codereview.qt-project.org, many people are willing to help polishing ros_qtc_plugin and focus on polishing. A Qt Creator developer André Pönitz said he can help porting ros_qtc_plugin to new Qt Creator API, let me post the reply from him

It would start with putting the plugin code at codereview.qt-project.org,
with target branch 'master'.

I understand that it doesn't currently compile in that state, but
from a quick look I don't see show stoppers, looks all fixable.

I can help with that once the code is on gerrit in so far that I
could make it compile. Actual testing etc. I'd rather leave to
people who know what to look for, i.e. "you".

Andre'

As I said before I think other people cannot submit ROS plugin code for you because other people cannot accept Qt Contribution Agreement on your behalf.

Would you mind putting the plugin code at codereview.qt-project.org first?

Thank a lot.

[Levi-Armstrong]

Ok, I will work on getting it posted. Because I need to sign there document I will need to get approval from my work first before signing.

[vincent-hui]

@Levi-Armstrong thank you very much for your contribution to ROS and Qt community

[vincent-hui]

Hi @Levi-Armstrong,

Would you mind telling us the progress? Did you submit ros_qtc_plugin to codereview.qt-project.org ?

Thank you

[vincent-hui]

Hi @Levi-Armstrong

Do you need helps for submitting ros_qtc_plugin to codereview.qt-project.org ?

Thank you

[Levi-Armstrong]

I am currently still waiting on approval. I will follow up again.

[vincent-hui]

Hi @Levi-Armstrong,

Did you get approval?

[v4hn]

ping @Levi-Armstrong , any response?

Also, for (very minor) new contributions, I'm currently unclear whether they should be contributed to the 4.9 (default) or 4.10 (latest) branch.

[vincent-hui]

Hi @Levi-Armstrong ,
You can sell your plugin in Qt marketplace

[v4hn]

@Levi-Armstrong @gavanderhoorn Are there plans to continue support for this plugin in the context of ros-industrial and what is the state of getting it submitted upstream to qt-project?

qt-creator 4.12 is released by now (and actually required for llvm 10.0.0) and APIs changed quite a bit again. Even with 4.10 I had the feeling some features do not work as they should.
I tried to migrate to 4.12, but not all API changes are obvious to me and I did not find associated documentation on the changes.

I just recently started using the plugin and it is quite a difference to plain vim 😎 .
It's a shame I can't use it now just because of an llvm version bump.

[Levi-Armstrong]

It is. Is there something in 4.12 that is needed? The main reason I have not spent time on upgrading it is the current release version supports my needs. If there is something that the community needs from 4.12 I will see what I can do.

[v4hn]

As I said, my distribution recently upgraded to llvm 10 and qt-creator only supports this in version 4.12. I also tried patching qt-creator 4.10 to support the new version, but it's a bit more than the usual clang-format parameter changes and upgrading the whole qt-creator is conceptually the better solution of course.

[Levi-Armstrong]

The way this is distributed in most case it should not matter what is on your system. It should be bundling everything it needs similar to a snap package. Can you post the error from Qt Creator that is complaining about llvm10?

[v4hn]

It should be bundling everything it needs similar to a snap package

I build from source using your setup.sh (although I had to modify things a bit to remove the debian-system assumption). The qt-creator this downloads can be configured to use a custom clang version, but then I would package and build another random clang version, e.g., in /opt/llvm9/ that would rot there..

Digging through the qt-creator history, I found this commit which actually applies on top of qt-creator 4.10 to get support for llvm 10. With this I have a working qt-creator with llvm 10.

Of course, it still remains important to move forward to qt-creator 4.12 upwards, but at least I have a working ide for the moment. There seem to be quite a lot of API changes in the projectexplorer component between the versions and I got a lot of override does not override errors from the compiler trying to migrate to version 4.12.

[gavanderhoorn]

There seem to be quite a lot of API changes

yes, and this is (partly) the problem with Qt Creator and maintaining plugins for it: they break API every *** release.

It's not just a matter of recompiling for a new version, it's essentially checking "everything" every time.

[v4hn]

they break API every *** release. It's not just a matter of recompiling for a new version, it's essentially checking "everything" every time.

Reading previous comments in this thread, I am under the impression that submitting the plugin to the qtproject can alleviate these problems because upstream could/would support the migration.

[gavanderhoorn]

It's not a magical process.

There's actually still work involved.

[v4hn]

It's not a magical process. There's actually still work involved.

I never said so. https://www.merriam-webster.com/dictionary/alleviate Anyway, I'm looking forward to functional support for more current versions of qt-creator.

[vincent-hui]

Yes, of course. There's actually still work involved like testing.
However, at least ros_qtc_plugin can get mechanical adapted to API change if it is on the source tree of Qt Creator
Let me quote the reply of the Qt Creator maintainer

The point is that for in-tree plugins some of the operations cause
practically no extra effort in some cases (e.g. some global renaming
doesn't really take notice on how many files are affected), and other
more manual scale more or less linearly with the number of plugins.

Together with the more or less constant overhead for creating and handling
the patch etc this means that the extra effort for an additonal
in-tree plugin is not *that* big.

For out-of-tree plugins the dominating factor is the patch handling in
the separate repo plus e.g. the effort to find out what actually
changed in the code. Together's usually much bigger than the code
adaption itself,

[Levi-Armstrong]

I will have sometime in the near future to get this working on the latest version. I am interested in trying to push this upstream but before I do I would at least like to update it to conform to there style guide before doing so. I will not have the time to do this but if someone else wants to take on the effort of doing so after I get it updated to the latest version, I will make time to support.

[v4hn]

I would at least like to update it to conform to there style guide before doing so

Could you link to the guide you mean? I found this linking to a qt-creator guideline, but the link is dead.
The general qt coding style is mostly about things clang-format takes care of (and things I would expect you to adhere to anyway).

What exactly needs to be cleaned up in your opinion?