Add ROS plugin to Qt plugin repo

[christian-rauch]

At the moment, a user of the ROS plugin for Qt relies on the binary installer provided on https://ros-qtc-plugin.readthedocs.io/en/latest/_source/How-to-Install-Users.html to install a fixed version of QtCreator alongside the plugin. Alternatively, a user can build the plugin from source for any QtCreator version.

There is a third option: Adding the plugin to the official QtCreator plugin repo: https://wiki.qt.io/Qt_Creator_Plug-in_Contribution_Guide. As a benefit, the plugin would be available on any QtCreator installation and would automatically track the latesst stable release. This would obviously also remove the need to provide dedicated binary installer for different Ubuntu versions.

[Levi-Armstrong]

I don't completely follow. This plugin is currently using the same method of distribution that Qt Creator Developers use. Although Qt Creator Developers do provide an a Debian which if I remember correctly, rarely gets updated so it is recommend to use the binary installers they provide. Also the binary installer provided is not a fixed version, it is linked to a repository which if updated any user should get notified the next time they open Qt Creator that a new version is available.

I do agree with the benefits of the third option about integrating directly with Qt Creator. I would also be interested in this because it would save time because every new version Qt Creator, it changes significantly requiring a lot of changes to the plug-in. Although for this to happen there is one major component which would need to address and that is the integration of using the existing CMake tools for parsing packages and building the code model. If anyone is interested in integrating this I would support this.

[christian-rauch]

The "official" QtCreator that is distributed via the "Qt Online Installer" contains an maintenance tool for installing different Qt versions and updating QtCreator.
The "ROS-QtCreator" that is distributed via the binary installer installs QtCreator with the ROS plugin, but does not update the QtCreator once a new stable version is released. E.g. on bionic, the version is fixed to 4.8.0-rc1 (4.7.84), although QtCreator version 4.8.1 has been released.

Uploading the ROS plugin to the Qt Creator Plug-in repo would allow to use the "official" installer and update QtCreator and plugin, once a new stable version has been released.
The only downside I see is that the plugin needs to be updated more frequently to keep track of API changes. However, as benefit it would be easier to use the newest stable releases and not needing to provide different dedicated installers for different Ubuntu versions.
Maybe having the plugin in the upstream repo also helps with keeping track of API changes.

[Levi-Armstrong]

The "ROS-QtCreator" that is distributed via the binary installer installs QtCreator with the ROS plugin, but does not update the QtCreator once a new stable version is released. E.g. on bionic, the version is fixed to 4.8.0-rc1 (4.7.84), although QtCreator version 4.8.1 has been released.

Uploading the ROS plugin to the Qt Creator Plug-in repo would allow to use the "official" installer and update QtCreator and plugin, once a new stable version has been released.
The only downside I see is that the plugin needs to be updated more frequently to keep track of API changes. However, as benefit it would be easier to use the newest stable releases and not needing to provide different dedicated installers for different Ubuntu versions.
Maybe having the plugin in the upstream repo also helps with keeping track of API changes.

This is true. Currently the onus is on me to upgrade the plug-in once Qt Creator has upgraded. This is usually time consuming effort because things change significantly and I have to get up to speed.

I could create a single installer similar to how Qt Creator does that works on most version of Linux's but I have not went through the process mainly because I am lazy and only have something that will build a release if given an installer.

My ultimate goal is to get it integrated into the main repository but it will take awhile to get everthing to a point where Qt Creator team would be willing to accept. I am open to someone taking this on if you are interested and would also help support make changes to allow it to be merged.

[vincent-hui]

@Levi-Armstrong if you submit ROS plugin to the Qt Creator source on codereview.qt-project.org and it is accepted there, it will get mechanical adapted to API changes. That means you can save time consuming effort to adapt it to API changes.
https://lists.qt-project.org/pipermail/qt-creator/2019-May/008011.html

[vincent-hui]

Hi @Levi-Armstrong , I contacted Qt Creator developers. One of developers, André Pönitz said you can submit code to codereview.qt-project.org with target branch 'master' of Qt Creator.

Will you submit ROS plugin code to Qt plugin repo?

Reference
https://lists.qt-project.org/pipermail/qt-creator/2019-August/008107.html

[vincent-hui]

Hi @Levi-Armstrong, I think other people cannot submit ROS plugin code for you because other people cannot accept Qt Contribution Agreement on your behalf.

Will you submit ROS plugin code to Qt plugin repo?

Thank you

[christian-rauch]

Let's warm this up again.

The Qt Creator Plug-in Contribution Guide mentions singing the Qt Contribution Agreement, and git and code quality standards.

Is there a way to know what in the code has to change before we submit the initial version? @Levi-Armstrong mentioned code-style, which is addressed in #423, and some member name refactoring. I would like to get the feedback directly from the Qt Creator project, before applying the code style to all source files, but I don't see the procedure to actually upload the code or create a PR with the Qt Creator project.

@Levi-Armstrong Is there a definite TODO-list what we would have to do? I am happy to work on the code style and variable renaming to get this thing upstreamed.

[vincent-hui]

I have sent an email to Qt Creator mail list to ask for advices
https://lists.qt-project.org/pipermail/qt-creator/2021-February/008778.html

[vincent-hui]

Please read Qt Creator mail list tonight.
https://lists.qt-project.org/pipermail/qt-creator/2021-February
A Qt Creator developer will reply tonight.
Thanks

[vincent-hui]

@christian-rauch @Levi-Armstrong
Feel free to read and reply https://lists.qt-project.org/pipermail/qt-creator/2021-February/008783.html
Thank a lot.

[Levi-Armstrong]

The super repo is an ok approach. What do you all think?

[vincent-hui]

@Levi-Armstrong
Yes, I think the super repo is an ok approach too.
By the way, would you mind subscribing Qt Creator mail list to discuss with Qt Creator developers directly?
Thank a lot.

[christian-rauch]

So, being part of the submodule mean that:

1. the official upstream becomes a new ros_qtc_plugin repo at https://code.qt.io/cgit/qt-creator/ros_qtc_plugin.git
2. this new upstream repo becomes a submodule in https://code.qt.io/cgit/qt-creator/qtc-super.git/tree/.gitmodules
3. all API changes are updated by the Qt Creator project in this repo
4. the binary version of the plugin will be available under https://github.com/qt-creator/ros_qtc_plugin/releases

That sounds fine to me. From a quick look at https://github.com/qt-creator/plugin-haskell/releases, it seems that these binary releases are the plugin archives that I suggested in #422. So while they are not shipped with Qt Creator, they can be added to any regular binary distribution of Qt Creator.

[vincent-hui]

By Subscribing to Qt-creator , we can discuss with Qt Creator developers directly.

[vincent-hui]

Hi @Levi-Armstrong,
Are you going to request https://code.qt.io/cgit/qt-creator/plugin-ros.git repo ?
Thanks

[vincent-hui]

What to do next?
Thanks

[vincent-hui]

Hi @Levi-Armstrong ,
Would you mind telling us your plan?
Thanks