Re: [Qt-creator] Generating QtCreator cmake project for given CMakeLists.txt from command line

[Hunger Tobias]

Hi,

apparently I replied only to René directly... find the original reply inline.

On Fr, 2016-04-15 at 13:03 +0200, René J.V. Bertin wrote:
> On Friday April 15 2016 10:05:02 Hunger Tobias wrote:
> Was there a reason you replied off-list?

Carelessness.

> > In the end you need to have the kit and the actual configuration in your
> > build
> > directory to match up: Otherwise the code model will not function properly.
> > So I
> > think the use-case of having a kit and a completely different configuration
> > in
> > your build directory is nothing Creator needs to support.
> 
> There's no point in supporting completely different configurations indeed, but
> the fact a feature could be used to work with such a senseless configuration
> doesn't mean it cannot have a valid reason to exist ...

I think this will no longer be an issue when you can just import an existing
build directory.

> > Creator has no internal cmake parser.
> 
> I know.
> 
> > We get most information out of the
> > codeblocks file.
> > 
> > For Qt Creator 4.0 all I did was to improve on the workflow for using cmake
> > projects. I did not yet look into how we can get more/better information out
> > of
> > cmake.
> 
> OK, so maybe my hint about the compile_commands.json file will serve a purpose
> :)

Thanks for the hint.

That file will probably work well, as long as you do not end up building one
source file as part of several targets (e.g. an executable and a test).

> > > The alternative would be to provide a way to control exactly how cmake is
> > > called, command and arguments (and record that information, contrary to
> > > earlier QtC versions that didn't remember the cmake arguments).
> > 
> > Qt Creator 4.0 should do that.
> 
> In the version I have I only see a way to change settings from the cache. But
> changes made there apparently can get lost.

Not those you do from inside Creator. Those sometimes did get lost before, too.

> > Yes, CMake is far from ideal for IDEs:-/
> 
> Is autoconf/automake/configure really that much better?

autoconf/automake are definitely easier to work with for IDE integration. At
least they have one defined set of outputs. CMake produces whatever it wants.

> > That is what importing a build directory is for. For now I do not think this
> > is
> > much of an issue since Creator should only pick up build directories that
> > happen
> > to be named like Qt Creator names them:-)
> 
> That's the automatic pickup, yes. But imagine a Debian (or other distribution)
> maintainer working on code and its packaging. If that involves a number of
> not-so-trivial patches it becomes useful to import the project and its
> existing build directory in an IDE, and evidently that IDE should then be as
> well-behaved as possible (i.e. only change things by explicit user request ...
> like source files ;))

Yes, I am not arguing that point. But the current "automatic" pickup of build
directories can not cover this use case: You want to explicitly import such a
build directory.

> > No. If you ask creator to use a certain cmake, then creator should not use
> > some
> > other cmake behind your back.
> 
> I should probably have removed those remarks after reading your idea of
> creating a kit off the build configuration.
> 
> > No idea, I never checked that.
> 
> Forget it, must have been something in the project itself. Just a redundant
> make invocation takes over 4 minutes with 4 parallel cmake processes running
> at 100% CPU.
> 
> > Yes, these kits are added forever (once you actually import the build
> > directory).
> 
> I'd probably want to have an option to disable that particular feature. Esp.
> if those kits take *all* cmake arguments into account (including the one that
> points cmake to the source directory!). QtC already keeps picking up kits for
> Qt build trees I keep around and I'd never use for building against, at some
> point something's gonna give ;)

Considering that you probably have a limited number of cmake binaries, compilers
and Qt versions, kits are bound to repeat themselves;-)

> > Kits can have their own set of environment varibales. fro a while now.
> 
> Yes, that I know. But you have to set them every time. It'd be convenient to
> have presets (profiles) that you configure once (and edit "centrally"), and
> then pick the appropriate one when creating a new project.

I am not sure that this is a common use case.

You could set up your environment before you start Qt Creator... that way the
environment will be inherited by all projects.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft:
Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Generating QtCreator cmake project for given CMakeLists.txt from command line

[Hunger Tobias]

On Do, 2016-04-14 at 18:19 +0200, René J. V. Bertin wrote:
> I'm not sure if I really grasped everything outlined in the OP, but I think I 
> have a similar question for a comparable workflow that doesn't involve ROS or 
> catkin.
> It does involve a distribution/packaging system that runs cmake (and make) in
> a 
> tightly controlled environment and with highly specific commandline options. 
> When developing (or adapting) software in the context of that system it is
> often 
> useful to be able to open a work directory (containing directories with the 
> [patched] source and an out-of-tree build directory) in an IDE, possibly even 
> (re)building parts of the code.
> 
> It is trivial to let the system have cmake use the "CodeBlocks - Unix
> Makefiles" 
> generator, but apparently that is not enough to let Qt Creator reuse the 
> configured build directory without re-running cmake. It is easy enough to re-
> run 
> the correct configure command if QtC calls cmake only once, on the initial 
> import. It's a different story if it keeps doing this each time a project is 
> (re)opened.
> 
> Is there a way to prevent QtC from re-running cmake each time it feels like 
> doing so?

Creator will rerun CMake whenever it feels like doing so, because that is the
only way to get up-to-date information on the project. CMake is not very
forthcoming with information:-/

Creator will keep the configuration unless at least one of these conditions is
met:

* The generator (ninja/make/etc.) used to set up a build directory does not
match up with the one used by the selected Kit.

* The cmake command that was run to set up a build directory is not the one
configured for the selected Kit.

Creator no longer clears the cache if the Extra Generator "CodeBlocks" is
missing.

I do want to have proper "Import build directory" support for the next version.
That should then set up a matching kit for a build directory.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft:
Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Looking for Enums with Locator

[Hunger Tobias]

On Mi, 2016-04-13 at 16:13 +0300, Prav wrote:
> Hi, Nikolai.
> 
> > I'm fine with making enum values "locatable", though personally I 
> > haven't missed them.
> OK ... as result filled
> https://bugreports.qt.io/browse/QTCREATORBUG-16060
> 
> Is there somewhere list of bugs planed for fixing for nearest versions of QtC?
> May be in JIRA itself?

Nope.

There is JIRA, which has all known bugs and feature requests. We will try to
process them in a timely manner based on priority and other factors.

In my experience it is really hard to do mid- and long-term planning in an open
source project with lots of volunteer contributors like Qt and Qt Creator is.
Contributors come and go, fix small issues here and there, add new functionality
or even implement whole plugins.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft:
Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

[Qt-creator] Nominating Marco Benelli for Approver status

[Hunger Tobias]

Hello Qt Developers,

I hereby nominate Marco Benelli for Approver status. He has put in a lot of
effort to maintain the QML code inside Qt Creator over the recent month and in
fact is the default assignee for all bugs in that area of Qt Creator.

He did good work in his area and Qt Creator in general, so I think he has more
than deserved Approver status by now.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft:
Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Qt Creator multi versions

[Hunger Tobias]

On Mi, 2016-04-13 at 09:22 +0200, ekke wrote:
> What's the best to deal with multi versions of Qt and Qt Creator ?
> 
> per ex. had installed Qt 5.6.0 RC together with Qt Creator 3.6.0
> then installed Qt 5.6.0 together with Qt Creator 3.6.1
> 
> noticed that preferences are shared between both versions

Yes, all versions share their settings.

Creator does update settings from one version to the next, but it is basically
undefined what will happen when you start an old Qt Creator version with
settings from a newer version.

> detection of Qt itself, Compilers, ... worked well - Qt Creator seems to
> find it all relative to directory where Qt Creator was installed

Nope. Autodetection of compilers and Qt versions are based on PATH and (for MSVC
windows) the registry. The Qt installer will also make its components known
using the SDKtool (via files in the shared/qtcreator/QtProject folder of the Qt
Creator installation).

> then I wanted to use two different Project directories, but this path is
> shared from both installations.
> Is there a way to install multi versions of Qt using different pathes
> for Project Dir ?

There is the "-settingspath" command line argument for that.

If you build Qt Creator yourself you can also change the "vendor" which is used
in the default settings path. By default that is QtProject.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft:
Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Where can I find a list of Creator's variables?

[Hunger Tobias]

On Mo, 2016-04-11 at 15:57 +0300, Nikos Chantziaras wrote:
> I have the issue of Creator using clang++ to build C++ sources, and GCC 
> to build C sources. I am trying to fix this, but for the life of me I 
> can't find a reference of Creator's variables anywhere.

I just added a button to list them all to the CMake Configuration dialog opened
by the kit options page.

> In the kit that uses Clang, Creator uses this in the "CMake 
> Configuration" field:
> 
>    CMAKE_CXX_COMPILER:STRING=%{Compiler:Executable}
> 
> That's nice. But CMAKE_C_COMPILER is not set, so I get a mixed Clang/GCC 
> build. %{Compiler:Executable} is obviously the C++ compiler. What is the 
> C compiler? What do I write here:
> 
>    CMAKE_C_COMPILER:STRING=%{???}

There is nothing:-/

Qt Creator has one compiler per kit and assumes that to be a C++ compiler. Until
we change that there is just no information on additional C compilers (or
whatever other language you want to use). Without that information there is
nothing that can be added to kits automatically.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft:
Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Generating QtCreator cmake project for given CMakeLists.txt from command line

[Hunger Tobias]

Hi Nikolaus,

On Thu, Mar 31, 2016 at 8:23 PM, Nikolaus Demmel  
wrote:
>> You actually should not even need to rerun cmake, provided you set up catkin 
>> to use the "-GCodeBlocks - Unix Makefiles" generator we need for Qt Creator.
>
> Is that enough? That sounds great. I thought that QtCreator might do some 
> more "magic".

We try very hard to not do any magic, especially not with the build systems! 
Ideally you should be able to open any project using one of the supported build 
systems without any changes and without any special configuration in Qt Creator.

That is one of the reasons why I sometimes joke that "Qt Creator is the best 
IDE for everybody that hates IDEs":-)

> This can be run easily for all packages with `catkin build --force-cmake 
> --cmake-args "-GCodeBlocks - Unix Makefiles"`.

In fact I did
catkin config -DCMAKE_BUILD_TYPE=Release "-GCodeBlocks - Unix Makefiles"

You need to experiment a bit to get the spaces quoted (who puts spaces into 
something that is supposed to be used as a command line argument?!).

> However I noticed that QtCreator currently reruns cmake in any case whenever 
> you open a project. I think this is fine, and that way the user doesn't even 
> have to remember to call `catkin build` with the `"-GCodeBlocks - Unix 
> Makefiles"` argument manually.

I do not know catkin well enough to comment whether or not that is viable.

Qt Creator will rerun cmake though, since it needs to make sure there is no 
stale data in the configuration it reads. Who knows what the user did to the 
project since cmake was last run?

>>> The step that is inconvenient, which I was asking about in this thread, is 
>>> the fact that for each ROS package, you have to manually select the correct 
>>> build directory and Kit when opening the project. Since there can be many 
>>> ROS packages in a workspace (>100), it gets cumbersome. That’s why I am 
>>> looking for a way to generate the project file (CMakeLists.txt.user) from 
>>> command line without user interaction. I want to be able to specify the 
>>> build directory(s), and also the configuration(s)/Kit(s). For the latter it 
>>> would be great if there was a “environment Kit”, which selects 
>>> compiler/qmake/cmake in the same way that cmake would on the command line 
>>> (in fact cmake has already been run from the initial `catkin build` call, 
>>> so QtCreator could just ask cmake what compiler it configured, which would 
>>> maybe be a sort of “cmake Kit”, where you let cmake run in the current 
>>> environment determine the compiler).
>>
>> My original idea was to use the default build directory setting 
>> (Tools>Options>Build & Run>General IIRC) and adapt that for catkin use. 
>> Opening the source directory should then automatically pick up the right 
>> build directory.
>
> Your idea is to determine if the opened CMakeLists.txt file corresponds to a 
> catkin package, and if yes, use some special logic to determine the correct 
> build directory? This could be the perfect solution, I like it.

Even simpler: My idea was to just configure the default build directory for all 
projects to point to wherever catkin will put its build directories. At this 
point I am mostly thinking about how you can configure Qt Creator to make 
things more convenient for you right now (or soon, since I assume you will be 
using Qt Creator 4.0 for the better cmake experience;-).



> This is only a rough sketch, but I think using catkin itself to find the 
> correct folders could be a robust solution. I can certainly help with 
> figuring out the details and edge cases, and also extending `catkin locate` 
> to provide all the informaton we need.

Sure, something like that would be best. But that of course requires somebody 
that knows those tools well to actually implement this:-)


>> For Qt Creator 4.1 I would like to have a "import existing build" 
>> functionality
>
> This sounds perfect. I think this could be the last piece of the puzzle to 
> achieve what I had originally intended. :)
>
> How would this work with configurations (Release / Debug / ...). At least 
> with the Makefile backend, a given build directory that you import would 
> correspond to exactly one configuration, namely the one that CMAKE_BUILD_TYPE 
> is set to. Would you then simply only offer this one configuration for that 
> project, or offer to create additional build directories for the other 
> configurations?

I want to generalize the code and reuse as much as possible from the qmake 
implementation. There we basically use the default build directory as 
configured by the user for the kits, go up one level and scan all the folders 
found in that directory. If a directory is found, then all the checkboxes for 
build configurations are unchecked, the existing directories are shown under 
the kit they use (with kits being set up for builds that do not match any 
existing kit) and all these directories are checked.

So all the 

Re: [Qt-creator] Generating QtCreator cmake project for given CMakeLists.txt from command line

[Hunger Tobias]

Hi Nikolaus,

On Thu, Mar 31, 2016 at 9:59 AM, Nikolaus Demmel  
wrote:
> Hi Tobias,
>
> thanks for trying it out.
>
> I think I made the wrong impression of what feature I am actually asking. It 
> should be much simpler. :-)

I agree, it should be simpler.

> The catkin_tools workflow is currently supported quite well with qtcreator, 
> given that catkin_tools creates more-or-less standard cmake build 
> directories, one for each ROS package. So go ahead in your new ROS workspace 
> after calling `catkin build`, open the CMakeLists.txt of one of the ROS 
> packages in QtCreator as a project, then select one configuration and point 
> the build directory to /build/. Now you can call make 
> from within QtCreator, rerun cmake, have code completion, click on warnings 
> to get to the source location, use the debugger, etc. That is all great.

You actually should not even need to rerun cmake, provided you set up catkin to 
use the "-GCodeBlocks - Unix Makefiles" generator we need for Qt Creator. 

> The step that is inconvenient, which I was asking about in this thread, is 
> the fact that for each ROS package, you have to manually select the correct 
> build directory and Kit when opening the project. Since there can be many ROS 
> packages in a workspace (>100), it gets cumbersome. That’s why I am looking 
> for a way to generate the project file (CMakeLists.txt.user) from command 
> line without user interaction. I want to be able to specify the build 
> directory(s), and also the configuration(s)/Kit(s). For the latter it would 
> be great if there was a “environment Kit”, which selects compiler/qmake/cmake 
> in the same way that cmake would on the command line (in fact cmake has 
> already been run from the initial `catkin build` call, so QtCreator could 
> just ask cmake what compiler it configured, which would maybe be a sort of 
> “cmake Kit”, where you let cmake run in the current environment determine the 
> compiler).

My original idea was to use the default build directory setting 
(Tools>Options>Build & Run>General IIRC) and adapt that for catkin use. Opening 
the source directory should then automatically pick up the right build 
directory. I am not sure this is an option anymore, considering that there are 
way more directories in $WS/build than there are in $WS/src. I need to check 
how that mapping from $WS/src/something/other/CMakeLists.txt to 
$WS/build/somedirectory works to check if that is an option. If"somedirectory" 
is just the CMake project name, then that should be easily doable already. 
Considering that such a simplistic mapping would fail in fun ways when you end 
up with two projects in $WS/src/* sharing the same project name (but in a 
different filesystem location), I do not think that is what catkin actually 
does:-)

You would still need to set up the kits yourself then (we need the information 
there for the code model).

For Qt Creator 4.1 I would like to have a "import existing build" functionality 
(as we have for qmake-based projects), which will pick a kit based on an 
existing build directory (and create a new kit if none matches). That requires 
quite a bit of refactoring of the qmake import functionality so that I can 
re-use (part of) the code from there. That is why this did not make the cut for 
Qt Creator 4.0: It was just too late to start a big refactoring when I got 
round to implement that.

> Of course one could also think about integrating catkin_tools itself better 
> into QtCreator (which is I think what you were talking about), but that is a 
> completely different story and to me catkin_tools is so great from the 
> command line, that I am happy continue using it there in conjunction with 
> editing code in an IDE.

Oh, OK:-)

Best Regards,
Tobias

--
Tobias Hunger, Senior Software Engineer | The Qt Company

The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der 
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] CMake in QtC 4.0 [ex Qt Creator 4.0 soft-branched]

[Hunger Tobias]

Hi Alexander,

On Mo, 2016-03-07 at 23:44 +1000, Alexander Drozdov wrote:
> 2016-02-29 19:31 GMT+10:00 Hunger Tobias <tobias.hun...@theqtcompany.com>:
> Hi Tobias, sorry for delay

No worry:-)

> >  Currently I
> > > see, that two of the four features that I support at the
> > > CMakeProjectManager2 (fork on github) already implemented:
> > > 1) Handling Kit compiler. But only C++, not C or other. But it simple
> > > configurable at the Kit configuration page now.
> > QtCreator does only know one toolchain for each Kit and assumes that to be
> > a C++
> > one. So there simply is not enough information to set up the C compiler
> > with the
> > information available. We will need to manage toolchains and programming
> > languages they support for that and I currently have no plans to go that
> > far,
> > even though that information is also useful for other build systems.
> > 
> > You can add any cmake settings you need to the Kit's cmake configuration
> > though
> > and those settings will then be applied automatically everywhere that kit
> > is
> > used.
> > 
> I know and understand. In my solution I simple predict C compiler based on
> some info: g++ -> gcc, clang++ -> clang, cl.exe -> cl.exe :-) with same
> prefixes and suffixes
> Look (core removed after dialog reworks):
> https://github.com/h4tr3d/cmakeprojectmanager2/commit/268b1cb93ea3fb40c7bdcaea
> d51452c764dc95bb#diff-8809e7f792412acf4605265b6ad2c20fR790

I would prefer to keep this as is: It is pretty straight forward for the users
(or an admin/packager) to provide custom cmake config flags to be set by a kit.
So this problem can be addressed at that level (till Qt Creator starts to manage
several toolchains per kit at some point -- if we ever go there).



> No. Toolchain file in simple way look like settings. But in some complex
> cases it can call CMake functions, search complilers via find_program() and
> so so.
> 
> To somplify: Toolchain file is a file that preloaded by the cmake before
> CMakeLists.txt.

I would argue that they still are just a bunch of settings... at least after
they are executed. Since kits are host specific, I still think we can get away
with the current approach: Just put whatever concrete information you need into
the Kit's settings and you are done. Yes, that fails to detect compilers and
stuff for you, but you know where those are anyway.

> If that is the case: Can the CMake Configuration in the Kits cover that?
> 
> Not in all cases. Also, in some cases you can want simple builds current
> project with current Kit but with suggested Toolchain. Toolchain can be
> specific for single project. Create Kits for every toolchains not a good
> idea. IMHO.

IMHO it is:-) How else would you switch between different configurations easily?

> Maybe we could add an "import from toolchain file" to the CMake
> > 
> > Configuration dialog?
> > 
> Not a good idea. See above.

OK.

> 2) Adding files via context menu and show all files in source Tree: it
> > > allows to add new file to the target directory, see it and after simple
> > add
> > > 
> > > to the needed target at the CMakeLists.txt
> > The only chance I ever see that happening is for cmake-daemon (
> > https://steveire
> > .wordpress.com/2016/01/24/cmake-daemon-for-user-tools/ ) to get accepted
> > upstream.
> > 
> I understand. I try to parse cmake (adopt tokenizer to build with plugin)
> but it to complex to process CMakeLists.txt and in sub-CMakeLists.txt.

I am not brave enough to go there:-)

> So currently I use next scenario:
> 1. For code module I use files provided by the CbpParser
> 2. For source tree I display all files. Yes, it displayes files like
> README, LICENSE and some sources that skipped from the compilation (and
> from the Model). But it simplify navigation and adding/removing/renaming

I have been thinking on doing that, too. I hate the idea of just scanning the
file system, but I think it is the best that cmake will let us do.

> 3. Enable items Add/Rename/Remove file

I don't plan on that yet.

> 4. In handlers of the given signals I ask BuildDirManager to do
> forceReparse()
>
> This scenarion works very well for FILE GLOBBING and AUX SOURCE DIR. And
> yes, this scenarion requires addition CMake execution when files described
> in CMakeLists.txt without globbing.

Yes, I see that it will work there. But that is not good enough for me, simply
because I will get tons of bug reports about "Add file" not working from lots of
people that do not use such a setup. There are just too many cmake users out
there for me to risk that:-)

> And yes, this algorithm requires additional work:
>

Re: [Qt-creator] [Dev] Qt Creator 4.0 soft-branched

[Hunger Tobias]

Hi Alexander,

On Mo, 2016-02-29 at 18:44 +1000, Alexander Drozdov wrote:
> Improved CMake support? What about scope of this improvements?

4.0 will mostly have workflow improvements for CMake.

There have been no improvements to the parser, etc. that extracts data from
CMake for our code model. Some bugs got fixed along the way. E.g. syntax
highlighting should work a bit better, but nothing major.

>  Currently I
> see, that two of the four features that I support at the
> CMakeProjectManager2 (fork on github) already implemented:
> 1) Handling Kit compiler. But only C++, not C or other. But it simple
> configurable at the Kit configuration page now.

QtCreator does only know one toolchain for each Kit and assumes that to be a C++
one. So there simply is not enough information to set up the C compiler with the
information available. We will need to manage toolchains and programming
languages they support for that and I currently have no plans to go that far,
even though that information is also useful for other build systems.

You can add any cmake settings you need to the Kit's cmake configuration though
and those settings will then be applied automatically everywhere that kit is
used.

> 2) Pointing Build Type to the CMake

That was in 3.6 already if I remember correctly:-)

> Next features I need, but it will be nevenr implement:
> 1) Good management for the CMake toolchain files. Upstream changes so
> fundamental, but I already port this changes to the new codebase. But
> pointing compiler via CMAKE_CXX_COMPILER, not via CXX/CC evn variables
> breaks toolchain files. I solve it via forgoting Kit configuration in case,
> when user select Toolchain file.

I have never used those myself: What exactly do those do? As I understood it,
they are just a bunch of settings that are fed to cmake to pre-fill its cash. Is
that correct?

If that is the case: Can the CMake Configuration in the Kits cover that? Maybe
we could add an "import from toolchain file" to the CMake Configuration dialog?

> 2) Adding files via context menu and show all files in source Tree: it
> allows to add new file to the target directory, see it and after simple add
> to the needed target at the CMakeLists.txt

The only chance I ever see that happening is for cmake-daemon ( https://steveire
.wordpress.com/2016/01/24/cmake-daemon-for-user-tools/ ) to get accepted
upstream.

> New changes, that likes me:
> 1) Integrated CMake dialog to the Project page and transparency CMake
> running.
> 2) Table editor for the CMake options. Small qestion according this
> improvement: will be added some set of known options and ability to select
> it via integrated combo box? will be editor delegates according to the
> option type added, like: if option type is a PATH use File Open dialog?

The editor already uses the type hints to some extend: The bool ones are
tickboxes that tackles between "ON" and "OFF".

A combobox to select between a set of different options is not going to happen,
simply because cmake has no way (that I found) to tell Qt Creator about the
allowed values. Using path-chooser to pick a path/directory is definitely an
option though.

> So, roadmap for the CMake Project Manager plugin is interesting.

My roadmap is simple: Make what is there stable for 4.0.

Next step is to help to polish cmake-daemon up to a state where it can be pushed
for review to the cmake project and use that when/if it makes it upstream. That
changeset is a game-changer (not just for Qt Creator!), but unfortunately my
impression is that the interest from the cmake side is low to non-existent.

Any help with cmake-daemon would be greatly appreciated by Steven, any help with
the cmake plugin is greatly appreciated by me:-)

Finally, please test the 4.0 branch and report bugs, especially if you use CMake
a lot.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft:
Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Problems with wizard.json regarding resolution of variables

[Hunger Tobias]

On Do, 2016-02-25 at 10:05 +0100, Stefan wrote:
> What is the difference in using wizard.json resp. wizard.xml?

A lot:-)

There is e.g. no %ProjectName% in wizard.xml, while there is %{ProjectName} in
wizard.json. But you are using that, so that is probably not what is biting you.

>  What am I doing wrong?

What does not work for you? I could not figure that out based on your mail,
sorry.

To debug wizards I recommend to set a keyboard shortcut (in
Tools>Options>Environment>Keyboard) to the Wizard.Inspect action.

You can then trigger the wizard you are curious about and trigger the
Wizard.Inspect action at any time the (JSON) wizard is running. That will get
you a page with all the variables the wizard knows at that point in time.

I found the Inspector a great help to debug problems with my wizards.

Best Regards,
Tobias


-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft:
Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] [cmake-developers] CMake daemon for user tools

[Hunger Tobias]

Hi Stephen, Hello Millian and the others,

On Do, 2016-02-18 at 00:37 +0100, Milian Wolff wrote:
> Considering the three of us (Tobias, you and me) are in Berlin, I'd say we at 
> least meet for a hackday or so. What do you say? That would get me at least
> to 
> work 8h on this for a full day and see how it integrates with KDevelop and we 
> could discuss things in-person. Still, I'm aware that I'll have to play
> around 
> with it before already to not waste too much of your time.

I am not sure how many people you would expect for a hackathon on a not-yet-
production-ready product that is heavily focused on IDE developers:-)

Anyway, I will be there:-)

Three people (Stephen, Millian and me) are pretty much commited to showing up. I
Dominik and Aleix from kate/kdevelop are pretty interested in this topic, based
on their mails to this thread. Clion and CDT devs are probably also going to be
interested, but I do not know those in person yet, so I am not sure there.

That already sounds like a fun crowd to spend a weekend or so coding with -- or
just to go out for a drink to discuss how to proceed from here.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft:
Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Configuring QtCreator for android

[Hunger Tobias]

On So, 2016-01-17 at 11:04 +0530, RISHABH GUPTA wrote:
> Hey,
> 
> I am trying to build a cmake based project for android but on clicking 'run
> cmake ' I get "no generator selected" and there are no generators listed in
> the generator option .Could anyone please help me out with this ?
> 
> I am on kubuntu 15.10 and I am using qtcreator 3.5.1 ,qt-version 5.5.1

Ho,

CMake is currently supported for desktop development only: Qt Creator needs the
"Codeblocks *" generators and there is none available for android.

AFAIK we only support qmake and qbs for android.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft:
Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Cannot display QML inside creator, works just fine outside it

[Hunger Tobias]

On Do, 2016-02-11 at 23:13 +0200, Nikos Chantziaras wrote:
> When I run an application that displays a QQuickWidget outside of 
> Creator, everything is fine. However, when running it in Creator (with 
> or without debugger), the application freezes at the moment the 
> QQuickWidget is used, and I get this error in "Application Output":
> 
>    Unrecognized OpenGL version
>    Unrecognized OpenGL version
> 
> What is wrong here?
> 
> I'm on Linux 64-bit, with Qt Creator 3.6.0.

Hello Nikos,

I had a similar problem before: Apparently some Linux graphics drivers lock up
when two applications try to use GL at the same time:-/

Your QML-using application is one program, and Qt Creator requires GL for the
QMLProfiler/QMLDesigner and the Welcome plugin. The first two are only loaded on
demand, but the Welcome page is shown directly. To prevent that, you can try to
start Qt Creator with "-noload Welcome" options.

If your application starts then without freezing Qt Creator, then you can try to
experiment with your graphics drivers.

You should get the same freezes by starting any two openGL applications at the
same time (e.g. two instances of GLXgears).

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft:
Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Creator gets confused when switching kits

[Hunger Tobias]

On Do, 2016-02-04 at 22:30 +0100, Jason H wrote:
> When I switch, the run/build/debug buttons go grey. Then I get the build icon
> back. It hit it and it says:
> 16:29:41: Configuration unchanged, skipping qmake step.
> 16:29:41: Starting: "/usr/bin/make" -j 8
> make: Nothing to be done for `first'.
> 16:29:42: The process "/usr/bin/make" exited normally.
> 16:29:42: Elapsed time: 00:00.
> 
> But the run/debug buttons never get enabled again. 
> 
> I switch kits a lot.

Hi Jason,

could you please file a bug report about issues like this? They do get lost on
the mailing list as soon as enough mails arrive to push this one down, but the
bug tracker never forgets;-)

Please provide as many details as possible in a bug report. Which OS are you
using, which buildsystem (qmake -- in this case that is very obvious;-), any
hint on how to trigger the issue reliably? Does "Run qmake" from the menu fix
the greyed-out buttons? What do you do to continue (restart Qt Creator,
close/open the project)? 

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft:
Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] License update! Please check license template!

[Hunger Tobias]

Hello Konstantin,

On Sa, 2016-01-16 at 18:15 +0300, Konstantin Tokarev wrote:
> E.g. look at Eclipse RCP which became a foundation for lots of open-source and
> commercial products.

I think the two GPL exceptions provided in the LICENSE.GPL3-EXCEPT file leave
room for both free software plugins as well as commercial ones.

But then please consult a lawyer and do not rely on my interpretation of *any*
legal text:-) I am not a lawyer and I tend to miss finer points of legal
documents.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft:
Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] License update! Please check license template!

[Hunger Tobias]

Hi Peter,

I was not involved in the agreement between the Free Qt Foundation and the Qt 
Company, so I can not comment in any meaningful way, sorry. Neither have I 
insight in our sales numbers, so I can not comment on the effect of GPL or LGPL 
on actual sales figures either.

Please consider to comment on the blog post announcing the change: You are more 
likely to contact people driving this change there. This is basically just our 
out-of-the-way technical mailing list.

I *personally* welcome the outcome very much: We get to provide more free 
software and I agree with the idea of software freedom as expressed by the GPL. 
It also makes my work-live much easier as I will have less repositories to 
juggle once the code moved into the public repository.

Best Regards,
Tobias

Tobias Hunger, Senior Software Engineer | The Qt Company

The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der 
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

[Qt-creator] License update! Please check license template!

[Hunger Tobias]

Hello everybody,



TL;DR: Please update your license template before adding files to master branch!



I just finished a patch set that updates the license information in Qt Creator
according to the announcement made this week:

http://blog.qt.io/blog/2016/01/13/new-agreement-with-the-kde-free-qt-foundation/

In essence Qt Creator will be GPL (with exception) from here on out. This
effects the master branch of the Qt Creator repository. The stable branches are
not going to get updated to the new licensing scheme.

Please take a bit of time and check whether the patches change the copyright in
unintended ways, especially if you have contributed code to Qt Creator. I think
I managed to keep all information in the headers intact, but please help to make
sure. Checking and double-checking all this information is tedious work and I
might have done some unintended changes.

Please also check your license template: Please use the one we ship with Qt
Creator in dist/copyright_template.txt (after adapting the copyright information
of course)! This file is already updated in git (master branch).

The first patch of the set is here:
https://codereview.qt-project.org/#/c/146218/

Please help reviewing the patches!


The commercial plugins that are effected by the agreement are currently getting
a similar license update and will get merged into the master branch once that is
complete.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft:
Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Dev: Qt Creator 3.7 schedule

[Hunger Tobias]

On Fr, 2016-01-08 at 15:23 +0100, Jason H wrote:
> 
> > Sent: Thursday, January 07, 2016 at 7:53 AM
> > From: "Ziller Eike" 
> > To: "qt-creator@qt-project.org" 
> > Subject: [Qt-creator] Dev: Qt Creator 3.7 schedule
> > 
> > I just updated https://wiki.qt.io/Qt_Creator_Releases
> > 
> > The tentative dates for Qt Creator 3.7 are:
> > 
> > * Feature freeze w10 (~Mar 1 2016)
> > * Beta release w12 (~Mar 15 2016)
> > * String freeze w14 (~Mar 29 2016)
> > * Release candidate w16 (~Apr 12 2016)
> > * Final release w18 (~Apr 26 2016)
> 
> Is there a page that mentions what will be in it? (Subject to change until FF)

Hello Jason,

Not really. The contents entirely depends on what will be polished enough in
time for feature freeze.

Any ongoing work is discussed here or visible over at 
codereview.qt-project.org, 
so those are the best places to keep up to date with what is going on.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft:
Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Use #pragma once as default instead of header guards

[Hunger Tobias]

On Mi, 2016-01-13 at 12:15 +, Bubke Marco wrote:
> We support it but it will be slow. It is your decision. Anyway how often do
> you need code completion in the header file. 

I agree with Christian that we should not change the coding standard to work
around problems in the code model.

> Maybe we can fix it in the future but it depends on Clang.

Good.

> Anyway I don't want to force you to anything. It was about the future. So
> #pragma once would be allowed for the people who want to use it.

No. A coding standard is supposed to help developers work with code in their
project that they are not familiar with by writing down a basic set of rules
that provide a base-line of consistency. This is only possible when everybody
follows the same set of rules. That is why we need a broad consensus on coding
style rules, with "do whatever you want" being an option only for rules that the
community is split on.

I do not think #pragma once is such an item:

 * According to Marco #pragma once is supported by all compilers we support with
Qt Creator.

 * It is less to type

 * It removes the need to come up with a long name that is unique in the project

 * It prevents unexpected results when that name is not as unique as you thought

 * It prevents unexpected results when you mistype that long name once in the
#define or #ifndef lines.

So I am in favor changing the coding style to ask developers to use #pragma once
in all new headers.

I think it will most likely even make sense to update existing headers in one
patch and be done with this change.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft:
Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] CMake daemon for user tools

[Hunger Tobias]

On Di, 2016-01-12 at 13:21 +0100, Mathias Hasselmann wrote:
> So whatever is done to IDE integration, ease of project file 
> manipulation should be considered as a high priority target. For that 
> low level goal of showing build artefacts parsing plain Makefile (or 
> Ninja files) imports would be sufficient.

I agree, that adding/removing files should be possible and is extremely
valuable. But I would love to get some help from cmake to reliably parse the
project information first. That is the low-hanging fruit.

Being able to add/remove files from CMake files is not going to be easy. I would
expect quite a few problems implementing that, so I would love to see the low-
hanging fruits picked before venturing there.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft:
Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] CMake daemon for user tools

[Hunger Tobias]

Hi Stephen,

I registered for the Berlin Meetup already and am looking forward to get an
update on your progress on the cmake front:-)

On So, 2016-01-10 at 12:10 +0100, Stephen Kelly wrote:

> This design is independent of any generator, and compared to the solution of
> writing json to a file, this solution doesn't require generating
> anything that is
> not asked for.

Having a file with the important data would have been nice -- at least as an
intermediary step:-)



> I am scheduled to give a talk at FOSDEM about the feature and how user
> tools can interact with it:
> 
>  https://fosdem.org/2016/schedule/event/enabling_gui_tools_for_cmake_code

Are you aware whether there will there be a recording of the presentation?
Please keep us updated with a link if there is:-)

> with a preview in Berlin:
> 
>  http://www.meetup.com/berlincplusplus/events/227896427/

I'll be there.



> However, I can't complete those tasks myself: I don't have
> relevant experience building IDEs to know how best to design the
> protocol, what IDE tools really need, how to design a fail-safe parser
> etc.  Additionally, I think a design which incorporates design ideas
> and implementation from more than one person will be better in the end.

About the protocol: Just use something existing? GDB has something, or maybe
just expect/return JSON or XML? Web services seem to work well with such an
approach:-)



I'll take a look at the repo.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft:
Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] 'Open Terminal Here' and login shell on Linux

[Hunger Tobias]

On Di, 2015-12-08 at 10:39 +0100, Andrzej Telszewski wrote:
> Hi,
> 
> When right-clicking on a file in the project's tree there is an option 
> to 'Open Terminal Here'.
> 
> If I understand correctly, the way the terminal is opened is the following:
> 1. Change to the directory where the file resides.

Yeap.

> 2. Execute "Tools -> Options -> Environment -> General -> Terminal" with 
> the shell executable path appended. In my case it's /bin/bash but I 
> guess Qt Creator actually takes /bin/sh or reads it from /etc/passwd or 
> something like that.

The shell is actually taken from the SHELL environment variable.

> My problem is that the shell isn't started as login shell and so the 
> .profile is not read and I would really like it to do so :)
> 
> Can I change it somehow?

Only by changing the code:-) Or by playing clever tricks with the terminal
arguments, but I doubt that will work as expected.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer | The Qt Company
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der Gesellschaft:
Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Providing a custom Kit in my own plugin

[Hunger Tobias]

Hi Olivier,

On Sun, Oct 18, 2015 at 6:30 PM, Olivier Renaud  wrote:
> What do you mean by "making sure not to introduce a regression for the C/C++
> toolchains"? I interpret it as "things could blow up if user choose a Rust
> compiler for a C++ project", but I'm not sure that's what you had in mind.

When we add new toolchains for languages other than C++, then we should make 
that explicit by e.g. adding a tag for the language the tool chain supports. We 
would also need to select the correct language with the ToolChainKitInformation.

When we do that, then we need to make sure not to break existing code. That 
implicitly assumes all toolchains to be for C++ after all. Changing assumptions 
like that tends to introduce regressions, so we need to make sure we have 
enough time to iron out those after introducing such a change.

That is all I wanted to say.

Best Regards,
Tobias

--
Tobias Hunger, Senior Software Engineer | The Qt Company
 
The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der 
Gesellschaft:  Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 
B 
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Providing a custom Kit in my own plugin

[Hunger Tobias]

Hallo Olivier,

that would be the first compiled language other than C/C++:-) As you noticed 
there is little infrastructure in place for such a case yet.

The ToolChain is implicitly a C++ toolchain. That would need some extending to 
make that work well with rust. Maybe add a flag for the language to the 
toolchain, if all of its interfaces makes sense in the rust use case? That 
would then require a bit of work to make the UI useful with more than one 
language, but that should be manageable.

Kits are just a grab-bag of settings, so it should not be a problem to add any 
information you want to them. They will become bigger as all kits have the same 
settings, but it is perfectly ok to have some kits with unset values. Adding 
toolchains for different languages is no problem at all from the kits 
perspective, but making sure not to introduce a regression for the C/C++ 
toolchains is probably a challenge;-).

We already have more than one build system in the kits: qmake and cmake. I do 
not see a problem adding another one. At some point we will need to think about 
something to provide filtered views on the kits (e.g. to only show settings 
relevant to cmake based projects or to rust projects or qmake projects or 
whatever), but that is a different issue.

Best Regards,
Tobias

Tobias Hunger, Senior Software Engineer | The Qt Company

The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der 
Gesellschaft:  Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 
B 
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] [OS X]: QFileSystemWatcher "using only polling engine"

[Hunger Tobias]

Hello,

please file bug reports when you run into issues over at 
https://bugreports.qt.io/.

Reports via mail or IRC tend to get lost once they are read on scroll off the 
screen. Bug tracker entries stay around for ever;-)

Best Regards,
Tobias

Tobias Hunger, Senior Software Engineer | The Qt Company

The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der 
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B


From: qt-creator-bounces+tobias.hunger=theqtcompany@qt-project.org 
 on behalf of 
René J.V. Bertin 
Sent: Wednesday, September 23, 2015 16:21
To: qt-creator@qt-project.org
Subject: [Qt-creator] [OS X]: QFileSystemWatcher "using only polling engine"

Hi,

When I launch Creator (v3.5.0-560-ge5f3c55) from a commandline I see the 
following warning messages:

%> "/Applications/MacPorts/Qt5/Qt Creator.app/Contents/MacOS/Qt Creator" 
/opt/local/site-ports/devel/qt5-creator/files/patch-show-menubar-with-xcb.diff
QFileSystemWatcher: skipping native engine, using only polling engine
SOFT ASSERT: "dir.startsWith(topLevel + QLatin1Char('/')) || topLevel == dir || 
topLevel.isEmpty()" in file .../vcsmanager.cpp, line 144
SOFT ASSERT: "dir.startsWith(topLevel + QLatin1Char('/')) || topLevel == dir || 
topLevel.isEmpty()" in file .../vcsmanager.cpp, line 144
SOFT ASSERT: "dir.startsWith(topLevel + QLatin1Char('/')) || topLevel == dir || 
topLevel.isEmpty()" in file .../vcsmanager.cpp, line 144
SOFT ASSERT: "dir.startsWith(topLevel + QLatin1Char('/')) || topLevel == dir || 
topLevel.isEmpty()" in file .../vcsmanager.cpp, line 144

(the message also appears as soon as I open a file after starting Creator 
without a file argument).

Using launch services these messages don't appear (in the System.log).

In addition, when one launches Creator through a symlink pointing to the bundle 
executable, the running application shows the generic "unix tool" icon in the 
Dock and app switcher. I haven't noticed this with earlier versions (nor in 
other Qt-based applications), and it may be related to why QFileSystemWatcher 
prints a warning.

BR,
R.
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] MSVC-bundled SDKs are missed by the toolchain detection (this breaks XP targeting)

[Hunger Tobias]

Hi Kuba,

I probably know that code well enough to review it, so please feel free to add 
me as a reviewer. Please also add Friedemann as he knows our windows support 
best.

Best Regards,
Tobias

Tobias Hunger, Senior Software Engineer | The Qt Company

The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der 
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Form Templates are compiled into Qt Creator ?

[Hunger Tobias]

Hi Jonas,

I have been reworking quite a few of our wizards since Qt Creator 3.4, so I 
guess I killed the wizard that actually used those templates but forgot to 
remove the templates themselves. I'll fix that.

The Qt Designer Form Class is still a old-style wizard that has basically 
everything hard-coded in formclasswizard.cpp and related classes.

That wizard should also use new json wizard syntax eventually, but there are a 
few things in it that are unique and not yet possible in the json wizards, but 
I am not sure it is worth the trouble of enableing the form handling code that 
is used in that code in the json wizard. Why generalize something that is used 
exactly once?

Best Regards,
Tobias

Tobias Hunger, Senior Software Engineer | The Qt Company

The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der 
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B


From: qt-creator-bounces+tobias.hunger=theqtcompany@qt-project.org 
qt-creator-bounces+tobias.hunger=theqtcompany@qt-project.org on behalf of 
Jonas Eriksen Hjortlund j...@pedax.com
Sent: Monday, August 24, 2015 09:41
To: 'qt-creator@qt-project.org'
Subject: [Qt-creator] Form Templates are compiled into Qt Creator ?

Hi

Win 7 (64bit), Qt 5.5. mingw, Qt Creator 3.4.2

The Dialog Templates shown
when Pressing File-New -Qt -Qt Designer Form Class
Like
Dialog_with_Buttons_Right

Those files seems to live in
Qt\Tools\QtCreator\share\qtcreator\designer\templates and
Enumerated in templates.xml

But even if I delete the whole folder, it is still shown in Creator ?!
and that seems to explain why adding a new one is 100% ignored and never listed.

So my questions are:
Can I add a new Form Template somehow ?

Are the external files something that was never fully implemented  or why does 
it include them
When it seems that Creator never loads them.

Thank you
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Question about QtCreator licensing

[Hunger Tobias]

Hi Jochen,

I am not a lawyer, but as I understand it the CLA grants us the privilege to 
relicense the code in Qt and Qt Creator (you keep the copyright of course as I 
read the text). So the Qt Company can actually do that, which in turn would 
mean the text is ok as I understand it.

But again, I am not a lawyer, I mostly just use whichever template I am asked 
to put into the code by people that actually know copyright law:-)

Best Regards,
Tobias

Tobias Hunger, Senior Software Engineer | The Qt Company

The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der 
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Which plugins are you working on?

[Hunger Tobias]

On 22 May 2015 at 22:45, Hunger Tobias tobias.hun...@theqtcompany.com wrote:
 Boost.Build Project Manager
 https://github.com/mloskot/qt-creator-plugin-boostbuild
 which is currently being prepared for submission to Qt Creator
 See announcement sent to the ML
 http://lists.qt-project.org/pipermail/qt-creator/2015-February/004436.html

Looking forward to seeing that!

 What can we do to make things easier for you?

 Help guiding through the review process, review the work we have
 already submitted
 to wip/boostbuildprojectmanager branch in Gerrit
 https://codereview.qt-project.org/#/c/111798/

My experience is that the review process is a huge help. Please give it a 
chance:-)

 Have you ever considered to contribute your plugins?

 Initially, I did not consider at all, until contributors/users asked for that.

Why not? It does save you some time as we tend to fix in-tree plugins when
refactoring (well, we at least keep them compiling;-).

 What is keeping you from doing so?

 Lack of resources to maintain it, as I explained in the README

Having the plugin upstream should save a few resources:-)

 https://github.com/mloskot/qt-creator-plugin-boostbuild/blob/master/README.md
 Then, I had number of doubts if I really want to go through the Gerrit
 nightmare,
 yes I still believe it's ridiculous to ask people to read the whole
 bible of Gerrit
 setup and intro, just to submit a patch.

I agree.

I recently started to work on our checkout wizards with the goal to be able to 
offer a Qt Creator wizard that does the setup for you. Not all stones are in 
place for that yet, but we will get there.

 Regardless, I'm giving it a shot, perhaps it will work.

Good luck with your plugin (intree or out-of-tree:-).

Best Regards,
Tobias

--
Tobias Hunger, Senior Software Engineer | The Qt Company

The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der 
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

[Qt-creator] Which plugins are you working on?

[Hunger Tobias]

Hi Mailing list!

In the NimPlugin thread there were some people implying that they are working 
on custom Qt Creator plugins. I do know about some of those, but I would be 
really curious as to what else is out there:-)

So I would like to ask: What kind of plugins do you work on?

What can we do to make things easier for you? Yes, a build service would be 
nice, but from my perspective I do not see that happening anytime soon:-/ Sorry 
about that.

Have you ever considered to contribute your plugins? What is keeping you from 
doing so?

Best Regards,
Tobias

PS: Please feel free to reply in private. I understand that some of you are not 
able to discuss their work in public, but I am still awfully curious about the 
cool stuff that you people are doing with Qt Creator and the extensions you 
wrote for it :-)

--
Tobias Hunger, Senior Software Engineer | The Qt Company

The Qt Company GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja Sitz der 
Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Warning during subproject add (my format of projects)

[Hunger Tobias]

Hi Andrey,

I created https://bugreports.qt.io/browse/QTCREATORBUG-14294 for that and will 
probably fix it next week.

The warning is indeed wrong for your use-case and I will need to figure out 
that the wizard is creating a subproject to fix that. The code should already 
be around somewhere, so it should not be too hard.

Thanks for reporting this, but please consider to use the bug tracker the next 
time you run into something. A mailing list will scroll by and mails vanish 
from view (and mind), bugs stay forever;-)

Best Regards,
Tobias

Tobias Hunger, Senior Software Engineer - Digia, Qt
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin. USt-IdNr: DE 286 306 868
Registergericht: Amtsgericht Charlottenburg, HRB 144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] How to add plugins in Qt Creator (3.3.2) with Qt 5.4? Where are the documentations?

[Hunger Tobias]

Hello Young,

sorry, you did not specify a license for the code you attached, so I will not 
read it. Who knows what kind of legal trouble that could get me into:-)

Anyway, I would recommend trying to do as much as you can in your own 
plugin(s). That reduces your dependency on our APIs. I would also recommend to 
just disable plugins you do not need completely in favor of removing code from 
plugins: That will be really hard to maintain as new versions of creator get 
released.​

I am currently kind of working on a patch set that allows for scripts to be run 
as part of a JSON wizard, so that might be something that would be interesting 
for you to run your python code. No ETA for that yet though, as I got heavily 
side-tracked into cleaning up usage of VcsCommands in Qt Creator. A necessary 
step to be able to eventually merge those custom script infrastructure (the 
current version of the patch produces all kinds of side effects on the Vcs 
systems we support:-).

Apart from that: The only advice I can give is to have fun and to 
communicate:-) If there is some functionality available inside some plugin that 
you would like to use but that is inaccessible from your plugin, feel free to 
send in a patch to change that. Our policy is to keep as much private as we can 
and only export symbols that somebody actually needs and asks for:-)

Best Regards,
Tobias
 
Tobias Hunger, Senior Software Engineer - Digia, Qt
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin. USt-IdNr: DE 286 306 868
Registergericht: Amtsgericht Charlottenburg, HRB 144331 B  

From: Yang.H hyll1...@gmail.com
Sent: Monday, April 13, 2015 15:46
To: Hunger Tobias
Cc: qt-creator@qt-project.org
Subject: Re: [Qt-creator] How to add plugins in Qt Creator (3.3.2) with Qt 5.4? 
Where are the documentations?
  

Hi Hunger,


Thank you for your detailed reply.


I'm working on a project called GRT. It's a reconfigurable system for wireless 
network. In this system you can change the MAC and PHY layers in the network's 
OSI model by re-programming FPGAs. 


My job is to develop an IDE for this system to help user generate Verilog 
code(Hardware Define Language) templates more easily and finish modifing 
modules in MAC and PHY layers more easily. Perhaps I need to add some debug 
info console windows and different  views in it. I also want to read the Qt 
Creator code and delete the functions which I don't need. 


Because there's only me in this task, I decide to tailor Qt Creator to finish 
this job which makes it easier.


There is another person in this project, she wrote a python code which can 
explain the given xml code to a verilog code template. So now I want to 
generate xml code using a wizard.


I attached my code in the attachments. This code is not based on Qt Creator, 
but it can reflect what I want to do. You can compile it if you have time.


Because I am a beginner in Qt, this program I send to you is barely a 
thing...please give me some coding advice if you have time.


You can have a new module and you can read a xml file and parse it to a wizard.


Best,


Young. 


On Mon, Apr 13, 2015 at 6:22 PM, Hunger Tobias  
tobias.hun...@theqtcompany.com wrote:
 Hi Yang.H,

yes, filewizarddialog.h is no more, I removed that a while back. In fact I want 
to trim down further on the number of different wizard-related classes we have. 
Apparently I missed some references to the now gone classes in the 
documentation. Sorry for that,  I'll put updating that onto my todo list. Feel 
free to report this as a bug on  https://bugreports.qt.io/ and assign it over 
to me if you want to follow the progress on the task.

There is documentation on the JsonWizard available here:

http://doc.qt.io/qtcreator/creator-project-wizards-json.html

Those are what I want to use to replace much of the custom wizard-code we have.

Qt Creator is constantly changing. We have quite a few people working on it and 
we do not promise stable interfaces between minor version upgrades. 
Documentation on APIs does get out of date, even though we try to fix the 
documentation along with the code.  I personally find just looking at how other 
parts of Qt Creator implement something the best way to get started with any 
task I did not attempt before. The code is always current after all:-) It is 
hard to recommend anything more specific than this based on  the little 
information I could extract from your mail.

What do you want your wizard to do?

Please also feel free to ask specific questions here or on IRC (freenode 
network, #qt-creator), when (not if;-) you run into things you can not figure 
out. European business hours work best on IRC.

Hope this helps:-)

Best Regards,
Tobias

Tobias Hunger, Senior Software Engineer - Digia, Qt
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin

Re: [Qt-creator] How to add plugins in Qt Creator (3.3.2) with Qt 5.4? Where are the documentations?

[Hunger Tobias]

Hi Yang.H,

yes, filewizarddialog.h is no more, I removed that a while back. In fact I want 
to trim down further on the number of different wizard-related classes we have. 
Apparently I missed some references to the now gone classes in the 
documentation. Sorry for that, I'll put updating that onto my todo list. Feel 
free to report this as a bug on https://bugreports.qt.io/ and assign it over to 
me if you want to follow the progress on the task.

There is documentation on the JsonWizard available here:

http://doc.qt.io/qtcreator/creator-project-wizards-json.html

Those are what I want to use to replace much of the custom wizard-code we have.

Qt Creator is constantly changing. We have quite a few people working on it and 
we do not promise stable interfaces between minor version upgrades. 
Documentation on APIs does get out of date, even though we try to fix the 
documentation along with the code. I personally find just looking at how other 
parts of Qt Creator implement something the best way to get started with any 
task I did not attempt before. The code is always current after all:-) It is 
hard to recommend anything more specific than this based on the little 
information I could extract from your mail.

What do you want your wizard to do?

Please also feel free to ask specific questions here or on IRC (freenode 
network, #qt-creator), when (not if;-) you run into things you can not figure 
out. European business hours work best on IRC.

Hope this helps:-)

Best Regards,
Tobias
 
Tobias Hunger, Senior Software Engineer - Digia, Qt
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin. USt-IdNr: DE 286 306 868
Registergericht: Amtsgericht Charlottenburg, HRB 144331 B  
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] QtCreator project contribution - how to start?

[Hunger Tobias]

Hallo Jakub,

welcome aboard:-) Is there anything in particular you want to look into?

To get started, just grab the code from 
http://code.qt.io/cgit/qt-creator/qt-creator.git/ and dig in:-)

When you have questions, then feel free to ask here or on IRC (freenode.net, 
#qt-creator channel). Using git blame filename and asking the people that 
show up for that file a lot helps.

Once you have something you want to contribute I can help with setting up 
codereview.qt-project.org as a git remote, so that you can push your changes 
there directly with one git command.

Best Regards,
Tobias

 
Tobias Hunger, Senior Software Engineer - Digia, Qt
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin. USt-IdNr: DE 286 306 868
Registergericht: Amtsgericht Charlottenburg, HRB 144331 B  
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] extracting path/filename from selected file in navigationwidget(Project)

[Hunger Tobias]

Hi Daniel,

you tend to know the project-related sidebar widgets very well, can you help 
Hermann?

Best Regards,
Tobias
 
Tobias Hunger, Senior Software Engineer - Digia, Qt
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin. USt-IdNr: DE 286 306 868
Registergericht: Amtsgericht Charlottenburg, HRB 144331 B  
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] tab area for open files

[Hunger Tobias]

Hi Freddy,

As far as I know there is no tab bar available for Qt Creator -- definitely not 
inside the official repos, but I am also not aware of any 3rd party plugins 
that add those.

In our opinion tabs are a great way to switch between a handful of things (lets 
say less than 20 or so). In an IDE we could use that to switch between files, 
but any real project will have thousands of files and you will routinely have 
more than a handful of those open at any time. So our stance is that tabs make 
no sense in the use-cases we have in Qt Creator and we are *very* reluctant to 
add code we do not think useful. AFAIR we rejected some tab bar plugin for that 
reason. We try hard to keep Creator lean and mean, so we are really reluctant 
to add code we do not consider to be useful.

We do over a long list of navigation options -- and I think in combination they 
address all the use-cases I have seen brought forward for tabs (in addition to 
many others):

The most powerful is the locator: Hit Ctrl-K and start typing a part of a file 
name to open any file in your open projects. Type c ClassName (after Ctrl-K) 
to open the header that defines the class ClassName. Type m someMethod to go 
to any place where someMethod is defined, etc. The locator is a really powerful 
way to hop around your project. IMHO anybody not hitting Ctrl-K a lot when 
using Qt Creator is doing something wrong:-)

Then you can use F2 to follow a symbol (which can act as a convenient way to 
switch between declaration and definition by the way). You can also use F4 to 
switch between a .cpp file and its header. That takes away much of the pain of 
many people requesting tabs: Those are used to navigate between a small set of 
files and quite often between a .cpp file and its header file.

There is also navigation history: Alt-Left/Alt-Right. It is basically the 
back button of Qt Creator. It takes you through the history of places you did 
editing. That also works inside one document.

There is Ctrl-Tab to quickly switch between recently used documents. That pops 
up a small window with the open documents sorted by use. That is pretty close 
to what a lot of people use tabs for.

Then there is the sidebar which can show the open documents. That is nice for 
more visual people and the closest you can get to a tab bar in Qt Creator that 
I am aware of.


Did we miss some aspect of the problem? What is your reason to ask for tabs?

Best Regards,
Tobias

Tobias Hunger, Senior Software Engineer - Digia, Qt
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin. USt-IdNr: DE 286 306 868
Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] C++11 in Creator's source: Update required features

[Hunger Tobias]

Another +1...

Best Regards,
Tobias

Tobias Hunger, Senior Software Engineer - Digia, Qt
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin. USt-IdNr: DE 286 306 868
Registergericht: Amtsgericht Charlottenburg, HRB 144331 B

___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Crash QtCreator using a simple json-based wizard

[Hunger Tobias]

Hi Axel,


the 3.3 wizards should load again in the 3.4 branch without any error. Thanks 
for catching this!


Best Regards,

Tobias


Tobias Hunger, Senior Software Engineer - Digia, Qt
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin. USt-IdNr: DE 286 306 868
Registergericht: Amtsgericht Charlottenburg, HRB 144331 B



From: qt-creator-bounces+tobias.hunger=theqtcompany@qt-project.org 
qt-creator-bounces+tobias.hunger=theqtcompany@qt-project.org on behalf of 
Tobias Hunger tobias.hun...@gmail.com
Sent: Monday, March 2, 2015 08:12
To: Axel Jäger
Cc: Stenger Christian; qt-creator
Subject: Re: [Qt-creator] Crash QtCreator using a simple json-based wizard


On Mar 2, 2015 12:14 AM, Axel Jäger 
axeljae...@googlemail.commailto:axeljae...@googlemail.com wrote:
 It is interesting to see that my template was not valid in the first place
 but only machine complained about it, even with a crash.

The Projects page taking a parameter is a recent addition. Looks like I need to 
check for backward compatibility to make sure not to break existing wizards 
with the 3.4 version.

Best Regards,
Tobias
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Dropping Qt Creator compilation with Qt 4

[Hunger Tobias]

On 09.07.2014 13:51, Ziller Eike wrote:
 After a long transitioning period of 3 minor Qt 5 versions, I think that it 
 is time to think about dropping support for compiling Qt Creator with Qt 4.
 The point, that it is nicely possible to slowly transition your application 
 from Qt 4 to Qt 5, has been made.
 Qt 5 has matured, and the Qt 4 “fallback” should no longer be necessary.
 Time to get rid of some ifdefs and simplify code.
 Time to actually benefit from new features in Qt 5. (Mime database, new 
 connect syntax, put your favorite Qt 5 feature here)

 So, the proposal is to drop compilation with Qt4 with Qt Creator 3.3 (current 
 master branch). Qt Creator 3.2 will be the last version of Qt Creator to be 
 compilable with Qt 4.
 Of course the Qt version that you can use to build your own applications 
 with, is untouched by that.

 Br, Eike

+1 from my side.

Best Regards,
Tobias
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] QtCreator 3.1.1 .pro.shared is not available to overwrite shadow build settings in .pro.user file

[Hunger Tobias]

Hi Markus,

On 02.07.2014 10:40, Liebe Markus (RtP2/TEF72) wrote:
 I am trying to use a .pro.shared file to overwrite some settings in the
 .pro.user file.

 In this case I want to explicitly disable shadow build. But no matter
 what I put in the .pro.shared file,

All the build settings are addressed via a kit Id. Those are specific to 
one Qt Creator instance (provided you did not use the SDKtool to create 
those kits from an installer.

Any other instance of Qt Creator will just ignore any settings for kits 
it does not know.

So basically Creator will happily ignore any build/run settings in a 
.shared file.

 QtCreator always comes up with the shadow build settings enabled.

You can actually disable that via ToolsOptionsBuild  RunGeneral.

There is a Default build directory field there. Change that to a single 
. (or %{CurrentProject:Path}) and you will end up with shadow builds 
right in your source directory;-)

 It seems to me that creator just ignores these settings in the
 .pro.shared file.

Yes it does ignore build settings. That is a known shortcoming which is 
unfortunately not simple to fix.

 I have already created a bug report on this issue [1]

Thanks:-)

Best Regards,
Tobias

___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Syntax highlighting of PHP files

[Hunger Tobias]

On 20.06.2014 20:10, Jochen Becher wrote:
  I would like to use QtCreator for some small PHP/HTML5/CSS/Javascript
  projects I am currently working on.

Creator might not be the best tool for this job.

 Any idea what's going wrong?

Unfortunately I do not, but then the editors are not really my area of 
expertise.

 I do not have Kate installed on my system
 but gedit from Gnome 3. It highlights these files correctly but I am
 not sure if gedit also uses the Kate definitions.

AFAIK gedit is using a completely different highlighter. So that gedit 
works is not really a sign that creator should also work.

Creator will most likely also have trouble with PHP embedded in HTML. 
AFAIK (not my area of expertise, see above) Creator has one generic 
highlighter, so you will get either PHP or HTML.

Best Regards,
Tobias
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Refactoring the CMake plugin

[Hunger Tobias]

On 19.06.2014 23:29, Benjamin Zeller wrote:
 Am 19.06.2014 00:13, schrieb Miller Henry:
 On question 3:

 When switching project configurations, if the build is at all out of date 
 the first thing I'm going to do is re-run make anyway.   The only other 
 option that makes sense it to completely blow away the build directory and 
 re-run cmake.  I would go so far as making it an option to just run a full 
 build anytime I switch my build configuration (default to true as it is what 
 the user wants even though it violates some purists expectation that no 
 files will be written).  I find it very annoying to have this cmake dialog 
 pop up when I open an out of date build, as I'm just going to hit run and 
 wait for it to complete.  So long as no build option is being changed, I 
 want qt creator to write the files it needs and not bother me.
 Thats almost what my current patch is doing, it runs cmake in the
 background when you change
 configurations, always,  without popping up the dialog.
 If you want to change arguments you can do so in the build settings.
 CMake will then
 be run automatically in the background when you leave the lineedit you
 changed your settings in.
 However this does create files without notice which is really a problem
 when for example you change
 the builddir many times, you might end up with n buildfolders on your
 harddisk.

You could only run cmake if the builddir already exists and have the 
user go through the run cmake dialog otherwise.

 I think it would probably be possible to run cmake automatically when
 you finished editing a cmake
 file, because in that case you did not change any builddir settings. You
 can again say that there might
 be cases when new files are created on the harddisk, but only in the
 builddirectory you specified anyway
 so I think that should be acceptable, right?

I think so, yes. I am not the maintainer though:-)

My personal opinion is that the builddir is property of the build system 
and it is basically free to do in there what it wants. Creator just 
should not add random directories (build directories and of course 
others as well) without being very explicit about it doing that.

 Now if the cmake dialog acted more like ccmake and let me change cached 
 options that might be useful: the only thing valid to do from the cmake 
 dialog in an existing build directory is change options that ccmake could 
 change for you, but since I only have access to the command line of cmake 
 this isn't convenient. I'm not sure if the cmake cache files are in a stable 
 format where it would be valid for qt creator to do this, but it would be 
 ideal.
 Hm i wonder if cmake has some embeddable tool we could use for that.

 One annoyance I have is once in a while an automated build fails, when I 
 open qt creator it tries to run cmake, which fails because of a syntax 
 error.  There is no easy way to open the offending file in qt creator so I 
 can fix the error(s).   If you can do something about this I'd be grateful.  
 At least I'd like it if an outdated project configuration could be used 
 because that will have 95% of what I need.
 Also almost what the patch does, but what will not work of course is
 when you open the project for the
 first time and the project file is invalid, then you will only see the
 root project file.
 Once the project is open it will not remove the files from the tree when
 you somehow change your
 project file and add a error to it.

Ideally a cmake error would be listed as a build issue, so that you can 
get to the right file/line from there. That is independent of whether 
the file is actually in the project tree already.

Best Regards,
Tobias
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Refactoring the CMake plugin

[Hunger Tobias]

Hi Benjamin,

On 18.06.2014 12:39, Benjamin Zeller wrote:
 I'm working on up-streaming the changes I made on the CMake plugin
 for the Ubuntu SDK, this all slowed down in the last weeks because
 I was really busy with other tasks.

 https://codereview.qt-project.org/80708
 https://codereview.qt-project.org/80709
 https://codereview.qt-project.org/80710

I did not read those, so my comments are entirely based on the contents 
of this mail.

 But before I start doing that I would like to discuss how the plugin
 should work
 and how it should be implemented.

 There are 3 features I would like to get into the CMake plugin:

 1) Registering new cmake instances / tools

   The idea is to provide a way for plugins to register their own
 cmake installation
   and I introduced a class called CMakeManager that will own all
 registered installations.
   Every registered cmake will be represented by a CMakeTool instance,
 that abstracts away
   how a specific cmake is invoked.

   To register them I can see 2 ways:

   a) using factories:
   Personally I like factories more, maybe the approach used by
   the toolchains would fit here too (QListCMakeTool*
 Factory::autoDetect()).
   That would also require a UI in the settings dialog where the user
 can manage the
   available cmake tools and manually register them.

   b) provide a function called registerCMakeTool() in the
 CMakeManager that can
   be called by plugins.

Why do you need all that? Why doesn't a simple path to the executable 
suffice? That executable may very well be a script if that is necessary.

 2) Associating a cmake tool with a build

   Now that there is a way to have more than one possible cmake, there
 needs to
   be a way to control which cmake is used when building/creating the
 project files.

   a) By linking it to a Kit
   - provide a CMakeKitInformation so the user can control which
 Kit uses which
   cmake tool

   b) By linking it to a build configuration
  - a CMakeBuildConfiguration would either need to return a
 Core::Id specifying the
  cmake tool it wants to use, or the CMakeTool instance itself, so
 the IDE can use it
  to create the build files. The build configurations config
 widget then can provide a
  way for the user to switch between the cmake installations
 available.

I'd say the kit is the way to go here. We created kits to get this 
repetitive configuration out of individual build configurations into one 
central place.

I would personally just add a CMakeKitInformation with the path to the 
cmake binary you need to call. No CMakeManager, no CMakeTool, nothing:-)

 3) Automatically running cmake in the background (Get rid of the Run
 cmake dialog)

I am not sure I like this.

The Run CMake dialog makes it clear that we are going to write something 
to disk. There is just no way to run cmake that does not write something 
somewhere.

We generally try to avoid writing files in places where that is not 
expected. If a user e.g. changes the build dir 100 times in Project mode 
between builds, then he should only see the 100th directory that is 
selected when he hits build, not the 99 directories before that.

   It would be nice if the user was not required to handle the cmake
 dialog
   every time he wants to change the build settings, cmake arguments
 or wants to
   switch between different build configurations.

   In my MR, a cmake run is automatically started every time the build
   settings are changed and when opening a unconfigured project the
 project
   configuration page is used.

IMHO that is a no-go: The user does not ever get a chance to change the 
build location before you pollute his drive then.

 At first sight this is very similar to
 how qmake behaves and makes it easily
   possible to switch between multiple build configurations without
 the need for running
   the cmake dialog every time. But the difference of course is that
 there are files created when running cmake
   and the user does probably not know about that.
   -- A possible solution to this would be to open a dialog to change
 the build settings, but to
   run cmake automatically when switching between build
 configurations. This would make the user more aware of what
   is happening.


I personally would not be opposed to not having the cmake dialog when 
switching back to an already configured build configuration with an 
already existing build directory.

But then I am not the cmake maintainer and am not fully familiar with 
the code base nor the direction it is supposed to take.

Best Regards,
Tobias

___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Refactoring the CMake plugin

[Hunger Tobias]

Hi Benjamin,

On 18.06.2014 15:12, Benjamin Zeller wrote:
snip out part about CMakeManager and CMakeTool

 Why do you need all that? Why doesn't a simple path to the executable
 suffice? That executable may very well be a script if that is necessary.
 Well the idea here was to be able to , for example, set different
 environment
 variables or add cmake arguments on the fly if the specific cmake
 version needs that.

We need to have a way for the kit to extend the environment anyway, so 
the environment variables should be covered by that functionality (to be 
written;-).

CMake arguments, etc. can all be added in a script. I do not see why 
that has to go into Qt Creator, especially considering that this is 
static configuration that the user will rarely want to change.

 I also heard from other people it would be nice if one could configure a
 cmake installation for example to add a preload cache script.

Yes, we should be flexible and allow users to do whatever they want, but 
we do not need to provide an UI for everything anybody may conceivably 
come up with.

This is one of those things IMHO.

 Also for example if you want to configure a special toolchain file, or
 just for
 identifying a special type of cmake in the sourcecode.

There are different kinds of cmake? That is new to me. I always grabbed 
the one from kitware.

 For example the
 ubuntu sdk plugin identifies Ubuntu SDK kits by checking if the cmake
 tool is of a special type.

Why would you do that?

Desktop ubuntu (is that even supported?) is a pretty normal desktop 
target, so why have a special type for that in the first place? And why 
bind that type to cmake? Why do you want to limit users to the cmake 
build system?

For the phones and other stuff you have to have devices to talk to those 
anyway, so why not use the type of device as a identification? You will 
need to do different deployment steps based on which device you have anyway.

snip part about mapping CMakeTools to Kits

 I would personally just add a CMakeKitInformation with the path to the
 cmake binary you need to call. No CMakeManager, no CMakeTool, nothing:-)
 Hm interesting, so we need at least a default cmake but that can still be
 the one found in PATH, or specified in the cmake settings dialog.

Why do you need a default cmake? Just use the one from PATH if the user 
has none explicitly set (and there is one in PATH).

In the cmake wizard you then need to have the user select a kit (one 
with a configured cmake) and off she goes.

I have nothing further to contribute to the discussion about when to run 
cmake, so I will just cut out that part.

Best Regards,
Tobias

___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Refactoring the CMake plugin

[Hunger Tobias]

On 18.06.2014 16:02, Benjamin Zeller wrote:
snip

 Ok, sounds good to me, so how would you want to have the Kit to extend the
 environment?
 Like having a KitInformation::addToEnvironment when the buildsteps are
 executed?

Add a EnvironmentKitInformation that can be configured to change the 
environment and then use the existing addToEnvironment, yes.

snip

 There are different kinds of cmake? That is new to me. I always grabbed
 the one from kitware.
 Yeah well, in our case we have build chroots that contain their own cmake
 instance and I need to invoke them inside the chroot. Thats probably
 why I needed all these things in the first place.

So you have host-binaries in a chroot for the target? Why would you do that?

You could have a sysroot set and then compare that to the cmake path. If 
sysroot is a prefix to cmake path, then you need to chroot... or do 
something similar.

 For example the
 ubuntu sdk plugin identifies Ubuntu SDK kits by checking if the cmake
 tool is of a special type.
 Why would you do that?

 Desktop ubuntu (is that even supported?) is a pretty normal desktop
 target, so why have a special type for that in the first place? And why
 bind that type to cmake? Why do you want to limit users to the cmake
 build system?
 The binding to that type of cmake just would happen for the special
 case I mentioned above, cross compiling in the chroots...

... which is actually pretty easily done with a script;-)

 Why do you need a default cmake? Just use the one from PATH if the user
 has none explicitly set (and there is one in PATH).

 Default cmake as in, the one to use when none is set in the Kit. And yes
 that would be the one from the PATH :).

No, if there is no cmake set in the kit, then this kit is not applicable 
for cmake-based projects. So you can just skip those kits when asking 
which ones the user wants to see his cmake project built with.

 In the cmake wizard you then need to have the user select a kit (one
 with a configured cmake) and off she goes.
 Ah yeah we can make the cmake wizard  just show Kits that actually have
 a cmake set,
 that would work also but requires more configuration from a user who
 just wants to
 use cmake without any fancy things. I would like to have the
 KitInformation fall back
 to the cmake in PATH.

Feel free to do that. That is why the KitInformation has methods for 
default values, for the initial setup and to fix it again in case 
something breaks:-)

Please make sure to only add cmake to kits where that actually makes 
sense. E.g. if there is no way to deploy cmake built binaries to the 
device in question, then just leave out the cmake for those kits. A user 
is still free to configure those kits manually if he knows what he does.

Best Regards,
Tobias
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] apply pro.shared settings to a project tree

[Hunger Tobias]

On 11.06.2014 18:46, EXTERNAL Konold Martin (erfrakon, RtP2/TEF72) wrote:
 Hi there,
 I have a nicely working, minimal and project independent pro.shared file.
 Is there a way to apply it for a tree of projects without copying with
 an appropriate name to each subproject directory?
 A copy approach would mean a severe maintenance issue for my intended
 use case.

Hi Martin,

Sorry, we have all been to QtCS, so your mail fell through the cracks so 
far:-/

Unfortunately I am not aware of a way to apply .shared files to a tree 
of projects. You could try to just have creator configured correctly: 
There is little in the .shared files that can be shared and is not a 
otherwise global configuration setting.

Best Regards,
Tobias

___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Refreshing the project tree

[Hunger Tobias]

 Currently running qmake doesn't seem to update the project tree. If
 running qmake did update it, that would be fine. I don't know if there
 are other use cases where it may be desirable (or clearer) to have a
 separate explicit refresh project tree button available.

That is correct: I am not aware of forcing a reparse short of touching a .pro 
file.

 One question related to the request of this functionality is if there is
 some way one could tri gger this refresh (either as a qmake call or as an
 explicit refresh projecttree operation) from the context of a Qt
 Creator external tool. The use case for this is for updating the project
 tree after a code generator has been run. The idea is for the developer
 to modify a meta data file (in our case we use QML), trigger the code
 generator through a Qt Creator external tool and then see the new files
 in the project tree without having to do any extra work themselves.

That will touch the .pro/.pri files, won't it? That in turn will trigger a 
reparsing.

Or are you relying on wildcards here? That would be strange, considering that
you generate the code and could just add it to the .pro files while at it 
anyway.
But even with wildcards it should be trivial to just touch any .pro/.pri file.

Best Regards,
Tobias

--
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator

Re: [Qt-creator] Qt Creator Issues tab does not populate

[Hunger Tobias]

Hello Alfonso!

snipDescription of problem with output parsing/snip

 How can I work around this problem?

That depends a lot on what kind of output you get from your tools and whether 
you receive
the output via stdout (black text in compile output) or stderr (red text).

 How does Qt Creator populate the Issues tab?

Each build step (make, qmake, custom build step, etc.) defines a list of output 
parsers that
look at each line of output received and extracts Tasks from that which are 
then routed to the
Issues pane.

The list of parsers for make contains e.g. a gnumakeparser and parsers for the 
tool chain
you have set up (MSVC, gcc, clang, whatever).

 As a reference, in their existing CodeWright IDE, they manually configure a 
 Custom Error Parser.

Creator does not have that yet, sorry.

 They essentially point the IDE to a .err file generated by the compile step 
 and give CodeWright a
 complex regular expression to use to parse the .err file and populate the 
 error list.

Something similar would be necessary, but you will have to do this in code.

 Perhaps this complex configuration doesn't need to be performed to get Qt 
 Creator set up for
 this, but I just have no idea how to get the Issues tab to populate or how to 
 continue to troubleshoot this.

How to proceed depends a lot on what the output looks like as well as how you 
get it. 

The simplest case would be if wmk is compatible with make (it is called a make 
tool on the
site you pointed too). Compatible in this context means it accepts the command 
line arguments
we need (-w to print working directories), it produces similar output and does 
not alter the
compiler output in any way (by e.g. moving the compilers stdout to stderr or 
the other way
around).

If you are then using a compiler that produces output like GCC or any other 
supported compiler,
then you only need to have a makestep and override the make command used.

If the tool does something different, then you will need to do some coding.

hack

You mention a .err file... You might get away with having a script that turns 
this into a .tasks file.
When loading a .tasks file into creator it will treat each line as one issue to 
put into the
isssues pane. That is very convenient for things like static code analysis 
results, etc. but might
be abused for your use case: You would need a script that turns the .err file 
into a .tasks file
(e.g. by watching the filesystem or by way of it being a wrapper around wmk). 
Creator will
watch .tasks files it opened and reload them whenever they change.

/hack


Tobias Hunger
Senior Software Engineer
Digia, Qt

Digia Germany GmbH
Rudower Chaussee 13, 12489 D-Berlin
Sitz der Gesellschaft: Berlin, Registergericht: Amtsgericht Charlottenburg, HRB 
144331 B,
Geschäftsführer: Mika Pälsi, Juha Varelius, Anja Wasenius
Email: tobias.hun...@digia.com
http://qt.digia.com
Qt Blog: http://blog.qt.digia.com/
Qt Facebook: www.facebook.com/qtcommercial
Qt Twitter: www.twitter.com/qtcommercial

Digia Germany is a group company of Digia Plc,
Valimotie 21, FI-00380 Helsinki Finland
Visit us at: www.digia.com
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator