[Qt-creator] Custom wizard vs qmake's wizards

[Christian Gagneraud]

On Mon, 29 Apr 2019 at 21:50, Eike Ziller <Eike.Ziller at qt.io> wrote:
> > On 29. Apr 2019, at 09:43, Christian Kandeler <christian.kandeler at qt.io> wrote:
> > On Mon, 29 Apr 2019 18:34:09 +1200
> > Christian Gagneraud <chgans at gmail.com> wrote:
> >>> If I register a new "Qbs.AddLibrary" action, i end up with duplicates
> >>> in the context menu (qmake disabled, and qbs enabled),
> Calling setVisible instead of setEnabled for these actions would of course be possible, but it would probably be better to try and not duplicate all the work.
>
> >>> if instead if
> >>> fetch the "Qt4.AddLibrary" and enable it, i get the (qmake) "Add
> >>> library wizard", but when i go till the end of the wizard i get qmake
> >>> stuff added to my qbs project file ... (that was funny, i expected a
> >>> crash or something :))
> >>>
> >>
> >> Actually, I just saw the supportsAction in the project node. That's a good
> >> start. But there doesn't seem to be anything generic to handle adding
> >> library, etc....
> >> Maybe it's not hard to add, maybe not...
>
> That might be the way to go, but I also can’t really tell how much work that would be. E.g. would it make sense to share (parts of) the actual wizard?

Well, maybe the project explorer shouldn't bother about implementation
details of the underlying project managers.
Why hard-code the concept of sub-projects, library, plugin, unit test,
file, project, non-qt project, ... into the project explorer?
Or even hard-code the qmake view of what a "library" is (internal,
external, system and pkg-config).
Both Qbs and CMake have different view of this and they handle that in
a better way.
So maybe the first page of the wizard could be shared (i'm not even
conviced of that), but then the next pages are very likely to be BS
dependent (BS=build-system, not bullshit :)).
For Qbs, an internal library is "as simple" as 'Depends { name:
"myInternalLibrary"}', no need to specify include path, etc (as
required by qmake and present in the current wizard), CMake work in a
very similar way AFAIU (eg public/private export).
qmake is the worst common denominator of "better" BS.

I'm not that familiar with CMake and other build system, but if the
project explorer attempts to dictate hard abstraction concepts, you
risk to end up will all supported build systems being limited (least
common denominator).
Currently the list of "Build system" plugins (project managers) are:
- autotools
- cmake
- clang compile db
- generic (does that include python projects?)
- qbs
- qmake

We can safely rule out clang db (as it is read-only AFAIK), autotools
(welcome to 21st century) and maybe generic (too generic?).
qmake is EOL, but will need support for years to come. CMake is
widespread and qbs a challenger with interesting potential (personal
opinion). And python is about to bring it's own lot of weird
requirements.

Just a wild idea, but what about having only one context menu entry:
"Add new item...", that would yield a re-organised "Add new file
and/or project and/or what-have-you" wizard under tight control of the
project manager implementation?
Maybe it's a good idea to share small bits, but not whole wizards.
Custom JSON wizards are cool for adding project manager independent
(re)sources, but i'm not convinced that they are good to handle
project manager/build system dependent features.

As far as Qbs is concerned here are the most likely candidates for
"Add new.." that are not files (source or not):
https://doc.qt.io/qbs/qbsconvenienceitems-qmlmodule.html
Note: I'm not saying we need support for all of these

My 2 cents.

Chris