[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
I'm sure someone in the community will try it and report bugs/etc. If not, then I'd really be worried since that shows that no one really wants it.
But, if we have to change code, or have two separate streams, one for e4 and one for 3.x, then that requires the investment I was mentioning.
On Fri, Jun 18, 2010 at 12:11 PM, Mike Wilson
<Mike_Wilson@xxxxxxxxxx> wrote:
Actually *moving* to the 4.x stream should wait until the Eclipse Project can deliver something that runs your code and performs well. For that to happen, you need to invest at least enough time to try running on Eclipse SDK 4.0 (once it ships in July) and reporting bugs/talking to us, so *some* work will definitely be required. We both would like to minimize that effort on your part, but I can't imagine it being zero.
McQ.
Doug Schaefer ---2010/06/18 10:59:58 AM---On Fri, Jun 18, 2010 at 10:48 AM, Greg Watson <g.watson@xxxxxxxxxxxx> wrote:
On Fri, Jun 18, 2010 at 10:48 AM, Greg Watson <g.watson@xxxxxxxxxxxx> wrote:
> On the performance aspect, do you have any reason to suspect performance will be an issue? I haven't tried e4 yet, so I don't have a feeling for how it compares to 3.6. Performance is a big issue for us as well, since it is an often used argument about why not to move to an IDE.
Exactly. That is the argument we face as well. Mind you that also
points out we're doing a bad job of selling the values of the IDE, or
maybe we haven't reached the point where the value is obvious. From
what I can tell, nothing e4 is doing adds value to our IDE proposition
so it's not grabbing much of my attention.
BTW, as I think of it, this is one of the biggest differences between
us and the rest of the Eclipse community and why we struggle so badly
with them. They're competing with other IDEs, while we're just trying
to get people to use IDEs in the first place. Big difference in the
problem space.
As for the performance issue, all the fancy CSS stuff and model-based
UI has to have some sort of performance impact, no? The alpha I tried
a couple of months ago did take much longer to start up than 3.x. That
was an alpha, and I need to try it with the newer builds to get a
sense of the trajectory.
> We (at PTP) can't do anything until CDT moves over obviously, but I think it's pretty important that we align our activities with you guys.
Definitely, we can make this a bigger community decision with all the
projects that we work with.
>
> Cheers,
> Greg
>
> On Jun 18, 2010, at 10:35 AM, Doug Schaefer wrote:
>
>> Well, as has been my argument all along, it depends on two factors. 1)
>> how long to we need to keep 3.x support and 2) who's available to do
>> the work.
>>
>> The easy path is that e4's backwards compatibility modes allow CDT to
>> work without any code change. Anything else is a question mark.
>>
>> In my opinion, and we should start this debate, e4 is very young. Will
>> it be ready for commercial vendors to adopt it next year? I'm not
>> sure. My biggest concern is performance. If it is any way slower than
>> the existing platform, it would be near impossible for me to sell it
>> internally here at Wind River. You should hear the conversations we're
>> having as it is. So I'm in a wait and see mode.
>>
>> Doug
>>
>> On Fri, Jun 18, 2010 at 9:53 AM, Greg Watson <g.watson@xxxxxxxxxxxx> wrote:
>>> Hi,
>>>
>>> Does CDT have any plans to move to e4? If so, in what time frame?
>>>
>>> Thanks,
>>> Greg
>>> _______________________________________________
>>> 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
>
> _______________________________________________
> 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
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev