Re: [cdt-dev] Qt Support?

[Doug Schaefer <cdtdoug@xxxxxxxxx>]

Thanks Warren, comments below.

On Thu, Jun 17, 2010 at 6:43 PM,  <Warren.Paul@xxxxxxxxx> wrote:
> Developing for Symbian requires you to use the Symbian emulator, simulator or on-device for debugging.  The first two take some time to boot since they're basically doing everything a real phone would be doing.  This is overkill for developing your Qt UI, so for this phase it's nicer to just develop a native Qt app on your development machine (we currently only support Windows but are looking at Linux as well).  So we'd like to be able to allow users to build/debug Win32 Qt apps (and Linux later) within our products.  We were thinking of MinGW + EDC.  There is also a Qt Simulator which I don't have a ton of info on.  I believe it's basically native code which is skinned with mobile device and supporting the new Qt Mobility API's.

My focus is mainly Windows and Linux desktop, which are pretty simple
scenarios. We may want to do something more elaborate but separate for
embedded. But I assume all that's controlled in the .pro file?

> We've had the intent of improving or replacing the existing Qt Eclipse integration and working with CDT in doing so.  We actually have some time allocated for this in the coming weeks.  We haven't had the chance yet to really breakdown the existing support to determine if it's worth using as a base or just starting from scratch.  There are some nice things in there, but it all needs improvement, and outside of the GUI tools, there's not really that much to it.  CDT does most of the heavy lifting already!  :)

If there are things we can take from the existing integration, that
would be great. I assume you guys have the power to relicense it as
you do that?

> If I were to start adding Qt support to CDT today, I'd probably do the following:
>
> - Create Qt project templates for use with the CDT project wizard (I assume that uses the template engine?).  It would be nice to have several different types of Qt project templates.  The existing Qt Eclipse support has 4 types, but I assume Creator has many more.

I think that would be the easy one (I'm not sure Creator actually does
have that much more, not from what I saw at least). Templates are
pretty easy to create and we can even add in actions to do more
complex things, like run qmake with an error parser attached. We
should be able to add in the builder from there too, I believe. We
need to check what state the project is in when the templates are run
(hopefully they're run at the end).

> - Create a qmake builder and error parser.  I guess you're right that the make file is setup to make sure qmake is called first, but there's a bug in the Symbian makespec so it doesn't actually work, so I never noticed it before.  But even if you just call it directly once, you'd still need a decent qmake error parser.  Not only for regular project builds but also at project creation time when you initially run qmake.  We've had requests from users to be able to customize the arguments passed to qmake as well, so perhaps its own builder isn't a bad idea.
> - Allow Qt project build configs to target different Qt installs and make specs.  Users may have several Qt SDK's installed, and they may want to build for different make specs in each SDK.  They should be able to customize the build configs at launch creation time manage them from project properties where they can control both the SDK (e.g. qmake location) and make spec (e.g. symbian-abld, symbian-raptor, win32-g++, etc)

Error parser is a must. And, yeah, as you mention next, different
build configs would need to invoke qmake differently.

> I wouldn't worry about a .pro file editor.  Trolltech tried putting a graphical editor on top of it before and it was lousy.  But it was lousy because the language for .pro files is so complicated.  Even Qt Creator just has a basic text editor.  They do have syntax coloring which is nice.  So does the existing Qt Eclipse integration BTW.  That would be pretty easy to add though, just not a real high priority IMO.

Actually, that's all I was thinking, a syntax highlighter only.
Hopefully that can be brought over.

> A nice to have would be a .pro file listener which (optionally) updates the .pro file to match changes made to the project from Eclipse (e.g. I add/rename/delete a source file).  The existing Qt Eclipse integration has this, but it would need some work.

This is a general function we need in the CDT. I can see this for
normal Makefile builds as well. I'm not sure whether we can reuse the
Makefile parser for something like this. I checked the qmake pro
syntax a while ago and it was different enough that it would need it's
own parser. We are in the refactoring business so we do know how to do
this :).

> Another nice to have would be to create Qt file templates like form, resource, etc.

Yup, the template engine could do all that.

> One thing we've been struggling with is how to support generic Qt development in Carbide, but also take advantage of the advanced Symbian build capabilities our custom builder has to offer.  Our users might want one project with build configs for Win32 desktop, Qt Simulator, and Symbian Debug/Release.  This can be done now, but not with mixing the regular CDT builder with ours for different build configs of the same project.  They'd have to have only the CDT builder and therefore nothing fancy for the Symbian build configs.  Any thoughts on this?

Dunno, how advanced could it be ;). Desktop Qt builds are pretty
simple and the makefiles generated by qmake are pretty full featured.
If all you are doing is calling something other than make, you can
hook that in by simply changing the build command. That's what I've
done for Android. What does your custom builder do that can't be done
with CDT standard one?

> Finally, the Qt GUI plugins from the existing Qt Eclipse integration is actually the same as in Creator.  There is very little Eclipse code for these views.  I don't know the mechanics of it, but the content of the views is basically pulled from dll's which are created by Trolltech and shared by Creator and the Qt Eclipse integration.  It could use some cleanup as well, but if we can get binary drops of these dll's periodically it would be pretty easy to provide this support from CDT.  The trick would be auto-registering the COM plugins that are currently registered by an installer.  I'm assuming there's some way of doing this from Java, or perhaps using p2 when installing the feature?

The GUI plugins would be tricky. My assumption is that the user
installs Qt separately. That works around licensing issues and the COM
registering and mad binary editing that the Qt installer does. The
Java code should then be able to find it, just as we need to find
qmake. And you're off to the races.

> How do you envision this will be structured?  An optional/installable CDT feature, e.g. org.eclipse.cdt.qt?

Yup. We probably want to make this a standard part of the Eclipse
C/C++ IDEs though. Which reminds me that we should have some detection
for whether Qt is installed and only offer the templates if it is.
Need to make sure the support is there in the template engine first.

BTW, we should start a wiki page and document what needs to be done
and who's doing what. And we should create bugs to break out the
discussions of the various pieces.