[Qt-creator] [request] Share some classes of QBS project manager plugin.

[Tobias Hunger]

Hi Denis,

2013/7/30 Denis Shienkov <scapig2 at yandex.ru>:
>> So let's hammer down the scope:
>>
>> Are we discussing a generic infrastructure in Qt Creator that can be
>> used to define all possible optimization levels of the different
>> supported compilers and then pass them on to the different build
>> system supported by QtC
>>
>> --or--
>>
>> are we discussing how to set the optimization property from qbs?
>>
>> My understanding after your first mail was that we are talking about
>> the first. Now I think we are talking about the second.
>
>
> Most likely it is a talk about pair of QBS & qbsprojectmanager...

My question is not which code will need changing but what you actually
want to do.

> Because I mean not only display of "standard" names of options of
> optimization (which "hard coded" in QBS at present), but also about CXX, C,
> ASM and LINKER flags. I.e. it is more global and complex issue.

So this is the 3rd use of the two options given above:

A generic infrastructure to set up compiler/linker/asm flags with a
specific implementation for qbs?

>> You can also set them via the command line and via the "Properties"
>> field in the build settings of Qt Creator.
>
>
> Yes, of course.
>
> In principle, has no value where to enter these options: or in command line,
> or in the file of the project or somewhere. The main problem that the user
> shall "advanced skills" and perfectly know options/flags of the compiler
> which uses.

I think there is a lot of value for those advanced users. We seem to
be in agreement that this is not for more average users.

>> I agree that this is not the ideal UI for setting all the different
>> properties. We should get a list of all properties defined in the
>> project (and the modules used by it) from Qbs, together with the set
>> of possible values.
>
>
> Agree.
>
> But the set of possible values we can store/contain in "database" of
> qbsprojectmanager plugin . IMHO, we not need  to query possible values from
> QBS, we need to query only present settings from the current project (from
> *.qbs file).

I do *not* want to have a properties DB in the QbsPM plugin! That will
be outdated as soon as it is commited:-)

All the information has to come from qbs somehow, incl. the defined
properties, their value range (if applicable) as well as a (optional?)
description that can be shown to the user.

The good thing is that qbs already has "PropertyOptions" defining all
that. So it is a question of defining a API to retrieve this
information from qbs.

> I suggest to enter a certain entity/class like "OptionsDisplayer" (for
> qbsprojectmanajer) which would have the virtual method
>
> ...
> QWidget *OptionsDisplayer::createWidget() const = 0

Why? Qbs will return a return a list (maybe a tree) of properties with
type, a description and maybe a list of allowed values. That can be
visualized like e.g. the properties of QWidgets in the Qt Designer.
Why do you think special widgets will be needed for certain areas of
this?

Basically I am thinking a bit along the line of what cmake-gui does.
See http://www.cmake.org/cmake/help/runningcmake.html ?

I actually wanted to wait a bit and see what the probes found in qbs
develop into (they can be used to find libraries, etc.): Those might
have an impact on how the UI should work...

> PS: Yes, I know that at present in qbsprojectmanager isn't implemented yet a
> display/showing of used tollchain (e.g. as for qt4projectmanager plugin) .
> But on future it will be implemented (I hope) ?

I have no plan for that yet.

Basically the kit already defines the toolchain being used (well, the
compiler), so why have another UI for that?

Creator already pushes its kit definition into qbs, defining the tool
chain and Qt version etc. and makes them available to the commandline
qbs client, too.

>> This will allow to set "qbs.optimization" to "fast" or "space" or
>> whatever.
>
> Not only it, but is possible also set and other options...

Yes. That was the idea:-)

>> It will _not_ allow to specify settings at the granularity shown in
>> your screenshot: You can just show the settings of qbs, not the exact
>> flags that will end up in the call to the compiler.
>
> Granulation of optimization options which I provided - only for an example
> (btw I take an example from Code::Blocks - there granulation). I simply
> wanted to show a place in which where I plan to insert OptionsWidget.

Ah, ok.

> PS: I simply curious to know: what do you (and others) think about idea to
> add UI for display (in user-friendly form) of options of the
> compiler/linker. For qbsprojectmanager plugin of QtCreator.

A nice way to set all the properties (which includes qbs.optimization,
etc. as well as paths to libraries used and other more high-level
things) is essential and the place you picked in your screenshot seems
very reasonable to put this. I think the actual implementation will
look more like the property editor in Qt Designer than in your
screenshot though.

I just want to limit the information displayed to what is available
from qbs (no API for that yet, but the information is already
available to qbs) and do not want to have the QtC plugin ship a
database of common settings. Projects will define their own
properties, and those can not be covered in a QtC database and the
database will be impossible to keep up to date anyway.

Best Regards,
Tobias