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

Denis Shienkov scapig2 at yandex.ru
Wed Jul 31 11:18:15 CEST 2013


Hi Tobias,


30.07.2013, 23:57, "Tobias Hunger" <tobias.hunger at gmail.com>:
>
>>  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?

I meant display of some (or all) properties of the QBS's CPP module, as: 

platformDefines, compilerDefines, includePaths, ... commonCompilerFlags, cppFlags, ... cxxFlags.

i.e. not only optimization. I am sorry if I misled.


> 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.

Yes, simply I gave an example in a context of embedded MCU's programmers which got used to use specialized 
IDE's in which it is possible "is thin" to adjust parameters, and for each base parameter there is a description 
and the help what he do... 

I.e. initially I had idea in relation to MCU features of IDE, because it was interested for me. But now I understand that, 
in principle, if is correct/rigth to think over infrastructure and concept of API for QBS, this issue can be resolved.

For a basis I can take a concept/idea of display of properties of the project from usual projects (on Windows, 
Linux and etc). And on its base to make customization for features of MCU's specific.


Now, the main and prime problem - realization of the UI mechanism of display of properties of the project for 
usual applications, about what you speak.. :)


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

Ahh. Yes you are right.
But then in QBS this information won't become outdated also? :)

I mean that then QBS has to contain a database on options and flags of the compiler, etc. and it will need 
to be updated sometimes...


> 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.

Ahh.. Also you are right. Simply I didn't know that QBS by design is such a combine which everything 
is able and is self-sufficient. :)


> 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.

Maybe need retrieve in "simple" XML form? 
e.g. as for *.ui files content for Designer...

Because if to use/take realization from ready "properties widget" of Designer - that there (I so assume) 
everything it is implemented through XML parsing?


>>  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?

Yes, I agree, it is possible to take ready realization from  Designer's widget. It is the simplest way.. You are right. 
The tree model - it is the most convenient form of information presentation, IMHO (if I correctly understood you).


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

Yes, something like it. Only to use in the form of a tree model (as Designer's properties widget), IMHO.


> 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...

How many approximately to wait?


>>  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?

Oops. I meant of course, the Kit display (instead of toolchain) on "build settings" page.
Kit is displayed at present in qbsprojectmanager, I was inattentive, sorry.

Simply I was confused by that fact that after attempt of opening of the QBS file of the project in QtCreator, 
wizard wasn't displayed where I could choose Kit necessary to me. 

I.e. by default is implicitly used "default" Kit. But it is not problem, because I can do "Add Kit" from "Build Settings" 
page of project, sorry. :)


> 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.

Yes, I am inattentive.


> 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.

Agree with take implementation from a Qt Designer's property editor.


> 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.

But then QBS should contains something like DB? 
>From where QBS will know about the available ranges of the properties/flags received from the project's file?
And then how QBS should interpret this properties to give info about properties by 
ask from qbsprojectmanager plugin?

Or you assume to describe all possible ranges of available properties, flags, values  (for used Kit/Toolchain),
in the *.qbs project file of the application?

Best regards,
Denis




More information about the Qt-creator mailing list