Nabble - Eclipse CDT

RE: CDT Moving to Helios Platform

2009-12-14T07:42:41Z

Hi everyone,

I'm ready to sumit my patch which will require 3.6 to build CDT.

I'll probably do it tomorrow.

Thanks

Marc

From: cdt-dev-bounces@... [mailto:cdt-dev-bounces@...] On Behalf Of Doug Schaefer
Sent: Wednesday, December 02, 2009 11:59 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] CDT Moving to Helios Platform

D'oh, maybe ;).

On Wed, Dec 2, 2009 at 11:54 AM, John Cortell <rat042@...> wrote:

I believe you're thinking about Marc :-)

John

At 09:52 AM 12/2/2009, Doug Schaefer wrote:

Hey gang, in preparation for Helios M4, we need to make sure CDT HEAD can work with the Helios Platform. Please upgrade you target platform now if you haven't already done so.

John Cortell has a check-in ready to take us there. John, check it in at any time. If there are issues we can always pull that change out later.

Cheers,
Doug.
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

From forum: Eclipse CDT - Development

Re: CDT and Qt Creator

2009-12-14T07:26:59Z

Fair enough. My point was really to encourage everyone to take a look at Serge's work and ensure it's going to really solve the problems we are having.

Doug.

On Mon, Dec 14, 2009 at 9:27 AM, Chris Recoskie <recoskie@...> wrote:

Well to be frank, I pretty much gave up on trying to get anything changed in the Resources area on e4, because the Platform Resources team didn't seem to have the time to devote to reviewing and collaborating on solutions. Despite having commit rights to e4, you can't really do anything in the Resources area without their signoff, so after having patches and ideas languish for months in Bugzilla with no real progress, I decided my time was better spent elsewhere.

===========================
Chris Recoskie
Team Lead, IBM CDT and RDT
IBM Toronto

Doug Schaefer ---12/11/2009 07:23:56 PM---I hope so. That's the whole driver behind the flexible resources work. It's been disappointing that

From:
Doug Schaefer <cdtdoug@...>

To:
"CDT General developers list." <cdt-dev@...>

Date:
12/11/2009 07:23 PM

Subject:
Re: [cdt-dev] CDT and Qt Creator

Sent by:
cdt-dev-bounces@...

I hope so. That's the whole driver behind the flexible resources work. It's been disappointing that more contributors haven't been able to help Serge out, especially those who apparently have a vested interest in it. Hopefully now that it's being put into Eclipse 3.6, we can take a better look at what Serge has done and make sure it meets our needs.

Doug.

On Fri, Dec 11, 2009 at 7:14 PM, John Cortell <rat042@...> wrote:
Won't the Project Layout issues be resolved by the E4 Flexible Projects work Serge Beauchamp had done?

John

At 06:11 PM 12/11/2009, Doug Schaefer wrote:

This is great data, and we could do something about most of this, if we work together as a community to address them. Up until now, we haven't really been involved in solving these issues for Carbide.

Next question. How does Qt Creator do these things better? Since that's the real topic of this thread.

Doug

On Fri, Dec 11, 2009 at 6:44 PM, Adrian Taylor <adrian@...> wrote:

Speaking as a user of Carbide, rather than one of its developers, here are some specifics from me:

Project layout:

-- Symbian has very specific ideas about project filesystem layout, as does Eclipse, and the two are fundamentally incompatible. Specifically:
-- Project files in Symbian-land are stored deep in a subdirectory, whilst Eclipse insists that .project and .cproject are at the outermost point which contains any relevant source code or headers.
-- Several Symbian projects may have the same 'outermost point' and thus conflict in Eclipse-land.
I know that the Carbide team and you yourself Doug have been fighting the Eclipse establishment to relax these rules, to little avail. I know you have hopes for EclipseFS. But meanwhile, this is responsible for a majority of the complexity.
-- The nature of projects themselves are a problem. Why shouldn't you just be able to work directly on Symbian project files? Why the need to create an Eclipse project? The Carbide team has done a great job of hiding it well using a slick import wizard, but it's still wrong.
-- And what's a workspace? Eclipse seems to want to copy, or at least link, my code into its own directory. Why? All my code has a fixed location in Symbian-land.

Builds:

The Carbide team have jumped through some big hoops to get the Symbian build system to play nicely with CDT, and on the whole, it now works well. But there are is still untidiness round the edges:

-- CDT can't cope properly with multi-line error messages emitted by compilers. In C++ code full of templates, that leads to despair and hopelessness.
-- Build configurations are important for Symbian. In CDT they are hidden away. And, although Carbide could expose that feature more obviously in the UI, it still might not be smooth in terms of the settings which applied globally versus as part of a build configuration.
-- There's nothing Carbide or CDT can do about this, but Symbian builds are slow. I think there's a perception they're slower in the IDE (sometimes this is true, but either way, it's the perception that counts). The whole CDT experience seems hugely less slick when builds always take 5-20 minutes. It's not related to complexity, but it is probably one reason why people are put off Carbide.

Indexer:

-- The indexer is *great*. But...
-- Often things go grey when you've made a mistake, but there's no way to find out the error message until you spend 10 minutes building the project with a compiler. It just seems weird to a user to have two different things parsing the code. Why does the IDE know I've done something wrong but it won't tell me what? Seems weird to an end-user.
-- Likewise, you have to fiddle with two sets of macro definitions, include paths etc. The Carbide team has done a good job of hiding this but it's not transparent.
-- Unfortunately the indexer still isn't quite perfect. For example the call hierarchy sometimes just stops. Which is a shame because when it works, it's terrific. But the fact that you can't quite trust its results makes everything seem complex.

Launches:

-- Launch configurations are useful. All the (fairly recent) efforts to hide/automate them are also useful. But they still seem to lurk as something sinister behind the scenes which users eventually will have to understand. The need for them is not obvious in Symbian-land.
-- The debug view is a pain. You seem to have to click in it before you can use debug keys, or at least it's possible for it to lose focus. Debugging should be a global operation, not stuck in some funny little pane. This may be Carbide-specific; I don't know.

Eclipse runes:

-- "Hard to learn" - to be a confident user of Carbide, you have to understand a perspective, a view, an editor, a plugin, a workspace, a project, a build configuration, a launch configuration, and probably a bit more. All of these are Eclipse terminology.
-- You just don't want to have to learn 10 more concepts when you're already struggling with the Symbian weirdness!
-- I imagine most Carbide users need to install Subversive pretty quickly. Then not only do they have to struggle with understanding plugins, update sites, etc. but they also have to contend with the Eclipse IP process, or specifically its implications meaning the key bits of Subversive are squirreled away on someone else's website. Sigh. It's enough to drive me mad and I must have installed it a dozen times. Still, things are improving in that specific area now.
-- Eclipse keystrokes differ from the rest of the world's.
-- Carbide's greatest value is in the indexer features hidden behind obscure keystrokes. Sadly I think most Carbide users don't get far enough to learn F3, ctrl-o, ctrl-alt-h, ctrl-t, etc.

I use Eclipse, Carbide and CDT all the time. For me, the power of the indexer makes it all worthwhile. But I must admit, if I were to try to create a simple IDE for Symbian beginners, I probably wouldn't start with Eclipse!

Adrian

On 11 Dec 2009, at 23:09, Doug Schaefer wrote:

Instead of talking in generalities, I'd prefer to talk with specifics. Saying Carbide is hard to learn, what exactly about it is it hard to learn? Is it things in the CDT or Eclipse platform or things Carbide has added on top? Is it creating projects? Is it setting up builds? Is it launching debug sessions? Is it creating files? Is it too many choices? Would adding wizards in strategic places make the CDT easier to learn?

Most of the complaints on usability with Eclipse I've heard are really complaints from users who find IDEs complex in general. Is Qt Creator really that less complex than the CDT? What about Qt Creator makes it easier to learn. And why don't we invest in the CDT to make it equivalent?

Doug.

On Fri, Dec 11, 2009 at 4:47 PM, Pawel Piech <pawel.piech@...> wrote:

All we've done so far is rather vendor-specific. What we would like to see in CDT is the ability to isolate and turn off various features using capabilities: e.g. build, static analysis, debuggers, etc. To accomplish this we would likely need to look at dependencies between these various CDT components and see if we can isolate them better. However, we haven't invested any time in this yet.
-Pawel

Paul Beusterien wrote:

Hi Pawel,

Thanks for the response. Are there any available artifacts from the stripped-down IDE investigation? Any effort estimates?

Regards,
Paul

On Thu, Dec 10, 2009 at 4:07 PM, Pawel Piech <pawel.piech@...> wrote:

Hi Paul,
Complexity is a common complaint about Eclipse-based tools (not especially limited to C - development tools). I don't know of any efforts to overhaul the UI, but I expect that there would be a lot of interest out there for it. For Wind River's part, we are investigating creating a stripped-down version of the IDE specifically targeted at Debugging use cases, but I know we won't be able to get far without support from the community.

Cheers,
Pawel

Paul Beusterien wrote:

Hi CDT community,

I'm responsible for the tools strategy at the Symbian Foundation. Like the Eclipse Foundation, Symbian depends on the contributions from open source communities to drive its mobile device platform technology forward.

I'm curious if you have any thoughts about one of the challenges we're facing with understanding/determining the direction for Symbian C++ development tools.

There are two open source communities vying for the Symbian C++ developer - Qt Creator and Carbide (based on CDT).

Carbide's investments have been primarily focused on adding features to give more power to device creators. While it has become very feature-full, it has also become very complex and hard to learn, especially for developers that want to just build simple mobile apps.

Qt Creator is a targeted C++ development environment with a big emphasis on usability. For example, it has rigorous hurdles to add a button or menu item. Now, it is rapidly adapting to improve its mobile development capabilities.

Thus, we currently have a fragmented C++ developer story at Symbian.

It is unlikely that Qt Creator will ever support the rich set of features that Carbide currently provides to the power user.

Are there any initiatives will enable CDT based IDEs to lower its learning curve and better support the needs of a simple C++ application developer?

Thanks,
Paul

--
Paul Beusterien
Development Tools Manager
Symbian Foundation
Foster City, California USA
twitter: paulbeusterien

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________ cdt-dev mailing list cdt-dev@...https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

From forum: Eclipse CDT - Development

Re: CDT and Qt Creator

2009-12-14T06:27:36Z

Well to be frank, I pretty much gave up on trying to get anything changed in the Resources area on e4, because the Platform Resources team didn't seem to have the time to devote to reviewing and collaborating on solutions. Despite having commit rights to e4, you can't really do anything in the Resources area without their signoff, so after having patches and ideas languish for months in Bugzilla with no real progress, I decided my time was better spent elsewhere.

===========================
Chris Recoskie
Team Lead, IBM CDT and RDT
IBM Toronto

Doug Schaefer ---12/11/2009 07:23:56 PM---I hope so. That's the whole driver behind the flexible resources work. It's been disappointing that

From:	Doug Schaefer <cdtdoug@...>
To:	"CDT General developers list." <cdt-dev@...>
Date:	12/11/2009 07:23 PM
Subject:	Re: [cdt-dev] CDT and Qt Creator
Sent by:	cdt-dev-bounces@...

I hope so. That's the whole driver behind the flexible resources work. It's been disappointing that more contributors haven't been able to help Serge out, especially those who apparently have a vested interest in it. Hopefully now that it's being put into Eclipse 3.6, we can take a better look at what Serge has done and make sure it meets our needs.

Doug.

On Fri, Dec 11, 2009 at 7:14 PM, John Cortell <rat042@...> wrote:

Won't the Project Layout issues be resolved by the E4

Flexible Projects

work Serge Beauchamp had done?

John

At 06:11 PM 12/11/2009, Doug Schaefer wrote:

This is great data, and we could do something about most of this, if we work together as a community to address them. Up until now, we haven't really been involved in solving these issues for Carbide.

Next question. How does Qt Creator do these things better? Since that's the real topic of this thread.

Doug

On Fri, Dec 11, 2009 at 6:44 PM, Adrian Taylor <

adrian@...

> wrote:

Speaking as a user of Carbide, rather than one of its developers, here are some specifics from me:

Project layout:

-- Symbian has very specific ideas about project filesystem layout, as does Eclipse, and the two are fundamentally incompatible. Specifically:

-- Project files in Symbian-land are stored deep in a subdirectory, whilst Eclipse insists that .project and .cproject are at the outermost point which contains any relevant source code or headers.

-- Several Symbian projects may have the same 'outermost point' and thus conflict in Eclipse-land.

I know that the Carbide team and you yourself Doug have been fighting the Eclipse establishment to relax these rules, to little avail. I know you have hopes for EclipseFS. But meanwhile, this is responsible for a majority of the complexity.

-- The nature of projects themselves are a problem. Why shouldn't you just be able to work directly on Symbian project files? Why the need to create an Eclipse project? The Carbide team has done a great job of hiding it well using a slick import wizard, but it's still wrong.

-- And what's a workspace? Eclipse seems to want to copy, or at least link, my code into its own directory. Why? All my code has a fixed location in Symbian-land.

Builds:

The Carbide team have jumped through some big hoops to get the Symbian build system to play nicely with CDT, and on the whole, it now works well. But there are is still untidiness round the edges:

-- CDT can't cope properly with multi-line error messages emitted by compilers. In C++ code full of templates, that leads to despair and hopelessness.

-- Build configurations are important for Symbian. In CDT they are hidden away. And, although Carbide could expose that feature more obviously in the UI, it still might not be smooth in terms of the settings which applied globally versus as part of a build configuration.

-- There's nothing Carbide or CDT can do about this, but Symbian builds are slow. I think there's a perception they're slower in the IDE (sometimes this is true, but either way, it's the perception that counts). The whole CDT experience seems hugely less slick when builds always take 5-20 minutes. It's not related to complexity, but it is probably one reason why people are put off Carbide.

Indexer:

-- The indexer is *great*. But...

-- Often things go grey when you've made a mistake, but there's no way to find out the error message until you spend 10 minutes building the project with a compiler. It just seems weird to a user to have two different things parsing the code. Why does the IDE know I've done something wrong but it won't tell me what? Seems weird to an end-user.

-- Likewise, you have to fiddle with two sets of macro definitions, include paths etc. The Carbide team has done a good job of hiding this but it's not transparent.

-- Unfortunately the indexer still isn't quite perfect. For example the call hierarchy sometimes just stops. Which is a shame because when it works, it's terrific. But the fact that you can't quite trust its results makes everything seem complex.

Launches:

-- Launch configurations are useful. All the (fairly recent) efforts to hide/automate them are also useful. But they still seem to lurk as something sinister behind the scenes which users eventually will have to understand. The need for them is not obvious in Symbian-land.

-- The debug view is a pain. You seem to have to click in it before you can use debug keys, or at least it's possible for it to lose focus. Debugging should be a global operation, not stuck in some funny little pane. This may be Carbide-specific; I don't know.

Eclipse runes:

-- "Hard to learn" - to be a confident user of Carbide, you have to understand a perspective, a view, an editor, a plugin, a workspace, a project, a build configuration, a launch configuration, and probably a bit more. All of these are Eclipse terminology.

-- You just don't want to have to learn 10 more concepts when you're already struggling with the Symbian weirdness!

-- I imagine most Carbide users need to install Subversive pretty quickly. Then not only do they have to struggle with understanding plugins, update sites, etc. but they also have to contend with the Eclipse IP process, or specifically its implications meaning the key bits of Subversive are squirreled away on someone else's website. Sigh. It's enough to drive me mad and I must have installed it a dozen times. Still, things are improving in that specific area now.

-- Eclipse keystrokes differ from the rest of the world's.

-- Carbide's greatest value is in the indexer features hidden behind obscure keystrokes. Sadly I think most Carbide users don't get far enough to learn F3, ctrl-o, ctrl-alt-h, ctrl-t, etc.

I use Eclipse, Carbide and CDT all the time. For me, the power of the indexer makes it all worthwhile. But I must admit, if I were to try to create a simple IDE for Symbian beginners, I probably wouldn't start with Eclipse!

Adrian

On 11 Dec 2009, at 23:09, Doug Schaefer wrote:

Most of the complaints on usability with Eclipse I've heard are really complaints from users who find IDEs complex in general. Is Qt Creator really that less complex than the CDT? What about Qt Creator makes it easier to learn. And why don't we invest in the CDT to make it equivalent?

Doug.

On Fri, Dec 11, 2009 at 4:47 PM, Pawel Piech <

pawel.piech@...

> wrote:

All we've done so far is rather vendor-specific. What we would like to see in CDT is the ability to isolate and turn off various features using capabilities: e.g. build, static analysis, debuggers, etc. To accomplish this we would likely need to look at dependencies between these various CDT components and see if we can isolate them better. However, we haven't invested any time in this yet.

-Pawel

Paul Beusterien wrote:

Hi Pawel,

Thanks for the response. Are there any available artifacts from the stripped-down IDE investigation? Any effort estimates?

Regards,

Paul

On Thu, Dec 10, 2009 at 4:07 PM, Pawel Piech <

pawel.piech@...

> wrote:

Hi Paul,

Complexity is a common complaint about Eclipse-based tools (not especially limited to C - development tools). I don't know of any efforts to overhaul the UI, but I expect that there would be a lot of interest out there for it. For Wind River's part, we are investigating creating a stripped-down version of the IDE specifically targeted at Debugging use cases, but I know we won't be able to get far without support from the community.

Cheers,

Pawel

Paul Beusterien wrote:

Hi CDT community,

I'm responsible for the tools strategy at the

Symbian Foundation

. Like the Eclipse Foundation, Symbian depends on the contributions from open source communities to drive its mobile device platform technology forward.

I'm curious if you have any thoughts about one of the challenges we're facing with understanding/determining the direction for Symbian C++ development tools.

There are two open source communities vying for the Symbian C++ developer -

Qt Creator

and Carbide (based on CDT).

Carbide's investments have been primarily focused on adding features to give more power to device creators. While it has become very feature-full, it has also become very complex and hard to learn, especially for developers that want to just build simple mobile apps.

Qt Creator is a targeted C++ development environment with a big emphasis on usability. For example, it has rigorous hurdles to add a button or menu item. Now, it is rapidly adapting to improve its mobile development capabilities.

Thus, we currently have a fragmented C++ developer story at Symbian.

It is unlikely that Qt Creator will ever support the rich set of features that Carbide currently provides to the power user.

Are there any initiatives will enable CDT based IDEs to lower its learning curve and better support the needs of a simple C++ application developer?

Thanks,

Paul

Paul Beusterien

Development Tools Manager

Symbian Foundation

Foster City, California USA

twitter: paulbeusterien

_______________________________________________

cdt-dev mailing list

cdt-dev@...

https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________

cdt-dev mailing list

cdt-dev@...

https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________

cdt-dev mailing list

cdt-dev@...

https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________

cdt-dev mailing list

cdt-dev@...

https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list

cdt-dev@...

https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list

cdt-dev@...

https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________ cdt-dev mailing list cdt-dev@...https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

From forum: Eclipse CDT - Development

Eclipse + cdb

2009-12-14T04:29:41Z

Hi,

I am sorry to send that mail on the dev channel but I really wanted to get dev point of view.

Our company switch compiler under windows from mingw to mscv.

We have been using eclipse for a long time now and have been loving it. Now going to msvc means that gdb doesn’t work anymore. I looked everywhere to see If there was a way to debug with cdb but I couldn’t find a definitive answer.

So is it possible?

And if not is it something planned? I know it s possible as codeblock and qtcreator do it but I don’t know what are your plans for cdt.

Thanks a lot

Martin

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

From forum: Eclipse CDT - Development

Why there are two implementations related to getGDBProcess() method in MIProcessAdapter class

2009-12-14T03:30:46Z

Hi all,

I am migrating our existing debug launch configuration which internally
uses MIProcessAdapter.

My doubts are as follows :-

1. I found two different implementations for the method getGDBProcess() in
MIProcessAdapter() class. So, why there are two implementations ? Which one
is called when.
2. I checked out the code from CDT 6 branch, it has the code which uses
thread but when I executed this plugin , then the method called is one
which is not the threaded. Why is it happening so ? When I looked at the
package names for each of them. They both are shown same.
3. The threaded one is much faster than the non-threaded one. And it seems
in earliar cdt version i.e. CDT 4, the threaded one was called. But as I
mentioned in my #2 question that when I tested with CDT 6, then the
non-threaded one is getting called. So, now which one is the latest code.
If it is non-threaded one then why the threaded one is replaced by
non-threaded as non-threaded takes lot of time.
4. And if non-threaded one is latest then where does that code exists. Why
checking out the code from CDT 6 branch still has threaded implementation ?

When I checked out the code from CVS for Branch CDT6_0, it shows the
following implementation for getGDBProcess() method in MIProcessAdapter
class

protected Process getGDBProcess(String[] args, int launchTimeout,
IProgressMonitor monitor) throws IOException {
final Process pgdb = ProcessFactory.getFactory().exec(args);
Thread syncStartup = new Thread("GDB Start") { //$NON-NLS-1$
public void run() {
try {
PushbackInputStream pb = new
PushbackInputStream(pgdb.getInputStream());
gdbInputStream = pb;
pb.unread(pb.read()); // actually read
something, then return it
} catch (Exception e) {
// Do nothing, ignore the errors
}
}
};
syncStartup.start();

int timepass = 0;
if (launchTimeout <= 0) {
// Simulate we are waiting forever.
launchTimeout = Integer.MAX_VALUE;
}

// To respect the IProgressMonitor we can not use wait/notify
// instead we have to loop and check for the monitor to allow
to cancel the thread.
// The monitor is check every 1 second delay;
for (timepass = 0; timepass < launchTimeout; timepass +=
ONE_SECOND) {
if (syncStartup.isAlive() && !monitor.isCanceled()) {
try {
Thread.sleep(ONE_SECOND);
} catch (InterruptedException e) {
// ignore
}
} else {
break;
}
}
try {
syncStartup.interrupt();
syncStartup.join(ONE_SECOND);
} catch (InterruptedException e) {
// ignore
}
if (monitor.isCanceled()) {
pgdb.destroy();
throw new OperationCanceledException();
} else if (timepass > launchTimeout) {
pgdb.destroy();
String message =
MIPlugin.getResourceString("src.GDBDebugger.Error_launch_timeout");
//$NON-NLS-1$
throw new IOException(message);
}
return pgdb;
}

However when I actually launch it and use the debugger to track it , it
actually executes the following method of getGDBProcess() in
MIAdapterClass.

protected Process getGDBProcess(String[] args , int launchTimeout,
IProgressMonitor monitor) throws IOException {
final Process pgdb = ProcessFactory.getFactory().exec(args);
int timepass = 0;
if (launchTimeout <=0) {
// Simulate we are waiting forever
launchTimeout = Integer.MAX_VALUE;
}

InputStream stream = pgdb.getInputStream();
for(timepass = 0; timepass < launchTimeout ; timeout += ONE_SECOND){
if (stream.available()<=0 && !monitor.isCancelled()){
try {
Thread.sleep(ONE_SECOND);
} catch (InterruptedException e){
//ignore
}
} else {
break;
}
}
if (monitor.isCancelled()){
pgdb.destroy();
throw new OperationCancelledException();
} else if (timepass > launchTimeout) {
pgdb.destroy();
String message =
MIPlugin.getResourceString("src.GDBDebugger.Error_launch_timeout");
throw new IOException(message);
}
return pgdb;
}

Thanks & Regards,

Nayna Jain

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

From forum: Eclipse CDT - Development

Re: build console code location

2009-12-13T12:25:28Z

Maybe it's not a problem any more ( I was not monitoring changes in this
area last time), but I guess that a placing of console code in UI
plugin could be a cause of a big pain for those who implement headless
application with console output.

Alex

On 13/12/2009 1:45 PM, Doug Schaefer wrote:

> As the new build system takes shape, we can eventually move it to the
> cdt.build.ui plugins. The relationship between the make and
> managedbuilder plugins right now is a little tough to figure, so I'd
> prefer not to make the change now.
>
> Doug.
>
> On Sun, Dec 13, 2009 at 1:35 PM, Andrew Gvozdev <angvoz.dev@...
> <mailto:angvoz.dev@...>> wrote:
>
> Guys, please help resolving this problem, because I'm
> completely blocked making patches
>
> while build console is in cdt.ui.
>
>
> As I already stated my opinion on a few occasions, Build Console
> should not belong to cdt.core but to one of build packages. In my
> opinion the most approprate place is cdt.make package. My
> reasoning is following:
>
> The current hierarchy goes like that:
>
> cdt.core
> |
> cdt.make.core <- cdt.make.ui
> |
> cdt.managedbuilder.core <- cdt.managedbuilder.ui
>
> The console is used in both make.core and managedbuilder.core via
> IConsole interface. As far as I see IConsole is only used for
> Build Console notion.
>
> Currently managedbuilder took over "new" manaded builds and
> Makefile project build (which is just a flavor of a managed
> project). However, old style projects and their build live dormant
> in cdt.make plugins. Although you cannot create those in vanilla
> CDT installation, they are pretty much alive and still being used
> by some third party plugins. (As a side note: We can say that we
> don't support those but we should still keep them operational.)
>
> So, in my opinion, Build Console belongs to cdt.make.* packages.
>
> As far as architecture, I stated my vision in bug 296935 New CDT
> Build System <https://bugs.eclipse.org/bugs/show_bug.cgi?id=296935>:
>
> Doug provided several good examples how the build model would
> be used. I'd like to provide in some sense a counter-example
> to illustrate some thoughts about architecture:
>
>
> There is a certain category of users who need indexer code
> navigation but are not interested in any build. They just use
> CDT for editing C/C++ files. I would go that far as state that
> well engineered architecture would allow to do that without
> installing build plugins and any overhead related to build system.
>
>
> One corollary of that is that cdt.core plugin currently is
> bloated with features which should really be in other plugins.
> Just look at its size. Such features as error parsers, build
> console etc. should be in build plugin(s) rather then in core.
> I am thinking of a build system as being multi-layered where
> each next layer is built on top of another. One layer is core
> which provides core functions but none of related to build.
> Next one would provide general build facilities such as build
> console, error parsers, unmanaged build, scanner discovery (in
> that view it would be cdt.make plugin which is sadly declared
> dead). Finally, managedbuilder plugin which provides the means
> of generating makefiles. Different managedbuilders like Ed's
> middle ground builder could be created as well.
>
>
> Doug, since I think that may contradict the direction you are
> taking for the new new build it would be nice if you (and anyone
> interested) could comment on that before we started moving.
>
> Thanks,
> Andrew
>
> 2009/11/30 Dmitry Kozlov <ddk@...
> <mailto:ddk@...>>
>
> As Andrew Gvozdev wrote to me commenting one of build console
> patches
>
>
> "- The name of build output file is being set in Builder
> Settings Tab (which is
> good). However, the Builder Settings are per configuration, so
> the file name
> needs to be stored per configuration as well. It should not be
> kept in
> .project. .project/.cproject could be shared via code
> repository and I don't
> think output file name normally belongs there."
>
> But configuration is part of cdt.managedbuilder.core. So to
> apply all my console enhancements and
> to confirm all Andrew's wishes I need console to depend on
> cdt.make.ui and cdt.managedbuilder.core. So there are two
> possible locations for buildconsole code:
> top-level separate package or part of cdt.managedbuilder.ui.
>
> Guys, please help resolving this problem, because I'm
> completely blocked making patches
> while build console is in cdt.ui.
>
> Dmitry
>
>
> Dmitry Kozlov wrote:
>
> Hi,
> we were discussing run command toolbar addition to build
> console toolbar.
> The idea is to add fields to build console toolbar which
> enables to run
> build command or some other command.
> This code requires build console to depend on make.core
> because we need
> to use
>
> MakeBuilderUtil.getBuildDirectory(project, info) and
> MakeBuilderUtil.getBuildDirectoryURI(project, info)
> to get working directory for command (working in other
> directory have no
> sense)
>
> and error parser:
> StreamMonitor streamMon = new StreamMonitor(new
> SubProgressMonitor(monitor, 100), cos, last.intValue());
> ErrorParserManager epm = new ErrorParserManager(project,
> workingDirectoryURI, this, info.getErrorParsers());
> ...
> ConsoleOutputSniffer sniffer =
> ScannerInfoConsoleParserFactory.getMakeBuilderOutputSniffer(
> stdout, stderr, project,
> workingDirectory, null, this, null);
>
>
> Will it be accepted by upstream if I move all build
> console code to
> cdt.make.ui?
>
> ---
> Dmitry
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@... <mailto:cdt-dev@...>
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@... <mailto:cdt-dev@...>
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@... <mailto:cdt-dev@...>
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@...
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

From forum: Eclipse CDT - Development

Re: build console code location

2009-12-13T10:45:05Z

As the new build system takes shape, we can eventually move it to the cdt.build.ui plugins. The relationship between the make and managedbuilder plugins right now is a little tough to figure, so I'd prefer not to make the change now.

Doug.

On Sun, Dec 13, 2009 at 1:35 PM, Andrew Gvozdev <angvoz.dev@...> wrote:

Guys, please help resolving this problem, because I'm completely blocked making patches
while build console is in cdt.ui.

As I already stated my opinion on a few occasions, Build Console should not belong to cdt.core but to one of build packages. In my opinion the most approprate place is cdt.make package. My reasoning is following:

The current hierarchy goes like that:

cdt.core
|
cdt.make.core <- cdt.make.ui
|
cdt.managedbuilder.core <- cdt.managedbuilder.ui

The console is used in both make.core and managedbuilder.core via IConsole interface. As far as I see IConsole is only used for Build Console notion.

Currently managedbuilder took over "new" manaded builds and Makefile project build (which is just a flavor of a managed project). However, old style projects and their build live dormant in cdt.make plugins. Although you cannot create those in vanilla CDT installation, they are pretty much alive and still being used by some third party plugins. (As a side note: We can say that we don't support those but we should still keep them operational.)

So, in my opinion, Build Console belongs to cdt.make.* packages.

As far as architecture, I stated my vision in bug 296935 New CDT Build System:

Doug provided several good examples how the build model would be used. I'd like to provide in some sense a counter-example to illustrate some thoughts about architecture:

There is a certain category of users who need indexer code navigation but are not interested in any build. They just use CDT for editing C/C++ files. I would go that far as state that well engineered architecture would allow to do that without installing build plugins and any overhead related to build system.

One corollary of that is that cdt.core plugin currently is bloated with features which should really be in other plugins. Just look at its size. Such features as error parsers, build console etc. should be in build plugin(s) rather then in core. I am thinking of a build system as being multi-layered where each next layer is built on top of another. One layer is core which provides core functions but none of related to build. Next one would provide general build facilities such as build console, error parsers, unmanaged build, scanner discovery (in that view it would be cdt.make plugin which is sadly declared dead). Finally, managedbuilder plugin which provides the means of generating makefiles. Different managedbuilders like Ed's middle ground builder could be created as well.

Doug, since I think that may contradict the direction you are taking for the new new build it would be nice if you (and anyone interested) could comment on that before we started moving.

Thanks,
Andrew

2009/11/30 Dmitry Kozlov <ddk@...>

As Andrew Gvozdev wrote to me commenting one of build console patches

"- The name of build output file is being set in Builder Settings Tab (which is
good). However, the Builder Settings are per configuration, so the file name
needs to be stored per configuration as well. It should not be kept in
.project. .project/.cproject could be shared via code repository and I don't
think output file name normally belongs there."

But configuration is part of cdt.managedbuilder.core. So to apply all my console enhancements and
to confirm all Andrew's wishes I need console to depend on
cdt.make.ui and cdt.managedbuilder.core. So there are two possible locations for buildconsole code:
top-level separate package or part of cdt.managedbuilder.ui.

Guys, please help resolving this problem, because I'm completely blocked making patches
while build console is in cdt.ui.

Dmitry

Dmitry Kozlov wrote:

Hi,
we were discussing run command toolbar addition to build console toolbar.
The idea is to add fields to build console toolbar which enables to run
build command or some other command.
This code requires build console to depend on make.core because we need
to use

MakeBuilderUtil.getBuildDirectory(project, info) and
MakeBuilderUtil.getBuildDirectoryURI(project, info)
to get working directory for command (working in other directory have no
sense)

and error parser:
StreamMonitor streamMon = new StreamMonitor(new
SubProgressMonitor(monitor, 100), cos, last.intValue());
ErrorParserManager epm = new ErrorParserManager(project,
workingDirectoryURI, this, info.getErrorParsers());
...
ConsoleOutputSniffer sniffer =
ScannerInfoConsoleParserFactory.getMakeBuilderOutputSniffer(
stdout, stderr, project,
workingDirectory, null, this, null);

Will it be accepted by upstream if I move all build console code to
cdt.make.ui?

---
Dmitry

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

From forum: Eclipse CDT - Development

Re: build console code location

2009-12-13T10:35:54Z

Guys, please help resolving this problem, because I'm completely blocked making patches

while build console is in cdt.ui.

As I already stated my opinion on a few occasions, Build Console should not belong to cdt.core but to one of build packages. In my opinion the most approprate place is cdt.make package. My reasoning is following:

The current hierarchy goes like that:

cdt.core

cdt.make.core <- cdt.make.ui

cdt.managedbuilder.core <- cdt.managedbuilder.ui

The console is used in both make.core and managedbuilder.core via IConsole interface. As far as I see IConsole is only used for Build Console notion.

Currently managedbuilder took over "new" manaded builds and Makefile project build (which is just a flavor of a managed project). However, old style projects and their build live dormant in cdt.make plugins. Although you cannot create those in vanilla CDT installation, they are pretty much alive and still being used by some third party plugins. (As a side note: We can say that we don't support those but we should still keep them operational.)

So, in my opinion, Build Console belongs to cdt.make.* packages.

As far as architecture, I stated my vision in bug 296935 New CDT Build System:

Doug provided several good examples how the build model would be used. I'd like to provide in some sense a counter-example to illustrate some thoughts about architecture:

There is a certain category of users who need indexer code navigation but are not interested in any build. They just use CDT for editing C/C++ files. I would go that far as state that well engineered architecture would allow to do that without installing build plugins and any overhead related to build system.

One corollary of that is that cdt.core plugin currently is bloated with features which should really be in other plugins. Just look at its size. Such features as error parsers, build console etc. should be in build plugin(s) rather then in core. I am thinking of a build system as being multi-layered where each next layer is built on top of another. One layer is core which provides core functions but none of related to build. Next one would provide general build facilities such as build console, error parsers, unmanaged build, scanner discovery (in that view it would be cdt.make plugin which is sadly declared dead). Finally, managedbuilder plugin which provides the means of generating makefiles. Different managedbuilders like Ed's middle ground builder could be created as well.

Doug, since I think that may contradict the direction you are taking for the new new build it would be nice if you (and anyone interested) could comment on that before we started moving.

Thanks,

Andrew

2009/11/30 Dmitry Kozlov <ddk@...>

As Andrew Gvozdev wrote to me commenting one of build console patches

"- The name of build output file is being set in Builder Settings Tab (which is
good). However, the Builder Settings are per configuration, so the file name
needs to be stored per configuration as well. It should not be kept in
.project. .project/.cproject could be shared via code repository and I don't
think output file name normally belongs there."

But configuration is part of cdt.managedbuilder.core. So to apply all my console enhancements and
to confirm all Andrew's wishes I need console to depend on
cdt.make.ui and cdt.managedbuilder.core. So there are two possible locations for buildconsole code:
top-level separate package or part of cdt.managedbuilder.ui.

Guys, please help resolving this problem, because I'm completely blocked making patches
while build console is in cdt.ui.

Dmitry

Dmitry Kozlov wrote:

Hi,
we were discussing run command toolbar addition to build console toolbar.
The idea is to add fields to build console toolbar which enables to run
build command or some other command.
This code requires build console to depend on make.core because we need
to use

MakeBuilderUtil.getBuildDirectory(project, info) and
MakeBuilderUtil.getBuildDirectoryURI(project, info)
to get working directory for command (working in other directory have no
sense)

and error parser:
StreamMonitor streamMon = new StreamMonitor(new
SubProgressMonitor(monitor, 100), cos, last.intValue());
ErrorParserManager epm = new ErrorParserManager(project,
workingDirectoryURI, this, info.getErrorParsers());
...
ConsoleOutputSniffer sniffer =
ScannerInfoConsoleParserFactory.getMakeBuilderOutputSniffer(
stdout, stderr, project,
workingDirectory, null, this, null);

Will it be accepted by upstream if I move all build console code to
cdt.make.ui?

---
Dmitry

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

From forum: Eclipse CDT - Development

Re: 6.1.0 weekly build

2009-12-12T06:40:45Z

Absolutely! This has been a sore point for a long time. Thanks, Andrew!

On Sat, Dec 12, 2009 at 6:29 AM, James Blackburn <jamesblackburn@...> wrote:

Speaking of tests...

The M4 candidate:
http://download.eclipse.org/tools/cdt/builds/6.1.0/I.I200912110805/junits.html
Has terrifically few test failures (3 remaining in managedbuild - down
from 40!).

Thanks Andrew for working so hard on this!

James

2009/11/20 Andrew Gvozdev <angvoz.dev@...>:

> What happened with Unit Testing results for weekly builds? There is nothing
> on the
> page http://download.eclipse.org/tools/cdt/builds/6.1.0/I.I200911200812/junits.html.
> The same thing happened with 6.0.2. The results are there for last week
> builds.
> Thanks,
> Andrew
>

> _______________________________________________
> cdt-dev mailing list
> cdt-dev@...

> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>
_______________________________________________

cdt-dev mailing list
cdt-dev@...

https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

From forum: Eclipse CDT - Development

Re: 6.1.0 weekly build

2009-12-12T03:29:15Z

Speaking of tests...

The M4 candidate:
http://download.eclipse.org/tools/cdt/builds/6.1.0/I.I200912110805/junits.html
Has terrifically few test failures (3 remaining in managedbuild - down
from 40!).

Thanks Andrew for working so hard on this!

James

2009/11/20 Andrew Gvozdev <angvoz.dev@...>:

> What happened with Unit Testing results for weekly builds? There is nothing
> on the
> page http://download.eclipse.org/tools/cdt/builds/6.1.0/I.I200911200812/junits.html.
> The same thing happened with 6.0.2. The results are there for last week
> builds.
> Thanks,
> Andrew
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@...
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

From forum: Eclipse CDT - Development

Re: CDT and Qt Creator

2009-12-12T03:22:36Z

2009/12/12 John Cortell <rat042@...>:
> Won't the Project Layout issues be resolved by the E4 Flexible Projects work
> Serge Beauchamp had done?

Our product has serge's flexible resources stuff in it, and it works
well. It effectively gives you VS style projects + the Eclipse
resource model - local history, team support (if linked resources are
supported), etc all working with CDT editing, managedbuild & debug
(CDI).

I believe CDT will be able to cope with all this just fine. There
may be a couple of places which still don't handle linked resources
properly, but when I was working on this, I went on a blitz of
submitting / committing fixes...

Cheers,
James

>
> John
>
> At 06:11 PM 12/11/2009, Doug Schaefer wrote:
>
> This is great data, and we could do something about most of this, if we work
> together as a community to address them. Up until now, we haven't really
> been involved in solving these issues for Carbide.
>
> Next question. How does Qt Creator do these things better? Since that's the
> real topic of this thread.
>
> Doug
>
> On Fri, Dec 11, 2009 at 6:44 PM, Adrian Taylor <adrian@...> wrote:
> Speaking as a user of Carbide, rather than one of its developers, here are
> some specifics from me:
>
> Project layout:
>
> -- Symbian has very specific ideas about project filesystem layout, as does
> Eclipse, and the two are fundamentally incompatible. Specifically:
> -- Project files in Symbian-land are stored deep in a subdirectory, whilst
> Eclipse insists that .project and .cproject are at the outermost point which
> contains any relevant source code or headers.
> -- Several Symbian projects may have the same 'outermost point' and thus
> conflict in Eclipse-land.
> I know that the Carbide team and you yourself Doug have been fighting the
> Eclipse establishment to relax these rules, to little avail. I know you have
> hopes for EclipseFS. But meanwhile, this is responsible for a majority of
> the complexity.
> -- The nature of projects themselves are a problem. Why shouldn't you just
> be able to work directly on Symbian project files? Why the need to create an
> Eclipse project? The Carbide team has done a great job of hiding it well
> using a slick import wizard, but it's still wrong.
> -- And what's a workspace? Eclipse seems to want to copy, or at least link,
> my code into its own directory. Why? All my code has a fixed location in
> Symbian-land.
>
> Builds:
>
> The Carbide team have jumped through some big hoops to get the Symbian build
> system to play nicely with CDT, and on the whole, it now works well. But
> there are is still untidiness round the edges:
>
> -- CDT can't cope properly with multi-line error messages emitted by
> compilers. In C++ code full of templates, that leads to despair and
> hopelessness.
> -- Build configurations are important for Symbian. In CDT they are hidden
> away. And, although Carbide could expose that feature more obviously in the
> UI, it still might not be smooth in terms of the settings which applied
> globally versus as part of a build configuration.
> -- There's nothing Carbide or CDT can do about this, but Symbian builds are
> slow. I think there's a perception they're slower in the IDE (sometimes this
> is true, but either way, it's the perception that counts). The whole CDT
> experience seems hugely less slick when builds always take 5-20 minutes.
> It's not related to complexity, but it is probably one reason why people are
> put off Carbide.
>
> Indexer:
>
> -- The indexer is *great*. But...
> -- Often things go grey when you've made a mistake, but there's no way to
> find out the error message until you spend 10 minutes building the project
> with a compiler. It just seems weird to a user to have two different things
> parsing the code. Why does the IDE know I've done something wrong but it
> won't tell me what? Seems weird to an end-user.
> -- Likewise, you have to fiddle with two sets of macro definitions, include
> paths etc. The Carbide team has done a good job of hiding this but it's not
> transparent.
> -- Unfortunately the indexer still isn't quite perfect. For example the call
> hierarchy sometimes just stops. Which is a shame because when it works, it's
> terrific. But the fact that you can't quite trust its results makes
> everything seem complex.
>
> Launches:
>
> -- Launch configurations are useful. All the (fairly recent) efforts to
> hide/automate them are also useful. But they still seem to lurk as something
> sinister behind the scenes which users eventually will have to understand.
> The need for them is not obvious in Symbian-land.
> -- The debug view is a pain. You seem to have to click in it before you can
> use debug keys, or at least it's possible for it to lose focus. Debugging
> should be a global operation, not stuck in some funny little pane. This may
> be Carbide-specific; I don't know.
>
> Eclipse runes:
>
> -- "Hard to learn" - to be a confident user of Carbide, you have to
> understand a perspective, a view, an editor, a plugin, a workspace, a
> project, a build configuration, a launch configuration, and probably a bit
> more. All of these are Eclipse terminology.
> -- You just don't want to have to learn 10 more concepts when you're already
> struggling with the Symbian weirdness!
> -- I imagine most Carbide users need to install Subversive pretty quickly.
> Then not only do they have to struggle with understanding plugins, update
> sites, etc. but they also have to contend with the Eclipse IP process, or
> specifically its implications meaning the key bits of Subversive are
> squirreled away on someone else's website. Sigh. It's enough to drive me mad
> and I must have installed it a dozen times. Still, things are improving in
> that specific area now.
> -- Eclipse keystrokes differ from the rest of the world's.
> -- Carbide's greatest value is in the indexer features hidden behind obscure
> keystrokes. Sadly I think most Carbide users don't get far enough to learn
> F3, ctrl-o, ctrl-alt-h, ctrl-t, etc.
>
> I use Eclipse, Carbide and CDT all the time. For me, the power of the
> indexer makes it all worthwhile. But I must admit, if I were to try to
> create a simple IDE for Symbian beginners, I probably wouldn't start with
> Eclipse!
>
> Adrian
>
>
> On 11 Dec 2009, at 23:09, Doug Schaefer wrote:
>
> Instead of talking in generalities, I'd prefer to talk with specifics.
> Saying Carbide is hard to learn, what exactly about it is it hard to learn?
> Is it things in the CDT or Eclipse platform or things Carbide has added on
> top? Is it creating projects? Is it setting up builds? Is it launching debug
> sessions? Is it creating files? Is it too many choices? Would adding wizards
> in strategic places make the CDT easier to learn?
>
> Most of the complaints on usability with Eclipse I've heard are really
> complaints from users who find IDEs complex in general. Is Qt Creator really
> that less complex than the CDT? What about Qt Creator makes it easier to
> learn. And why don't we invest in the CDT to make it equivalent?
>
> Doug.
>
> On Fri, Dec 11, 2009 at 4:47 PM, Pawel Piech < pawel.piech@...>
> wrote:
> All we've done so far is rather vendor-specific. What we would like to see
> in CDT is the ability to isolate and turn off various features using
> capabilities: e.g. build, static analysis, debuggers, etc. To accomplish
> this we would likely need to look at dependencies between these various CDT
> components and see if we can isolate them better. However, we haven't
> invested any time in this yet.
> -Pawel
>
>
>
> Paul Beusterien wrote:
>
> Hi Pawel,
>
> Thanks for the response. Are there any available artifacts from the
> stripped-down IDE investigation? Any effort estimates?
>
> Regards,
> Paul
>
> On Thu, Dec 10, 2009 at 4:07 PM, Pawel Piech < pawel.piech@...>
> wrote:
> Hi Paul,
> Complexity is a common complaint about Eclipse-based tools (not especially
> limited to C - development tools). I don't know of any efforts to overhaul
> the UI, but I expect that there would be a lot of interest out there for
> it. For Wind River's part, we are investigating creating a stripped-down
> version of the IDE specifically targeted at Debugging use cases, but I know
> we won't be able to get far without support from the community.
>
> Cheers,
> Pawel
>
> Paul Beusterien wrote:
>
> Hi CDT community,
>
> I'm responsible for the tools strategy at the Symbian Foundation. Like the
> Eclipse Foundation, Symbian depends on the contributions from open source
> communities to drive its mobile device platform technology forward.
>
> I'm curious if you have any thoughts about one of the challenges we're
> facing with understanding/determining the direction for Symbian C++
> development tools.
>
> There are two open source communities vying for the Symbian C++ developer -
> Qt Creator and Carbide (based on CDT).
>
> Carbide's investments have been primarily focused on adding features to give
> more power to device creators. While it has become very feature-full, it has
> also become very complex and hard to learn, especially for developers that
> want to just build simple mobile apps.
>
> Qt Creator is a targeted C++ development environment with a big emphasis on
> usability. For example, it has rigorous hurdles to add a button or menu
> item. Now, it is rapidly adapting to improve its mobile development
> capabilities.
>
> Thus, we currently have a fragmented C++ developer story at Symbian.
>
> It is unlikely that Qt Creator will ever support the rich set of features
> that Carbide currently provides to the power user.
>
> Are there any initiatives will enable CDT based IDEs to lower its learning
> curve and better support the needs of a simple C++ application developer?
>
> Thanks,
> Paul
>
> --
> Paul Beusterien
> Development Tools Manager
> Symbian Foundation
> Foster City, California USA
> twitter: paulbeusterien
>
>
>
>
>
>
> _______________________________________________
>
> cdt-dev mailing list
>
> cdt-dev@...
>
>
>
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>
>
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@...
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@...
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@...
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@...
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@...
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

From forum: Eclipse CDT - Development

comment lost when write ast in c file

2009-12-12T03:16:22Z

hello

i try to add brace after "if", "for" or while ... if brace don't exist:

if(a) b=0; /*comments*/

=> if(a) { b=0;}

i succes with change CASTExpressionStatement in CASTCompoundStatement for statement ThenClause elseClase (for if)
body (for for and while)....

at the end my ast is correct after
ASTWriter writer = new ASTWriter();
String root = writer.write(ast);
is done

BUT when i write root (which is a string) in a cfile, i lose comments which existed in original c file.

Coud you help me please??

How write my ast in a cfile and keep existed comments???

thanks a lot

From forum: Eclipse CDT - Development

Re: CDT and Qt Creator

2009-12-11T18:50:50Z

Totally agree Leo. And where there are things we need to work on to make Eclipse less Java centric. CDT has a powerful voice in the Eclipse community these days. We need to wield it a bit more.

So back to Qt Creator, I just installed it from my Fedora 12 distro. It looks a lot like Eclipse. Perspectives, views, editors, key bindings (no emacs keys in the default install :(). Keys seem to be the same (Ctrl-space for content assist for example). Project creation was a similar experience, lots of choices. Launch configurations are even there but set up automatically for you, something we should do for CDT projects too.

We need to clean up a few things and add more project templates to address usability, but it doesn't appear to me that Qt Creator is that much simpler than the CDT. Unless I'm missing something, and again, specific comparisons from people who've actively used both would be helpful. (or are we FUD chasing here?)

Doug

On Fri, Dec 11, 2009 at 9:25 PM, Treggiari, Leo <leo.treggiari@...> wrote:

> And, yeah, if your IDE doesn't do as much, it will be simpler.

There seems to be a usability tradeoff between IDEs focused on a single language and a limited set of problems domains, vs. a generic, multi-language IDE like Eclipse or Visual Studio. Examples on the Visual Studio side include, on the simplicity end, Visual Basic and Visual C++ from ten years ago vs. the current, all encompassing Visual Studio. A simple example is on the usability of VC++ version 6 (which pretty much only supported C++ development) and its successors which support .NET languages, additional tools etc. When the user asked for help on a topic in VC++ version 6, they got help specific to using it with VC++. With later versions of Visual Studio, you have to wade through many hits to help topics that are not appropriate to your task at hand. There are ways to try to handle this including, filtering, context sensitivity, but Visual Studio has not yet returned to the usability of VC++ version 6 help – at least in the opinion of many users…

Eclipse is another “mega-IDE”, which unfortunately for C++ programmers, has a Java “slant” – the most annoying examples being the project file system restrictions and the lack of build configurations. It exposes new concepts that probably would not be necessary if it were a C++ only IDE. However, I’ll take a highly extensible, multi-platform, mega-IDE over a non-extensible, C++ only IDE. Actually I know nothing about Qt Creator and am just assuming it is non-extensible – e.g. the ability to plug in widely varying new C++ tools without convincing the providers of the IDE to do it themselves.

Leo

From: cdt-dev-bounces@... [mailto:cdt-dev-bounces@...] On Behalf Of Doug Schaefer
Sent: Friday, December 11, 2009 4:22 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] CDT and Qt Creator

Thanks, Mike. The indexer is truly our biggest asset and one of things I'm most proud of for our community. I use the CDT for some small projects at work and for playing with the Android native development kit and I'm always pleasantly surprised when it works as often as it does even for platforms we never thought of when building it (like Android).

BTW, I ran Eclipse on my Dell Mini 10v and it ran fine, other than the tiny screen. And it's just a Atom chip with 1G RAM.

As for OS X, that's really up to the community to support. Right now, I don't think any of the vendors contributing to the CDT support Mac for their products, thus the weaker support. If I had a Mac, I would be inclined to make it work better there, but I don't.

And, yeah, if your IDE doesn't do as much, it will be simpler.

Doug.

On Fri, Dec 11, 2009 at 7:04 PM, Michael Jackson <mike.jackson@...> wrote:

As a User....

I'll vote for the indexer (with a caveat). The indexer is basically the main reason I use Eclipse rather than Visual Studio* or Xcode**, which are my two main platforms. 99% of the time the indexer has the proper variable, template, method, class in its cache to make intelligent selections. QtCreator's indexer is,well, not "there" yet.

The "Code Templates", the ones where I can type "sout" and have that expanded inline to std::cout << "" << std::endl; are absolutely WONDERFUL. QtCreator does not have these.

Caveats: With boost versions greater that 1.36 the indexer has a problem with shared_ptr.hpp. Not really sure what is going on but by code stopping being indexed completely when I switch versions of Boost from 1.36 to anything higher. No idea what the problem is but it generally sucks. I actually keep boost 1.36 around just for the indexer to use so I can get code completion. Visual Assist X for Visual Studio (while costing money) does NOT seem to have the problem with newer versions of boost, but then again, you are paying money for it. Visual Studio without Visual Assist X is just a lost cause for C++ programming and code completion. Xcode for C++ is about the same type of joke.

Eclipse is Big and Bulky and you need a hulking huge machine to run it. (Xeon 5500 with 12 GB of Ram here). I use CMake to generate makefiles, and then manually setup the "Makefile" project in eclipse. I tell git to ignore the .cproject and .project file in the top level of my source tree. _I_ didn't find CDT too bad to start out with but then again I was doing pretty vanilla C++ programming. '

Lately, CDT has taken a turn for the worse on OS X. Two major bugs in debugging are forcing me over to the Visual Studio camp so I can effectively debug my software. This only effects OS X/CDT so the number of programmers actually impacted by the bugs are probably pretty small but it still sucks if you are one of those impacted.

I have tried QtCreator with each new release but it just does not have some of the conveniences that CDT has so I give it up and wait for the next iteration. Eventually it might catch up, but it will be a very long while.
I would venture to say that QtCreator is great for Beginners while CDT is great for those like me who need more control over their projects, assuming you can live with in the confines of Eclipse.

Thanks for listening.
_________________________________________________________
Mike Jackson mike.jackson@...
BlueQuartz Software www.bluequartz.net
Principal Software Engineer Dayton, Ohio

On Dec 11, 2009, at 6:44 PM, Adrian Taylor wrote:

Speaking as a user of Carbide, rather than one of its developers, here are some specifics from me:

Project layout:

-- Symbian has very specific ideas about project filesystem layout, as does Eclipse, and the two are fundamentally incompatible. Specifically:
-- Project files in Symbian-land are stored deep in a subdirectory, whilst Eclipse insists that .project and .cproject are at the outermost point which contains any relevant source code or headers.
-- Several Symbian projects may have the same 'outermost point' and thus conflict in Eclipse-land.
I know that the Carbide team and you yourself Doug have been fighting the Eclipse establishment to relax these rules, to little avail. I know you have hopes for EclipseFS. But meanwhile, this is responsible for a majority of the complexity.
-- The nature of projects themselves are a problem. Why shouldn't you just be able to work directly on Symbian project files? Why the need to create an Eclipse project? The Carbide team has done a great job of hiding it well using a slick import wizard, but it's still wrong.
-- And what's a workspace? Eclipse seems to want to copy, or at least link, my code into its own directory. Why? All my code has a fixed location in Symbian-land.

Builds:

The Carbide team have jumped through some big hoops to get the Symbian build system to play nicely with CDT, and on the whole, it now works well. But there are is still untidiness round the edges:

-- CDT can't cope properly with multi-line error messages emitted by compilers. In C++ code full of templates, that leads to despair and hopelessness.
-- Build configurations are important for Symbian. In CDT they are hidden away. And, although Carbide could expose that feature more obviously in the UI, it still might not be smooth in terms of the settings which applied globally versus as part of a build configuration.
-- There's nothing Carbide or CDT can do about this, but Symbian builds are slow. I think there's a perception they're slower in the IDE (sometimes this is true, but either way, it's the perception that counts). The whole CDT experience seems hugely less slick when builds always take 5-20 minutes. It's not related to complexity, but it is probably one reason why people are put off Carbide.

Indexer:

-- The indexer is *great*. But...
-- Often things go grey when you've made a mistake, but there's no way to find out the error message until you spend 10 minutes building the project with a compiler. It just seems weird to a user to have two different things parsing the code. Why does the IDE know I've done something wrong but it won't tell me what? Seems weird to an end-user.
-- Likewise, you have to fiddle with two sets of macro definitions, include paths etc. The Carbide team has done a good job of hiding this but it's not transparent.
-- Unfortunately the indexer still isn't quite perfect. For example the call hierarchy sometimes just stops. Which is a shame because when it works, it's terrific. But the fact that you can't quite trust its results makes everything seem complex.

Launches:

-- Launch configurations are useful. All the (fairly recent) efforts to hide/automate them are also useful. But they still seem to lurk as something sinister behind the scenes which users eventually will have to understand. The need for them is not obvious in Symbian-land.
-- The debug view is a pain. You seem to have to click in it before you can use debug keys, or at least it's possible for it to lose focus. Debugging should be a global operation, not stuck in some funny little pane. This may be Carbide-specific; I don't know.

Eclipse runes:

-- "Hard to learn" - to be a confident user of Carbide, you have to understand a perspective, a view, an editor, a plugin, a workspace, a project, a build configuration, a launch configuration, and probably a bit more. All of these are Eclipse terminology.
-- You just don't want to have to learn 10 more concepts when you're already struggling with the Symbian weirdness!
-- I imagine most Carbide users need to install Subversive pretty quickly. Then not only do they have to struggle with understanding plugins, update sites, etc. but they also have to contend with the Eclipse IP process, or specifically its implications meaning the key bits of Subversive are squirreled away on someone else's website. Sigh. It's enough to drive me mad and I must have installed it a dozen times. Still, things are improving in that specific area now.
-- Eclipse keystrokes differ from the rest of the world's.
-- Carbide's greatest value is in the indexer features hidden behind obscure keystrokes. Sadly I think most Carbide users don't get far enough to learn F3, ctrl-o, ctrl-alt-h, ctrl-t, etc.

I use Eclipse, Carbide and CDT all the time. For me, the power of the indexer makes it all worthwhile. But I must admit, if I were to try to create a simple IDE for Symbian beginners, I probably wouldn't start with Eclipse!

Adrian

On 11 Dec 2009, at 23:09, Doug Schaefer wrote:

Instead of talking in generalities, I'd prefer to talk with specifics. Saying Carbide is hard to learn, what exactly about it is it hard to learn? Is it things in the CDT or Eclipse platform or things Carbide has added on top? Is it creating projects? Is it setting up builds? Is it launching debug sessions? Is it creating files? Is it too many choices? Would adding wizards in strategic places make the CDT easier to learn?

Most of the complaints on usability with Eclipse I've heard are really complaints from users who find IDEs complex in general. Is Qt Creator really that less complex than the CDT? What about Qt Creator makes it easier to learn. And why don't we invest in the CDT to make it equivalent?

Doug.

On Fri, Dec 11, 2009 at 4:47 PM, Pawel Piech <pawel.piech@...> wrote:
All we've done so far is rather vendor-specific. What we would like to see in CDT is the ability to isolate and turn off various features using capabilities: e.g. build, static analysis, debuggers, etc. To accomplish this we would likely need to look at dependencies between these various CDT components and see if we can isolate them better. However, we haven't invested any time in this yet.
-Pawel

Paul Beusterien wrote:

Hi Pawel,

Thanks for the response. Are there any available artifacts from the stripped-down IDE investigation? Any effort estimates?

Regards,
Paul

On Thu, Dec 10, 2009 at 4:07 PM, Pawel Piech <pawel.piech@...> wrote:
Hi Paul,
Complexity is a common complaint about Eclipse-based tools (not especially limited to C - development tools). I don't know of any efforts to overhaul the UI, but I expect that there would be a lot of interest out there for it. For Wind River's part, we are investigating creating a stripped-down version of the IDE specifically targeted at Debugging use cases, but I know we won't be able to get far without support from the community.

Cheers,
Pawel

Paul Beusterien wrote:

Hi CDT community,

I'm responsible for the tools strategy at the Symbian Foundation. Like the Eclipse Foundation, Symbian depends on the contributions from open source communities to drive its mobile device platform technology forward.

I'm curious if you have any thoughts about one of the challenges we're facing with understanding/determining the direction for Symbian C++ development tools.

There are two open source communities vying for the Symbian C++ developer - Qt Creator and Carbide (based on CDT).

Carbide's investments have been primarily focused on adding features to give more power to device creators. While it has become very feature-full, it has also become very complex and hard to learn, especially for developers that want to just build simple mobile apps.

Qt Creator is a targeted C++ development environment with a big emphasis on usability. For example, it has rigorous hurdles to add a button or menu item. Now, it is rapidly adapting to improve its mobile development capabilities.

Thus, we currently have a fragmented C++ developer story at Symbian.

It is unlikely that Qt Creator will ever support the rich set of features that Carbide currently provides to the power user.

Are there any initiatives will enable CDT based IDEs to lower its learning curve and better support the needs of a simple C++ application developer?

Thanks,
Paul

--
Paul Beusterien
Development Tools Manager
Symbian Foundation
Foster City, California USA
twitter: paulbeusterien

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

From forum: Eclipse CDT - Development

RE: CDT and Qt Creator

2009-12-11T18:25:25Z

> And, yeah, if your IDE doesn't do as much, it will be simpler.

There seems to be a usability tradeoff between IDEs focused on a single language and a limited set of problems domains, vs. a generic, multi-language IDE like Eclipse or Visual Studio. Examples on the Visual Studio side include, on the simplicity end, Visual Basic and Visual C++ from ten years ago vs. the current, all encompassing Visual Studio. A simple example is on the usability of VC++ version 6 (which pretty much only supported C++ development) and its successors which support .NET languages, additional tools etc. When the user asked for help on a topic in VC++ version 6, they got help specific to using it with VC++. With later versions of Visual Studio, you have to wade through many hits to help topics that are not appropriate to your task at hand. There are ways to try to handle this including, filtering, context sensitivity, but Visual Studio has not yet returned to the usability of VC++ version 6 help – at least in the opinion of many users…

Eclipse is another “mega-IDE”, which unfortunately for C++ programmers, has a Java “slant” – the most annoying examples being the project file system restrictions and the lack of build configurations. It exposes new concepts that probably would not be necessary if it were a C++ only IDE. However, I’ll take a highly extensible, multi-platform, mega-IDE over a non-extensible, C++ only IDE. Actually I know nothing about Qt Creator and am just assuming it is non-extensible – e.g. the ability to plug in widely varying new C++ tools without convincing the providers of the IDE to do it themselves.

Leo

From: cdt-dev-bounces@... [mailto:cdt-dev-bounces@...] On Behalf Of Doug Schaefer
Sent: Friday, December 11, 2009 4:22 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] CDT and Qt Creator

Thanks, Mike. The indexer is truly our biggest asset and one of things I'm most proud of for our community. I use the CDT for some small projects at work and for playing with the Android native development kit and I'm always pleasantly surprised when it works as often as it does even for platforms we never thought of when building it (like Android).

BTW, I ran Eclipse on my Dell Mini 10v and it ran fine, other than the tiny screen. And it's just a Atom chip with 1G RAM.

As for OS X, that's really up to the community to support. Right now, I don't think any of the vendors contributing to the CDT support Mac for their products, thus the weaker support. If I had a Mac, I would be inclined to make it work better there, but I don't.

And, yeah, if your IDE doesn't do as much, it will be simpler.

Doug.

On Fri, Dec 11, 2009 at 7:04 PM, Michael Jackson <mike.jackson@...> wrote:

As a User....

I'll vote for the indexer (with a caveat). The indexer is basically the main reason I use Eclipse rather than Visual Studio* or Xcode**, which are my two main platforms. 99% of the time the indexer has the proper variable, template, method, class in its cache to make intelligent selections. QtCreator's indexer is,well, not "there" yet.

The "Code Templates", the ones where I can type "sout" and have that expanded inline to std::cout << "" << std::endl; are absolutely WONDERFUL. QtCreator does not have these.

Caveats: With boost versions greater that 1.36 the indexer has a problem with shared_ptr.hpp. Not really sure what is going on but by code stopping being indexed completely when I switch versions of Boost from 1.36 to anything higher. No idea what the problem is but it generally sucks. I actually keep boost 1.36 around just for the indexer to use so I can get code completion. Visual Assist X for Visual Studio (while costing money) does NOT seem to have the problem with newer versions of boost, but then again, you are paying money for it. Visual Studio without Visual Assist X is just a lost cause for C++ programming and code completion. Xcode for C++ is about the same type of joke.

Eclipse is Big and Bulky and you need a hulking huge machine to run it. (Xeon 5500 with 12 GB of Ram here). I use CMake to generate makefiles, and then manually setup the "Makefile" project in eclipse. I tell git to ignore the .cproject and .project file in the top level of my source tree. _I_ didn't find CDT too bad to start out with but then again I was doing pretty vanilla C++ programming. '

Lately, CDT has taken a turn for the worse on OS X. Two major bugs in debugging are forcing me over to the Visual Studio camp so I can effectively debug my software. This only effects OS X/CDT so the number of programmers actually impacted by the bugs are probably pretty small but it still sucks if you are one of those impacted.

I have tried QtCreator with each new release but it just does not have some of the conveniences that CDT has so I give it up and wait for the next iteration. Eventually it might catch up, but it will be a very long while.
I would venture to say that QtCreator is great for Beginners while CDT is great for those like me who need more control over their projects, assuming you can live with in the confines of Eclipse.

Thanks for listening.
_________________________________________________________
Mike Jackson mike.jackson@...
BlueQuartz Software www.bluequartz.net
Principal Software Engineer Dayton, Ohio

On Dec 11, 2009, at 6:44 PM, Adrian Taylor wrote:

Speaking as a user of Carbide, rather than one of its developers, here are some specifics from me:

Project layout:

-- Symbian has very specific ideas about project filesystem layout, as does Eclipse, and the two are fundamentally incompatible. Specifically:
-- Project files in Symbian-land are stored deep in a subdirectory, whilst Eclipse insists that .project and .cproject are at the outermost point which contains any relevant source code or headers.
-- Several Symbian projects may have the same 'outermost point' and thus conflict in Eclipse-land.
I know that the Carbide team and you yourself Doug have been fighting the Eclipse establishment to relax these rules, to little avail. I know you have hopes for EclipseFS. But meanwhile, this is responsible for a majority of the complexity.
-- The nature of projects themselves are a problem. Why shouldn't you just be able to work directly on Symbian project files? Why the need to create an Eclipse project? The Carbide team has done a great job of hiding it well using a slick import wizard, but it's still wrong.
-- And what's a workspace? Eclipse seems to want to copy, or at least link, my code into its own directory. Why? All my code has a fixed location in Symbian-land.

Builds:

The Carbide team have jumped through some big hoops to get the Symbian build system to play nicely with CDT, and on the whole, it now works well. But there are is still untidiness round the edges:

-- CDT can't cope properly with multi-line error messages emitted by compilers. In C++ code full of templates, that leads to despair and hopelessness.
-- Build configurations are important for Symbian. In CDT they are hidden away. And, although Carbide could expose that feature more obviously in the UI, it still might not be smooth in terms of the settings which applied globally versus as part of a build configuration.
-- There's nothing Carbide or CDT can do about this, but Symbian builds are slow. I think there's a perception they're slower in the IDE (sometimes this is true, but either way, it's the perception that counts). The whole CDT experience seems hugely less slick when builds always take 5-20 minutes. It's not related to complexity, but it is probably one reason why people are put off Carbide.

Indexer:

-- The indexer is *great*. But...
-- Often things go grey when you've made a mistake, but there's no way to find out the error message until you spend 10 minutes building the project with a compiler. It just seems weird to a user to have two different things parsing the code. Why does the IDE know I've done something wrong but it won't tell me what? Seems weird to an end-user.
-- Likewise, you have to fiddle with two sets of macro definitions, include paths etc. The Carbide team has done a good job of hiding this but it's not transparent.
-- Unfortunately the indexer still isn't quite perfect. For example the call hierarchy sometimes just stops. Which is a shame because when it works, it's terrific. But the fact that you can't quite trust its results makes everything seem complex.

Launches:

-- Launch configurations are useful. All the (fairly recent) efforts to hide/automate them are also useful. But they still seem to lurk as something sinister behind the scenes which users eventually will have to understand. The need for them is not obvious in Symbian-land.
-- The debug view is a pain. You seem to have to click in it before you can use debug keys, or at least it's possible for it to lose focus. Debugging should be a global operation, not stuck in some funny little pane. This may be Carbide-specific; I don't know.

Eclipse runes:

-- "Hard to learn" - to be a confident user of Carbide, you have to understand a perspective, a view, an editor, a plugin, a workspace, a project, a build configuration, a launch configuration, and probably a bit more. All of these are Eclipse terminology.
-- You just don't want to have to learn 10 more concepts when you're already struggling with the Symbian weirdness!
-- I imagine most Carbide users need to install Subversive pretty quickly. Then not only do they have to struggle with understanding plugins, update sites, etc. but they also have to contend with the Eclipse IP process, or specifically its implications meaning the key bits of Subversive are squirreled away on someone else's website. Sigh. It's enough to drive me mad and I must have installed it a dozen times. Still, things are improving in that specific area now.
-- Eclipse keystrokes differ from the rest of the world's.
-- Carbide's greatest value is in the indexer features hidden behind obscure keystrokes. Sadly I think most Carbide users don't get far enough to learn F3, ctrl-o, ctrl-alt-h, ctrl-t, etc.

I use Eclipse, Carbide and CDT all the time. For me, the power of the indexer makes it all worthwhile. But I must admit, if I were to try to create a simple IDE for Symbian beginners, I probably wouldn't start with Eclipse!

Adrian

On 11 Dec 2009, at 23:09, Doug Schaefer wrote:

Instead of talking in generalities, I'd prefer to talk with specifics. Saying Carbide is hard to learn, what exactly about it is it hard to learn? Is it things in the CDT or Eclipse platform or things Carbide has added on top? Is it creating projects? Is it setting up builds? Is it launching debug sessions? Is it creating files? Is it too many choices? Would adding wizards in strategic places make the CDT easier to learn?

Most of the complaints on usability with Eclipse I've heard are really complaints from users who find IDEs complex in general. Is Qt Creator really that less complex than the CDT? What about Qt Creator makes it easier to learn. And why don't we invest in the CDT to make it equivalent?

Doug.

On Fri, Dec 11, 2009 at 4:47 PM, Pawel Piech <pawel.piech@...> wrote:
All we've done so far is rather vendor-specific. What we would like to see in CDT is the ability to isolate and turn off various features using capabilities: e.g. build, static analysis, debuggers, etc. To accomplish this we would likely need to look at dependencies between these various CDT components and see if we can isolate them better. However, we haven't invested any time in this yet.
-Pawel

Paul Beusterien wrote:

Hi Pawel,

Thanks for the response. Are there any available artifacts from the stripped-down IDE investigation? Any effort estimates?

Regards,
Paul

On Thu, Dec 10, 2009 at 4:07 PM, Pawel Piech <pawel.piech@...> wrote:
Hi Paul,
Complexity is a common complaint about Eclipse-based tools (not especially limited to C - development tools). I don't know of any efforts to overhaul the UI, but I expect that there would be a lot of interest out there for it. For Wind River's part, we are investigating creating a stripped-down version of the IDE specifically targeted at Debugging use cases, but I know we won't be able to get far without support from the community.

Cheers,
Pawel

Paul Beusterien wrote:

Hi CDT community,

I'm responsible for the tools strategy at the Symbian Foundation. Like the Eclipse Foundation, Symbian depends on the contributions from open source communities to drive its mobile device platform technology forward.

I'm curious if you have any thoughts about one of the challenges we're facing with understanding/determining the direction for Symbian C++ development tools.

There are two open source communities vying for the Symbian C++ developer - Qt Creator and Carbide (based on CDT).

Carbide's investments have been primarily focused on adding features to give more power to device creators. While it has become very feature-full, it has also become very complex and hard to learn, especially for developers that want to just build simple mobile apps.

Qt Creator is a targeted C++ development environment with a big emphasis on usability. For example, it has rigorous hurdles to add a button or menu item. Now, it is rapidly adapting to improve its mobile development capabilities.

Thus, we currently have a fragmented C++ developer story at Symbian.

It is unlikely that Qt Creator will ever support the rich set of features that Carbide currently provides to the power user.

Are there any initiatives will enable CDT based IDEs to lower its learning curve and better support the needs of a simple C++ application developer?

Thanks,
Paul

--
Paul Beusterien
Development Tools Manager
Symbian Foundation
Foster City, California USA
twitter: paulbeusterien

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

From forum: Eclipse CDT - Development

Re: CDT and Qt Creator

2009-12-11T16:23:45Z

Doug.

On Fri, Dec 11, 2009 at 7:14 PM, John Cortell <rat042@...> wrote:

Won't the Project Layout issues be resolved by the E4 Flexible Projects work Serge Beauchamp had done?

John
At 06:11 PM 12/11/2009, Doug Schaefer wrote:
This is great data, and we could do something about most of this, if we work together as a community to address them. Up until now, we haven't really been involved in solving these issues for Carbide.

Next question. How does Qt Creator do these things better? Since that's the real topic of this thread.

Doug

On Fri, Dec 11, 2009 at 6:44 PM, Adrian Taylor <adrian@...> wrote:
Speaking as a user of Carbide, rather than one of its developers, here are some specifics from me:

Project layout:

-- Symbian has very specific ideas about project filesystem layout, as does Eclipse, and the two are fundamentally incompatible. Specifically:

-- Project files in Symbian-land are stored deep in a subdirectory, whilst Eclipse insists that .project and .cproject are at the outermost point which contains any relevant source code or headers.

-- Several Symbian projects may have the same 'outermost point' and thus conflict in Eclipse-land.

I know that the Carbide team and you yourself Doug have been fighting the Eclipse establishment to relax these rules, to little avail. I know you have hopes for EclipseFS. But meanwhile, this is responsible for a majority of the complexity.

-- The nature of projects themselves are a problem. Why shouldn't you just be able to work directly on Symbian project files? Why the need to create an Eclipse project? The Carbide team has done a great job of hiding it well using a slick import wizard, but it's still wrong.

-- And what's a workspace? Eclipse seems to want to copy, or at least link, my code into its own directory. Why? All my code has a fixed location in Symbian-land.

Builds:

The Carbide team have jumped through some big hoops to get the Symbian build system to play nicely with CDT, and on the whole, it now works well. But there are is still untidiness round the edges:

-- CDT can't cope properly with multi-line error messages emitted by compilers. In C++ code full of templates, that leads to despair and hopelessness.

-- Build configurations are important for Symbian. In CDT they are hidden away. And, although Carbide could expose that feature more obviously in the UI, it still might not be smooth in terms of the settings which applied globally versus as part of a build configuration.

-- There's nothing Carbide or CDT can do about this, but Symbian builds are slow. I think there's a perception they're slower in the IDE (sometimes this is true, but either way, it's the perception that counts). The whole CDT experience seems hugely less slick when builds always take 5-20 minutes. It's not related to complexity, but it is probably one reason why people are put off Carbide.

Indexer:

-- The indexer is *great*. But...

-- Often things go grey when you've made a mistake, but there's no way to find out the error message until you spend 10 minutes building the project with a compiler. It just seems weird to a user to have two different things parsing the code. Why does the IDE know I've done something wrong but it won't tell me what? Seems weird to an end-user.

-- Likewise, you have to fiddle with two sets of macro definitions, include paths etc. The Carbide team has done a good job of hiding this but it's not transparent.

-- Unfortunately the indexer still isn't quite perfect. For example the call hierarchy sometimes just stops. Which is a shame because when it works, it's terrific. But the fact that you can't quite trust its results makes everything seem complex.

Launches:

-- Launch configurations are useful. All the (fairly recent) efforts to hide/automate them are also useful. But they still seem to lurk as something sinister behind the scenes which users eventually will have to understand. The need for them is not obvious in Symbian-land.

-- The debug view is a pain. You seem to have to click in it before you can use debug keys, or at least it's possible for it to lose focus. Debugging should be a global operation, not stuck in some funny little pane. This may be Carbide-specific; I don't know.

Eclipse runes:

-- "Hard to learn" - to be a confident user of Carbide, you have to understand a perspective, a view, an editor, a plugin, a workspace, a project, a build configuration, a launch configuration, and probably a bit more. All of these are Eclipse terminology.

-- You just don't want to have to learn 10 more concepts when you're already struggling with the Symbian weirdness!

-- I imagine most Carbide users need to install Subversive pretty quickly. Then not only do they have to struggle with understanding plugins, update sites, etc. but they also have to contend with the Eclipse IP process, or specifically its implications meaning the key bits of Subversive are squirreled away on someone else's website. Sigh. It's enough to drive me mad and I must have installed it a dozen times. Still, things are improving in that specific area now.

-- Eclipse keystrokes differ from the rest of the world's.

-- Carbide's greatest value is in the indexer features hidden behind obscure keystrokes. Sadly I think most Carbide users don't get far enough to learn F3, ctrl-o, ctrl-alt-h, ctrl-t, etc.

I use Eclipse, Carbide and CDT all the time. For me, the power of the indexer makes it all worthwhile. But I must admit, if I were to try to create a simple IDE for Symbian beginners, I probably wouldn't start with Eclipse!

Adrian
On 11 Dec 2009, at 23:09, Doug Schaefer wrote:
Instead of talking in generalities, I'd prefer to talk with specifics. Saying Carbide is hard to learn, what exactly about it is it hard to learn? Is it things in the CDT or Eclipse platform or things Carbide has added on top? Is it creating projects? Is it setting up builds? Is it launching debug sessions? Is it creating files? Is it too many choices? Would adding wizards in strategic places make the CDT easier to learn?

Most of the complaints on usability with Eclipse I've heard are really complaints from users who find IDEs complex in general. Is Qt Creator really that less complex than the CDT? What about Qt Creator makes it easier to learn. And why don't we invest in the CDT to make it equivalent?

Doug.
On Fri, Dec 11, 2009 at 4:47 PM, Pawel Piech <pawel.piech@...> wrote:
All we've done so far is rather vendor-specific. What we would like to see in CDT is the ability to isolate and turn off various features using capabilities: e.g. build, static analysis, debuggers, etc. To accomplish this we would likely need to look at dependencies between these various CDT components and see if we can isolate them better. However, we haven't invested any time in this yet.

-Pawel
Paul Beusterien wrote:
Hi Pawel,

Thanks for the response. Are there any available artifacts from the stripped-down IDE investigation? Any effort estimates?

Regards,

Paul
On Thu, Dec 10, 2009 at 4:07 PM, Pawel Piech <pawel.piech@...> wrote:

Hi Paul,

Complexity is a common complaint about Eclipse-based tools (not especially limited to C - development tools). I don't know of any efforts to overhaul the UI, but I expect that there would be a lot of interest out there for it. For Wind River's part, we are investigating creating a stripped-down version of the IDE specifically targeted at Debugging use cases, but I know we won't be able to get far without support from the community.

Cheers,

Pawel

Paul Beusterien wrote:

Hi CDT community,

I'm responsible for the tools strategy at the Symbian Foundation. Like the Eclipse Foundation, Symbian depends on the contributions from open source communities to drive its mobile device platform technology forward.

I'm curious if you have any thoughts about one of the challenges we're facing with understanding/determining the direction for Symbian C++ development tools.

There are two open source communities vying for the Symbian C++ developer - Qt Creator and Carbide (based on CDT).

Carbide's investments have been primarily focused on adding features to give more power to device creators. While it has become very feature-full, it has also become very complex and hard to learn, especially for developers that want to just build simple mobile apps.

Qt Creator is a targeted C++ development environment with a big emphasis on usability. For example, it has rigorous hurdles to add a button or menu item. Now, it is rapidly adapting to improve its mobile development capabilities.

Thus, we currently have a fragmented C++ developer story at Symbian.

It is unlikely that Qt Creator will ever support the rich set of features that Carbide currently provides to the power user.

Are there any initiatives will enable CDT based IDEs to lower its learning curve and better support the needs of a simple C++ application developer?

Thanks,

Paul

--

Paul Beusterien

Development Tools Manager

Symbian Foundation

Foster City, California USA

twitter: paulbeusterien
_______________________________________________

cdt-dev mailing list

cdt-dev@...



https://dev.eclipse.org/mailman/listinfo/cdt-dev

  
_______________________________________________

cdt-dev mailing list

cdt-dev@...

https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________

cdt-dev mailing list

cdt-dev@...

https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________

cdt-dev mailing list

cdt-dev@...

https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

From forum: Eclipse CDT - Development

Re: CDT and Qt Creator

2009-12-11T16:21:30Z

BTW, I ran Eclipse on my Dell Mini 10v and it ran fine, other than the tiny screen. And it's just a Atom chip with 1G RAM.

And, yeah, if your IDE doesn't do as much, it will be simpler.

Doug.

On Fri, Dec 11, 2009 at 7:04 PM, Michael Jackson <mike.jackson@...> wrote:

As a User....

I'll vote for the indexer (with a caveat). The indexer is basically the main reason I use Eclipse rather than Visual Studio* or Xcode**, which are my two main platforms. 99% of the time the indexer has the proper variable, template, method, class in its cache to make intelligent selections. QtCreator's indexer is,well, not "there" yet.

The "Code Templates", the ones where I can type "sout" and have that expanded inline to std::cout << "" << std::endl; are absolutely WONDERFUL. QtCreator does not have these.

Caveats: With boost versions greater that 1.36 the indexer has a problem with shared_ptr.hpp. Not really sure what is going on but by code stopping being indexed completely when I switch versions of Boost from 1.36 to anything higher. No idea what the problem is but it generally sucks. I actually keep boost 1.36 around just for the indexer to use so I can get code completion. Visual Assist X for Visual Studio (while costing money) does NOT seem to have the problem with newer versions of boost, but then again, you are paying money for it. Visual Studio without Visual Assist X is just a lost cause for C++ programming and code completion. Xcode for C++ is about the same type of joke.

Eclipse is Big and Bulky and you need a hulking huge machine to run it. (Xeon 5500 with 12 GB of Ram here). I use CMake to generate makefiles, and then manually setup the "Makefile" project in eclipse. I tell git to ignore the .cproject and .project file in the top level of my source tree. _I_ didn't find CDT too bad to start out with but then again I was doing pretty vanilla C++ programming. '

Lately, CDT has taken a turn for the worse on OS X. Two major bugs in debugging are forcing me over to the Visual Studio camp so I can effectively debug my software. This only effects OS X/CDT so the number of programmers actually impacted by the bugs are probably pretty small but it still sucks if you are one of those impacted.

I have tried QtCreator with each new release but it just does not have some of the conveniences that CDT has so I give it up and wait for the next iteration. Eventually it might catch up, but it will be a very long while.
I would venture to say that QtCreator is great for Beginners while CDT is great for those like me who need more control over their projects, assuming you can live with in the confines of Eclipse.

Thanks for listening.
_________________________________________________________
Mike Jackson mike.jackson@...
BlueQuartz Software www.bluequartz.net
Principal Software Engineer Dayton, Ohio

On Dec 11, 2009, at 6:44 PM, Adrian Taylor wrote:

Speaking as a user of Carbide, rather than one of its developers, here are some specifics from me:

Project layout:

-- Symbian has very specific ideas about project filesystem layout, as does Eclipse, and the two are fundamentally incompatible. Specifically:
-- Project files in Symbian-land are stored deep in a subdirectory, whilst Eclipse insists that .project and .cproject are at the outermost point which contains any relevant source code or headers.
-- Several Symbian projects may have the same 'outermost point' and thus conflict in Eclipse-land.
I know that the Carbide team and you yourself Doug have been fighting the Eclipse establishment to relax these rules, to little avail. I know you have hopes for EclipseFS. But meanwhile, this is responsible for a majority of the complexity.
-- The nature of projects themselves are a problem. Why shouldn't you just be able to work directly on Symbian project files? Why the need to create an Eclipse project? The Carbide team has done a great job of hiding it well using a slick import wizard, but it's still wrong.
-- And what's a workspace? Eclipse seems to want to copy, or at least link, my code into its own directory. Why? All my code has a fixed location in Symbian-land.

Builds:

The Carbide team have jumped through some big hoops to get the Symbian build system to play nicely with CDT, and on the whole, it now works well. But there are is still untidiness round the edges:

-- CDT can't cope properly with multi-line error messages emitted by compilers. In C++ code full of templates, that leads to despair and hopelessness.
-- Build configurations are important for Symbian. In CDT they are hidden away. And, although Carbide could expose that feature more obviously in the UI, it still might not be smooth in terms of the settings which applied globally versus as part of a build configuration.
-- There's nothing Carbide or CDT can do about this, but Symbian builds are slow. I think there's a perception they're slower in the IDE (sometimes this is true, but either way, it's the perception that counts). The whole CDT experience seems hugely less slick when builds always take 5-20 minutes. It's not related to complexity, but it is probably one reason why people are put off Carbide.

Indexer:

-- The indexer is *great*. But...
-- Often things go grey when you've made a mistake, but there's no way to find out the error message until you spend 10 minutes building the project with a compiler. It just seems weird to a user to have two different things parsing the code. Why does the IDE know I've done something wrong but it won't tell me what? Seems weird to an end-user.
-- Likewise, you have to fiddle with two sets of macro definitions, include paths etc. The Carbide team has done a good job of hiding this but it's not transparent.
-- Unfortunately the indexer still isn't quite perfect. For example the call hierarchy sometimes just stops. Which is a shame because when it works, it's terrific. But the fact that you can't quite trust its results makes everything seem complex.

Launches:

-- Launch configurations are useful. All the (fairly recent) efforts to hide/automate them are also useful. But they still seem to lurk as something sinister behind the scenes which users eventually will have to understand. The need for them is not obvious in Symbian-land.
-- The debug view is a pain. You seem to have to click in it before you can use debug keys, or at least it's possible for it to lose focus. Debugging should be a global operation, not stuck in some funny little pane. This may be Carbide-specific; I don't know.

Eclipse runes:

-- "Hard to learn" - to be a confident user of Carbide, you have to understand a perspective, a view, an editor, a plugin, a workspace, a project, a build configuration, a launch configuration, and probably a bit more. All of these are Eclipse terminology.
-- You just don't want to have to learn 10 more concepts when you're already struggling with the Symbian weirdness!
-- I imagine most Carbide users need to install Subversive pretty quickly. Then not only do they have to struggle with understanding plugins, update sites, etc. but they also have to contend with the Eclipse IP process, or specifically its implications meaning the key bits of Subversive are squirreled away on someone else's website. Sigh. It's enough to drive me mad and I must have installed it a dozen times. Still, things are improving in that specific area now.
-- Eclipse keystrokes differ from the rest of the world's.
-- Carbide's greatest value is in the indexer features hidden behind obscure keystrokes. Sadly I think most Carbide users don't get far enough to learn F3, ctrl-o, ctrl-alt-h, ctrl-t, etc.

I use Eclipse, Carbide and CDT all the time. For me, the power of the indexer makes it all worthwhile. But I must admit, if I were to try to create a simple IDE for Symbian beginners, I probably wouldn't start with Eclipse!

Adrian

On 11 Dec 2009, at 23:09, Doug Schaefer wrote:

Instead of talking in generalities, I'd prefer to talk with specifics. Saying Carbide is hard to learn, what exactly about it is it hard to learn? Is it things in the CDT or Eclipse platform or things Carbide has added on top? Is it creating projects? Is it setting up builds? Is it launching debug sessions? Is it creating files? Is it too many choices? Would adding wizards in strategic places make the CDT easier to learn?

Most of the complaints on usability with Eclipse I've heard are really complaints from users who find IDEs complex in general. Is Qt Creator really that less complex than the CDT? What about Qt Creator makes it easier to learn. And why don't we invest in the CDT to make it equivalent?

Doug.

On Fri, Dec 11, 2009 at 4:47 PM, Pawel Piech <pawel.piech@...> wrote:
All we've done so far is rather vendor-specific. What we would like to see in CDT is the ability to isolate and turn off various features using capabilities: e.g. build, static analysis, debuggers, etc. To accomplish this we would likely need to look at dependencies between these various CDT components and see if we can isolate them better. However, we haven't invested any time in this yet.
-Pawel

Paul Beusterien wrote:

Hi Pawel,

Thanks for the response. Are there any available artifacts from the stripped-down IDE investigation? Any effort estimates?

Regards,
Paul

On Thu, Dec 10, 2009 at 4:07 PM, Pawel Piech <pawel.piech@...> wrote:
Hi Paul,
Complexity is a common complaint about Eclipse-based tools (not especially limited to C - development tools). I don't know of any efforts to overhaul the UI, but I expect that there would be a lot of interest out there for it. For Wind River's part, we are investigating creating a stripped-down version of the IDE specifically targeted at Debugging use cases, but I know we won't be able to get far without support from the community.

Cheers,
Pawel

Paul Beusterien wrote:

Hi CDT community,

I'm responsible for the tools strategy at the Symbian Foundation. Like the Eclipse Foundation, Symbian depends on the contributions from open source communities to drive its mobile device platform technology forward.

I'm curious if you have any thoughts about one of the challenges we're facing with understanding/determining the direction for Symbian C++ development tools.

There are two open source communities vying for the Symbian C++ developer - Qt Creator and Carbide (based on CDT).

Carbide's investments have been primarily focused on adding features to give more power to device creators. While it has become very feature-full, it has also become very complex and hard to learn, especially for developers that want to just build simple mobile apps.

Qt Creator is a targeted C++ development environment with a big emphasis on usability. For example, it has rigorous hurdles to add a button or menu item. Now, it is rapidly adapting to improve its mobile development capabilities.

Thus, we currently have a fragmented C++ developer story at Symbian.

It is unlikely that Qt Creator will ever support the rich set of features that Carbide currently provides to the power user.

Are there any initiatives will enable CDT based IDEs to lower its learning curve and better support the needs of a simple C++ application developer?

Thanks,
Paul

--
Paul Beusterien
Development Tools Manager
Symbian Foundation
Foster City, California USA
twitter: paulbeusterien

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

From forum: Eclipse CDT - Development

Re: CDT and Qt Creator

2009-12-11T16:14:18Z

Won't the Project Layout issues be resolved by the E4 Flexible Projects work Serge Beauchamp had done?

John

At 06:11 PM 12/11/2009, Doug Schaefer wrote:

This is great data, and we could do something about most of this, if we work together as a community to address them. Up until now, we haven't really been involved in solving these issues for Carbide.

Next question. How does Qt Creator do these things better? Since that's the real topic of this thread.

Doug

On Fri, Dec 11, 2009 at 6:44 PM, Adrian Taylor <adrian@...> wrote:
Speaking as a user of Carbide, rather than one of its developers, here are some specifics from me:

Project layout:

-- Symbian has very specific ideas about project filesystem layout, as does Eclipse, and the two are fundamentally incompatible. Specifically:

-- Project files in Symbian-land are stored deep in a subdirectory, whilst Eclipse insists that .project and .cproject are at the outermost point which contains any relevant source code or headers.

-- Several Symbian projects may have the same 'outermost point' and thus conflict in Eclipse-land.

I know that the Carbide team and you yourself Doug have been fighting the Eclipse establishment to relax these rules, to little avail. I know you have hopes for EclipseFS. But meanwhile, this is responsible for a majority of the complexity.

-- The nature of projects themselves are a problem. Why shouldn't you just be able to work directly on Symbian project files? Why the need to create an Eclipse project? The Carbide team has done a great job of hiding it well using a slick import wizard, but it's still wrong.

-- And what's a workspace? Eclipse seems to want to copy, or at least link, my code into its own directory. Why? All my code has a fixed location in Symbian-land.

Builds:

The Carbide team have jumped through some big hoops to get the Symbian build system to play nicely with CDT, and on the whole, it now works well. But there are is still untidiness round the edges:

-- CDT can't cope properly with multi-line error messages emitted by compilers. In C++ code full of templates, that leads to despair and hopelessness.

-- Build configurations are important for Symbian. In CDT they are hidden away. And, although Carbide could expose that feature more obviously in the UI, it still might not be smooth in terms of the settings which applied globally versus as part of a build configuration.

-- There's nothing Carbide or CDT can do about this, but Symbian builds are slow. I think there's a perception they're slower in the IDE (sometimes this is true, but either way, it's the perception that counts). The whole CDT experience seems hugely less slick when builds always take 5-20 minutes. It's not related to complexity, but it is probably one reason why people are put off Carbide.

Indexer:

-- The indexer is *great*. But...

-- Often things go grey when you've made a mistake, but there's no way to find out the error message until you spend 10 minutes building the project with a compiler. It just seems weird to a user to have two different things parsing the code. Why does the IDE know I've done something wrong but it won't tell me what? Seems weird to an end-user.

-- Likewise, you have to fiddle with two sets of macro definitions, include paths etc. The Carbide team has done a good job of hiding this but it's not transparent.

-- Unfortunately the indexer still isn't quite perfect. For example the call hierarchy sometimes just stops. Which is a shame because when it works, it's terrific. But the fact that you can't quite trust its results makes everything seem complex.

Launches:

-- Launch configurations are useful. All the (fairly recent) efforts to hide/automate them are also useful. But they still seem to lurk as something sinister behind the scenes which users eventually will have to understand. The need for them is not obvious in Symbian-land.

-- The debug view is a pain. You seem to have to click in it before you can use debug keys, or at least it's possible for it to lose focus. Debugging should be a global operation, not stuck in some funny little pane. This may be Carbide-specific; I don't know.

Eclipse runes:

-- "Hard to learn" - to be a confident user of Carbide, you have to understand a perspective, a view, an editor, a plugin, a workspace, a project, a build configuration, a launch configuration, and probably a bit more. All of these are Eclipse terminology.

-- You just don't want to have to learn 10 more concepts when you're already struggling with the Symbian weirdness!

-- I imagine most Carbide users need to install Subversive pretty quickly. Then not only do they have to struggle with understanding plugins, update sites, etc. but they also have to contend with the Eclipse IP process, or specifically its implications meaning the key bits of Subversive are squirreled away on someone else's website. Sigh. It's enough to drive me mad and I must have installed it a dozen times. Still, things are improving in that specific area now.

-- Eclipse keystrokes differ from the rest of the world's.

-- Carbide's greatest value is in the indexer features hidden behind obscure keystrokes. Sadly I think most Carbide users don't get far enough to learn F3, ctrl-o, ctrl-alt-h, ctrl-t, etc.

I use Eclipse, Carbide and CDT all the time. For me, the power of the indexer makes it all worthwhile. But I must admit, if I were to try to create a simple IDE for Symbian beginners, I probably wouldn't start with Eclipse!

Adrian
On 11 Dec 2009, at 23:09, Doug Schaefer wrote:
Instead of talking in generalities, I'd prefer to talk with specifics. Saying Carbide is hard to learn, what exactly about it is it hard to learn? Is it things in the CDT or Eclipse platform or things Carbide has added on top? Is it creating projects? Is it setting up builds? Is it launching debug sessions? Is it creating files? Is it too many choices? Would adding wizards in strategic places make the CDT easier to learn?

Most of the complaints on usability with Eclipse I've heard are really complaints from users who find IDEs complex in general. Is Qt Creator really that less complex than the CDT? What about Qt Creator makes it easier to learn. And why don't we invest in the CDT to make it equivalent?

Doug.
On Fri, Dec 11, 2009 at 4:47 PM, Pawel Piech <pawel.piech@...> wrote:
All we've done so far is rather vendor-specific. What we would like to see in CDT is the ability to isolate and turn off various features using capabilities: e.g. build, static analysis, debuggers, etc. To accomplish this we would likely need to look at dependencies between these various CDT components and see if we can isolate them better. However, we haven't invested any time in this yet.

-Pawel
Paul Beusterien wrote:
Hi Pawel,

Thanks for the response. Are there any available artifacts from the stripped-down IDE investigation? Any effort estimates?

Regards,

Paul
On Thu, Dec 10, 2009 at 4:07 PM, Pawel Piech <pawel.piech@...> wrote:

Hi Paul,

Complexity is a common complaint about Eclipse-based tools (not especially limited to C - development tools). I don't know of any efforts to overhaul the UI, but I expect that there would be a lot of interest out there for it. For Wind River's part, we are investigating creating a stripped-down version of the IDE specifically targeted at Debugging use cases, but I know we won't be able to get far without support from the community.

Cheers,

Pawel

Paul Beusterien wrote:

Hi CDT community,

I'm responsible for the tools strategy at the Symbian Foundation. Like the Eclipse Foundation, Symbian depends on the contributions from open source communities to drive its mobile device platform technology forward.

I'm curious if you have any thoughts about one of the challenges we're facing with understanding/determining the direction for Symbian C++ development tools.

There are two open source communities vying for the Symbian C++ developer - Qt Creator and Carbide (based on CDT).

Carbide's investments have been primarily focused on adding features to give more power to device creators. While it has become very feature-full, it has also become very complex and hard to learn, especially for developers that want to just build simple mobile apps.

Qt Creator is a targeted C++ development environment with a big emphasis on usability. For example, it has rigorous hurdles to add a button or menu item. Now, it is rapidly adapting to improve its mobile development capabilities.

Thus, we currently have a fragmented C++ developer story at Symbian.

It is unlikely that Qt Creator will ever support the rich set of features that Carbide currently provides to the power user.

Are there any initiatives will enable CDT based IDEs to lower its learning curve and better support the needs of a simple C++ application developer?

Thanks,

Paul

--

Paul Beusterien

Development Tools Manager

Symbian Foundation

Foster City, California USA

twitter: paulbeusterien
_______________________________________________

cdt-dev mailing list

cdt-dev@...



https://dev.eclipse.org/mailman/listinfo/cdt-dev

  
_______________________________________________

cdt-dev mailing list

cdt-dev@...

https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________

cdt-dev mailing list

cdt-dev@...

https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________

cdt-dev mailing list

cdt-dev@...

https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

From forum: Eclipse CDT - Development

Re: CDT and Qt Creator

2009-12-11T16:11:33Z

Next question. How does Qt Creator do these things better? Since that's the real topic of this thread.

Doug

On Fri, Dec 11, 2009 at 6:44 PM, Adrian Taylor <adrian@...> wrote:

Speaking as a user of Carbide, rather than one of its developers, here are some specifics from me:

Project layout:

-- Symbian has very specific ideas about project filesystem layout, as does Eclipse, and the two are fundamentally incompatible. Specifically:
-- Project files in Symbian-land are stored deep in a subdirectory, whilst Eclipse insists that .project and .cproject are at the outermost point which contains any relevant source code or headers.

-- Several Symbian projects may have the same 'outermost point' and thus conflict in Eclipse-land.
I know that the Carbide team and you yourself Doug have been fighting the Eclipse establishment to relax these rules, to little avail. I know you have hopes for EclipseFS. But meanwhile, this is responsible for a majority of the complexity.

-- The nature of projects themselves are a problem. Why shouldn't you just be able to work directly on Symbian project files? Why the need to create an Eclipse project? The Carbide team has done a great job of hiding it well using a slick import wizard, but it's still wrong.

-- And what's a workspace? Eclipse seems to want to copy, or at least link, my code into its own directory. Why? All my code has a fixed location in Symbian-land.

Builds:

The Carbide team have jumped through some big hoops to get the Symbian build system to play nicely with CDT, and on the whole, it now works well. But there are is still untidiness round the edges:

-- CDT can't cope properly with multi-line error messages emitted by compilers. In C++ code full of templates, that leads to despair and hopelessness.
-- Build configurations are important for Symbian. In CDT they are hidden away. And, although Carbide could expose that feature more obviously in the UI, it still might not be smooth in terms of the settings which applied globally versus as part of a build configuration.

-- There's nothing Carbide or CDT can do about this, but Symbian builds are slow. I think there's a perception they're slower in the IDE (sometimes this is true, but either way, it's the perception that counts). The whole CDT experience seems hugely less slick when builds always take 5-20 minutes. It's not related to complexity, but it is probably one reason why people are put off Carbide.

Indexer:

-- The indexer is *great*. But...
-- Often things go grey when you've made a mistake, but there's no way to find out the error message until you spend 10 minutes building the project with a compiler. It just seems weird to a user to have two different things parsing the code. Why does the IDE know I've done something wrong but it won't tell me what? Seems weird to an end-user.

-- Likewise, you have to fiddle with two sets of macro definitions, include paths etc. The Carbide team has done a good job of hiding this but it's not transparent.
-- Unfortunately the indexer still isn't quite perfect. For example the call hierarchy sometimes just stops. Which is a shame because when it works, it's terrific. But the fact that you can't quite trust its results makes everything seem complex.

Launches:

-- Launch configurations are useful. All the (fairly recent) efforts to hide/automate them are also useful. But they still seem to lurk as something sinister behind the scenes which users eventually will have to understand. The need for them is not obvious in Symbian-land.

-- The debug view is a pain. You seem to have to click in it before you can use debug keys, or at least it's possible for it to lose focus. Debugging should be a global operation, not stuck in some funny little pane. This may be Carbide-specific; I don't know.

Eclipse runes:

-- "Hard to learn" - to be a confident user of Carbide, you have to understand a perspective, a view, an editor, a plugin, a workspace, a project, a build configuration, a launch configuration, and probably a bit more. All of these are Eclipse terminology.

-- You just don't want to have to learn 10 more concepts when you're already struggling with the Symbian weirdness!
-- I imagine most Carbide users need to install Subversive pretty quickly. Then not only do they have to struggle with understanding plugins, update sites, etc. but they also have to contend with the Eclipse IP process, or specifically its implications meaning the key bits of Subversive are squirreled away on someone else's website. Sigh. It's enough to drive me mad and I must have installed it a dozen times. Still, things are improving in that specific area now.

-- Eclipse keystrokes differ from the rest of the world's.
-- Carbide's greatest value is in the indexer features hidden behind obscure keystrokes. Sadly I think most Carbide users don't get far enough to learn F3, ctrl-o, ctrl-alt-h, ctrl-t, etc.

I use Eclipse, Carbide and CDT all the time. For me, the power of the indexer makes it all worthwhile. But I must admit, if I were to try to create a simple IDE for Symbian beginners, I probably wouldn't start with Eclipse!

Adrian
On 11 Dec 2009, at 23:09, Doug Schaefer wrote:
Instead of talking in generalities, I'd prefer to talk with specifics. Saying Carbide is hard to learn, what exactly about it is it hard to learn? Is it things in the CDT or Eclipse platform or things Carbide has added on top? Is it creating projects? Is it setting up builds? Is it launching debug sessions? Is it creating files? Is it too many choices? Would adding wizards in strategic places make the CDT easier to learn?

Most of the complaints on usability with Eclipse I've heard are really complaints from users who find IDEs complex in general. Is Qt Creator really that less complex than the CDT? What about Qt Creator makes it easier to learn. And why don't we invest in the CDT to make it equivalent?

Doug.
On Fri, Dec 11, 2009 at 4:47 PM, Pawel Piech <pawel.piech@...> wrote:
All we've done so far is rather vendor-specific. What we would like to see in CDT is the ability to isolate and turn off various features using capabilities: e.g. build, static analysis, debuggers, etc. To accomplish this we would likely need to look at dependencies between these various CDT components and see if we can isolate them better. However, we haven't invested any time in this yet.
-Pawel

Paul Beusterien wrote:
Hi Pawel,

Thanks for the response. Are there any available artifacts from the stripped-down IDE investigation? Any effort estimates?

Regards,
Paul
On Thu, Dec 10, 2009 at 4:07 PM, Pawel Piech <pawel.piech@...> wrote:
Hi Paul,
Complexity is a common complaint about Eclipse-based tools (not especially limited to C - development tools). I don't know of any efforts to overhaul the UI, but I expect that there would be a lot of interest out there for it. For Wind River's part, we are investigating creating a stripped-down version of the IDE specifically targeted at Debugging use cases, but I know we won't be able to get far without support from the community.

Cheers,
Pawel

Paul Beusterien wrote:
Hi CDT community,

I'm responsible for the tools strategy at the Symbian Foundation. Like the Eclipse Foundation, Symbian depends on the contributions from open source communities to drive its mobile device platform technology forward.

I'm curious if you have any thoughts about one of the challenges we're facing with understanding/determining the direction for Symbian C++ development tools.

There are two open source communities vying for the Symbian C++ developer - Qt Creator and Carbide (based on CDT).

Carbide's investments have been primarily focused on adding features to give more power to device creators. While it has become very feature-full, it has also become very complex and hard to learn, especially for developers that want to just build simple mobile apps.

Qt Creator is a targeted C++ development environment with a big emphasis on usability. For example, it has rigorous hurdles to add a button or menu item. Now, it is rapidly adapting to improve its mobile development capabilities.

Thus, we currently have a fragmented C++ developer story at Symbian.

It is unlikely that Qt Creator will ever support the rich set of features that Carbide currently provides to the power user.

Are there any initiatives will enable CDT based IDEs to lower its learning curve and better support the needs of a simple C++ application developer?

Thanks,
Paul

--
Paul Beusterien
Development Tools Manager
Symbian Foundation
Foster City, California USA
twitter: paulbeusterien
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev
  
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

From forum: Eclipse CDT - Development

Re: CDT and Qt Creator

2009-12-11T16:04:27Z

As a User....

I'll vote for the indexer (with a caveat). The indexer is basically
the main reason I use Eclipse rather than Visual Studio* or Xcode**,
which are my two main platforms. 99% of the time the indexer has the
proper variable, template, method, class in its cache to make
intelligent selections. QtCreator's indexer is,well, not "there" yet.

The "Code Templates", the ones where I can type "sout" and have that
expanded inline to std::cout << "" << std::endl; are absolutely
WONDERFUL. QtCreator does not have these.

Caveats: With boost versions greater that 1.36 the indexer has a
problem with shared_ptr.hpp. Not really sure what is going on but by
code stopping being indexed completely when I switch versions of Boost
from 1.36 to anything higher. No idea what the problem is but it
generally sucks. I actually keep boost 1.36 around just for the
indexer to use so I can get code completion. Visual Assist X for
Visual Studio (while costing money) does NOT seem to have the problem
with newer versions of boost, but then again, you are paying money for
it. Visual Studio without Visual Assist X is just a lost cause for C++
programming and code completion. Xcode for C++ is about the same type
of joke.

Eclipse is Big and Bulky and you need a hulking huge machine to
run it. (Xeon 5500 with 12 GB of Ram here). I use CMake to generate
makefiles, and then manually setup the "Makefile" project in eclipse.
I tell git to ignore the .cproject and .project file in the top level
of my source tree. _I_ didn't find CDT too bad to start out with but
then again I was doing pretty vanilla C++ programming. '

Lately, CDT has taken a turn for the worse on OS X. Two major bugs
in debugging are forcing me over to the Visual Studio camp so I can
effectively debug my software. This only effects OS X/CDT so the
number of programmers actually impacted by the bugs are probably
pretty small but it still sucks if you are one of those impacted.

I have tried QtCreator with each new release but it just does not
have some of the conveniences that CDT has so I give it up and wait
for the next iteration. Eventually it might catch up, but it will be a
very long while.
I would venture to say that QtCreator is great for Beginners while
CDT is great for those like me who need more control over their
projects, assuming you can live with in the confines of Eclipse.

Thanks for listening.
_________________________________________________________
Mike Jackson mike.jackson@...
BlueQuartz Software www.bluequartz.net
Principal Software Engineer Dayton, Ohio

On Dec 11, 2009, at 6:44 PM, Adrian Taylor wrote:

> Speaking as a user of Carbide, rather than one of its developers,
> here are some specifics from me:
>
> Project layout:
>
> -- Symbian has very specific ideas about project filesystem layout,
> as does Eclipse, and the two are fundamentally incompatible.
> Specifically:
> -- Project files in Symbian-land are stored deep in a subdirectory,
> whilst Eclipse insists that .project and .cproject are at the
> outermost point which contains any relevant source code or headers.
> -- Several Symbian projects may have the same 'outermost point' and
> thus conflict in Eclipse-land.
> I know that the Carbide team and you yourself Doug have been
> fighting the Eclipse establishment to relax these rules, to little
> avail. I know you have hopes for EclipseFS. But meanwhile, this is
> responsible for a majority of the complexity.
> -- The nature of projects themselves are a problem. Why shouldn't
> you just be able to work directly on Symbian project files? Why the
> need to create an Eclipse project? The Carbide team has done a great
> job of hiding it well using a slick import wizard, but it's still
> wrong.
> -- And what's a workspace? Eclipse seems to want to copy, or at
> least link, my code into its own directory. Why? All my code has a
> fixed location in Symbian-land.
>
> Builds:
>
> The Carbide team have jumped through some big hoops to get the
> Symbian build system to play nicely with CDT, and on the whole, it
> now works well. But there are is still untidiness round the edges:
>
> -- CDT can't cope properly with multi-line error messages emitted by
> compilers. In C++ code full of templates, that leads to despair and
> hopelessness.
> -- Build configurations are important for Symbian. In CDT they are
> hidden away. And, although Carbide could expose that feature more
> obviously in the UI, it still might not be smooth in terms of the
> settings which applied globally versus as part of a build
> configuration.
> -- There's nothing Carbide or CDT can do about this, but Symbian
> builds are slow. I think there's a perception they're slower in the
> IDE (sometimes this is true, but either way, it's the perception
> that counts). The whole CDT experience seems hugely less slick when
> builds always take 5-20 minutes. It's not related to complexity, but
> it is probably one reason why people are put off Carbide.
>
> Indexer:
>
> -- The indexer is *great*. But...
> -- Often things go grey when you've made a mistake, but there's no
> way to find out the error message until you spend 10 minutes
> building the project with a compiler. It just seems weird to a user
> to have two different things parsing the code. Why does the IDE know
> I've done something wrong but it won't tell me what? Seems weird to
> an end-user.
> -- Likewise, you have to fiddle with two sets of macro definitions,
> include paths etc. The Carbide team has done a good job of hiding
> this but it's not transparent.
> -- Unfortunately the indexer still isn't quite perfect. For example
> the call hierarchy sometimes just stops. Which is a shame because
> when it works, it's terrific. But the fact that you can't quite
> trust its results makes everything seem complex.
>
> Launches:
>
> -- Launch configurations are useful. All the (fairly recent) efforts
> to hide/automate them are also useful. But they still seem to lurk
> as something sinister behind the scenes which users eventually will
> have to understand. The need for them is not obvious in Symbian-land.
> -- The debug view is a pain. You seem to have to click in it before
> you can use debug keys, or at least it's possible for it to lose
> focus. Debugging should be a global operation, not stuck in some
> funny little pane. This may be Carbide-specific; I don't know.
>
> Eclipse runes:
>
> -- "Hard to learn" - to be a confident user of Carbide, you have to
> understand a perspective, a view, an editor, a plugin, a workspace,
> a project, a build configuration, a launch configuration, and
> probably a bit more. All of these are Eclipse terminology.
> -- You just don't want to have to learn 10 more concepts when you're
> already struggling with the Symbian weirdness!
> -- I imagine most Carbide users need to install Subversive pretty
> quickly. Then not only do they have to struggle with understanding
> plugins, update sites, etc. but they also have to contend with the
> Eclipse IP process, or specifically its implications meaning the key
> bits of Subversive are squirreled away on someone else's website.
> Sigh. It's enough to drive me mad and I must have installed it a
> dozen times. Still, things are improving in that specific area now.
> -- Eclipse keystrokes differ from the rest of the world's.
> -- Carbide's greatest value is in the indexer features hidden behind
> obscure keystrokes. Sadly I think most Carbide users don't get far
> enough to learn F3, ctrl-o, ctrl-alt-h, ctrl-t, etc.
>
> I use Eclipse, Carbide and CDT all the time. For me, the power of
> the indexer makes it all worthwhile. But I must admit, if I were to
> try to create a simple IDE for Symbian beginners, I probably
> wouldn't start with Eclipse!
>
> Adrian
>
>
> On 11 Dec 2009, at 23:09, Doug Schaefer wrote:
>
>> Instead of talking in generalities, I'd prefer to talk with
>> specifics. Saying Carbide is hard to learn, what exactly about it
>> is it hard to learn? Is it things in the CDT or Eclipse platform or
>> things Carbide has added on top? Is it creating projects? Is it
>> setting up builds? Is it launching debug sessions? Is it creating
>> files? Is it too many choices? Would adding wizards in strategic
>> places make the CDT easier to learn?
>>
>> Most of the complaints on usability with Eclipse I've heard are
>> really complaints from users who find IDEs complex in general. Is
>> Qt Creator really that less complex than the CDT? What about Qt
>> Creator makes it easier to learn. And why don't we invest in the
>> CDT to make it equivalent?
>>
>> Doug.
>>
>> On Fri, Dec 11, 2009 at 4:47 PM, Pawel Piech <pawel.piech@...
>> > wrote:
>> All we've done so far is rather vendor-specific. What we would
>> like to see in CDT is the ability to isolate and turn off various
>> features using capabilities: e.g. build, static analysis,
>> debuggers, etc. To accomplish this we would likely need to look at
>> dependencies between these various CDT components and see if we can
>> isolate them better. However, we haven't invested any time in this
>> yet.
>> -Pawel
>>
>>
>>
>> Paul Beusterien wrote:
>>>
>>> Hi Pawel,
>>>
>>> Thanks for the response. Are there any available artifacts from
>>> the stripped-down IDE investigation? Any effort estimates?
>>>
>>> Regards,
>>> Paul
>>>
>>> On Thu, Dec 10, 2009 at 4:07 PM, Pawel Piech <pawel.piech@...
>>> > wrote:
>>> Hi Paul,
>>> Complexity is a common complaint about Eclipse-based tools (not
>>> especially limited to C - development tools). I don't know of any
>>> efforts to overhaul the UI, but I expect that there would be a lot
>>> of interest out there for it. For Wind River's part, we are
>>> investigating creating a stripped-down version of the IDE
>>> specifically targeted at Debugging use cases, but I know we won't
>>> be able to get far without support from the community.
>>>
>>> Cheers,
>>> Pawel
>>>
>>> Paul Beusterien wrote:
>>>>
>>>> Hi CDT community,
>>>>
>>>> I'm responsible for the tools strategy at the Symbian
>>>> Foundation. Like the Eclipse Foundation, Symbian depends on the
>>>> contributions from open source communities to drive its mobile
>>>> device platform technology forward.
>>>>
>>>> I'm curious if you have any thoughts about one of the challenges
>>>> we're facing with understanding/determining the direction for
>>>> Symbian C++ development tools.
>>>>
>>>> There are two open source communities vying for the Symbian C++
>>>> developer - Qt Creator and Carbide (based on CDT).
>>>>
>>>> Carbide's investments have been primarily focused on adding
>>>> features to give more power to device creators. While it has
>>>> become very feature-full, it has also become very complex and
>>>> hard to learn, especially for developers that want to just build
>>>> simple mobile apps.
>>>>
>>>> Qt Creator is a targeted C++ development environment with a big
>>>> emphasis on usability. For example, it has rigorous hurdles to
>>>> add a button or menu item. Now, it is rapidly adapting to improve
>>>> its mobile development capabilities.
>>>>
>>>> Thus, we currently have a fragmented C++ developer story at
>>>> Symbian.
>>>>
>>>> It is unlikely that Qt Creator will ever support the rich set of
>>>> features that Carbide currently provides to the power user.
>>>>
>>>> Are there any initiatives will enable CDT based IDEs to lower its
>>>> learning curve and better support the needs of a simple C++
>>>> application developer?
>>>>
>>>> Thanks,
>>>> Paul
>>>>
>>>> --
>>>> Paul Beusterien
>>>> Development Tools Manager
>>>> Symbian Foundation
>>>> Foster City, California USA
>>>> twitter: paulbeusterien
>>>
>>>
>>> _______________________________________________
>>> cdt-dev mailing list
>>> cdt-dev@...
>>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>>>
>>
>>
>> _______________________________________________
>> cdt-dev mailing list
>> cdt-dev@...
>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>>
>>
>> _______________________________________________
>> cdt-dev mailing list
>> cdt-dev@...
>> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@...
> https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

From forum: Eclipse CDT - Development

Re: CDT and Qt Creator

2009-12-11T15:44:18Z

Speaking as a user of Carbide, rather than one of its developers, here are some specifics from me:

Project layout:

-- Symbian has very specific ideas about project filesystem layout, as does Eclipse, and the two are fundamentally incompatible. Specifically:

-- Project files in Symbian-land are stored deep in a subdirectory, whilst Eclipse insists that .project and .cproject are at the outermost point which contains any relevant source code or headers.

-- Several Symbian projects may have the same 'outermost point' and thus conflict in Eclipse-land.

-- And what's a workspace? Eclipse seems to want to copy, or at least link, my code into its own directory. Why? All my code has a fixed location in Symbian-land.

Builds:

The Carbide team have jumped through some big hoops to get the Symbian build system to play nicely with CDT, and on the whole, it now works well. But there are is still untidiness round the edges:

-- CDT can't cope properly with multi-line error messages emitted by compilers. In C++ code full of templates, that leads to despair and hopelessness.

-- There's nothing Carbide or CDT can do about this, but Symbian builds are slow. I think there's a perception they're slower in the IDE (sometimes this is true, but either way, it's the perception that counts). The whole CDT experience seems hugely less slick when builds always take 5-20 minutes. It's not related to complexity, but it is probably one reason why people are put off Carbide.

Indexer:

-- The indexer is *great*. But...

-- Likewise, you have to fiddle with two sets of macro definitions, include paths etc. The Carbide team has done a good job of hiding this but it's not transparent.

Launches:

Eclipse runes:

-- You just don't want to have to learn 10 more concepts when you're already struggling with the Symbian weirdness!

-- Eclipse keystrokes differ from the rest of the world's.

-- Carbide's greatest value is in the indexer features hidden behind obscure keystrokes. Sadly I think most Carbide users don't get far enough to learn F3, ctrl-o, ctrl-alt-h, ctrl-t, etc.

Adrian

On 11 Dec 2009, at 23:09, Doug Schaefer wrote:

Instead of talking in generalities, I'd prefer to talk with specifics. Saying Carbide is hard to learn, what exactly about it is it hard to learn? Is it things in the CDT or Eclipse platform or things Carbide has added on top? Is it creating projects? Is it setting up builds? Is it launching debug sessions? Is it creating files? Is it too many choices? Would adding wizards in strategic places make the CDT easier to learn?

Most of the complaints on usability with Eclipse I've heard are really complaints from users who find IDEs complex in general. Is Qt Creator really that less complex than the CDT? What about Qt Creator makes it easier to learn. And why don't we invest in the CDT to make it equivalent?

Doug.
On Fri, Dec 11, 2009 at 4:47 PM, Pawel Piech <pawel.piech@...> wrote:
All we've done so far is rather vendor-specific. What we would like to see in CDT is the ability to isolate and turn off various features using capabilities: e.g. build, static analysis, debuggers, etc. To accomplish this we would likely need to look at dependencies between these various CDT components and see if we can isolate them better. However, we haven't invested any time in this yet.
-Pawel

Paul Beusterien wrote:
Hi Pawel,

Thanks for the response. Are there any available artifacts from the stripped-down IDE investigation? Any effort estimates?

Regards,
Paul
On Thu, Dec 10, 2009 at 4:07 PM, Pawel Piech <pawel.piech@...> wrote:
Hi Paul,
Complexity is a common complaint about Eclipse-based tools (not especially limited to C - development tools). I don't know of any efforts to overhaul the UI, but I expect that there would be a lot of interest out there for it. For Wind River's part, we are investigating creating a stripped-down version of the IDE specifically targeted at Debugging use cases, but I know we won't be able to get far without support from the community.

Cheers,
Pawel

Paul Beusterien wrote:
Hi CDT community,

I'm responsible for the tools strategy at the Symbian Foundation. Like the Eclipse Foundation, Symbian depends on the contributions from open source communities to drive its mobile device platform technology forward.

I'm curious if you have any thoughts about one of the challenges we're facing with understanding/determining the direction for Symbian C++ development tools.

There are two open source communities vying for the Symbian C++ developer - Qt Creator and Carbide (based on CDT).

Carbide's investments have been primarily focused on adding features to give more power to device creators. While it has become very feature-full, it has also become very complex and hard to learn, especially for developers that want to just build simple mobile apps.

Qt Creator is a targeted C++ development environment with a big emphasis on usability. For example, it has rigorous hurdles to add a button or menu item. Now, it is rapidly adapting to improve its mobile development capabilities.

Thus, we currently have a fragmented C++ developer story at Symbian.

It is unlikely that Qt Creator will ever support the rich set of features that Carbide currently provides to the power user.

Are there any initiatives will enable CDT based IDEs to lower its learning curve and better support the needs of a simple C++ application developer?

Thanks,
Paul

--
Paul Beusterien
Development Tools Manager
Symbian Foundation
Foster City, California USA
twitter: paulbeusterien
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev
  
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

From forum: Eclipse CDT - Development

Re: CDT and Qt Creator

2009-12-11T15:09:23Z

Doug.

On Fri, Dec 11, 2009 at 4:47 PM, Pawel Piech <pawel.piech@...> wrote:

All we've done so far is rather vendor-specific. What we would like to see in CDT is the ability to isolate and turn off various features using capabilities: e.g. build, static analysis, debuggers, etc. To accomplish this we would likely need to look at dependencies between these various CDT components and see if we can isolate them better. However, we haven't invested any time in this yet.
-Pawel

Paul Beusterien wrote:
Hi Pawel,

Thanks for the response. Are there any available artifacts from the stripped-down IDE investigation? Any effort estimates?

Regards,
Paul
On Thu, Dec 10, 2009 at 4:07 PM, Pawel Piech <pawel.piech@...> wrote:
Hi Paul,
Complexity is a common complaint about Eclipse-based tools (not especially limited to C - development tools). I don't know of any efforts to overhaul the UI, but I expect that there would be a lot of interest out there for it. For Wind River's part, we are investigating creating a stripped-down version of the IDE specifically targeted at Debugging use cases, but I know we won't be able to get far without support from the community.

Cheers,
Pawel

Paul Beusterien wrote:
Hi CDT community,

I'm responsible for the tools strategy at the Symbian Foundation. Like the Eclipse Foundation, Symbian depends on the contributions from open source communities to drive its mobile device platform technology forward.

I'm curious if you have any thoughts about one of the challenges we're facing with understanding/determining the direction for Symbian C++ development tools.

There are two open source communities vying for the Symbian C++ developer - Qt Creator and Carbide (based on CDT).

Carbide's investments have been primarily focused on adding features to give more power to device creators. While it has become very feature-full, it has also become very complex and hard to learn, especially for developers that want to just build simple mobile apps.

Qt Creator is a targeted C++ development environment with a big emphasis on usability. For example, it has rigorous hurdles to add a button or menu item. Now, it is rapidly adapting to improve its mobile development capabilities.

Thus, we currently have a fragmented C++ developer story at Symbian.

It is unlikely that Qt Creator will ever support the rich set of features that Carbide currently provides to the power user.

Are there any initiatives will enable CDT based IDEs to lower its learning curve and better support the needs of a simple C++ application developer?

Thanks,
Paul

--
Paul Beusterien
Development Tools Manager
Symbian Foundation
Foster City, California USA
twitter: paulbeusterien
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev
  
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

From forum: Eclipse CDT - Development

Re: CDT and Qt Creator

2009-12-11T13:47:34Z

Hi Pawel,

Thanks for the response. Are there any available artifacts from the stripped-down IDE investigation? Any effort estimates?

Regards,
Paul
On Thu, Dec 10, 2009 at 4:07 PM, Pawel Piech <pawel.piech@...> wrote:
Hi Paul,
Complexity is a common complaint about Eclipse-based tools (not especially limited to C - development tools). I don't know of any efforts to overhaul the UI, but I expect that there would be a lot of interest out there for it. For Wind River's part, we are investigating creating a stripped-down version of the IDE specifically targeted at Debugging use cases, but I know we won't be able to get far without support from the community.

Cheers,
Pawel

Paul Beusterien wrote:
Hi CDT community,

I'm responsible for the tools strategy at the Symbian Foundation. Like the Eclipse Foundation, Symbian depends on the contributions from open source communities to drive its mobile device platform technology forward.

I'm curious if you have any thoughts about one of the challenges we're facing with understanding/determining the direction for Symbian C++ development tools.

There are two open source communities vying for the Symbian C++ developer - Qt Creator and Carbide (based on CDT).

Carbide's investments have been primarily focused on adding features to give more power to device creators. While it has become very feature-full, it has also become very complex and hard to learn, especially for developers that want to just build simple mobile apps.

Qt Creator is a targeted C++ development environment with a big emphasis on usability. For example, it has rigorous hurdles to add a button or menu item. Now, it is rapidly adapting to improve its mobile development capabilities.

Thus, we currently have a fragmented C++ developer story at Symbian.

It is unlikely that Qt Creator will ever support the rich set of features that Carbide currently provides to the power user.

Are there any initiatives will enable CDT based IDEs to lower its learning curve and better support the needs of a simple C++ application developer?

Thanks,
Paul

--
Paul Beusterien
Development Tools Manager
Symbian Foundation
Foster City, California USA
twitter: paulbeusterien
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev
  

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

From forum: Eclipse CDT - Development

Re: CDT and Qt Creator

2009-12-11T13:40:11Z

Hi Pawel,

Thanks for the response. Are there any available artifacts from the stripped-down IDE investigation? Any effort estimates?

Regards,
Paul

On Thu, Dec 10, 2009 at 4:07 PM, Pawel Piech <pawel.piech@...> wrote:

Hi Paul,
Complexity is a common complaint about Eclipse-based tools (not especially limited to C - development tools). I don't know of any efforts to overhaul the UI, but I expect that there would be a lot of interest out there for it. For Wind River's part, we are investigating creating a stripped-down version of the IDE specifically targeted at Debugging use cases, but I know we won't be able to get far without support from the community.

Cheers,
Pawel

Paul Beusterien wrote:
Hi CDT community,

I'm responsible for the tools strategy at the Symbian Foundation. Like the Eclipse Foundation, Symbian depends on the contributions from open source communities to drive its mobile device platform technology forward.

I'm curious if you have any thoughts about one of the challenges we're facing with understanding/determining the direction for Symbian C++ development tools.

There are two open source communities vying for the Symbian C++ developer - Qt Creator and Carbide (based on CDT).

Carbide's investments have been primarily focused on adding features to give more power to device creators. While it has become very feature-full, it has also become very complex and hard to learn, especially for developers that want to just build simple mobile apps.

Qt Creator is a targeted C++ development environment with a big emphasis on usability. For example, it has rigorous hurdles to add a button or menu item. Now, it is rapidly adapting to improve its mobile development capabilities.

Thus, we currently have a fragmented C++ developer story at Symbian.

It is unlikely that Qt Creator will ever support the rich set of features that Carbide currently provides to the power user.

Are there any initiatives will enable CDT based IDEs to lower its learning curve and better support the needs of a simple C++ application developer?

Thanks,
Paul

--
Paul Beusterien
Development Tools Manager
Symbian Foundation
Foster City, California USA
twitter: paulbeusterien

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

From forum: Eclipse CDT - Development

RE: new thread kills eclipse

2009-12-11T13:02:03Z

Yes but I have already seen this message before when everything worked fine without the new thread. So is this really
that kind of a message or just red herring?

Maybe I'll assume the message is legit now because I'm creating a thread so I'll get rid of it and see.

thanx
/carl h.

-----Original Message-----
From: cdt-debug-dev-bounces@... [mailto:cdt-debug-dev-bounces@...] On Behalf Of Vladimir Prus
Sent: Friday, December 11, 2009 1:13 AM
To: cdt-debug-dev@...
Subject: Re: [cdt-debug-dev] new thread kills eclipse

On Thursday 10 December 2009 21:10:34 Heyendal, Carl wrote:

> My Linux based embedded C application was a single process with no threads and it ran fine within Eclipse using DSF-GDB.
>
> However I needed to create a new thread in my application running on my remote target that did a bit of work on the side, which I implemented.
>
> But now, whenever I launch the application in Eclipse, I can step through the main parent thread without any problem, until I get to the point where I create a new thread. At that point, once the new thread is created, everything stops working, and the only thread that's running gets suspended. I can't even examine the return code from the call to pthread_create()!
>
> I tried setting a breakpoint in the new thread but it never makes it to the breakpoint, ending with the same result described above.
>
> This only happens whenever I create a thread and run the app using DSF-GDB in Eclipse. Other than that, the application runs fine stand-alone (without Eclipse) with the new thread.
>
> Attached is a file containing a snapshot of the Eclipse debugger.
>
> Seems to be something to do with a thread/debugger/eclipse
> interaction. (really narrows it down, huh? :-)
>
> What am I missing? I'd appreciate any help if you can.

Your screenshot has a message in red, in console, and that message basically say "nothing is gonna work from now on". It's most likely that you did not configure your debug configuration to properly find shared libraries, on the "Shared Libraries"
tab.

- Volodya
_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev

_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev

From forum: Eclipse CDT - debug

RE: Plea for EclipseCon submissions

2009-12-11T10:34:12Z

I know there has been interest in Codan from Ericsson, so my feeling is it would be a good talk to have.

________________________________________
From: cdt-dev-bounces@... [cdt-dev-bounces@...] On Behalf Of Alena Laskavaia [elaskavaia.cdt@...]
Sent: December 11, 2009 12:23 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Plea for EclipseCon submissions

Do you know what is the deadline? I have trouble finding it on the site.

I want to submit a talk something like "Codan: a Static Analysis
Framework for C/C++ in CDT",
would people think it would be interesting?

Another question, I want it to be packaged with CDT 7.0, is there any
objectives? But I need some help,
I tried to cleaned up API but I never did any public API work before,
I am not sure I have done a good job...
Can somebody look it at it? Framework in CVS in "codan" folder. Wiki
page at http://wiki.eclipse.org/CDT/designs/StaticAnalysis.

Also what would be recommended format of packaging? Optional feature?
Or two? (It has framework itself and checkers set)

On Wed, Dec 2, 2009 at 11:05 AM, Doug Schaefer <cdtdoug@...> wrote:

> Hey gang,
>
> Just a reminder, especially given the low submission numbers currently, to
> post your talk ideas for talks EclipseCon soon. There's only two more weeks
> left before we close. And if you do it real soon, you'll be eligible for
> prizes!
>
> http://www.eclipsecon.org/2010/
>
> Thanks,
> Doug.
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@...
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
>

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

From forum: Eclipse CDT - Development

Re: Plea for EclipseCon submissions

2009-12-11T09:23:13Z

Do you know what is the deadline? I have trouble finding it on the site.

I want to submit a talk something like "Codan: a Static Analysis
Framework for C/C++ in CDT",
would people think it would be interesting?

Another question, I want it to be packaged with CDT 7.0, is there any
objectives? But I need some help,
I tried to cleaned up API but I never did any public API work before,
I am not sure I have done a good job...
Can somebody look it at it? Framework in CVS in "codan" folder. Wiki
page at http://wiki.eclipse.org/CDT/designs/StaticAnalysis.

Also what would be recommended format of packaging? Optional feature?
Or two? (It has framework itself and checkers set)

On Wed, Dec 2, 2009 at 11:05 AM, Doug Schaefer <cdtdoug@...> wrote:

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

From forum: Eclipse CDT - Development

Helios M4 Candidate

2009-12-11T07:12:35Z

M4 Candidate is now available for testing: http://download.eclipse.org/tools/cdt/builds/6.1.0/I.I200912110805/index.html

Please report any issues you found with this build. Monday December 14 is the Helios M4 + 1 date.

Regards,

Vivian Kong
IBM Eclipse CDT
IBM Canada Toronto Lab
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

From forum: Eclipse CDT - Development

Re: org.eclipse.cdt.releng

2009-12-11T07:09:19Z

We use the cdt.map file to list the projects to check out of CVS. It might be cleaner to add your plug-ins there.

On Fri, Dec 11, 2009 at 3:04 AM, David Sariel <datosar@...> wrote:

Hello,

If I want to build cdt-master-version#.zip from my local version of cdt sources. I have a small change in org.eclipse.cdt.ui and 2 new plugins. So I thought to put sources to my cvs repository and to change org.eclipse.cdt.releng/build.xml to fetch sources from my cvs.
Is it the best way to do it?

Thanks,

David

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

From forum: Eclipse CDT - Development

org.eclipse.cdt.releng

2009-12-11T00:04:58Z

Hello,

If I want to build cdt-master-version#.zip from my local version of cdt
sources. I have a small change in org.eclipse.cdt.ui and 2 new plugins.
So I thought to put sources to my cvs repository and to change
org.eclipse.cdt.releng/build.xml to fetch sources from my cvs.
Is it the best way to do it?

Thanks,

David

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

From forum: Eclipse CDT - Development

Re: new thread kills eclipse

2009-12-10T22:12:40Z

On Thursday 10 December 2009 21:10:34 Heyendal, Carl wrote:

> My Linux based embedded C application was a single process with no threads and it ran fine within Eclipse using DSF-GDB.
>
> However I needed to create a new thread in my application running on my remote target that did a bit of work on the side, which I implemented.
>
> But now, whenever I launch the application in Eclipse, I can step through the main parent thread without any problem, until I get to the point where I create a new thread. At that point, once the new thread is created, everything stops working, and the only thread that's running gets suspended. I can't even examine the return code from the call to pthread_create()!
>
> I tried setting a breakpoint in the new thread but it never makes it to the breakpoint, ending with the same result described above.
>
> This only happens whenever I create a thread and run the app using DSF-GDB in Eclipse. Other than that, the application runs fine stand-alone (without Eclipse) with the new thread.
>
> Attached is a file containing a snapshot of the Eclipse debugger.
>
> Seems to be something to do with a thread/debugger/eclipse interaction. (really narrows it down, huh? :-)
>
> What am I missing? I'd appreciate any help if you can.

Your screenshot has a message in red, in console, and that message basically say
"nothing is gonna work from now on". It's most likely that you did not configure
your debug configuration to properly find shared libraries, on the "Shared Libraries"
tab.

- Volodya
_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev

From forum: Eclipse CDT - debug

Re: CDT and Qt Creator

2009-12-10T16:42:27Z

I would venture a guess that Eclipse was much simper in its infancy, and that the complexity has grown steadily as Eclipse caters to more and more types of tools and applications. There certainly have been lots of measures over the years to streamline the UI and improve the user experience. Many have been effective, in my opinion, but it seems like it's never enough.

Someone could write a very simple development toolset based on Eclipse technology...but it would be little more than an RPC application. Users want solutions highly customized to their exact needs. Software providers want cost effective implementations and high reusability. I think these two will always be at odds.

John

At 06:07 PM 12/10/2009, Pawel Piech wrote:

Hi Paul,
Complexity is a common complaint about Eclipse-based tools (not especially limited to C - development tools). I don't know of any efforts to overhaul the UI, but I expect that there would be a lot of interest out there for it. For Wind River's part, we are investigating creating a stripped-down version of the IDE specifically targeted at Debugging use cases, but I know we won't be able to get far without support from the community.

Cheers,
Pawel

Paul Beusterien wrote:
Hi CDT community,

I'm responsible for the tools strategy at the Symbian Foundation. Like the Eclipse Foundation, Symbian depends on the contributions from open source communities to drive its mobile device platform technology forward.

I'm curious if you have any thoughts about one of the challenges we're facing with understanding/determining the direction for Symbian C++ development tools.

There are two open source communities vying for the Symbian C++ developer - Qt Creator and Carbide (based on CDT).

Carbide's investments have been primarily focused on adding features to give more power to device creators. While it has become very feature-full, it has also become very complex and hard to learn, especially for developers that want to just build simple mobile apps.

Qt Creator is a targeted C++ development environment with a big emphasis on usability. For example, it has rigorous hurdles to add a button or menu item. Now, it is rapidly adapting to improve its mobile development capabilities.

Thus, we currently have a fragmented C++ developer story at Symbian.

It is unlikely that Qt Creator will ever support the rich set of features that Carbide currently provides to the power user.

Are there any initiatives will enable CDT based IDEs to lower its learning curve and better support the needs of a simple C++ application developer?

Thanks,
Paul

--
Paul Beusterien
Development Tools Manager
Symbian Foundation
Foster City, California USA
twitter: paulbeusterien
_______________________________________________
cdt-dev mailing list
cdt-dev@...

https://dev.eclipse.org/mailman/listinfo/cdt-dev
  
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

From forum: Eclipse CDT - Development

Re: CDT and Qt Creator

2009-12-10T16:07:27Z

Hi Paul,
Complexity is a common complaint about Eclipse-based tools (not especially limited to C - development tools). I don't know of any efforts to overhaul the UI, but I expect that there would be a lot of interest out there for it. For Wind River's part, we are investigating creating a stripped-down version of the IDE specifically targeted at Debugging use cases, but I know we won't be able to get far without support from the community.

Cheers,
Pawel

Paul Beusterien wrote:

Hi CDT community,

I'm responsible for the tools strategy at the Symbian Foundation. Like the Eclipse Foundation, Symbian depends on the contributions from open source communities to drive its mobile device platform technology forward.

I'm curious if you have any thoughts about one of the challenges we're facing with understanding/determining the direction for Symbian C++ development tools.

There are two open source communities vying for the Symbian C++ developer - Qt Creator and Carbide (based on CDT).

Carbide's investments have been primarily focused on adding features to give more power to device creators. While it has become very feature-full, it has also become very complex and hard to learn, especially for developers that want to just build simple mobile apps.

Qt Creator is a targeted C++ development environment with a big emphasis on usability. For example, it has rigorous hurdles to add a button or menu item. Now, it is rapidly adapting to improve its mobile development capabilities.

Thus, we currently have a fragmented C++ developer story at Symbian.

It is unlikely that Qt Creator will ever support the rich set of features that Carbide currently provides to the power user.

Are there any initiatives will enable CDT based IDEs to lower its learning curve and better support the needs of a simple C++ application developer?

Thanks,
Paul

--
Paul Beusterien
Development Tools Manager
Symbian Foundation
Foster City, California USA
twitter: paulbeusterien
_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev
  

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

From forum: Eclipse CDT - Development

CDT and Qt Creator

2009-12-10T15:30:34Z

From forum: Eclipse CDT - Development

new thread kills eclipse

2009-12-10T10:10:34Z

My Linux based embedded C application was a single process with no threads and it ran fine within Eclipse using DSF-GDB.

However I needed to create a new thread in my application running on my remote target that did a bit of work on the side, which I implemented.

But now, whenever I launch the application in Eclipse, I can step through the main parent thread without any problem, until I get to the point where I create a new thread. At that point, once the new thread is created, everything stops working, and the only thread that's running gets suspended. I can't even examine the return code from the call to pthread_create()!

I tried setting a breakpoint in the new thread but it never makes it to the breakpoint, ending with the same result described above.

This only happens whenever I create a thread and run the app using DSF-GDB in Eclipse. Other than that, the application runs fine stand-alone (without Eclipse) with the new thread.

Attached is a file containing a snapshot of the Eclipse debugger.

Seems to be something to do with a thread/debugger/eclipse interaction. (really narrows it down, huh? :-)

What am I missing? I'd appreciate any help if you can.

/carl h.

_______________________________________________
cdt-debug-dev mailing list
cdt-debug-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev

Screenshot-Debug - CM-Src-firmware.c - Eclipse .png (173K) Download Attachment

From forum: Eclipse CDT - debug

Question about source lookup

2009-12-10T02:25:20Z

Hi,

In the context of linux tools project
(http://www.eclipse.org/linuxtools/), I've made my own
CSourceNotFoundEditor
(https://dev.eclipse.org/svnroot/technology/org.eclipse.linuxtools/gprof/trunk/org.eclipse.linuxtools.binutils/src/org/eclipse/linuxtools/binutils/link2source/STCSourceNotFoundEditor.java)

I've made that, because when viewing gprof profiling result, there is no
debugger active (so I can't use CSourceNotFoundEditor).
I've added a "Locate File..." button, allowing the user to choose a C
file in the filesystem. Moreover, this button adds a new
MapEntrySourceContainer in sourceLookupDirector.

It works fine, but unfortunately, MapEntrySourceContainer is an internal
class. Therefore, a warning is issued at compile time (see
https://bugs.eclipse.org/bugs/show_bug.cgi?id=285328)

So, my question is the following:
=> Is there a way to implement this feature another way, to avoid such
warnings ?
=> If not, is it possible to add a public API in CDT, to allow access to
MapEntrySourceContainer ?

Many thanks

Xavier Raynaud

_______________________________________________
cdt-dev mailing list
cdt-dev@...
https://dev.eclipse.org/mailman/listinfo/cdt-dev

From forum: Eclipse CDT - Development