[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdt-dev] Qt Support?
|
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