[Qt-creator] .prf handling, application palette, and performance concerns

[Adam Higerd]

Daniel Teske wrote:
>> If this were a task tracker I'd be reporting this as three separate
>> issues, but as this is just a mailing list I'll drop everything in at once.
>>
>> I've been using Qt Creator for a few days now and I must say I'm quite
>> impressed. The .pro handling is excellent except for a couple of quirks
>> that I'm fairly sure are just bugs. The only shortcoming I've
>> encountered in this regard is that it doesn't follow the CONFIG variable
>> to read in imported .prf files
> We do actually read .prf files, e.g. the moc.prf is read, but it might very 
> well be that we don't look for .prf files in the right locations. So how does 
> your setup look like? And where does the .prf file reside.
> And please report all bugs you find with our .pro file handling.
I've got "CONFIG += qxt" in my .pro file, and I have a qxt.prf file in 
$$[QT_INSTALL_PREFIX]/mkspecs/features/ (on my system, 
/usr/share/qt4/mkspecs/features/).

qxt.prf consults the $${QXT} variable for a list of modules, analogous 
to $${QT}; typically it'll be set as "QXT = core gui". Each module in 
the variable modifies the INCLUDEPATH variable. If you would like to see 
the file, "svn co svn://libqxt.org/svn/libqxt/trunk libqxt" and look in 
deploy/qt/qxt.prf.

Perhaps the problem is that the .prf file is parsed at the wrong time 
during the loading of the .pro file? qmake doesn't load .prf files until 
after the entire .pro file has been parsed.

>> but at home I have a Duron 1.3GHz and it drops 15-25% of my keystrokes.
> That shouldn't be. The most limiting factor to Qt Creators performance isn't 
> actually the cpu, but the graphics cards driver. So it would be good to know 
> which kind of graphics card and which driver you have.
Both my home system and my work system are using the same video card, a 
GeForce4 MX 440 dual-head, and the same driver, the latest binary nvidia 
driver that still has support for the card. The only significant 
difference between the two systems is that my home system has 384MB of 
RAM and a 1.3GHz Duron, while my work system has 1GB of RAM and an 
Athlon X2 4600+.

>> I suspect the performance
>> hit may be coming from the code completion but there's currently no way
>> to disable it to find out. (I also know some users who would like to
>> disable code completion anyway.)
> Well the C++-engine is in our view a fundamental part of the architecture. So 
> a lot of stuff, like e.g. the F1 key depend on the C++-engine. We intend to 
> build more features on top of the C++-engine. 
I'm not so worried about the C++ engine itself. I WANT the C++ engine; I 
want the context-sensitive help, I want syntax highlighting, I want 
indexing. The code completion is the only thing that I'm talking about 
here -- the part that automatically checks the current partially-typed 
keywords for completion and pops up a completer window. Other IDEs I've 
used have had performance issues with code completion enabled; without 
seeing Creator's code I can't really profile it but I wouldn't be 
surprised if the same is true.

/s/ Adam