Re: [Qt-creator] RunConfiguration, RunControl and RunConfigurationAspect
I am trying to understand the various Run classes and what each is responsible for. I have stepped through their behavior with a debugger and am still struggling with how they might be able to help me. The problem that I am trying to solve involves writing a qt-creator plugin that provides a runconfiguration that returns a different executable string depending upon whether it is responding to a DebuggerRunControl or a normal RunControl. RunConfiguration does not have access to the mode that contains that information, whereas a RunControl or RunControlFactory knows about ProjectExplorer::RunMode. You probably want to implement your own RunControlFactory that knows how to convert your RunConfiguration to a RunControl. daniel ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] switching RunConfigurations in the code
On Friday 22 May 2015 13:32:25 Petr Vanek wrote: hi all, my plugin exposes two types of ProjectExplorer::LocalApplicationRunConfiguration: class QorusExecutableRunConfiguration : public ProjectExplorer::LocalApplicationRunConfiguration and class QoreExecutableRunConfiguration : public ProjectExplorer::LocalApplicationRunConfiguration my idea is to switch between these configurations whenever the current edited document changes. Then the lookup into registered mime types shows what run configuration should be used. But I cannot find how I can set the current run configuration in the code. I'm able to do it only by hands in the UI - MiniProjectTargetSelector. Is there some hidden build/run target handler inside qt creator, please? project()-target()-setActiveRunConfiguration(), but that's sounds very strange to want. daniel ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] QtCreator plugin contribution
On Monday 13 Apr 2015 10:04:05 Mateusz Loskot wrote: On 13 April 2015 at 09:36, Mateusz Loskot mate...@loskot.net wrote: On 13 April 2015 at 08:18, André Hartmann andre.hartm...@iseg-hv.de wrote: https://wiki.qt.io/Branch_Guidelines The latter explains recommendations and caveats of possible development workflows. But that's only true for Qt itself. The /Branches article says Qt Creator uses the same branching policy as Qt itself So just push your new plugins to master. I've been looking for answer on which branch to branch off, thanks. I should have clarified, I'm going to work prepare for contribution this way: - fork Qt Creator on GitHub - create branch boostbuild-plugin branched off of the master - import source of my plugin - work on the plugin integration, apply necessary changes, etc. - once the integration is completed, submit the plugin through Gerrit I hope it's acceptable workflow, as two other developers that joined my efforts are based on GitHub, and GitHub simlifies our collaboration a lot. Every author needs to agree to the Contribution Licensee Agreement, so make sure that everyone that joins you understands and signs that CLA. daniel ___ 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)
Am Donnerstag, 9. April 2015, 09:17:45 schrieb Hermann Fieger: After including following line #include projectexplorer/projectnodes.h i was able to compile. ProjectExplorerPlugin *plug = ProjectExplorerPlugin::instance(); // OK ProjectExplorer::Node *nod = plugcurrentNode();// OK QString qs_path = nod-path(); // OK Now it compiles all, but crashes, because nod is NULL. So i think i made a wrong assumption. I 've not an open project, because i deal with python3. What i have to do, is to extract the path and filename from the Filesystem navigation widget and not from the Project navigation widget. The file system view is implemented in FolderNavigationWidget and the rlated classes. There's no api that gives you the currently selected file in the that widget though. daniel ___ 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
If anyone wants to propose a coding style, please come forward. https://codereview.qt-project.org/#/c/109766/ Those are basic stubs for those entries. I expect the coding guidelines to grow as we use those features. daniel ___ 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
Now, we need to discuss our coding guidelines regarding those new features. While we don't need a coding guideline for each C++ feature, I think for those new features it's worth having a guideline on when to use them and how to use them. If anyone wants to propose a coding style, please come forward. We had some discussions on some features in the office, and based on that I'd like to propose the following coding guidelines: - Use Delegating constructors, Initializer lists, Defaulted functions, Alias templates where it makes sense. Note: typedefs instead of Alias templates are still fine and there's no need to mass convert typedefs. - You can use Scoped Enums. Note: Scoped Enums seem to be a somewhat mixed bad, making them not strictly better than unscoped Enums. They are neither forbidden nor recommended. We probably need more experience with this. - You can use nullptr, but Note: There was no consensus to ban nor to recommend them, but the majority didn't think nullptr brings a benefit, so individually maintainers might object to usage of nullptr. daniel ___ 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
On Monday 09 Mar 2015 12:14:04 Daniel Teske wrote: If anyone wants to propose a coding style, please come forward. ** Range-based for ** I'd like to propose the following guideline: Do not use the C++11 range based for loop unless your loop modifies the contents of the container. Prefer to use Qt's foreach macro for read-only iteration. Reason: The range-based for loop is using the helper functions std::begin() and std::end, which unless overloaded call container.begin() and container.end(). Which for Qt's container classes call detach unless the container is const. Overloading std::begin() and std::end() to return const_iterators doesn't work, since you can't then no longer modify the container's contents. Thus, the range-based for loop has worse performance for read-only iteration unless: - The container is const - The container is unshared This makes imho the range-based for loop to error-prone for read-only iteration. I'd like to allow the range-based for loop for modification, since that's something that simply isn't possible with qt's foreach macro. But, I would also agree to a coding guideline of discouraging the range based for loop completely. So, we had quite a bit of discussion on how to treat ranged based for loops internally, and thus I like to suggest a different coding guideline: Use range based for-loops, but beware of the spurious detachment problem. If the for-loop only reads the container and it's non-obvious whether the container is const or unshared, use std::cref() to ensure that the container isn't unnecessarily detached. daniel ___ 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
Hi, I thus suggest requiring the subset of C++11 that is implemented by VS 2013, g++ 4.7 and clang 3.1 in master. I was expecting this to be somewhat controversial. But, apparently it isn't. We have a consensus on this then. Now, we need to discuss our coding guidelines regarding those new features. While we don't need a coding guideline for each C++ feature, I think for those new features it's worth having a guideline on when to use them and how to use them. If anyone wants to propose a coding style, please come forward. We'll have internal discussions at the Berlin office about specific features, so I would expect some coding guideline proposals to come from that. daniel ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
[Qt-creator] C++11 in Creator's source: Update required features
Hi, almost exactly a year ago we allowed the usage of some C++11 features in Qt Creator's source code and effectively dropped support for Visual Studio 2008, g++ 4.5 and clang 3.1. As a quick browse around the Qt Creator source code shows, those features are nowadays quite common and lead to code that is imho easier to maintain. It's time to discuss whether we should move forward and require an even greater subset of C++11. I thus suggest requiring the subset of C++11 that is implemented by VS 2013, g++ 4.7 and clang 3.1 in master. We don't require using those specific compilers, any fully compliant C++11 compiler should work, but we typically only compile with compilers from those 3 mentioned vendors. This would open up at least the following C++11 features (I've not included a few items that are probably not relevant to our usages): * Non static data member initializers * Variadic templates * Initializer lists * Alias templates * Strongly typed enums * Delegating constructors * Defaulted and deleted functions * Range based for loop * override and final * nullptr This is quite a list of new stuff and I would expect a few items to be somewhat controversial. Just like last time, we need to discuss the coding style for each feature. daniel ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Preparing to contribute Boost.Build Plugin to Qt Creator
On Thursday 19 Feb 2015 09:35:32 Mateusz Loskot wrote: Hi. Recently, the plugin has received some updates [1] and there are users who would like to see it submitted to Qt Creator. Perhaps that's a good idea to give it a go. I've opened GitHub issue [2] devoted to discussion it further and prepare the submission through Gerrit. Anyone interested in this plugin, feel welcomed to post your comments. Do note that every committer to that repository needs to sign the contributor license agreement. daniel ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] CppTools::ProjectInfo project sources and include paths
On Tuesday 03 Feb 2015 15:29:48 Nikolai Kosjar wrote: Hi! On Mon, 02. Feb 16:51, Roman Nikiforov wrote: The problem is that if I have conditions in qmake .pro file and some sources and include paths are added only for special configuration, I still get all source files from ProjectInfo, but include paths only for active configuration. Consequently Lint cannot resolve some includes and stops with error. At the end of the day, your observation describes what the code model needs. All project files are passed in so they can be indexed (as far as possible) so that their symbols show up in the locator or e.g. Search Symbols. Providing more include paths than for the current build configuration could lead to subtle/unexpected side effects. Note that in general you can't just assume that a project is buildable/analyzable for all configuration since e.g. some headers are only available on certain platforms. That is, getting all include paths wouldn't help you here for the general case. It seems better to analyze only the files that are part of the current build configuration. [For qmake projects:] Unfortunately I don't see a way how to find out whether a file is part of the current build configuration or not. We get the files via e.g. pro-variableValue(CppSourceVar) in QmakeProject::updateCppCodeModel() and this seem to contain *all* files of the project, independent of the configuration. @Daniel: Is there a way to get only the files that are selected by the build configuration? Yes we have that information, we just don't store it anywhere since so far no one had any use for it. daniel ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] CppTools::ProjectInfo project sources and include paths
On Tuesday 03 Feb 2015 17:11:51 you wrote: Hi Nikolai Daniel, thanks for your answers. For my plugin it would be better to get files and include paths for selected configuration, not just all for the active project. Sources of selected configuration create final binary, so it has sence to check only these files. @Daniel: Could you please point me to the prived methods you have to get active sources? I coud than build custom version of qtcreator for the first time and make them public in this version. Those methods don't exist. The data is retrieved from the parsers in QmakeProFileNode::evaluate, the exact parser is the one that contains the data you want. Whereas the cumulative parser contains all kinds of heuristics to gather more files. daniel ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Auto complete for Qt5 signals and slots connections
Currently I use the SIGNAL and SLOT macro to get the correct method, then I edit the result to be according to the Qt5 syntax. Independent of what Nikolai promised, there's a quick fix for converting qt4 style connects to qt5 connects. Press Alt+Enter for that. daniel ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Cmake plugin again
its been a while since we last merged the upstream CMake plugin into our own Ubuntu-SDK codebase. As a result our current version is behind the most recent QtC release. Since the last merge there were a lot of things changed in the plugin that makes it almost impossible to merge it again, so we decided to start from scratch and since we have learned from the last time we want to first propose the refactoring steps we are going to work on. We decided to drop the idea of removing the Run cmake dialog but still need a possibility to have a cmake per Kit. So here are the steps, each one would be a self contained patch: Patch 1: - Add a view to register multiple cmake instances to the system (in tools-options-BuildRun-cmake) * The user can select a default cmake tool that will be used for every build * do not add it to the Kit yet to keep the patch small * use a view like in the QtVersions settings page (treeview) * provide a central registry for all the cmake instances (CMakeToolManager) Patch 2: - Make the cmake instances known to the Kits (CMakeKitInformation) * The run cmake dialog will pick up the cmake from the kit Patch 1 is rather big, but I do not see a way to break it down even more, but I'm open for suggestions :). Daniel, can you please tell me if this proposal as the base of our implementation is acceptable for you? So I have only limited understanding of your setup and needs, thus I can only comment on this in isolation. There have been some people wanting to have multiple different cmake executables, but that's a fringe use case as far as I'm concerned. Still, if that's the only patches that you need, I'm not opposed to that. After all that should help prevent further damage by your fork of creator. daniel ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] 3.3.0-rc1 Android Manifest target SDK
On Tuesday 25 Nov 2014 10:47:06 Harri Pasanen wrote: When looking at the Target SDK in AndroidManifest.xml it displays for me: API 20: Android 5.0 But reading http://developer.android.com/reference/android/os/Build.VERSION_CODES.html it would seem to me that API 20 is Android 4.4W, KITKAT_WATCH and API 21 would be LOLLIPOP, or Android 5.0 I'm not sure where the values are populated from, so I suppose it could be some artifact of my Android SDK installation? We have a hardcoded list and Api 20 was just missing. https://codereview.qt-project.org/100745 daniel ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Qt Quick UI example code
On Friday 31 Oct 2014 12:41:44 John Idarraga wrote:
Hello all,
I downloaded the last version of QtCreator (3.2.2 Built on Oct 10 2014
11:17:04 From revision 34971be5cc). I proceed to start a new
Application project -- Qt Quick UI. The template code generated for
the constructor of the class goes as follows
SpidrMpx3Eq::SpidrMpx3Eq(QWidget *parent) :
QMainWindow(parent),
ui(new Ui::SpidrMpx3Eq)
{
ui-setupUi(this);
}
if for instance i want to connect a signal to a slot for a given object
I need to do
connect( ui-_myButton, )
My question is. Why not letting the Ui setup by doing
this-setupUi(this);
and then simply use the inherited public member _myButton
connect( _myButton, )
what's the use for the ui pointer here ?
Whether you prefer Ui::SpidrMpx3Eq as a base class or as a member depends on
how you view the SpidrMpx3Eq class.
In our code we usually prefer to have the details on how the ui is implemented
to be encapsulated, and to then offer a api tailored to the purpose of the
class.
daniel
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Proposals for Updating the Qt Creator Coding Style
On Thursday 02 Oct 2014 10:01:30 Christian Kandeler wrote: On 10/01/2014 04:21 PM, Daniel Teske wrote: ** Qt5 connects vs Qt4 connects - Prefer to use qt5 style connects with member function pointers to the qt4 style of using SIGNAL and SLOT macros. - Avoid overloading signals or slots - Avoid calling connect via object-connect() Can you elaborate on the latter point? I forgot the reason. The reason is that it's different between the qt4 connect and the qt5 connect. With qt4 connects, a-connect(b, SIGNAL(sig(), SLOT(slot())) is equivalent to connect(b, SIGNAL(sig()), a, SLOT(slot())); because there is a member method connect for that. Thus the connection is removed if a is deleted whereas: a-connect(b, B::sig, A::slot), calls the *static* connect method, that takes no context object, so the connection is not removed if a is deleted. For that reason I'd like to discourage using the member functions at all. daniel ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
[Qt-creator] Proposals for Updating the Qt Creator Coding Style
Hi, since current master allows for using qt5 only features in Creator's source code, I propose the following (independent) changes/additions to our coding style. ** Qt5 connects vs Qt4 connects - Prefer to use qt5 style connects with member function pointers to the qt4 style of using SIGNAL and SLOT macros. - Avoid overloading signals or slots - Avoid calling connect via object-connect() - Be careful with lambda slots Reasons: The qt5 connects are type checked at compile time, which eliminates a huge error source. Also the code model can understand them better than the SIGNAL and SLOT macros. ** Qt Logging Framework - This is the preferred solution for logging in Creator. Reasons: This allows for one way to disable/enable logging for all of Creator. ** QRegularExpression - Prefer to use QRegularExpression to QRegExp, except if you need QRegExp's features, e.g. wildcard matching. - If the code is performance critical measure which regular expression engine is faster. Reasons: QRegularExpression has a better api and a more commonly used pattern syntax. In general performance should be better, but if it matters, you need to measure. ** QStringLiteral - Prefer to use instead of QString::fromLatin1() - QLatin1String is still fine to use, if you don't need a QString Reasons: There's no huge difference to using QStringLiteral or not. daniel ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
[Qt-creator] Proposals for Updating the Qt Creator Coding Style
Hi, since current master allows for using qt5 only features in Creator's source code, I propose the following (independent) changes/additions to our coding style. ** Qt5 connects vs Qt4 connects - Prefer to use qt5 style connects with member function pointers to the qt4 style of using SIGNAL and SLOT macros. - Avoid overloading signals or slots - Avoid calling connect via object-connect() - Be careful with lambda slots Reasons: The qt5 connects are type checked at compile time, which eliminates a huge error source. Also the code model can understand them better than the SIGNAL and SLOT macros. ** Qt Logging Framework - This is the preferred solution for logging in Creator. Reasons: This allows for one way to disable/enable logging for all of Creator. ** QRegularExpression - Prefer to use QRegularExpression to QRegExp, except if you need QRegExp's features, e.g. wildcard matching. - If the code is performance critical measure which regular expression engine is faster. Reasons: QRegularExpression has a better api and a more commonly used pattern syntax. In general performance should be better, but if it matters, you need to measure. ** QStringLiteral - Prefer to use instead of QString::fromLatin1() - QLatin1String is still fine to use, if you don't need a QString Reasons: There's no huge difference to using QStringLiteral or not. daniel ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Clever editing features (no way to disable)
On Thursday 11 Sep 2014 00:06:48 Campbell Barton wrote:
Recently I've noticed in qtcreator/master getting some interesting features
- Entering quote `` when there is a selection, adds quotes around the
selection.
- Entering quote `` without a selection adds `` - even when
autocomplete is disabled.
- Entering brace `{`, pressing enter, adds a matching brace. `{\n}`
While I can see that some users may want, these - find them quite
annoying, is there some way to disable?
Yes. The option is under TextEditor/Completion/Automatically insert matching
characters
daniel
___
Qt-creator mailing list
Qt-creator@qt-project.org
http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] UI blocked
This is a regression from previous versions which did not have this problem. Are you sure it is a regression. And if so from which version? daniel ___ 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
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. +1 daniel ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Compiling fails to link *sometimes*
On Wednesday 09 Jul 2014 16:48:19 Jason MacDonald wrote: I've had similar issues that I haven't been able to resolve. Although when it happens, it will usually keep happening until I reboot. I am also unable to manually delete the file. I don't think my issues are qt-creator related. Process Monitor from http://technet.microsoft.com/en-us/sysinternals/bb896645 can show you which process keeps the file open. daniel ___ 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
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 I'd like to see more than just a ubuntu sdk specific use case for this. As is, I don't see much value in that. CMakeManager that can be called by plugins. 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. Like Tobias said, definitely in the kit. 3) Automatically running cmake in the background (Get rid of the Run cmake dialog) 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. 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. Right, that would work. daniel ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] QtCreator 3.0.84 - GUI hangs when loading large project
Am Thursday, 24. April 2014, 10:00:12 schrieb Liebe Markus (RtP2/TEF72): Hi there, we have a quite large project tree here - consisting of one main .pro file which then contains several subdir projects and so on (around 400 .pro files). (Btw. we are using OpenSuSE 13.1.) The problem that we are facing is that when loading our project, the GUI of QtCreator freezes until the project has been loaded. Because of the size of the project you have to stare for about a minute or two on a non-responsive screen. This leads to the wrong thinking that Creator has crashed - and several fellow developers just kill the app and try again. You can try this for yourself when loading the QtCreator sources: QtCreator is unresponsive as long as the project is beeing loaded. Is this a known issue? I already skimmed the issues in the bug tracker and found none relating to this. Yes. There's rom for improvement there, feel free to create a bug report. It's a rather big task to do that. daniel ___ 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.1 is freezing
On Friday 04 Apr 2014 12:45:06 Adam Strzelecki wrote: Hi, What is current status about detaching Qt releases from QtCreator? I remember it was planned for next major release, but I guess QtCreator will be still shipped together with Qt 5.3. It that correct? No. The 3.1 release is in ~2 weeks (if everything goes according to plan.). Qt 5.3 won't even have a rc before that. daniel ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Using C++11 in Creator's source
On Tuesday 18 Mar 2014 09:44:17 Christian Kandeler wrote: On 03/05/2014 11:12 AM, Poenitz Andre wrote: Ziller Eike wrote: One rule for using “auto” that I’d like to establish, is to use it only “when the type is obvious when reading the code”. Of course what that exactly means should be discussed and shown in some examples, and then it’s still up for interpretation. E.g.: Yes: auto f = new FooBar; auto a = new A; auto myAction = menu-addAction(…); auto it = list.const_iterator(); No: auto i = 4; // the difference between “4;” and “4.;” is subtile with big consequences What is obvious for some might unfortunately not be so obvious for others. From the list of Yes cases I only fully agree with auto it = list.const_iterator(); I'd actually like to restrict the use of auto to cases where it significantly reduces typing and line noise (say, identifiers longer than x chars, and to cases where it doesn't change meaning. On the other hand, patches that change types in function signatures will potentially get much smaller if auto is used extensively. For instance, if you take a look at the QString - Core::Id or QString - Utils::FileName patches, you will notice that quite a number of hunks would disappear entirely. But that's NOT a good thing. After all the type changed, the behavior changed, and you need to look at all those places to consider the implications. Utils::FIleName is a mostly drop in replacement for QString, but it behaves differently. In general, it seems to me that using auto is sensible when assigning the result of a function call, as the type is already specified. The ultimate aim of our coding style is to make code maintainable, by being readable. If you need to lookup the return values of functions, to understand code then that makes the code less readable to me. The types of variables are important, and thus shouldn't be hidden. daniel ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Project-specific make tool
On Wednesday 12 Mar 2014 14:28:03 Stephen Kelly wrote: Daniel Teske wrote: Currently jom can be selected as the build tool on Windows as a global setting in creator. Would a patch changing that to be a per-project setting be accepted? That's already possible per buildconfiguration. It appears the option can be overridden by specifying a different path to a make-tool binary. Is that what you are referring to here? Yes. daniel ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Project-specific make tool
On Wednesday 12 Mar 2014 14:33:03 Stephen Kelly wrote: Daniel Teske wrote: On Wednesday 12 Mar 2014 14:28:03 Stephen Kelly wrote: Daniel Teske wrote: Currently jom can be selected as the build tool on Windows as a global setting in creator. Would a patch changing that to be a per-project setting be accepted? That's already possible per buildconfiguration. It appears the option can be overridden by specifying a different path to a make-tool binary. Is that what you are referring to here? Yes. Ok, that is possible with qmake builds, but not with cmake builds. That looks like a oversight. The way to specify such a tool with cmake is to invoke cmake in the build directory with -DCMAKE_MAKE_PROGRAM=/path/to/jom . Would a patch doing that be accepted? Why do you want to run cmake on changing which make tool is used? What benefit does that bring? daniel ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Project-specific make tool
On Wednesday 12 Mar 2014 14:49:56 Stephen Kelly wrote: Daniel Teske wrote: The way to specify such a tool with cmake is to invoke cmake in the build directory with -DCMAKE_MAKE_PROGRAM=/path/to/jom . Would a patch doing that be accepted? Why do you want to run cmake on changing which make tool is used? What benefit does that bring? It allows cmake to run the correct build tool. I loaded a cmake project in creator on Windows, and creator executed cmake for me. That populated the cache with: //Program used to build from makefiles. CMAKE_MAKE_PROGRAM:STRING=nmake So, if the makefiles cause cmake to run any part of the build, it will use nmake. Creator expects jom to be used. The solution is to tell cmake to use jom. Can you demonstrate this in a example? We don't expect cmake to run make for us, and other things would break if cmake does that. daniel ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Using C++11 in Creator's source
On Friday 07 Mar 2014 11:42:30 Tobias Hunger wrote: On 04.03.2014 14:09, Daniel Teske wrote: Hi, since we have branched 3.1 from master, master no longer needs to support OS X 10.6. As such I propose, that we open up master for those C++11 features that are supported by VS 2010, g++ 4.5 and clang 3.1. That is the list that is used for Qt 5, but why can't we go for something a bit newer? Because it makes no difference in which parts of C++11 we can use. VS 2010 limits what we can use, g++ 4.5 and clang 3.1 are simply the first versions that more or less support a superset of VS 2010's support. As I wrote in my initial mail, in practice I would expect no one to use those compilers any more. I am no Windows user, maybe we can just bump the requirement to MSVC 2012 there? That would be a huge step forward for our C++11 support! No, I think it's too early for that. daniel ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Using C++11 in Creator's source
So, I put this concrete rule up for discussion: Optionally you can use the “auto” keyword in the following cases. If in doubt, if auto could make the code less readable, do not use auto. Keep in mind that code is read much more often than written. * When it avoids repetition of a type in the same statement. You should explicitly mention any “const”, “” and “*” as well, even if they were implicit. - auto *something = new MyCustomType(…); - auto *somethingElse = qobject_castMyOtherCustomType *(sender()); - auto myFunnyListOfThings = QStringList() QLatin1String(“FooThing”) QLatin1String(“BarThing”); * When assigning iterator types. - auto it = myFunnyListOfThings.const_iterator(); I think we should stop the discussion about auto now, and simply go with those rules. They are fairly conservative and we can extend them later. So: +1 daniel ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Using C++11 in Creator's source
On Wednesday 05 Mar 2014 10:29:33 you wrote: On Mar 4, 2014, at 2:09 PM, Daniel Teske daniel.te...@digia.com wrote: Hi, since we have branched 3.1 from master, master no longer needs to support OS X 10.6. As such I propose, that we open up master for those C++11 features that are supported by VS 2010, g++ 4.5 and clang 3.1. I think it's too early to require a newer version of Visual Studio, though requiring those 3 compilers gives us both *auto* and *lambda*. I suspect that in practice the minimum g++ or clang version will be higher, since practically no one uses those versions any more. We need to extend the coding rules for auto and lambda. Suggestions are welcome for that. One rule for using “auto” that I’d like to establish, is to use it only “when the type is obvious when reading the code”. Of course what that exactly means should be discussed and shown in some examples, and then it’s still up for interpretation. E.g.: I agree on principle. I'd like to add: If in doubt, don't use auto. Yes: auto f = new FooBar; auto a = new A; auto myAction = menu-addAction(…); auto it = list.const_iterator(); I agree on the first 2 and the last one. daniel ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Whacky thought of the day
On Tuesday 04 Mar 2014 16:19:03 Miller Henry wrote: My workflow may be helpful: Create header, right-click on function in header, select Refactor, then Add Definition in …” The shortcut for that is Alt+Enter. daniel ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
[Qt-creator] Qt Creator 3.2 dropping support for Mac OS X 10.6
Hi, Let's make this: Qt Creator 3.2: - drop support for compiling running Qt Creator on 10.6 We want to start using C++11 also in Qt Creator, and 10.6 is the only thing preventing that. Since 10.6 is deployment target only for Qt, we don’t necessarily need to keep “its IDE” running there (yes, that’s a Qt-centric way of looking at Qt Creator). a actual independant proposal (since it doesn't really depend on what qt supports) and cross post it to qt-creator for some wider exposure. Actually using C++11 would also mean bumping the minimum supported compiler for *compiling* Qt Creator. That's somewhat separate, but I would assume we would require at least lamba and auto support for compiling Qt Creator 3.2. That means MSVC 2010, clang 3.1 or g++ 4.5 if I remember correctly. daniel ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Required conventions (was: Documentation for plugin development)
On Tuesday 26 November 2013 10:43:24 Mateusz Loskot wrote: On 26 November 2013 10:10, Tobias Hunger tobias.hun...@digia.com wrote: * Please make sure to follow the coding style. http://doc-snapshot.qt-project.org/qtcreator-extending/coding-style.html has the details. (...) There usually are lots of misplaced * and chars in newly submitted code, too. Or, one day, Qt will drop its C with classes heritage and allow folks to apply C++ semantic and emphasize actual type instead of syntax of declaration as C folks do. That isn't the reason. The reason is that it makes the * or stand out more. Humans pay more attention to the first character of a word thatn to the last one. So putting the *, in front of a word instead at the end increases readability. Since the qt coding style strongly advises against putting multiple variable declarations on one line, there's also no draw back to that. daniel ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] where does qDebug() end up?
On Monday 30 Sep 2013 22:09:03 André Pönitz wrote: On Mon, Sep 30, 2013 at 03:29:26PM -0400, Michael Jackson wrote: I am running QtCreator 2.8.1 on Windows 7x64 using the VS2008 compilers. I have a console application that I am writing. I use qDebug() to output progress to the console but when I debug those messages are not showing up in the Application Output and a command window does not pop up either? Is there a setting I need to toggle to be able to either have the console window pop up or have the output streamed so that QtCreator can display it? For the separate window, there's a check box Run in Console in the project's Run settings. But, you should get the debug output inside creator if that is unchecked. Windows is limited though in that there can be only one application subscribed to the debug output of all applications. Thus you need to ensure that there's no debugviewer and no other creator running. daniel ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] No snapshot for qtcreator 3.0-pre available
On Monday 30 Sep 2013 11:52:04 Kalinowski Maurice wrote: On 30.09.2013, at 11:00, Christian Kandeler christian.kande...@digia.com wrote: On 09/30/2013 08:55 AM, Ziller Eike wrote: We are currently in yet another change of build infrastructure *and* we are transferring the Qt Creator builds to use Qt 5.2 (which is a requirement for getting the full Qt Creator 3.0 nowadays), What exactly is 5.2 needed for? I'm only aware of 5.1 being required. Embedding of Qt Quick 2 into a QWidget hierarchy seems to be something you only want to do starting with Qt 5.2. It has several issues in pre Qt 5.2, rendering Qt Creator useless in some configurations. (Thomas could probably say more, I don't know the details.) As far as I can tell androiddeployqt is also coming with 5.2 and Qt Creator now uses that internally as well. Here Daniel can probably say more. That's the target qt, not the host qt. For the android target creator supports all qt versions that have android support. daniel ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Keyboard layout switching hotkey?
On Wednesday 18 Sep 2013 13:21:37 André Hartmann wrote: Hi all, It happens once in a while that I press a key sequence that switches the keyboard layout from German to English within Qt Creator. My system is Windows 7 64bit, QtCreator 2.8.1 (Qt 4.8.4) from qt-project.org. Other Windows program and I seems other Creator instances are not influenced. On windows the keyboard layout is (by default) per application. The keyboard shortcut for that is globally configureable in windows' system settings. daniel ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Remote Linux plugin and CMake
If a patch is provided which does the right thing, are you going to reject it for being a 'duplicate solution'? No. daniel ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Remote Linux plugin and CMake
There's absolutely no reason we can't support two different ways of deployment, apart from my unwilligness to maintain two. Which just means that someone else has to step up to do it. How does what you wrote above relate to the quote below? Daniel Teske wrote: I don't want to maintain multiple ways. That's beyond what I consider reasonable effort for the benefit. (Others can disagree and volunteer.) I want one solution. Are you now saying multiple solutions is ok? In both cases I stated my wish that I don't want to mantain two methods. Also in both cases I stated that others can and should volunteer if they want more. To answer the first question. I see only miniscule differences in what I wrote in those two cases. To answer the second qusetion, no I'm not saying multiple solutions is ok, since that's grammatically wrong. daniel ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Remote Linux plugin and CMake
I have the choice between supporting an existing patch that comes from a CMake user which is declared by him as serving the purpose and supporting an approach that does not have a patch A superior approach which will serve more than one user. It will instead serve all CMake users. Clearly Oleksii prefers his solution, and no user has actually spoken up in a thread which specifally asked users to speak up. , and for which I rate the chance of showing up at all at about zero. Why is your expectation so low? Why do you think I'm on this mailing list and this thread. Maybe you should tell us? Because your actions don't speak of any interest in Creator. I see one patch in Creator which adjusted Creator's code to a api change in qt. Why do you think I keep asking Tobias Hunger about his build configuration patches? He recommended a few weeks ago that I wait for them before diving into the CMake related code in creator. It has been pointed out that both approaches can be implemented, and can co-exist. That is not correct. They can not co-exist. What is installed by running make install may not be the same as what is in the deployment file. You would have to have UI to allow the user to configure which one is authoritive. There's absolutely no reason we can't support two different ways of deployment, apart from my unwilligness to maintain two. Which just means that someone else has to step up to do it. Yes, I can implement it. I thought my recommended approach was already rejected. Please be more clear about that. Or maybe I need to wait for Daniels decision? I have already decided, there's a a mail in this thread about that. We'll go with the patch from Oleksii. daniel ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Remote Linux plugin and CMake
Maybe the solution is to simply support both. List of files for some cases, 'make install' for other. User selects. Or can be determined by the presence of the 'CMakeDeployment.txt'. Or something like that. I don't want to maintain multiple ways. That's beyond what I consider reasonable effort for the benefit. (Others can disagree and volunteer.) I want one solution. I'm pretty confident that all 3 solutions I did suggest are implementable and don't take unreasonable effort. The purpose of the mail though wasn't so much to discuss how to implement that. I want to know how many people want such a feature. And secondly how they would want Creator to integrate with their cmake project. daniel ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Qnx Plugin status for 3.0
It will also clarify the maintenance. Right now, the plugin is not even listed here: http://qt-project.org/wiki/Maintainers I would like to propose: * Tobias Nätterlund for Qnx maintainer: Tobias is the original author of the Qnx and BlackBerry plugin, and is working closely with the people using Qnx daily at KDAB (means they kick him every time something does not work) * El Mehdi Fekari for BlackBerry maintainer: Mehdi is in charge of the Qt Creator plugin for BlackBerry, and has already done his share of work on it, obviously testing the plugin regularly, even on unreleased NDK Only approvers can become maintainers.[1] Also the right mailing list for proposing maintainers is d...@qt-project.org not qt-project. daniel [1] See http://qt-project.org/wiki/The_Qt_Governance_Model ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] use of std::function in creator
On Thursday 15 Aug 2013 14:28:42 Mohamed Fawzi wrote: Hi there were already discussions on using C++11, but I would like to use something that is a bit older. std::function can be very useful to define callbacks, and thus improving the api very much. It was already available as part of the technical report 1: #include tr1/functional std::tr1::function windows released that in 2008, and gcc/clang should work even earlier. libstdc++ support is not complete (custom allocator are not supported), but if I understand it correctly (you cannot pass custom allocators to the function type) it should be fine. So with a couple of #ifdef and typedefs one could use it already. What do other think? I'd be in favour of that if we restrict ourselves to the subset of tr1 that was later included in C++11. tr1 is widely supported and it's standard c++ now. Though I want to see how complicated the code is that works on all compilers. daniel ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] BareMetal Target Plugin
On Tuesday 13 Aug 2013 17:27:21 Tim Sander wrote: Am Dienstag, 13. August 2013, 12:06:10 schrieb Daniel Teske: I have a BareMetalKit up and running. I have two problems right now: * the Kit and the Device Dialog apear twice. Probably i changed the provider name or s.th. and now i have some inconsistencies? No idea. Somehow i changed s.th. in the baremetal.pluginspec and after a rebuild the double entries where gone. * If i disable qt in the kit then i can't select the kit in the QMake dialog even if config -= qt is set. Any idea where this check might be hidden? That's correct if you are using .pro files you need a qt version, as those need a qmake (and various auxilary files). Yes, but if i am cross building i can have a local qmake and a target without qt and i can build the binary for the target without qt on target with a local qmake as build system. So if you have a qmake project with config -= qt there is no reason to grey out that widget if no qt version is set. You'll need at least the mkspec/default, mkspec/*.pri and mkspec/features (and for qt5 mkspec/modules) for qmake to work. The only additional requirement Creator has are that the directories returned by qmake -query QT_HOST_BINS and qmake -query QT_INSTALL_HEADERS have to exist. Those are to catch qt installations that are incomplete, which does happen from time to time. daniel ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Dev: add/remove folder in File System view
i did setup gerrit yesterday. So i can start contributing soon. However, at the moment the add/remove folder is not available in the project manager view (for any kind of project) but in the file-system view which works independent from projects. Okay. That one doesn't allow for adding files though? And I'd imagine adding folders is for later adding files into them. The generic project managers purpose is to be build-system agnostic. It knows almost nothing about the way the project is built, and that should stay that way. The main reason for its existance is to provide enough information to Creator that e.g. the code model and the locator can do their work. In the private mail you send, you mentioned parsing makefiles for their target. That would not fit into what the generic project manager is. (That the generic project manager has it's own specific makestep is just a relict from the first implementation.) I understand that. So my question is: if my whishes don't fit into the genric projetc manager, the other option would be to introduce a new project-manager specific for Makefile-based projects. Is that the woy to go? A new project manager is always a possibility, but that's quite a bit of work. What build system are you using? daniel ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] updating QtCreator
There are also two new entries under the automatic section for Android, x86 and armv7. Both have a red icon and the details say that there is not a compiler installed that can support these. How can I remove these? Those are created if you configure a path to a android ndk in the android settings. daniel ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] designer plugins
Hi Have you read the manual? It has answers to all your questions: http://qt-project.org/doc/qtcreator-2.7/adding-plugins.html If there are incorrect information on that page or if you are missing something after reading that, open a documentation bug report. In general though, the answer is that Creator is not different from a standalone designer. E. g. the requirement to compile the plugins with the same compiler as creator is compiled is exactly the same as it is for designer. daniel ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] CMake and Macros
On Saturday 09 Mar 2013 00:22:35 Peter Kümmel wrote: Could someone please test if the macro detection works for cmake projects on Windows? I filed a bug report but it seems it's not reproducible: https://bugreports.qt-project.org/browse/QTCREATORBUG-8864 No, that is not the problem. The problem is that you do write bug reports that are just a waste of time. And I'm no longer willing to invest a lot of time per bug report to figure which parts of your bug reports are completly misleading and should be ignored, and which parts actually describe the problem. There is indeed a problem with macros, but your bug report makes it impossible to figure that out. Let's start: - Your title of the bug report claims: compile flag detection is broken The actual bug has absolutely nothing to do with compile flags, nor does your CMakeLists.txt contain ANY compile flags at all. So this part of the bug report is misleading. - Then you write: Parsing flags.make fails: On Windows there file is at CMakeFiles/foo.dir but creator looks for CMakeFiles/all.dir/flags.make Now this is apparently you trying to read the code, or testing some code. And it turns out that you did that wrong. The code is reading the right files, and thus this portion of the bug report is again misleading. And when using the ninja generator there is no flags.make at all. Which is completly irrelevant to the regression. Now, so far, there has been zero mentioning of MACROS in your description. This is going to change, since your next sentence is: Reverting 20cfccd75 helps. That actually is correct, but since you never actually succeded in even coming close to describing the actual bug. You wrote a bug report which didn't even contain anything that come close to mentioning the actual regression. Amazingly you manage to actually describe the problem now in your email. daniel ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] QtCreator customization: creating new project wizard, Kit and device configuration (creating an Ubuntu SDK plugin)
1) Being able to create a New Ubuntu project (since Ubuntu projects utilize Ubuntu QML components): to do this I need to understand how QtCreator wizards are created. Where can I find more informations about it? I know, there is source code, but it's not a small project :P if you can point me to some documentation I would apreciate it :) The documentation is here: http://doc.qt.digia.com/qtcreator-extending/ That does contain some information but quite possible not everything you need to know. 3) Adding a Add new Ubuntu Device in Options-Devices: so people will be able to add it. For the moment what we need is not different from what Generic Linux Device already offers, but I'd like to know how to customize it, just in case we will need something different in the future. Which part of the code do I have to customize? By creating your own devicefactory. 4) Can/must the 3 previous steps be implemented with a specific Ubuntu plugin (just like the BlackBerry one for example) or I must modify QtCreator source code here and there? All of that should be implementable in a plugin, but the experience shows that every new target needs some adjustments in the general code. daniel ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Creating new project templates
On Wednesday 28 Nov 2012 10:27:18 Harri Pasanen wrote: On 11/28/2012 09:31 AM, Ziller Eike wrote: On 27.11.2012, at 23:28, Harri Pasanen ha...@mpaja.com wrote: I'm wondering if there is a public api/entry point to create new or modify existing new project templates? http://doc.qt.digia.com/qtcreator-extending/index.html Generating Domain Specific Code and Templates Thanks! exactly what I was looking for. This does not appear to be part of Qt Creator 2.6.0 manual (.qch), I wonder why? For instance, I'd like to tweak the existing Non-Qt Project - Plain C++ Project (CMake Build) so that I could do a Cocos2d-x project. Kind of cool would be able to do also Android Cocos2d-x builds from Qt-Creator directly, in the same fashion as Necessitas. What prevents you from doing that now? Perhaps nothing, I haven't tried yet. So far I have a simple cmake project that can I can use to build,run,debug HelloCpp using cocos2d-x-2.0 on linux, from Qt Creator. That appears to be working fine. Boosted by that success, I figured I'll try if I can tweak it to build an Android version. I believe OpenCV project port to Android used cmake, so hopefully it is straight forward. Ideally I would be able to use the Kits, deploy to device/emulator, run debug on those as well. The actual deploy step is somewhat dependant on the qmake project manager. Detangling that is on my todo list. daniel ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Type of the tests of QtCreator
I would like to ask about general topic of tests(unit, functional, regression and so on). What kind of tests do we have for testing of QtCreator? I know that there are some unit tests for completion, code generation(only tests the InsertionPointLocator) and for FakeVim plugin. I have seen also scripts for Squish but as far as I understand Squish is used internally(it is not possible for external developers to use it).There is also Jenkins which is used mostly for building snapshots. Those and also starting a debug Creator with -test all will run some autotests in a running Creator. What about integration unit tests results and other kind of available test results there(run all kind of tests after building and checking the results)? There are no integration tests. daniel ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Is MSVC on Windows supported?
Try a git clean -dxf there. Yes, all is clean. Amazing, instead of actually trying the suggestion, you did what? $ git status # On master nothing to commit (working directory clean) But I found a way: $ rm .gitignore $ git clean -df Seems .gitignore allows files which break the build, git clean removed some .pluginspec files. ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
[Qt-creator] Symbian support removed
Hi, somewhat to my suprise, since I'm the maintainer [1], the Symbian support was removed with ae23d50576ac076aeb22a3d56abdb5e2c1d9b327. I actually intended to wait a little bit longer if someone would be interested in that code and release it as is with 2.6. Tobias did test it a little bit after his refacotring, but it's likely that some things were broken. Since it looks very unlikely that anyone would want to take it up and somewhat likely that the Symbian support in 2.6 would have been subpar anyway, I won't revert the removal. If *you* would want to step up, now would be the last chance to say so. Also I'll close all remaining symbian bugs now as out of scope. daniel PS: Also I think, bigger feature removals should be first announced on the mailing lists as a matter of principle, before actually submitting it. [1] Only technically since I'm responsible for anything unmaintained under the Project Management Targets component. ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Build Creator itself and make it deployable on Mac
On Thursday 21 Jun 2012 17:19:28 ext Stephen Chu wrote: Hi. I finally managed to build Creator itself from git source. My question is how do I make it a self-contained app bundle like the official release? There are so many different parts and helpers in it. I am not sure I can find and copy all of them manually. Is there a post-build package making script somewhere? iirc, make dmg should create a dmg. daniel ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Stepping down
On Friday 01 Jun 2012 13:37:48 Paweł Polański wrote: Hi, due to the fact that I have no longer enough time to maintain Symbian in Qt Creator's Project Management Targets I would like to step down from this position. My symbian knowledge is rather limited. I will be looking over any gerrit change requests or bug reports, but I would consider the symbian support to be in pratice unmaintained. That is, I'm seeking help with that part of Creator, be it by submitting patches or by voluntering for maintainer, as otherwise it'll will break and will get removed eventually. daniel ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
[Qt-creator] Android plugin and Qt Creator development
Hi, as you might have heard, a few days ago most of the android plugin was merged to Qt Creator master. There's still a change outstanding [1], but there were also some hacks in the android plugin code that aren't merged to the master branch. I'd like to start a discussion on how to develop the plugin in the future, which prevents unneeded divergence between the code in Qt Creator master and the code in the Necessitas repositories. Before we can discuss that properly, we need to know though, if and how many changes the Necessitas Qt Creator needs on top of Qt Creator master. As I recall we dropped a few things while reviewing because they looked too hacky for master. Also we probably need to have some idea how often the Necessitas SDK is going to be released and whether you prefer to base your releases on master or release branches, e.g. 2.6. I think the goal should be move the development of the Necessitas Qt Creator onto gerrit. As to the Bug tracker and mailing lists, I would propose that nothing changes. There's still some confusion about the mailing lists and bug trackers for Necessitas from the last move, as such adding another bug tracker or a mailinglist would do no good at the moment. (Especially with only the Creator part being moved.) Nevertheless any bugs that are reported against the android plugin in bugreports.qt-project.org will be handled. daniel [1] https://codereview.qt-project.org/#change,21980 ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Strange behavior of Utils::FileSystemWatcher
Utils::FileSystemWatcher solves only one is issue of QFileSystemWatcher. That is on some platforms watching file systems is pretty expensive and has a significant overhead per QFileSystemWatcher. Utils::FileSystemWatcher does not actually solve the problem that QFileSystemWatcher looses the watch if a file is replaced by a delete + rename, like you described: However, when I switched I've discovered very strange behavior: I get signal fileChanged for certain file only once. When it's modified second time I get no signal for this file (if I modify ither fiiles I get signal first time but only once for each file). We probably should get rid of Utils::FileSystemWatcher, or fix it to actually work better then QFileSystemWatcher. If I switch back to QFSW everything works fine again. That can't be, if you don't readd the file after a fileChanged() signal, you won't get a second signal out of QFSW either. Does anybody have a clue? Use a dummy IDocument derived class, for example take a look at WatchableFile in maemoglobal.h daniel ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
Re: [Qt-creator] Strange behavior of Utils::FileSystemWatcher
Does anybody have a clue? Use a dummy IDocument derived class, for example take a look at WatchableFile in maemoglobal.h Because the DocumentManger tries to ensure that the file is watched after it has been changed. Do note though, that whatever the DocumentManager does, it does so on top of QFileSystemWatcher, which is build on top of whatever the OS supports. And those APIs are rather less then ideal. daniel ___ Qt-creator mailing list Qt-creator@qt-project.org http://lists.qt-project.org/mailman/listinfo/qt-creator
