Re: [Qt-creator] Request advices for Qt Creator plugin developers to adopt API changes easily

[Jakob Lettenbichler]

Hiho,

Sorry to hijack this thread to bring it back on topic: I am quite interested in 
the answer to the question of how to adopt API changes for the QtC plugins 
easily.

Our team loves the QtCreator and we therefore use it as sole tool for our 
Qt-based toolchain (yes, of course we have the proper Qt Licence for that  ). 
So many thanks to you guys for doing such an incredible job there!

But the issue is as mentioned in the thread title: These QtC API (and sometimes 
even behavior) changes typically are difficult to find and typically end in 
searching the internet for other QtC plugins having the same issue (but finding 
plugins, that are actively maintained and sharing their code is not easy).
Why I am asking: our team uses about 25 QtC plugins we made over the years 
(tailored to our toolchain) and haven't upgraded our QtCreator for years now 
(stuck at 4.4.1 atm).
The reason for that is, that upgrading from 4.0 to 4.4 took the whole team 
several weeks to finish (so about 2 man-months) and some well-hidden behavior 
changes surfaced (sorry, did not find the exact causes documented in our 
ticketing system) much later causing painful searches in our non QtC codebase 
since we didn't expect the plugins to be the cause.
Back then we had less than 20 plugins and some of the newer ones dive deeply 
into i.e. QtDesigner (we are stuck with Qt Widgets too), which is especially 
hard to deal with.

And yes, reading the code and the standard QtC plugins (and their git history) 
helps, but not for everything, since the QtC codebase is not heavily documented 
and quite a lot (sorry for the criticism there).

Interestingly the jump from QtC 2.7 to 4.0 was much easier (so the version 
numbers give no hint of the amount of porting work to be done).

So to re- ask Vincent Hui's question: is there a well maintained help for 
upgrading QtC plugins considering API and behavior changes? (porting guides 
like for Qt itself would of course be an ideal tool)

Any answer is very welcome, so thanks in advance,

Cheers,
Jakob

-Original Message-
From: Qt-creator  On Behalf Of André Hartmann
Sent: Sunday, 14 February 2021 16:38
To: André Pönitz ; Vincent Hui 
Cc: qt-creator@qt-project.org
Subject: Re: [Qt-creator] Request advices for Qt Creator plugin developers to 
adopt API changes easily

Hi all,

sorry for hijacking this thread, but having a terminal integrated into Creator 
sounds like a great addition.

There has been https://bugreports.qt.io/browse/QTCREATORBUG-8511 plus 
duplicates for years, so maybe that is the chance to get that thing in?

Best regards,
André

On 13.02.21 07:52, André Pönitz wrote:
> On Wed, Feb 03, 2021 at 11:04:20PM +0800, Vincent Hui wrote:
>> Hi Andre',
>
> Hi.
>
>> Sorry for my late reply.
>> Now the contributors of ros_qtc_plugin are preparing upstreaming
>> ros_qtc_plugin to Qt Creator repository.
>> 
>> [1]https://github.com/ros-industrial/ros_qtc_plugin/issues/406#issuecomment-766868092
>> Would you mind giving them some advices how to upstream ros_qtc_plugin to
>> Qt Creator repository quickly. I think upstreaming ros_qtc_plugin can
>> greatly benefit to both of ROS community of Qt community.
>> br,
>> Vincent
>
> Sorry, this fell through the cracks.
>
> We had a short chat in the meantime here.
>
> There are currently two possible ways to integrate plugins into 
> Creator, first a "full integration" in the Creator core code base, 
> with all the benefits and all the restrictions, and second an 
> integration as submodule in the super-repo, which currently contains 
> Creator proper as submodule, as well as a Haskell support plugin and a plugin 
> for the fossil source control system.
> The super-repo is located at 
> http://code.qt.io/cgit/qt-creator/qtc-super.git/
>
> The long term plan is to move more to the modular (i.e. super-repo) path.
> It also looks like the ros_qtc_plugin seems to have a hard dependency 
> on QTerminalWidget which would probably be hard to get into the 
> Creator core because that would need the license agreement be accepted 
> from the QTerminalWidget folks.
>
> So the suggestion is to choose the second option, i.e. have 
> https://code.qt.io/cgit/qt-creator/plugin-ros.git similar to what is 
> there for plugin-haskell and plugin-fossil, and link that as submodule from 
> qtc-super.
>
> This would require:
> - someone to request the creation of this repo on the
>developm...@qt-project.org mailing list
>and create a corresponding jira task. Anyone could do that, if you don't
>want to, I'd do it,
> - in that request we need to name someone who will feel responsible for it,
>suggestion here is that this is you or someone else from the ROS 
> community
>
> The implications of being in the super-repo are:
> - the plugin will get "automatical" updates when internal Creator API changes,
>so it is kept *compilable*, but final verification of a "working" state 
> 

Re: [Qt-creator] Request advices for Qt Creator plugin developers to adopt API changes easily

[André Hartmann]

Hi all,

sorry for hijacking this thread, but having a terminal integrated into
Creator sounds like a great addition.

There has been https://bugreports.qt.io/browse/QTCREATORBUG-8511 plus
duplicates for years, so maybe that is the chance to get that thing in?

Best regards,
André

On 13.02.21 07:52, André Pönitz wrote:

On Wed, Feb 03, 2021 at 11:04:20PM +0800, Vincent Hui wrote:

Hi Andre',


Hi.


Sorry for my late reply.
Now the contributors of ros_qtc_plugin are preparing upstreaming
ros_qtc_plugin to Qt Creator repository.

[1]https://github.com/ros-industrial/ros_qtc_plugin/issues/406#issuecomment-766868092
Would you mind giving them some advices how to upstream ros_qtc_plugin to
Qt Creator repository quickly. I think upstreaming ros_qtc_plugin can
greatly benefit to both of ROS community of Qt community.
br,
Vincent


Sorry, this fell through the cracks.

We had a short chat in the meantime here.

There are currently two possible ways to integrate plugins into Creator,
first a "full integration" in the Creator core code base, with all the benefits
and all the restrictions, and second an integration as submodule in the
super-repo, which currently contains Creator proper as submodule, as well
as a Haskell support plugin and a plugin for the fossil source control system.
The super-repo is located at http://code.qt.io/cgit/qt-creator/qtc-super.git/

The long term plan is to move more to the modular (i.e. super-repo) path.
It also looks like the ros_qtc_plugin seems to have a hard dependency
on QTerminalWidget which would probably be hard to get into the
Creator core because that would need the license agreement be accepted
from the QTerminalWidget folks.

So the suggestion is to choose the second option, i.e. have
https://code.qt.io/cgit/qt-creator/plugin-ros.git similar to what is there for
plugin-haskell and plugin-fossil, and link that as submodule from qtc-super.

This would require:
- someone to request the creation of this repo on the
   developm...@qt-project.org mailing list
   and create a corresponding jira task. Anyone could do that, if you don't
   want to, I'd do it,
- in that request we need to name someone who will feel responsible for it,
   suggestion here is that this is you or someone else from the ROS community

The implications of being in the super-repo are:
- the plugin will get "automatical" updates when internal Creator API changes,
   so it is kept *compilable*, but final verification of a "working" state will
   (often) be left to the "responsible person"
- the plugin will *not* be part of the pre-compiled Qt Creator binaries or the
   Qt install.
- there will be pre-build binaries for the plugin created for each Qt Creator
   release, at https://github.com/qt-creator/plugin-ros/releases/..., which
   can be used together with the pre-compiled Qt Creator binaries.
- there would be no hard requirement to stick to Qt Creator coding style rules.

If that sounds ok for you we'd need the name of the "responsible person"
to request the repo.

If it is not ok for you, we can have a second look on whether integration into
the Creator core distribution would be possible. That would start with
clarifying the state of the QTermWidget dependency.

Best regards,
Andre'



On Wed, 8 May 2019 at 05:31, André Pönitz <[2]apoen...@t-online.de> wrote:

  On Tue, May 07, 2019 at 04:16:17PM +0800, Vincent Hui wrote:
  > Hi,
  >
  > Thank for developing Qt Creator such a great IDE.
  >
  > I am a user of ROS Qt Creator Plug-in
  > <[3]https://github.com/ros-industrial/ros_qtc_plugin>. After a new
  version of
  > Qt Creator had been released, it took the developer of ROS plugin a
  long
  > time to adopt Qt Creator API changes to support a new version of Qt
  Creator.
  >
  > My question is how to let plugin developers to adopt API changes
  easily so
  > that tey can release newer pulgins quickly ?

  The changes are all visible in git, so in principle anyone interested
  could
  follow up immediately.

  However, I see and know that this is quite some effort.

  One potential workaround is to develop the plugin in-tree, i.e. submit
  it
  to the Qt Creator source on [4]codereview.qt-project.org. If it is
  accepted
  there it will at least get mechanical adapted to API changes. Release
  testing and/or feature work will not be covered.

  Andre'

References

Visible links
1. 
https://github.com/ros-industrial/ros_qtc_plugin/issues/406#issuecomment-766868092
2. mailto:apoen...@t-online.de
3. https://github.com/ros-industrial/ros_qtc_plugin
4. http://codereview.qt-project.org/

___
Qt-creator mailing list
Qt-creator@qt-project.org
https://lists.qt-project.org/listinfo/qt-creator



___
Qt-creator mailing