I don’t think anyone in good faith can discount the navigation benefits of a modern IDE.  Yes my favorite is still written in C++, as is my favorite editor (put that vim and emacs shit down, son, it’s time to code…I KID), nothing beats speed when you just want to type code.  But JetBrains has shown how they can provide amazing IDE features for all kinds of code: C++, Python, Scala, etc. with their Java library stack.  Yes you pay a performance price and yes we’ve been burned by slow Java IDEs before, haven’t we, Eclipse… but JetBrains has really hit a critical mass of solid IDE functionality,  and I’m going to give it another good try.  Here are some rolling notes, made in cronological order…

• the soggy keylag is KILLING me… but I love the navigation power… hrmph…
• it’s not THAT laggy considering all it is doing… and my other dev environment is through a VM anyway (does that make it better or worse, not sure yet…) continuing…
• on a VM, all hope is lost.  Even sublime is uselessly unusable.  Back to emacs.  Sad world.
• The speed is now pretty good, I don’t know if it got everything indexed and it’s faster, or if I got used to it.  I think it’s faster!  Just in time for my open source license to expire… and JetBrains renewed it!  Yay, thanks guys.
• Some things just take some adjustment.  Keymaps, panes, etc.  Also, don’t expect to copy/paste huge chunks of code as fast as you can in a dumb editor – it causes a ton of analysis to occur.  In a non-VM fairly-decent environment, CLion is humming along now.
• CLion is undeniably faster than Sublime on my VM.  It is downright snappy at editing code compared to Sublime.  Happily shocked!
• Uhoh… lots of clion lockups on laptop… doh, whoops, out of disk space.  Don’t let it happen!  🙂

Fun tips:

• You can open a file into an existing clion session by running the startup script with a full path to the file, or do this:
  clion `pwd`/myfile.cpp
  or use the little bash script to do it for you:
  !/bin/bash
# if $1 does not start with [/], prefix it with `pwd`
MYFILE=$1
if ! [[ $MYFILE =~ ^/ ]]; then MYFILE=`pwd`/$1; fi
cd /home/m/apps/jetbrains/clion/bin
./clion.sh $MYFILE $2 $3 $4 $5 &
• For the huge hirez monitors I have gotten addicted to using with i3, make sure you enable this (which is oddly disabled by default):
  

  File > Settings > Editor > General > [x] Change font size (zoom) with Ctrl+Mouse Wheel

• CLion will auto-create projects from CMakeLists.txt, really nice.  It seems to auto-create Debug config using ./cmake-build-debug.  To create Release config too, go to:
  

  File > Settings > Build… > CMake > click +, it will auto-create Release (a little weird but it was what I needed)

I am loving cross-platform development with Qt, it’s robust and logical and leads to amazing native desktop apps. Before getting started, I expected that there would be lots of platform-specific hackery required, and going cross-platform would slow down the end product by 20-30%. But Qt is so reliable, and well-laid-out, and provides so much more than just lowest-common-denominator functionality, that I’m finding it to be much faster than, e.g., developing a desktop app with C# or Java.

Another reason it is giving me leverage: [n] compilers are better than one. (continued…)

Here are quick instructions to get this done and start using TagLib in your project to manipulate tag data in your music files. I had to pull this together from about 5 different places…

NOTE: This was moved to the wiki, because persistent articles belong on wikis, not blogs! 🙂

Why is this not documented well? I don’t understand why people spend man-years creating great software and then don’t bother to document it – did I just miss it somewhere? Prolly…

A new article describing my cross-platform development environment setup is now on the wiki…

Updated with more detail on 2011/09/18…

I’m using the cross-platform Qt C++ library to write an app for linux, OS X, and Windows. Qt source can be compiled to a wide range of systems and devices, with two obvious omissions that are not likely to be filled any time soon: iPhone and Android. I know I am going to need client code on these devices, and I know that the client code is going to be extremely similar to the Qt client code. How do you design for this?

Applying the concept of separation of concerns, you design your classes into layers. The base layer consists of high level concept classes that perform all fundamental actions using generic data types. Then, the derived layer is used to get the job done, using the most useful and powerful lower level tools at your disposal. Push everything you can into the base layer, until you hit the limit of non-portable information and data types. It’s a beautiful way to code.

To be more specific, in my case, the base class layer will be using C++, including the STL, which gives me tons of power. I will pull in boost if even more horsepower is needed. The derived class layer for the first round of clients will be Qt-powered. The Qt library has a massive amount of real-world usefulness, supporting everything from http to video playback. I have not gotten to the iPhone and Android clients yet so the whole concept may change, but here’s my current plan. The iPhone code will be Objective C with the C++ base class layer linked in. I will attempt to incorporate the C++ base class layer into the Android code using the NDK.

Here’s a quick example of the layer approach, in this case used to quickly set up profiling using Qt’s QTime class at the lower level: (continued…)