We at JetBrains know about dogfooding. We practice it daily to close the distance to our users, so we can understand their needs, feel their pains and problems.
IntelliJ IDEA has been dogfooded ever since JetBrains existed. WebStorm and its web development technologies are being used by our web team all the time. TeamCity, YouTrack, etc. And starting recently, we’ve been seeing CLion users inside the company!
JetBrains Toolbox app – what’s that?
JetBrains Toolbox app helps you manage all your developer tools from JetBrains, taking care of installing new versions, cleaning up old ones, getting updates, or rolling back. You can follow release-only channels or participate in EAPs as you prefer.
The app is especially helpful if you use several IDEs from JetBrains, or if you participate in Early Access Programs and installing EAP builds side by side with stable versions of some of our IDEs. It simplifies the update process by getting updates silently in just one click, so you don’t waste any time on the installation/patching process. JetBrains Toolbox can also aggregate all your projects and select an IDE that suits each of your projects for you.
The JetBrains Toolbox Google Chrome extension also makes is possible to open GitHub projects inside a JetBrains tool in a single click:
Technologies behind JetBrains Toolbox app
On the client side, JetBrains Toolbox app is a native Qt-based application, which includes an embedded browser (Qt WebEngine based on Blink) to show you a web page and keeps a tray icon. The UI in the browser is done with React/Redux and ES6, while Webpack is used to pack all this functionality.
Native App at client side
The native application is written in C++ (C++11) and uses the Qt platform. CMake was selected as the build system for this cross-platform app. As many other C++ cross-platform developers, the Toolbox team chose CMake as a universal build tool. Some reasons why they chose CMake:
- They use CPack for building some installers.
- CMake provides built-in options for Qt (resources generation, AUTOMOC, and others).
- The choice made it possible to use CLion for the development.
- On Windows, those who prefer MSVC compiler can use it as well with Visual Studio (and ReSharper C++).
- There are macOS parts done in Objective-C/C++ too.
For testing, the team was initially using QTest provided by Qt, but later moved to Google Test. This was done for several reasons.
- The first being the ability to skip test method declarations. In Google Test, you just implement the test body and that’s it, no need to list the tests in some special class that is later provided to the runner.
- Another reason was the rich set of assertions available in Google Test.
- There is also a first-class TeamCity support for Google Test.
- And last but not least was, obviously, integration with CLion and ReSharper C++.
All information on available releases for Toolbox is available as a set of files on a static HTTP server. There is no server-side application running for Toolbox app at all. Initially a bare JSON files were used, but soon they added XZ compression and digital signatures.
Finally, there is an application in Kotlin that collects all the data about releases and product builds. The application generates files that are uploaded to a HTTP server that is used by Toolbox.
CLion for Toolbox: the story of effective collaboration
We took this chance to work together and thus improve CLion and want to share here the story of this collaboration.
Introduction: You just open and start
The overall impression we got from the Toolbox team was positive. Without a broad experience in C++, CMake or Qt, they were quite happy with the easy start that CLion gave them. “You just open it and go!” they said. That was really a promising description.
The indexing of the project took several minutes, but when the index was ready, CLion started quickly.
There was some negative feedback as well. And that’s a good thing. I mean, who could be fairer and more straightforward than your own colleagues? We have their open and constructive feedback to thank for collecting and fixing a number of important issues in CLion.
First story: Qt connect & variadic templates
The Toolbox team used Qt and especially Qt C++11 connect calls widely, which made their code red and full of warnings before we implemented variadic templates. Starting from v2016.1, CLion can handle the following code correctly:
The implementation took some time and affected lots of code all around the parser. At that stage we were really scared of the idea of putting all the changes to the upcoming release and even EAP build. So we first provided the Toolbox team with a private build that they were evaluated for about a week. That let us work on implementation performance and regressions introduced there. Only after that did we make the changes available to all, inside the public EAP build. Some additional problems were found, but the major performance issues were eliminated at the first stage.
Speaking of performance, in addition to the variadic implementation testing and some debugger issues investigations (the latter were helpful when working on GDB/LLDB drivers changes introduced in 2016.2), Toolbox developers faced high CPU usage problems which are still under investigation.
Second story: digging in compiler and CMake output
There were some complaints about the compiler and CMake output in CLion. When you are new to the technology, excessive logging may confuse, especially when it’s not well-structured.
Some users want to have colored output, some on the contrary prefer to keep away from so many colors. CLion can provide a solution for both sides. The coloring control is implemented via the original CMake/compiler options:
- CMake coloring can be disabled by setting CMAKE_COLOR_MAKEFILE to OFF,
- for Clang, add -fno-color-diagnostics compiler flag,
- and for GCC, add -fno-diagnostics-color flag.
Almost all of our users (and Toolbox team is not an exception here) want to see CMake output when (re)loading the project. We understand the importance of that and we did have feature planned for 2016.2. Unfortunately, we were unable to deliver it in the July release, but it will become available soon in one of 2016.2.x updates.
Third story: Darcula perfectionism
Another issue was noticed by the Darcula-theme fans. Some colors and icons look bad, as not polished. Here we were actually quite lucky, since the problems were caught by the developer who introduced Darcula to IntelliJ Platform. With his help, we came up with a much more accurate and nice-looking theme.
Ask for more
Our tracker is always open for any feature requests our users have in mind. The Toolbox team addressed some interesting cases in their feedback. Check them out and upvote if you miss them too!
After moving to Google Test from QTest, the Toobox team started using CLion’s integration and made lots of interesting suggestions. Some of them came from their experience in the Java world and using IntelliJ IDEA. A prime example would be gutter icons for tests, like it’s done for JUnit. We are going to consider this, as well as other Google-Test-related reports from the Toolbox team.
Swift & Objective-C/C++
Toolbox app got some Objective-C/C++ code in addition to C++, and Swift is being considered as a possible addition. Of course, they may generate Xcode project from CMake and open it in AppCode, but that didn’t look good to them (especially since the project is cross-platform).
The team was excited to learn the news about the Swift plugin for CLion. As for Objective-C, there is a feature request placed in our tracker (and even some interesting hack from one of our users). But in general, this makes us think again that Objective-C/C++ can be a useful addition to the world of cross-platform C/C++ development. So, if you would like to see Objective-C/C++ support in CLion, do let us know in the corresponding ticket.
Visual C++ compiler
MSVC support on Windows: I’m afraid we have little to comment a lot here. We are thinking about adding it, but we lack the resources to do it at this time.
We hope that more teams will adopt CLion and share their feedback with us. Recently, we’ve helped our UI team that is customizing the JDK for our IntelliJ-based IDEs, and now they can also try CLion for their development. If you’ve ever wanted to use CLion for OpenJDK dev, please check this patch (intended for Linux environment only).
We’ll be glad to hear your feedback as well! Give CLion a try and let us know what you think.
Your CLion Team
The Drive to Develop
Subscribe to Blog updates
Thanks, we've got you!
Dealing with Makefile Projects in CLion: Status Update
Update: Makefile projects support is now public in CLion 2020.2. What request in our tracker has more than 1000 votes, 370 comments, and 800 watchers? You guessed it: Support Makefile projects. This has been a story of interesting findings, semi-automatic workarounds, and a long battle that we st…
CLion in 2015: A Review of Feature Usage
Hi everyone, CLion IDE was released to the public in April 2015, and now may be a good time to look back and see how things have developed (no pun intended). We published a similar overview within six weeks of the launch of the first public CLion EAP (Early Access Program). At that time we wer…
Applying Genetic Algorithms to Automatic Code Formatting
Our traditional JetBrains Hackathon was held this summer at our St. Petersburg and Munich locations. Earlier we shared the first impressions and quick overview of the winning projects in our company blog. Today we’d like to tell you about one of the projects that came in third in more detail. Why do…
Infographic: C/C++ Facts We Learned Before Going Ahead with CLion
Hi all, Since the first CLion announcement and public preview build, we've received many questions about technologies and toolchains selected to be the first in CLion (CMake, GCC, and GDB). We've also had a couple of interesting discussions about the C and C++ market on various conferences and he…