> On Feb 15, 2021, at 08:52, Jakob Lettenbichler > <jakob.lettenbich...@artech.at> wrote: > > 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!
That is great to hear. > 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). Yes, especially some more overview documentation (e.g. how certain sets of classes work together) would certainly be helpful. Knowing which parts of the Qt Creator API would be most in need of documentation for the existing plugin developers would also be helpful though - we have been adding some documentation here or there, but it would be good to actually put effort where it is most needed/wanted instead of adding information blindly. > 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). Indeed. Since we do not provide binary compatibility between minor versions, also the major versions have not much meaning wrt that. So it all comes down to when we did refactorings to adapt to changing requirements on what Qt Creator needs to do, or to keep things more maintainable. > 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) The short answer is no. Especially not if you try to catch up with 3-4 years of development. Iâd say, as it is, the best way for plugin developers is to follow Qt Creator releases closely, and in doubt ask questions on IRC or on this mailing list. Generally we try to be helpful :) For open source plugins we want to advertise the Qt Project and the opensource super-repository for Qt Creator more, as suggested for the ROS people in this thread. This will not scale indefinitely - but neither will adding plugins to the main Qt Creator repository. That said, I think it would be nice if we would more pro-actively communicate public API changes, at least the ânon-obviousâ ones. That would still not prevent e.g. behavior changes to go by unnoticed though. And information about what parts of the API are actually used would probably be helpful in that regard too. Br, Eike > Any answer is very welcome, so thanks in advance, > > Cheers, > Jakob > > -----Original Message----- > From: Qt-creator <qt-creator-boun...@qt-project.org> On Behalf Of AndrĂ© > Hartmann > Sent: Sunday, 14 February 2021 16:38 > To: AndrĂ© Pönitz <apoen...@t-online.de>; Vincent Hui <vincenthk...@gmail.com> > 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<mailto: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 list > Qt-creator@qt-project.org > https://lists.qt-project.org/listinfo/qt-creator > > > > > > FN 181686 k. HG Wien, UID-Nr. ATU 47056901, zertifiziert nach ISO 9001:2015 > Nr. 04036/0 Der Inhalt dieser E-Mail ist vertraulich und ausschlieĂlich fĂŒr > den bezeichneten Adressaten bestimmt. Wenn Sie nicht der vorgesehene Adressat > dieser E-Mail oder dessen Vertreter sein sollten, so beachten Sie bitte, dass > jede Form der Kenntnisnahme, Veröffentlichung, VervielfĂ€ltigung oder > Weitergabe des Inhaltes dieser E-Mail unzulĂ€ssig ist. Wir bitten Sie, sich in > diesem Fall mit dem Absender der E-Mail in Verbindung zu setzen und die > E-Mail zu vernichten. FĂŒr Ăbermittlungsfehler oder sonstige IrrtĂŒmer bei der > Ăbermittlung besteht keine Haftung. > This e-mail is intended solely for the person to whom it is addressed and may > contain confidential or legally privileged information. Access to this e-mail > by anyone else is unauthorized. If an addressing or transmission error has > misdirected this e-mail, please notify the author by replying to this e-mail > and destroy this e-mail and any attachments. E-mail may be susceptible to > data corruption, interception, unauthorized amendment, viruses and delays or > the consequences thereof. If you are not the intended recipient, be advised > that you have received this e-mail in error and that any use, dissemination, > forwarding, printing or copying of this e-mail is strictly prohibited. > _______________________________________________ > Qt-creator mailing list > Qt-creator@qt-project.org > https://lists.qt-project.org/listinfo/qt-creator -- Eike Ziller Principal Software Engineer The Qt Company GmbH Erich-Thilo-StraĂe 10 D-12489 Berlin eike.zil...@qt.io http://qt.io GeschĂ€ftsfĂŒhrer: Mika PĂ€lsi, Juha Varelius, Jouni Lintunen Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B _______________________________________________ Qt-creator mailing list Qt-creator@qt-project.org https://lists.qt-project.org/listinfo/qt-creator
