Re: [cdt-dev] Qt Support?

[Doug Schaefer <cdtdoug@xxxxxxxxx>]

Super! Thanks, Ken.

On Tue, Jul 13, 2010 at 1:24 AM, 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
>