Re: [cdt-dev] Qt Support?

["ken.ryall@xxxxxxxxx" <ken.ryall@xxxxxxxxx>]

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