Re: [cdt-dev] Qt Support?

[Michael Jackson <mike.jackson@xxxxxxxxxxxxxx>]

>From the perspective of current user of CDT that does Qt development
the single most important "integration" for me is to be able to
display the values of QStrings and other Qt types in the debugger. All
the other ideas in the bug report have work arounds that can be used
except the debugger issues. If a small contribution to CDT 7.1 to
enable the debugger features I think that would make a big splash for
those of us using CDT and Qt.

Thanks
-----
Mike Jackson                      www.bluequartz.net
Principal Software Engineer       mike.jackson@xxxxxxxxxxxxxx
BlueQuartz Software               Dayton, Ohio

On Jul 13, 2010, at 1:24, "ken.ryall@xxxxxxxxx" <ken.ryall@xxxxxxxxx> wrote:

> Doug,
>
> We discussed these issues for a couple hours this afternoon.
>
> I ended up creating https://bugs.eclipse.org/bugs/show_bug.cgi?id=319657
>
> as an epic to capture the overall effort.
>
> - Ken
>
>> From: Schaefer Doug <cdtdoug@xxxxxxxxx>
>> Reply-To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
>> Date: Fri, 18 Jun 2010 18:17:39 +0200
>> To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
>> Subject: Re: [cdt-dev] Qt Support?
>>
>> 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.
>> _______________________________________________
>> cdt-dev mailing list
>> cdt-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev