Note: I’m no gcc expert, nor am I C++ standards expert so please bear with me if this reads a little bit like a rant. I’m really just surprised
So I’ve just built kdevelop and noticed an new warning:
/usr/include/c++/4.3/backward/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated.
Ok, no problem, it even tells me where to look to fix it. Very nice. So I went to the file and saw that one is supposed to use “unordered_map” instead of ext/hash_map. So I changed the relevant files to do that and rebuilt (I’m now using gcc 4.3 as Debian decided to change that recently). Now I’m getting:
/usr/include/c++/4.3/c++0x_warning.h:36:2: error: #error This file requires compiler and library support for the upcoming ISO C++ standard, C++0x. This support is currently experimental, and must be enabled with the -std=c++0x or -std=gnu++0x compiler options.
And that leaves me pretty much stuck.
How come gcc developers deemed it a good idea to deprecate something and thus encourage users to change to non-deprecated code but at the same time mark this code as highly experimental and thus not ready for wide usage? That doesn’t look good, even if gcc won’t drop the header next week, at the point we’ll probably have to change a lot more code using it than we have now.
Ok, enough of that, I’ll revert my local changes and live happily with the warning, in the hope that I won’t be around when it gets dropped from gcc
Today I comitted my patch to kstyle.cpp which enables using the QAbstractItemView::activated() signal properly with KDE styles. As noted in the API documentation of the activated() signal it depends on the platform and until today that meant double-clicking on linux.
Luckily the Troll’s have foreseen such needs as from KDE and implemented this behaviour by asking the style wether it wants item-activation on single or double click. So by just adding another case to the styleHint() method of KStyle it was possible to actually read the KDE-wide setting for single/double clicking and provide that to the itemview.
This means that any QAbstractItemView running with a KDE style (one inheriting from KStyle) now behaves this way, so if you find your itemview to work differently you know where it comes from.
Of course I managed to break KStyle with the initial commit, this was due to a bit to little tests on my side. I only tested with my current QtCurve style and didn’t notice that even when linking against KDE4 it still uses a plain Qt style as its base class. So I didn’t notice that my change actually caused a ASSERT in KComponentData to trigger. But once I changed that I was able to quickly fix kdelibs and apparently nobody else noticed
Its been quite some time since I’ve been really active, this was mostly due to “real life” kicking in. That means moving to a new appartment, getting to know a new city, working a bit longer than usual and not feeling like hacking in the late evening.
So the last 3 hours I spent debugging a crash in kdevelop4, fixing kdebugdialogs scrolling bug (or rather working around it by using QTreeWidget instead of QListWidget), creating a example app for the trolls for the QListWidget bug and last but not least extending the KDevelop PG-Qt parser generator to allow to customize the auto-generated Ast nodes a bit.
Sorry Aleix, no time for fixing the building inside KDevelop4, but thats on the table for wednesday (as I doubt I’m able to hack tomorrow, real life you know