Hiho, @ QtCreator using a different Qt version as all the other stuff we are doing: interesting approach, we didn't think of that one yet (we use a different Qt version for windows/linux (5.9, which we use for compiling the QtCreator, the widgets, our tools and the plugins of course too) and our embedded system, though, which is still 4.8 for some customers (5.9 for the more reasonable customers)). @ the classic QtDesigner as a standalone tool is not in use anymore - for us. We use the QtDesigner plugin that is delivered with the QtCreator instead.
An ad-hoc overview of what our Plugíns do (maybe that helps you already to locate some points that might be relevant for documenting), in no particular oder: * registering/handling custom file and project types, wizards and custom editors for them, --> so various signals for file/project changes and stuff are relevant here, as well as how to add editors and couple them to mime types and stuff. (how to handle custom highlighting would be nice, but we haven't actually tried it yet) * command line arguments for the QtCreator --> the hook that is accessible via plugins * various tools accessing and modifying the .ui/project/cpp files (i.e. import-export tools for widgets in the QtDesigner plugin, needed for our custom widgets and for the fact, that copy&paste of Widgets that are not grouped in a parent widget are sorted alphabetically when pasting, which destroys the z-order) --> here we mostly need to be able to access/modify the (selected) (custom) widgets, (QDesignerForm[Editor/Window/WindowManager]Interface) * Ui list Plugin for the QtDesigner (there we were not able to find out how to integrate it nicely, except via the area at the bottom, where you can show i.e. the application/compile output * Search plugins -> API for adding search plugins * Various wizards accessible via Menu on the top --> so mostly project change and Menu stuff is QtCreator API dependent * custom documentation via Help thingy on the right bar (well, it's not much plugin-related, since it is mostly doxygen stuff with some converters, the only overlap with the QtCreator here is the Qt Help Browser (which was Webkit in earlier (Qt) versions and now is QTextBrowser for those not being able to use clang in Linux (which is a prerequisite for compiling chromium there)) and the way to be able to show it along with the Qt Help,. A more detailed listing of all the APIs used is unfortunately too time consuming for the moment, but I will try my best and add specific parts in future questions/diskussions about plugins. Hope that helps and many thanks for your input, Cheers, Jakob -----Original Message----- From: Eike Ziller <eike.zil...@qt.io> Sent: Monday, 15 February 2021 14:38 To: Jakob Lettenbichler <jakob.lettenbich...@artech.at> Cc: qt-creator@qt-project.org Subject: Re: [Qt-creator] Request advices for Qt Creator plugin developers to adopt API changes easily > On Feb 15, 2021, at 13:02, Jakob Lettenbichler > <jakob.lettenbich...@artech.at> wrote: > > Hiho, > > I received two answers (one from Eike Ziller, see below) and one from > Christan Kandeler. > Since the answer of Eike Ziller contains practically a superset of Christians > information/answer, I will answer to this. > But of course, thanks to both of you for these fast replies. > > Your main message is: stick closely to your release cycle and you wont have > such problems (that much). > > Short answer: we want, we can't. > > Long answer: > On a personal level, I agree (but more (in-code?) documentation would always > help of course (but the divergence between theory and practice seems to be a > natural constant). > > But as always - theory and practice - there is some show-stopper. > > In our case, our dev team in charge of the QtCreator based toolchain, is not > allowed to upgrade relevant parts frequently (i.e. we are still stuck with > gcc 5.3, Qt 5.9 and python 2.7), since our superiors are not that software > affine and disapprove any changes until something breaks that can not be > patched by ourselves. (This is also coupled to our clients using that > toolchain, which react allergic to any (visible) change). > Even if we would be able to i.e. upgrade the QtC, since the impact is not as > severe as i.e. upgrading the Qt version, we would be stuck with QtC 4.9 since > it is the last version supporting Qt 5.9. So you also have limitations on which Qt version Qt Creator is built with? Since you can still develop Qt 5.9 applications with Qt Creator 4.14 based on Qt 5.15. If you really cannot update Qt Creator, then yeah, choices are limited. The only thing that comes to my mind would be if the team that is responsible for your custom Qt Creator parts kept track of Qt Creator and upgraded your tools to new Qt Creator versions as they appear in a “dev” version of your tools, even though that is not used by the rest of your organization…. but of course that requires that at least the dev team is allowed to upgrade Qt & Qt Creator, and it might be frustrating to do this work that might or might not be relevant in a few years... > I know that sounds like some pretty exotic scenario, but there are many > companies out there which can not upgrade software packages easily since > there are some non-trivial cross-dependencies to other things and then the > slowest element defines the overall speed of a project. Which is one of the > reasons why we still use Qt Widgets and no line of QML code so far. > Conservative software update planning is dangerous and disapproved by > practically everyone who is allowed to decide this on their own, but practice > dictates that one is typically not allowed to decide that on his/her own. > Therefore big jumps breaking are unfortunately more common than small-steps > policies then one would think. > Therefore migration guides updated every now and then would help a lot > 😉 > > That you as core developers do not get the information which parts are > actually used by plugin developers, is indeed an important and valid point > and I'll try to post something about that on this ML (at some point we will > upgrade the QtCreator and then we will come running for help anyway). But I > suspect that most of our non-trivial usage of your API is related to the > QtDesigner Plugin (so even one level above the QtCreator itself), which as > mentioned here frequently, is mostly some relict of the past, when Qt Widgets > still were a thing (so documenting them would be nice for us, but less and > less relevant for others), API breaking does happen mostly on other parts, > though. Qt Widgets are pretty much alive even though not changing much - Qt Creator itself has almost no QML based UI. If you mean that you have plugins for Widget Designer directly, and not extending the Designer integration plugin in Qt Creator: This part in Qt (the actual Designer that we integrate) doesn’t change very much. So I’d expect that plugins for the Designer itself don’t need many changes, if any at all. In this case documentation for Qt Creator wouldn’t help you anyway though. Br, Eike > -----Original Message----- > From: Eike Ziller <eike.zil...@qt.io> > Sent: Monday, 15 February 2021 11:51 > To: Jakob Lettenbichler <jakob.lettenbich...@artech.at> > Cc: André Hartmann <aha_1...@gmx.de>; André Pönitz > <apoen...@t-online.de>; Vincent Hui <vincenthk...@gmail.com>; > qt-creator@qt-project.org > Subject: *****POSSIBLE SPAM***** Re: [Qt-creator] Request advices for > Qt Creator plugin developers to adopt API changes easily > > > >> 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 -- 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
