Qt Creator 2.6.0 beta released

Published Tuesday September 11th, 2012 | by

This prerelease of Qt Creator 2.6 gives you a an early impression of the many new features and the bigger changes that we will introduce with this release. And of course it is your chance to give us last feedback and help us find bugs and problems :)

Let’s start with the most apparent change: We replaced what we called “Target” before in Qt Creator, with what we call “Kits”.

“Targets” were basically a setting for something related to the device type, e.g. “Desktop”, “MeeGo Device” and so on. They were fixed, hardwired into Qt Creator, and came with defaults for build settings like which tool chain and debugger and sysroot to use. Some settings were unclear how they were chosen (like the Qt version). Some combinations of settings were prevented, for example the available tool chains were reduced to the ones Qt Creator thought would work with the Qt version you chose. You’d add support for a “target” to your project in Projects mode, and build and run settings were set up with the defaults. Deviating from the defaults required manually changing all build and run configurations.

“Kits” basically specify which combinations of device, compiler, debugger, and Qt version (and possibly other settings) you want to develop for. They are user defined, and the set of options in the kits is extensible from (binary) plugins. You define kits through adding them in Tools > Options > Build & Run > Kits, where you then freely choose each individual settings value in the kit independent from all others (meaning that you can for example choose any compiler that you configured in Tools > Options > Build & Run > Compilers, independent from what Qt version you set). If Qt Creator thinks that a certain combination of settings will not work, it prints a warning, but it does not prevent you from knowing better ;). You add support for a kit to your project in Projects mode similar to it was before with “targets”. You can change a kit to use different settings, and any change is automatically reflected on all projects that use that kit. Qt Creator sets up a default kit on first run, with settings derived from the tools found in your PATH.

 

Regarding new features, we merged both the Android support and the QNX support into Qt Creator 2.6. This is great news on the “platform support” side of things, and even more impressive because we did all the above mentioned refactoring regarding targets and kits simultaneously. Thanks to all that made this happen!

These new supported target platforms are unfortunately shadowed a bit by the fact that we also had to drop Symbian support because of missing maintainer.

New are also experimental support for Gerrit, which allows you to browse your current changes and browse the diffs or cherry-pick/pull directly from within Qt Creator, and experimental support for the ClearCase version control system. There have been lots of other smaller and larger changes and fixes, like compilation of single files for qmake projects, more fixes for C++11, and a UI for setting temporary breakpoints, just to name a few. You find the more complete changes list here.

All in all 75 people have contributed to this release (see the end of the changes file), a big Thank You to all of them!

Get binaries and source code from our download page.

Note to Mac OS X Mountain Lion users: The application is not signed yet, to open it you need to right click and select “Open” from the context menu the first time you run it.

Note to Windows and Linux users: We are currently in the process of moving the package build infrastructure to the Qt Project. Unfortunately we cannot offer you installers for this release, simply uncompress the 7z files and run the Qt Creator binary located in the bin/ directory.

Did you like this? Share it:

Posted in migrate, Qt, QtCreator

73 comments to Qt Creator 2.6.0 beta released

kamre says:

Any news about clang integration? Current parser is not very accurate…

Dcow says:

Cool! What about support Qt5 in qmlDesinger?

JanneK says:

Can I save Kits and export them? I’m in a middle of avoiding to implementing my own project manager just because I want to default to different qmlrunner from qmlviewer for all projects (on multiple machines).

I guess I’ll check it out, nice work.

Andre' says:

@kamre: No recent changes. And note that clang alone would not be a full solution either, as it trades “sometimes inaccurate, but fast” vs “accurate, but (sometimes extremely) slow”. It does not improve overall user experience that way.

@dcow: Not in the works currrently.

@JanneK: No(t yet). Sounds like good to have though. The problems here might come from paths in the sub-items that are specific to a single installation. But maybe that’s managable.

kkoehne says:

@JanneK: The choice of the qml runtime isn’t part of a Kit, but rather a per-project setting (since e.g. for Qt5, there’s both qmlviewer and qmlscene). So saving the Kit won’t help you at the moment … Anyhow, feel free to file a suggestion describing your exact use case, we could think about introducing a configurable ‘qml runtime’ .

Slavko says:

Great work guys, thank you!!

Gastal says:

What about qbs support?

Michael says:

Nice update. Great to see C++11 lambdas getting some attention.

Here is my fix wishlist as of 2.5:
-QTCreator doesnt parse cmake project defines, so C++ source code can be greyed out when it shouldnt be.
-On Windows it opens up files with upper case letters and converts them all to lower case. The result of this is that CVS tools stop working on the file.
-It doesnt understand build errors from the Intel Compiler. You cant double click on them in the Issues list.
-Even with the GCC compiler, if the file path is relative to the build directory and not absolute, then the issues list still wont find that file. It would be good for it to look for files relative to the current build directory.

nacho says:

hi, what about multilanguage?

Michael says:

Another thing for my wishlist:

Everytime I setup a CMake project for a debug build, I have to type:
-DCMAKE_BUILD_TYPE=debug
in the cmake args in the wizard. It would be great to add this as a checkbox in the CMake wizard.

Andre' says:

@Michael: Wishlists and actual bug reports are best handled at bugreports.qt-project.org.

@nacho: What do you mean by “multilanguage”?

Gerald says:

“Class view” doesn’t work.
Tested with old and with new created project.
(WinXP SP3 32bit, QtCreator 2.5.82)

kamre says:

@Andre': i am ready to wait for parsing (as for compiling), correct/reliable code navigation is extremely helpful and will greatly “improve overall user experience”; reparsing as i edit is another thing and some balance should be kept for good user experience.

Andre' says:

@kamre: it’s the old story, see also the extensive discussions on the mailing list. (a) 100% correctness is _not achievable_ by definition (e.g. same code included in different contexts resulting in different interpretations). (b) “modern C++” can easily spend half an hour on one translation unit (google e.g.”c++ spirit compilation time”). The current situation _is_ a compromise, reasonably suited for the kind of project Qt Creator itself is. It is understood that “erring a bit more on the correct side by sacrificing some speed” would be in order, too, but going “all clang” would not result in a good balance.

If you are really interested in the contributing to the clang side of that shoot-out I’d suggest to check out the wip/clang branch and bring it to a state where speed can be considered “remotely acceptable”. When we are there, we can re-start the discussion with a clean slate.

Desert says:

>” Not in the works currrently.”
@Andre really? so, when 2.6 gets released this means it will have a Quick 2.0 wizard, but no Designer support? This seems odd.

Vinipsmaker says:

> Fixed lambda formatting issues

Does this also fixes initializer list issues?

Mike7b4 says:

Offtopic but in longer run it would be epiic if qtcreator IDE could be used for embedded low/midend arm often used with gcc toolchains and C only. I know not directly related to qt projects but actually qtcreator IDE is better than bloated eclipse in many ways. So sick of eclipse at my work on lowend embedded.

Howerer dont know how much is pluggabe in qtcreator and if even possible…

Actually this could also push qt forward cause if we did have a good IDE on lowend embedded it would be natural choice using this IDE + QT when working with GUi apps on mid/hiend ARM :)

Dave says:

@Michael – go Tools, Options, Build & Run, Tool Chains and add Linux ICC (or whatever).

Andre' says:

@Mike7b4: What kind of setup would you like to handle exactly?

Fahmy says:

Well done! I luv Qt <3 Hope this framework will go on even Nokia don't want it.

Cristian says:

QtCreator is *the IDE* for Linux. It doesn’t have obscure bugs like Eclipse has when run under x11vnc. Eclipse will fail to start (out of memory) because of data present in clipboard. FAIL :)

QtCreator 2.6 will be awesome.

Eike Ziller says:

@Michael: you have to tell Qt Creator that you use icc in the kit’s settings (Options > Build & Run > Compilers, add your ICC compiler there, switch to the Kits tab and let your kit use your ICC compiler)

Guildem says:

hi, thanks for this beta, but i don’t have Android compilation option, and don’t find a way to add it… some tips for me ?
i’m on archlinux x64 and downloaded the x64 7z package

Great work! It’s great to see the merging of Android and QNX work. Looks like the political barriers that prevented it are finally crumbled down.

Eike Ziller says:

@guildem you need a android qt version, tool chain / sysroot, etc, and configure a Kit to use all that. http://necessitas.kde.org

Eike Ziller says:

@flavio I’m not aware of any political barriers that would have prevented merging of Android and QNX, though I *am* aware of Android and QNX support upstreaming not making the feature freeze for Qt Creator 2.5 ;)

Mahesh says:

How to add a kit for the new project.? i’m not able to do it

Tobias Hunger says:

Mahesh: Check the Kit in Tools->Options->Build & Run->Kits. Does it have all the information needed for your project? For qmake that is a Qt version.

Ray Donnelly says:

Great work guys.

I’ve compared our Necessitas Alpha 4 source for the Android plugin with then 2.6.0 beta source and I’d caution people that they’d be better off using Necessitas Alpha 4 as there’s 5 or 6 problems that we’ve fixed in A4 that are still broken in 2.6.0 beta.

Andre' says:

@Ray Donelly: What are these 5 or 6 problems, and could we such fixes perhaps include in 2.6 “upstream”?

Avassen says:

Thanks! I was waiting impatiently the new version of my favorite IDE.
But i found a bug, reported here:
https://bugreports.qt-project.org/browse/QTCREATORBUG-7872

RM says:

Why don’t you drop QtCreator and use Eclipse instead? Sure it’s Java and a bit slower, but it would significantly reduce the amount of work you would need to do with regards to the IDE side of things.

I’m sure lots of people will scream/shout at this (maybe some won’t) but from an business/effort perspective, Qt should stand on the shoulders of giants as they say.

Ray Donnelly says:

@Andre': Some of this isn’t upstreamed because it’s a bit too hacky and some of it because it was already rejected (BogDan will know more). We plan to merge with 2.6.0 beta, then do an update to Alpha 4 and get feedback.

1. On Windows, readelf output parsing is wrong (CRLF) so the needed libraries are not auto-detected (parseSharedLibs in androidpackagecreationstep.cpp)
2. void addToEnvironment(const ProjectExplorer::Profile *p, Utils::Environment &env) const; missing from AndroidQtVersion which BogDan had to add (as a bit of a hack IIRC – see AndroidPackageCreationWidget::initGui()) to make sure the Android settings were picked up by qmake, otherwise *sometimes* the settings were wrong (using the defaults in mkspecs/android-g++/qmake.conf)
3. QML Debugging support missing from AndroidDebugSupport and androidrunconfiguration.cpp
4. qtSoPaths() missing so solibSearchPath will not be correct.
5. On Windows, we provide our own ma-make.exe to work around deficiencies in mingw32-make.exe and MSYS make.exe and also to make sure that some arbitrary make.exe on the users’ PATH isn’t run instead of our own. For this to work with subdirs projects, you need to launch Necessitas Qt Creator via necessitas.bat so that it adds QtCreator/bin to PATH before running QtCreator. I’m not sure whether the mingw32-make.exe (I guess?) you provide for Windows will work for Android (it certainly won’t while we explicitly call ma-make.exe), but our make allows -jN (correctly) thanks to including Trok Runkel’s jobserver patch. The make we use is at: https://mingw-and-ndk.googlecode.com/files/make.exe

@RM: How about because Eclipse sucks massively and Qt Creator is awesome (IMHO, the best IDE ever created)?

Thanks,

Ray.

Cristian says:

@RM see my comment at #21.

The x11vnc and clipboard bug has been reported for Eclipse since 5 years ago. Actually there are two bugs reported:
Bug 205678 – [Clipboard] Using x11vnc with clipboard transfer causes eclipse to OOM
Bug 252692 – [DND] Out of memory error when starting brand new eclipse 3.4 when big amt on clipboard

And it just a matter of principle of having a C++ IDE to develop C++ (Qt) Applications.

Ray Donnelly says:

Also, there’s not many better ways to test (parts of!) Qt than write Qt Creator with it.

Eike Ziller says:

@RM: aside from what Ray said, that’s what we (partly) did in the early days (before Qt Creator) and know what it would mean:
1) Eclipse sucks (actually that’s what Ray said, sorry for the repetition)
2) Bridging between Java and C++ eats resources and sucks (and we use and share C++ parts)
3) Just following the changes in Eclipse (that one has no control over) to keep existing functionality running eats resources and sucks
4) Setting C++/Qt experts on a Java task, or having Java experts on a task that requires Qt expertise (which would then also not be good at helping the Qt framework itself) is not very good for synergy, and to the contrary, sucks

Btw regarding 4) and synergy, it’s amazing how many bugs have been fixed in Qt because of Qt Creator :)

aportale says:

@RM: Here is the Eclipse Plugin which we did back then: http://labs.qt.nokia.com/2007/07/11/develop-qt-applications-in-eclipse/

Steve Moore says:

I am a little confused on the point of having to configure the tool chain in Creator. A version of Qt is built against a specific compiler. Under what circumstances is it useful to specify a different tool chain? If I just use qmake from the command line it uses my default mkspec which has all the compiler info already in it and everything works. In my environment adding this stuff and then Qt Creator overriding the default mkspec will usually break my embedded arm builds. I then have to go override the mkspec to get it to just use the default mkspec again. I build for X11, win32, and embedded arm devices. What is the utility of having this information in Qt Creator?

Carlos says:

I find incredible that Nokia drops support to the IDE that allows development to the OS that powers most of the smartphones they sell.
I need Symbian support, Is there any problem using Qt Creator in Nokia SDK for Symbian projects and Qt Creator 2.6 for other OSs?

Matriarch says:

I love you all for new C/C++ macro highlighting/navigating/refracting. It will helps me in every day of my work life (C/C++ developer). Awesome job :-* !

CDC says:

@Carlos: Symbian is dead, Qt sold to Digia. Why should they bother with Symbian support any longer?

Tobias Hunger says:

@Carlos: The alternative would have been to deliver basically untested code. I think recomending a well tested Qt Creator 2.4 for symbian development is the better option than offering a unstable IDE to devleopers. If somebody wants to take over maintainership of the code: It is still available in the git history… the code will need a lot of work to get into a state where we can consider adding it back again!

There should be no problem using the Qt SDK Creator for Symbian work and the 2.6 version for everything else. I would recommend using separate directories for the settings though, as we do not test running older versions after a newer version has updtaed the settings.

“-settingspath” is the argument used to change this.

Tobias Hunger says:

@Carlos: The dicision was between recommending a well tested Qt Creator 2.4 to Symbian developers or to offer a Qt Creator 2.6 with reduced Symbian specific functionality to them (that was not at all tested with Symbian phones!). If somebody steps up to maintain the platform: Great! The code is still available in the git history, but will need a lot of work to get into a state where we can consider to add it again.

Running Qt Creator from the SDK for Symbian development and Qt Creator 2.6 for everything else is fine. I would recommend using “-settingspath /some/dir” with one of them to keep the configuration of the two separate. We do not test how older creator versions fare once a newer version updated the configuration.

Tobias Hunger says:

Sorry for the double post… I wrote the second one after waiting for 5 min at which point I had assumed that my browser failed to submit it due to JS being turned off for the site:-(

I know that Eclipse CDT is A LOT heavier (to say the least) and has some pretty nasty bugs, but Qt Creator, even though it works great with the features it has implemented right now, there is still missing a lot of the basics like a visual diff integrated into the editor, or support for multiple screens (at work, It’s basic to have two screens, usually one vertical and one horizontal).

Does anyone know if there’s already a request for visual diff and multiple screen support on Qt Creator? it’s odd to me that Qt Creator has been around long enough for people actually needing a visual diff.

Carlos says:

@CDC, @Tobias, I know everything that happened to Symbian but I hoped that the promise to support it until 2015 included developer tools maintenance.

@Tobias, thanks for your advice.

RM says:

I’m afraid I have to agree with @Raul Guerrero. I have used Eclipse quite extensively and now I’m using QtCreator – so I am actually able to compare them quite well. Every developer likes to stick to what they know – which is why QtCreator users says eclipse sucks and vice versa. But realistically Eclipse is far better than QtCreator – there’s more to an IDE than just the support it provides for the language. For example the SVN client in Eclipse is better, the visual diff is better, it’s the whole eco system around it that also has a big impact. Once you know the quirks of Eclipse you’ll wonder how you ever lived without it.

As for the features that are missing – why spend time adding features to QtCreator when it would be quicker to add those to Eclipse?

As for saying Eclipse is heavier – 8GB of ram is a mere £30, peanuts really.

Ray Donnelly says:

@RM: On behalf of the rest of us delusional Qt Creator fans, thanks for your kind gift of some realism, the Qt Creator developers have explained their reasoning for not using Eclipse and yet you persist? How about proving them all wrong and making Eclipse the #1 IDE for Qt?

Sergey Shambir says:

>But realistically Eclipse is far better than QtCreator – there’s more to an IDE
You call it better just because it has more functions. But amount of functions itself has no matter. Most programmers never used all Eclipse possibilities, because nobody can use 30 languages simultaneously; live is too short to read all instructions. QtCreator looks like designed to keep programmer’s time.
Also, look this: http://developer.ubuntu.com/get-started/ What is the first alternative to quickly? ;)
P.S. sorry for poor english

fonzi337 says:

I’m happy to see more and more C++11 features being supported by Qt Creator. :)

By the way, I realize Qt 5 isn’t out yet, but when can we expect to see a version of Qt Creator that supports Qt 5? I’ve been using the Qt 5 beta and I have had to manually modify my include path for the Qt libraries to get code completion; it would also be nice to have Qt 5 project templates (particularly for Qt Quick 2.0 projects). Any chance these changes will be rolled out in Qt Creator before the Qt 5 final release?

Regarding the Eclipse vs. Qt Creator discussion: Prior to a project I am working on, I hadn’t really used either. I looked into Eclipse before, but it just feels so bloated. When I start up Eclipse or Visual Studio, I feel like I’m starting up an entire operating system. I absolutely love Qt Creator’s lightweight feel. It starts up/shuts down fast and the UI feels minimalistic yet provides everything you need for Qt development.

While making an Eclipse plugin instead of Qt Creator may have saved some development time, I think they made a fantastic application with Qt Creator and I think it has been time well-spent.

bmanc says:

I use both QtCreator and Eclipse (for Java and Python). I’ve tried Eclipse CDT a number of times – and it doesn’t come close to QtCreator. The notion of a light weight feel with QtCreator is true. Eclipse CDT is too painful, and wastes too much of the developers time. Despite it’s power it’s not designed for the C++ tool chains. QtCreator has that necessary focus for developing C++.

That said I still have to say it’s unbelievable that the multi-screen issue is still being ignored. That is my one biggest gripes about QtCreator as beautiful as it maybe – given modern setups that’s one place where Creator is causing me to waste time. The issue has been around for a long time in the task list.

RefaQtor says:

I’d like to echo @Mike7b4’s interest in configuring compilers for other micros (msp430, avr). I mean to look into the plugin system and see if I can make some effort in that direction.

Regarding ARM development, I’ve had just fantastic results daily coding Qt applications (console and GUI apps) on my Windows or Linux development machines, then running and debugging through QtCreator by deploying to a linux (ARM – BeagleBone) remote host. Getting all the debug abilities of stepping through code and terminal feedback, just as though it were running on my desktop. I’ve enjoyed that ability daily with the current QtCreator, without any tweaking of mkspec’s, etc.

Eike Ziller says:

@fonzi: Qt Quick 2.0 application template should be part of the 2.6 beta release afaik. It might not be shown in the “new” dialog if you don’t have a qt5 qt version registered though. Otherwise Qt 5 seems to unfortunately be quite a moving target still, but we try to keep up with it. It would be great if you guys could help by checking Qt Creator snapshots (http://builds.qt-project.org/view/Qt%20Creator/) against recent Qt5 (best from git) and creating bugreports :)

Danny says:

The editor seems to have the same corruption problem on OSX that plagued the 2.5.x builds. If you scroll, the text drawing screws up. This is a regression.

It doesn’t display the colors for my custom themes correctly. Do these need to be re-created?

Also, I noticed that LLDB was listed as debugger for my Qt installation in the ‘kits’ screen but it wouldn’t let me select it. What do I need to do to get the LLDB debugger working with Qt? (I’m working on a non-Qt C++ project right now).

Eike Ziller says:

@danny: Regarding the editor, yes, that was a fix in Qt that we missed to pull over to the new infrastructure. It’s fixed in the new snapshots on builds.qt-project.org

fonzi337 says:

@Eike: Thanks for the heads up. I only just tried the beta and noticed there is a Qt Quick 2 project template. That is great! :)

I did notice that the code created by the template is formatted a bit strangely (e.g., it includes extra spaces within many lines of the generated code). Not a big deal, and I can’t complain given that Qt 5 isn’t out yet, but just thought I’d let you know.

abdallah says:

whats about python on Qt creator??

Sergey Shambir says:

@abdallah: Tobias said about half-year ago that nor Nokia neither Digia now interested in python (or just have more important tasks). Python support should be added by community – probably it will be added in the next year ;)

Tobias Hunger says:

Sergey: Just to clarify this: I said that our team in Nokia had no interest in adding Python support.

I can not speak for all of Nokia and I definitely not for Digia.

7 says:

Qt already supports a interpreted language – JS. I don’t think yet another language is needed to fragment and steal development resources further. Frankly I Hope with the move to Digia C++ will return back into main focus.

Mika Hanhijärvi says:

> These new supported target platforms are unfortunately shadowed a bit by the fact
> that we also had to drop Symbian support because of missing maintainer.

So. Qt Creator 2.6 will be 100% useless for me :-P

Stuffy says:

Please help, i’m new with qtcreator, my prob is that i can’t see the application option in the create new project option

Mika Hanhijärvi says:

@ CDC

Rubbish. There is still millions of Symbian users and lots of us developers creating Symbian applications. Symbian is far from dead.

@Carlos

> I know everything that happened to Symbian but I hoped that the
> promise to support it until 2015 included developer tools maintenance.

Yep. It was said that “Symbian will be supported atleast until year 2016″. But it looks like that promise was a pure lie.

7 says:

@Mika Hanhijärvi – maybe it is time to move to another platform… or another framework.

Eike Ziller says:

@abdallah: There is python highlighting support through the “generic” highlighting (kate files), and there even is a python debugger, though I don’t know the state of the latter :). Aside from that I don’t know of any plans regarding python.

Gates.lu says:

I found the Qt STL Activate completion in qtc2.6.2 dosen’t work, such as QStringList :(

Jake says:

Great work :).
But still no multi screen. As long there won’t be support for multi screen, Qt Creator will never be a possible alternative or maybe even a competition to Visual Studio or Eclipse.

Andre says:

@RM: You drew quite some flak already, let me try with reason ;-)

The “business reason” to have Qt Creator is _not_ to have “yet another C++ IDE”.

Of course having a reasonably well working development process is a “must have” pre-requisite for successful use of Qt, and making sure there exists at least one such process therefore _is_ a business reason. Providing a cross-platform IDE that integrates well with Qt is one way to make sure that there’s a such a “reasonably well working development process”, but, of course, not the only one.

However, there are more actual business reasons to have Qt Creator.

For one, it serves as a show case of what can be achieved _with_ Qt. A lot of people simply do not _believe_ that you can have working, non-trivial cross-platform applications. Qt Creator is a convenient example that such beasts exist. There is not much platform-specific code inside, and people aren free to check the sources.

Qt Creator also serves as a test bed _for_ Qt. New Qt technologies get integrated and get early “real world exposure”, feedback, and perhaps correction _before_ a full Qt release gets pushed out. While Qt gets quite a bit of regular testing, some issues only show up in a somewhat more complex setup. A recent example for that would be QTBUG-27039, which, had it gone unnoticed, caused a very… “interesting…” Qt 5.0 release (and, perhaps, a price raise for brown paper bags). Another typical kind of issues in Qt that are discovered by “just having Qt Creator” are performance issues, and issues that turn up in “weird” configurations, like broken graphic cards, strange firewall settings etc, i.e. anything that you typically can’t test in a
moderately sized CI system.

So, now. You claim that Eclipse “would significantly reduce the amount of work you would need to do with regards to the IDE side of things”. To some degree that might even be true, your point with SVN integration could be a valid one, I don’t know it. On either side, actually. However, as listed above, the “IDE side of things” is only one issue. Going all-in with Eclipse would give us neither a show case of, nor a test bed for Qt.

Also, the effort to create a Qt integration for Eclipse is well known, as there are people who previously worked on the Qt Eclipse integration and are now working on Creator, and that effort is known to be _significant_. [And as a side note, all(!) those people were happy when the task was passed on to someone else, as more often than not the integration work resulted in hitting hard walls in the Eclipse interfaces, or in the time it took to execute simple tasks]

As it stands, following your suggestion probably would not even solve the “well working development process” for Qt either. If I read the previously cited https://bugs.eclipse.org/bugs/show_bug.cgi?id=162108 correctly, Eclipse does currently not even fully support all of Qt’s Tier 1 platforms. (No debugger support for a Tier 1 platform _is_ a blocker in my world.) So to make that viable, we’d have to implement that anyway, but suddenly we can’t use the tools we’d like to use, and have in Cresator (C++, Qt, …) but we’d have to do that in Eclipse (and Java…) Speaking of that, which Eclipse C++ debugger framework would you suggest to use? CDI? DSF? TCF? EDC seems dead now. Roll our own? See the problems?

So, no, from a “business/effort perspective” your proposal is, I honestly think, no good idea.

I’m not sure why but this website is loading very slow for me. Is anyone else having this problem or is it a problem on my end? I’ll check back later on аnd ѕee if
the problem ѕtill existѕ.

Here is my ωeb-site; water pollution

It’s actually a cool and useful piece of information. I am satisfied that you simply shared this helpful info with us. Please stay us up to date like this. Thanks for sharing.

I’m not that much of a internet reader to be honest
but your sites really nice, keep it up! I’ll go ahead and bookmark your site to come back later. Cheers

Gertie says:

I read this article completely on the topic of the difference of most up-to-date and preceding technologies, it’s remarkable article.

Commenting closed.