Whole Tomato Software Forums
Whole Tomato Software Forums
Main Site | Profile | Register | Active Topics | Members | Search | FAQ
User name:
Password:
Save Password
Forgot your password?

 All Forums
 Visual Assist
 Feature Requests
 Add Include improvements
 New Topic  Reply to Topic
 Printer Friendly
Author Previous Topic Topic Next Topic  

jschmidt
New Member

Canada
4 Posts

Posted - Jul 27 2011 :  09:52:56 AM  Show Profile  Reply with Quote
The Add Include option under the contextual menu Refactor is really a useful tool, but sometimes, when you use the option for types like QPushButton (mostly include from 3rd party) and such you get:

#include "qpushbutton.h" instead of #include <QPushButton> (without the .h, the quoting is not important, can be "" or <>)

Could it be possible to detect header without extension first and include them if available? I know it is really library dependent, but for QT it would be nice cause the casing is not the same. QT always have a extension less header that directly include the header with an extension.

Thanks

accord
Whole Tomato Software

United Kingdom
3164 Posts

Posted - Jul 31 2011 :  12:46:27 PM  Show Profile  Reply with Quote
*uh* This is a special problem. Every library has its own policy and some of them uses special logic, like in this case. It cannot be solved generally, since strictly speaking VA includes the header which contains the symbol definition, so it can be considered "normal".

Is this causing any serious problem (i.e. with compiling or using the library), or is it "just" a cosmetic issue?
Simply only detecting whether the header has extension would have cause problems for other libraries / projects.
I'm not sure if is there any simple solution here, rather that supporting QT specifically.
Go to Top of Page

chrisaverage
Junior Member

Poland
20 Posts

Posted - Feb 17 2014 :  10:21:24 AM  Show Profile  Reply with Quote
I'm a heavy user of Qt too, so it would be really nice to have this. Also Qt is quite popular these days so targeting it specifically might not be that bad of an idea.
There are not many libraries with Q-starting classes so maybe this could be used as an indicator?
If you don't like the idea of targeting specific libraries maybe this could be generalized into some sort of user defined regexp or templates like:

^Q.* --> <%SYMBOL%>
^SomeLib.* --> "Some/Lib/%SYMBOL_LOWERCASE%.h"

or something like this. This could cover a lot of (if not most of) the libraries out there.
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
15984 Posts

Posted - Feb 18 2014 :  4:19:36 PM  Show Profile  Reply with Quote
We have added some special handling for Qt already, for handling signals and slots, and we do see quite a few support requests that involve Qt to some degree or other.

The regular expression idea is interesting, but it is likely to run into so many edge cases that I am not sure its going to be that useful.

As accord asked, is this actually causing any problems, or is it simply a cosmetic issue? If its causing actual problems then it is obviously more urgent.

zen is the art of being at one with the two'ness
Go to Top of Page

chrisaverage
Junior Member

Poland
20 Posts

Posted - Feb 20 2014 :  08:13:37 AM  Show Profile  Reply with Quote
There are no problems (that I know of) like something not compiling or linking etc. so yeah, it's not extremely urgent.
It's a matter of style and convenience mostly. It's along the lines of including "stdlib.h" instead of <cstdlib>.
As such it usually causes code review feedback so for Qt types I end up either fixing the includes or typing them in manually in the first place.
It's a very deeply rooted convention in Qt world and it's just that nobody actually does it differently, and if they do they're immediately asked why :)

Another comment here is that the extensionless headers correspond to the Qt classes, while it's not always the case with .h files, eg.
both <QDate> and <QDateTime> include "qdatetime.h" or <QEvent> actually includes "qcoreevent.h".
It's easier for example to cleanup the includes when they correspond exactly to used classes instead of finding which include is actually for what.
Go to Top of Page

feline
Whole Tomato Software

United Kingdom
15984 Posts

Posted - Feb 27 2014 :  11:40:46 AM  Show Profile  Reply with Quote
We are considering some way of handling this general situation, but its not yet clear how best to do that. I have added Qt to the libraries we want to look at for this:

case=37006

zen is the art of being at one with the two'ness
Go to Top of Page

sean
Whole Tomato Software

USA
2641 Posts

Posted - Apr 07 2014 :  3:40:30 PM  Show Profile  Reply with Quote
build 2031 improves add include results for Qt 5 in some scenarios.
Go to Top of Page

chrisaverage
Junior Member

Poland
20 Posts

Posted - Apr 07 2014 :  4:49:56 PM  Show Profile  Reply with Quote
Thanks for this. It works almost ok but it still includes eg. "QByteArray" when it should include <QByteArray>.
Go to Top of Page

sean
Whole Tomato Software

USA
2641 Posts

Posted - Apr 07 2014 :  6:52:00 PM  Show Profile  Reply with Quote
<> should be used if you added the Qt include dirs to:
Project Properties | Configuration Properties | VC++ Directories | Include Directories

"" is used if you added Qt include dirs to:
Project Properties | Configuration Properties | C/C++ | Additional Include Directories

(Unless you have modified the AddIncludeTokenStyle VA registry value from the default of 0 per http://support.wholetomato.com/default.asp?W338.)
Go to Top of Page

chrisaverage
Junior Member

Poland
20 Posts

Posted - Apr 08 2014 :  05:04:54 AM  Show Profile  Reply with Quote
Actually I did neither (myself). There's a Qt add-in for Visual Studio that does that when you select Qt modules in a configuration dialog.
From what I see they indeed add that in the C/C++ section. Do you think this is something I should ask Qt guys to fix in the plugin?
Go to Top of Page

sean
Whole Tomato Software

USA
2641 Posts

Posted - Apr 08 2014 :  12:43:17 PM  Show Profile  Reply with Quote
One other difference about the two directory lists is that if you use the VA "Stable symbols in italic" option, then Qt symbols will be rendered in italic if the Qt dirs are listed on the VC++ Directories page rather than the C/C++ page.

I don't think it is a Qt config bug per se, but it would be good if they offered the option to add the include dirs to one or the other list.
Go to Top of Page

Predelnik
Senior Member

Russia
37 Posts

Posted - Apr 09 2014 :  10:22:30 AM  Show Profile  Reply with Quote
Well I also interested in such behaviour with Qt but even using 2031 beta, can't achieve anything similar.
I have AddIncludePreferShortestRelativePath set to 0 and it just prints full path to Qt header, starting from "C:\\...", if I have this option turned on path is relative but still long. So what should I do to enable this behavior?

And also regarding additional include directories, QMake default behavior is to put Qt related paths there, so I don't think it would be easy to change that.
Go to Top of Page

sean
Whole Tomato Software

USA
2641 Posts

Posted - Apr 09 2014 :  11:36:08 AM  Show Profile  Reply with Quote
What version of Qt?

What paths are added to Additional Include Directories?

When AddIncludePreferShortestRelativePath is at the default value of 1, what text does add include insert?
Go to Top of Page

Predelnik
Senior Member

Russia
37 Posts

Posted - Apr 09 2014 :  3:08:53 PM  Show Profile  Reply with Quote
Well I use stable branch from Qt git, `qmake -v` shows me 5.3.0 version.

Let's say "C:\\rfd\\qt-git-5-x64" - is path to my Qt

My additional include directories (I leave only Qt related paths):
quote:

"C:\\rfd\\qt-git-5-x64\\qtbase\\include";"C:\\rfd\\qt-git-5-x64\\qtbase\\include\\QtOpenGL";"C:\\rfd\\qt-git-5-x64\\qtbase\\include\\QtPrintSupport";"C:\\rfd\\qt-git-5-x64\\qtbase\\include\\QtSvg";"C:\\rfd\\qt-git-5-x64\\qtbase\\include\\QtWidgets";"C:\\rfd\\qt-git-5-x64\\qtbase\\include\\QtNetwork";"C:\\rfd\\qt-git-5-x64\\qtbase\\include\\QtGui";"C:\\rfd\\qt-git-5-x64\\qtbase\\include\\QtCore";C:\\rfd\\qt-git-5-x64\\qtbase\\mkspecs\\win32-msvc2013;"



On the other hand I would note(maybe it's important) that sources dir for the project I'm working on is written as a related path, like "..\\src". There is also a bunch of dependencies with full path which most likely do not matter in this case.

With AddIncludePreferShortestRelativePath - 1, it adds something like:
#include "../src/corelib/io/qurl.h"

with 0, it adds something like:
"c:/rfd/qt-git-5-x64/qtbase/src/corelib/io/qurl.h"

By the way correct (absolute) path to this file should actually be
"c:\\rfd\\qt-git-5-x64\\qtbase\\include\\QtCore\\qurl.h"

So it's very disturbing, maybe you have supported this stuff only for Qt4, because all of these duplicated headers in Qt5 seem to be confusing for VAX.
Go to Top of Page

sean
Whole Tomato Software

USA
2641 Posts

Posted - Apr 09 2014 :  3:47:55 PM  Show Profile  Reply with Quote
Yes, the duplicate headers are a problem. It looks like you are trying to use AddIncludePreferShortestRelativePath to deal with that problem but AddIncludePreferShortestRelativePath just muddles the situation since it assumes a single header file in one location - it was not introduced to deal with header files being duplicated.

In my Qt project, I link to libs/dlls so I do not have any qt /src/ dirs in my additional include dirs. The include dirs you listed do not have any qt /src/ dirs either. Do you have the qt /src/ dirs listed somewhere? Or are you compiling qt /src/ dirs in your project?
Go to Top of Page

Predelnik
Senior Member

Russia
37 Posts

Posted - Apr 10 2014 :  07:12:04 AM  Show Profile  Reply with Quote
Well I've posted all Qt related directories here, so there's no src directory mentioned explicitly. And /src dirs are definetily not used in project.
That's really weird though, looks like path "../src/corelib..." is based on "%QT_DIR%/include" include which is kinda strange behavior.
Go to Top of Page

sean
Whole Tomato Software

USA
2641 Posts

Posted - Apr 10 2014 :  12:10:18 PM  Show Profile  Reply with Quote
When your solution is loaded, open the VA Options dialog; on the C/C++ Directories page, what Platform is selected? By default, it should be Project defined.

Change the Show Directories for dropdown to Source files. Are the Qt src dirs listed there?
Go to Top of Page

Predelnik
Senior Member

Russia
37 Posts

Posted - Apr 11 2014 :  02:20:51 AM  Show Profile  Reply with Quote
Yes, "Project defined" is selected and there's no Qt src dirs in source files:
Go to Top of Page

sean
Whole Tomato Software

USA
2641 Posts

Posted - Apr 11 2014 :  02:35:51 AM  Show Profile  Reply with Quote
Can you capture a log of the solution load and of running add include on a qt symbol?
File | Close solution
Enable logging on Performance page of VA options
Load solution
run add include
exit
then zip va.log and send it in via the contact form:
http://www.wholetomato.com/support/contact.asp
Go to Top of Page

Predelnik
Senior Member

Russia
37 Posts

Posted - Apr 11 2014 :  03:09:02 AM  Show Profile  Reply with Quote
I've sent it.
Go to Top of Page

sean
Whole Tomato Software

USA
2641 Posts

Posted - Apr 11 2014 :  7:13:44 PM  Show Profile  Reply with Quote
Thanks for the log. I'll use QDialog as an example.

I've just done an install with source from qt-opensource-windows-x86-msvc2012-5.2.1.exe that I downloaded from the project site.

Here are the QDialog headers that are installed:
D:\\src.qt\\Qt5.2.1\\5.2.1\\Src\\qtbase\\include\\QtWidgets\\QDialog (1 line -> includes qdialog.h in same dir)
D:\\src.qt\\Qt5.2.1\\5.2.1\\Src\\qtbase\\include\\QtWidgets\\qdialog.h (1 line -> includes qdialog.h in qtbase\\src dir)
D:\\src.qt\\Qt5.2.1\\5.2.1\\Src\\qtbase\\src\\widgets\\dialogs\\qdialog.h (full class definition - identical to other full one)
D:\\src.qt\\Qt5.2.1\\5.2.1\\msvc2012\\include\\QtWidgets\\QDialog (1 line -> includes qdialog.h in same dir - same as first QDialog)
D:\\src.qt\\Qt5.2.1\\5.2.1\\msvc2012\\include\\QtWidgets\\qdialog.h (full class definition - identical to other full one)

1 version of QDialog copied to 2 directories.
2 versions of qdialog.h where 1 version is copied to 2 directories and a different version is copied to a third directory.

Looking at the 5 paths above, there are 2 subtree groups:
Src\\qtbase\\...
msvc2012\\include\\...

The changes made in VA build 2031 work when using the 2nd subtree (msvc2012\\include\\...) as additional include directories, but not the first (Src\\qtbase\\...). We'll try to improve results for the 1st subtree in the next build.

Edited by - sean on Apr 11 2014 7:57:27 PM
Go to Top of Page

Predelnik
Senior Member

Russia
37 Posts

Posted - Apr 12 2014 :  01:35:38 AM  Show Profile  Reply with Quote
Thank you.
Looks like Qt built from the source has first subtree only, maybe with some additional build parameters it would change but since it's working as intended without them, no one cares very much anyway. So better work with first subtree would be very much appreciated.
Go to Top of Page

chrisaverage
Junior Member

Poland
20 Posts

Posted - Apr 12 2014 :  04:34:31 AM  Show Profile  Reply with Quote
I don't think it should use the first subtree. The so called "offline installers" like the one you used are kinda slice of what the main - online installer does. With it you can install several builds of Qt and source separately. The structure is then:
Src\\qtbase\\...
msvc2012\\include\\...
msvc2010\\include\\...
mingw48_32\\include\\...

I think VA should use the one the project is using, cause they can be configured quite differently, with different defines, modules enabled etc. The Src directory is kinda addition to them if you want to for example build Qt yourself.
Go to Top of Page

Predelnik
Senior Member

Russia
37 Posts

Posted - Apr 12 2014 :  05:28:40 AM  Show Profile  Reply with Quote
quote:
Originally posted by chrisaverage

I don't think it should use the first subtree. The so called "offline installers" like the one you used are kinda slice of what the main - online installer does. With it you can install several builds of Qt and source separately. The structure is then:
Src\\qtbase\\...
msvc2012\\include\\...
msvc2010\\include\\...
mingw48_32\\include\\...

I think VA should use the one the project is using, cause they can be configured quite differently, with different defines, modules enabled etc. The Src directory is kinda addition to them if you want to for example build Qt yourself.


Well it's obvious that if Qt is configured to add include dirs from second subtree which is the case when it was installed by installers when the second subtree will be used just fine. So for installed versions nothing will change.

The problem is that when you build Qt yourself(which for example you need to do if you want to use if with MSVC2013 currently) you don't have second subtree at all(at least if you built it without any special options) and dirs from the first one is being added to project configuration and thus not handled correctly.

By the way the best usage of source in installed version is to be able to debug it, it really helps sometimes.

Edited by - Predelnik on Apr 12 2014 05:29:11 AM
Go to Top of Page

chrisaverage
Junior Member

Poland
20 Posts

Posted - Apr 12 2014 :  06:43:23 AM  Show Profile  Reply with Quote
Well you should use special options (at least --prefix) and not build in the source dir in the first place. For VS 2013(which is MSVC 12.0) you can also find ready binaries(eg. here: http://www.tver-soft.org/qt64) which have a proper tree structure. They do have the .pdb files so you can debug with them, unless of course you want to debug Qt itself, in which case you do need sources.
Go to Top of Page

Predelnik
Senior Member

Russia
37 Posts

Posted - Apr 12 2014 :  10:28:42 AM  Show Profile  Reply with Quote
Well but I certainly did not see any reason to add --prefix before this problem with VAX because everything else was working pretty much fine, so I think it's not exactly right to say that it is something completely obligatory.

Well it's nice that some custom sites do these builds on the other hand for example there was a bug in build for VS 2013 in released Qt version so I've had to use version from Git/ apply custom fix anyway, so until it's officially released there's no guarantee that it's working. Maybe now I'll try them though, thank you.
Go to Top of Page

Predelnik
Senior Member

Russia
37 Posts

Posted - Apr 14 2014 :  04:24:03 AM  Show Profile  Reply with Quote
I've tried installable version from http://www.tver-soft.org/qt64 and "add include" for Qt classes works pretty much fine except "QUrl"/<QUrl> issue of course.

Edited by - Predelnik on Apr 14 2014 04:24:24 AM
Go to Top of Page

sean
Whole Tomato Software

USA
2641 Posts

Posted - May 23 2014 :  2:56:43 PM  Show Profile  Reply with Quote
case=80599 was opened for Add Include improvement for Qt.
case=80599 is fixed in build 2036.
Go to Top of Page
  Previous Topic Topic Next Topic  
 New Topic  Reply to Topic
 Printer Friendly
Jump To:
© 2019 Whole Tomato Software, LLC Go To Top Of Page
Snitz Forums 2000