Nabble - 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

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

Re: CDT and Qt Creator

2009-12-11T16:23:45Z

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

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

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

Re: CDT and Qt Creator

2009-12-11T16:11:33Z

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

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

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.

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

Re: CDT and Qt Creator

2009-12-11T15:09:23Z

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

Re: CDT and Qt Creator

2009-12-11T13:47:34Z

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

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

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

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

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

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

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

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

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

CDT and Qt Creator

2009-12-10T15:30:34Z

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

Re: Re: Run Configuration application path

2009-12-08T15:45:57Z

Hi,

Is this using a Standard (managed) project or a Makefile project? Using
a Makefile project should work. I think in a standard project, only
configuration folders are scanned by the binary parser. Once the parser
sees the executable, it should appear in the project explorer and you
should be able to select it with the Browse button in the Run configuration.

Marc-Andre

Manuel Feige wrote:

> Hello,
>
> I have got the same problem like Martin Guillon:
> Is there any possibility to use variables (or relative paths) in the
> run configuration application path?
>
> Regards
> Manuel
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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

Re: Run Configuration application path

2009-12-08T13:58:34Z

Hello,

I have got the same problem like Martin Guillon:
Is there any possibility to use variables (or relative paths) in the run configuration application path?

Regards
Manuel

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

Re: C++0x

2009-12-08T12:41:59Z

Markus has already started working on it:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=294730

Mike Kucera
Software Developer
Eclipse CDT/PTP
IBM Toronto
mkucera@...

Doug Schaefer ---12/08/2009 03:10:29 PM---Hey gang,

From:	Doug Schaefer <cdtdoug@...>
To:	"CDT General developers list." <cdt-dev@...>
Date:	12/08/2009 03:10 PM
Subject:	[cdt-dev] C++0x

Hey gang,

I was just on the newsgroup as someone is having trouble using gcc 4.4.2 which is starting to sneak in things that need the C++0x flag turned on. That brings up the question on when we should start in earnest working on add the new grammar to our parsers.

Does anyone have thoughts on that or the time and desire to work on it?

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

C++0x

2009-12-08T12:09:29Z

Hey gang,

I was just on the newsgroup as someone is having trouble using gcc 4.4.2 which is starting to sneak in things that need the C++0x flag turned on. That brings up the question on when we should start in earnest working on add the new grammar to our parsers.

Does anyone have thoughts on that or the time and desire to work on it?

Thanks,
Doug.

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

Re: CDT Helios M4 and CDT 7.0

2009-12-08T11:48:26Z

Re: [cdt-dev] CDT Helios M4 and CDT 7.0 No problem postponing those changes until after M4, sounds like a good idea.

- Ken

From: ext Vivian Kong <vivkong@...>
Reply-To: "CDT General developers list." <cdt-dev@...>
Date: Tue, 8 Dec 2009 20:43:43 +0100
To: "CDT General developers list." <cdt-dev@...>
Subject: [cdt-dev] CDT Helios M4 and CDT 7.0

Hi everyone,

Helios M4 + 1 is next Monday December 14 so this Friday's (December 11) build will be our M4 candidate. I've already updated our build to build against Eclipse 3.6 so this will be our first milestone build against Eclipse 3.6.

When can we expect API breaking changes to be in HEAD? Can we postponed them till after M4 so consumers have more time to adapt to the new changes? Thoughts?

Regards,

Vivian Kong
IBM Eclipse CDT
IBM Canada Toronto Lab

Doug Schaefer ---12/02/2009 11:26:38 AM---Hey gang, At the CDT call, we had a good discussion about moving CDT to 7.0 for the

From:
Doug Schaefer <cdtdoug@...>

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

Date:
12/02/2009 11:26 AM

Subject:
[cdt-dev] CDT Helios as CDT 7.0

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

Hey gang,

At the CDT call, we had a good discussion about moving CDT to 7.0 for the Helios train in June. There are a few APIs that need to be changed to allow us to make the changes we need to do this release. There is also a strong desire to have firm and stable APIs and it would be good not to change them. That conflicts making this a tough decision.

But here's my thinking. I'm very glad we have the desire to have stable APIs and am very glad we are committed to managing them with the API tooling. However, until we have good APIs, I'm not sure we benefit from stable APIs. I don't think we're ready to commit to the APIs that we have as the set we want to stick with for the foreseeable future.

So basically, this means major releases until we get there. Unless we get a veto, Helios will be CDT 7.0. Committers need to commit to minimizing the API changes they do make to ensure the community can easily adopt CDT 7. And they need to commit to documenting the changes so that we can produce an upgrade guide. I think that's the most pragmatic approach.

I also think next year will be CDT 8.0. I encourage all contributors to take a look at the APIs we have and make the changes necessary to commit to them. I know the Build APIs are in much need of cleaning up. We also need to decide what exactly the API should be and remove things that we don't want. But the hope is that CDT 8.x is the last major release for a while.

Please comment, especially if you disagree. We need to work together and decide as a community where we want to go with our APIs.
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 Helios M4 and CDT 7.0

2009-12-08T11:43:43Z

Hi everyone,

Helios M4 + 1 is next Monday December 14 so this Friday's (December 11) build will be our M4 candidate. I've already updated our build to build against Eclipse 3.6 so this will be our first milestone build against Eclipse 3.6.

When can we expect API breaking changes to be in HEAD? Can we postponed them till after M4 so consumers have more time to adapt to the new changes? Thoughts?

Regards,

Vivian Kong
IBM Eclipse CDT
IBM Canada Toronto Lab

Doug Schaefer ---12/02/2009 11:26:38 AM---Hey gang, At the CDT call, we had a good discussion about moving CDT to 7.0 for the

From:	Doug Schaefer <cdtdoug@...>
To:	"CDT General developers list." <cdt-dev@...>
Date:	12/02/2009 11:26 AM
Subject:	[cdt-dev] CDT Helios as CDT 7.0
Sent by:	cdt-dev-bounces@...

Hey gang,

At the CDT call, we had a good discussion about moving CDT to 7.0 for the Helios train in June. There are a few APIs that need to be changed to allow us to make the changes we need to do this release. There is also a strong desire to have firm and stable APIs and it would be good not to change them. That conflicts making this a tough decision.

But here's my thinking. I'm very glad we have the desire to have stable APIs and am very glad we are committed to managing them with the API tooling. However, until we have good APIs, I'm not sure we benefit from stable APIs. I don't think we're ready to commit to the APIs that we have as the set we want to stick with for the foreseeable future.

So basically, this means major releases until we get there. Unless we get a veto, Helios will be CDT 7.0. Committers need to commit to minimizing the API changes they do make to ensure the community can easily adopt CDT 7. And they need to commit to documenting the changes so that we can produce an upgrade guide. I think that's the most pragmatic approach.

I also think next year will be CDT 8.0. I encourage all contributors to take a look at the APIs we have and make the changes necessary to commit to them. I know the Build APIs are in much need of cleaning up. We also need to decide what exactly the API should be and remove things that we don't want. But the hope is that CDT 8.x is the last major release for a while.

Please comment, especially if you disagree. We need to work together and decide as a community where we want to go with our APIs.
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

RE: Adding new MI commands to the gdb/mi interface for integration with CDT

2009-12-08T10:32:44Z

For some commands, you can use CLI to communicate between GDB and CDI or DSF.

In DSF-GDB, we use CLI commands like 'reverse' or 'attach' We use these commands

because there is currently no MI equivalent. In those cases, we have to parse the CLI

result, which is more diffcult to do than with MI.

So, in your case, you could use your CLI command directly, if you can parse its output

reliably.

Marc

From: cdt-dev-bounces@... [mailto:cdt-dev-bounces@...] On Behalf Of Rohit Girme
Sent: December-08-09 1:25 PM
To: CDT General developers list.
Subject: Re: [cdt-dev] Adding new MI commands to the gdb/mi interface for integration with CDT

Hi,

You are saying CDI/DSF can be integrated using CLI instead of MI?

Rohit

On Mon, Dec 7, 2009 at 7:27 AM, Marc Khouzam <marc.khouzam@...> wrote:

The communication with GDB is the same if you use CDI or DSF. They both talk to GDB using GDB/MI (but also CLI).

From: cdt-dev-bounces@... [mailto:cdt-dev-bounces@...] On Behalf Of Rohit Girme
Sent: Monday, December 07, 2009 2:09 AM

To: CDT General developers list.
Subject: Re: [cdt-dev] Adding new MI commands to the gdb/mi interface for integration with CDT

Hi,

If I use DSF to integrate gdb with Eclipse, would I need an MI command to talk with gdb? I have the presentation about to write a DSF based debugger for PDA. Is there any documentation for gdb based debugger integration with DSF?

Thanks,
Rohit

On Sun, Dec 6, 2009 at 11:51 AM, Marc Khouzam <marc.khouzam@...> wrote:

Hi,

there are now two GDB integration is CDT. The orginal one (CDI), and the new one (DSF-GDB).
First, you will have to choose which one you want to use. Very little work is being done in CDI and there
are no big plans for the future. DSF-GDB is more active, and already has support for a lot of the latest GDB features.

Either way, adding a new MI command is not difficult, but then you'll have to call is somewhere (which shouldn't be too
bad either :-)).

In DSF-GDB, look for an example command like MIBreakInsert

Marc

P.S. DSF-GDB supports Process Record Replay from GDB 7.0, in case your 'replay' is related to that.

________________________________________
From: cdt-dev-bounces@... [cdt-dev-bounces@...] On Behalf Of Rohit Girme [rgirme@...]
Sent: December 6, 2009 1:46 AM
To: CDT General developers list.
Subject: [cdt-dev] Adding new MI commands to the gdb/mi interface for integration with CDT

Hi,

I have added a new feature/command in gdb called 'replay'. It doesnt matter what exactly replay does. Now I am trying to integrate this 'replay' with CDT. I will first have to add a new MI command for the gdb/mi interface.
Does anyone know anything about this?
Let me know if you need any more information.

--
Thanks & Regards,
Rohit Girme

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

--
Thanks & Regards,
Rohit Girme

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

--
Thanks & Regards,
Rohit Girme

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

Re: Adding new MI commands to the gdb/mi interface for integration with CDT

2009-12-08T10:24:38Z

Hi,

You are saying CDI/DSF can be integrated using CLI instead of MI?

Rohit

On Mon, Dec 7, 2009 at 7:27 AM, Marc Khouzam <marc.khouzam@...> wrote:

The communication with GDB is the same if you use CDI or DSF. They both talk to GDB using GDB/MI (but also CLI).

From: cdt-dev-bounces@... [mailto:cdt-dev-bounces@...] On Behalf Of Rohit Girme
Sent: Monday, December 07, 2009 2:09 AM

To: CDT General developers list.
Subject: Re: [cdt-dev] Adding new MI commands to the gdb/mi interface for integration with CDT

Hi,

If I use DSF to integrate gdb with Eclipse, would I need an MI command to talk with gdb? I have the presentation about to write a DSF based debugger for PDA. Is there any documentation for gdb based debugger integration with DSF?

Thanks,
Rohit

On Sun, Dec 6, 2009 at 11:51 AM, Marc Khouzam <marc.khouzam@...> wrote:

Hi,

there are now two GDB integration is CDT. The orginal one (CDI), and the new one (DSF-GDB).
First, you will have to choose which one you want to use. Very little work is being done in CDI and there
are no big plans for the future. DSF-GDB is more active, and already has support for a lot of the latest GDB features.

Either way, adding a new MI command is not difficult, but then you'll have to call is somewhere (which shouldn't be too
bad either :-)).

In DSF-GDB, look for an example command like MIBreakInsert

Marc

P.S. DSF-GDB supports Process Record Replay from GDB 7.0, in case your 'replay' is related to that.

________________________________________
From: cdt-dev-bounces@... [cdt-dev-bounces@...] On Behalf Of Rohit Girme [rgirme@...]
Sent: December 6, 2009 1:46 AM
To: CDT General developers list.
Subject: [cdt-dev] Adding new MI commands to the gdb/mi interface for integration with CDT

Hi,

I have added a new feature/command in gdb called 'replay'. It doesnt matter what exactly replay does. Now I am trying to integrate this 'replay' with CDT. I will first have to add a new MI command for the gdb/mi interface.
Does anyone know anything about this?
Let me know if you need any more information.

--
Thanks & Regards,
Rohit Girme

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

--
Thanks & Regards,
Rohit Girme

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

--
Thanks & Regards,
Rohit Girme

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

Re: IManagedOptionValueHandler.isEnumValueAppropriate parameter type

2009-12-08T05:11:10Z

On Saturday 05 December 2009 20:38:18 Andrew Gvozdev wrote:

> Hi Vladimir,
> On Sat, Dec 5, 2009 at 8:48 AM, Vladimir Prus <vladimir@...>wrote:
>
> >
> > At present, the signature of
> > IManagedOptionValueHandler.isEnumValueAppropriate
> > is as follows:
> >
> > public boolean isEnumValueAppropriate(IBuildObject configuration,
> > IHoldsOptions holder, IOption option, String
> > extraArgument,
> > String enumValue)
> >
> > It seems to be that the type and name of the first parameter are
> > misleading.
> > First, looking at the name one can assume that it's configuration that is
> > passed
> > in (and in fact, IConfiguration does extend IBuildObject). However,
> > in practice IResourceInfo is always passed in -- after upcast to
> > IBuildObject.
> > Second, even assuming IBuildObject can be passed -- what is a poor method
> > to do?
> > There's a dozen interfaces that directly extend IBuildObject, and it's
> > unlikely
> > that any of that dozen can be passed.
> >
> > So:
> >
> > 1. Why is the parameter type so needlessly generic?
> >
>
> I doubt that somebody can answer the first question. The creators of the
> design are not around anymore.
>
>
> > 2. Could this be fixed?
> >
>
> That could be problematic by the reason of my answer to the first question.
> The best we can do is: a) accept a patch renaming the variable - not
> changing API - and describing your findings in JavaDoc for the function, and
> b) you can create a bug in bugzilla requesting API change (put API word in
> description). All the bugs like that would get looked at when project model
> is redesigned (optimistically, there is a non-zero chance of that)

Can IManagedOptionValueHandler2 be introduced, and the corresponding code modified
to check which one is implemented, at runtime.

It appears that this interface has yet another issue -- the 'enumValue' is actually
what is shown in the UI, not the id of the enumerator. And the thing shown in UI
is somewhat volatile -- e.g. just now out product got a name of enumerator changed
for clarify. Ideally, the id of the enumerator should be passed.

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

Getting putpkt: write failed: Broken pipe error on launching remote attach debug session

2009-12-07T09:27:42Z

Hi all,

I have implemented MyDebugger by subclassing from GDBCDIDebugger2.

And also the MyLaunchDelegate by understanding the attach session code
from LocalCDILaunchDelegate

But after the connection and all is made, I am getting the following error
:

Ignoring packet error, continuing

putpkt: write failed : broken pipe
Error while reading shared library symbols:

Can someone help, what might be the issue. ?

Thanks & Regards,
- Nayna Jain

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

RE: Best way to send a patched CDT?

2009-12-07T09:00:11Z

Thanks Christian and James for your help.

I tried installing CDT with P2 and then using the dropins folder but as Christian mentions, that didn't work.

-> What did work was to use the dropins folder of an Eclipse without CDT, and put all the CDT plugins in there.

Then, I was able to put test CDT plugins that had a new version numbers.

I think this was also James' suggestion, while adding the bit about changing the version

(good thing he did, 'cause I would have screwed that up :-))

Either way, thanks both!

From: cdt-dev-bounces@... [mailto:cdt-dev-bounces@...] On Behalf Of Christian W. Damus
Sent: Monday, December 07, 2009 10:59 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] Best way to send a patched CDT?

Hi, James,

I think I've read somewhere that bundles in the dropins/ folder cannot supersede bundles installed by P2: the P2 reconciler/discovery thing ignores anything it finds that has the same ID as an installed IU.

I have attempted this before, with no joy. Mind you, I should mention that I have attempted the patch feature method, also without success. But probably I did something wrong ... which is easy to do :-D

cW

On Mon, 2009-12-07 at 15:48 +0000, James Blackburn wrote:
2009/12/7 Marc Khouzam <marc.khouzam@...>

I'm trying to find the most efficient way to send a patched CDT to someone.

Sending all plugins is kind of big and I'd like to avoid it.

If I build a single plugin, can the recipient manually replace the plugin in a nightly build zip file?

The nightly build zip file is a p2 update site. There's XML in there that describes the IUs so manually replacing the plugin won't work.

Feature patches can work if you want to be able to update your changed plugin set using the p2 UI.

If you're just distributing one plugin for testing, say, the dropins folder should do the trick (and is likely the easiest way). NB if you don't increment the plugin's version number in the plugin manifest p2 will just ignore it!

Cheers,
James

Thanks for any suggestions

Marc

Marc Khouzam
Software Designer, Methods and Tools

Ericsson Canada Inc

EMC/Q
8500 Decarie Blvd.
H4P 2N2, Mont-Royal, Qc, Canada
www.ericsson.com

Office: +514 345 7900 x42350

Fax: +514 345 6159

Mobile: +514 951 7191

Email: Marc.Khouzam@...

Ce courriel est confidentiel et uniquement destiné à son ou ses destinataires. Il est défendu de le consulter, de l'utiliser, de le dévoiler ou de le diffuser sans autorisation. Si ce message vous est parvenu par erreur, merci d'en aviser l'expéditeur par retour de courrier et de le détruire sans le divulguer. Un courriel et ses pièces jointes peut être sans autorisation corrompu, interrompu, amendé, altéré et infecté. L'entreprise ne reçoit et n'envoie de courriel qu'avec l'entente qu'elle n'est responsable d'aucune corruption, interception, modification, altération, infection ou conséquence possible.

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

_______________________________________________
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
Christian W. Damus
Software Developer, IDE Team
QNX Software Systems

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

Re: Best way to send a patched CDT?

2009-12-07T07:58:41Z

Hi, James,

I think I've read somewhere that bundles in the dropins/ folder cannot supersede bundles installed by P2: the P2 reconciler/discovery thing ignores anything it finds that has the same ID as an installed IU.

I have attempted this before, with no joy. Mind you, I should mention that I have attempted the patch feature method, also without success. But probably I did something wrong ... which is easy to do :-D

cW

On Mon, 2009-12-07 at 15:48 +0000, James Blackburn wrote:

2009/12/7 Marc Khouzam <marc.khouzam@...>

I'm trying to find the most efficient way to send a patched CDT to someone.

Sending all plugins is kind of big and I'd like to avoid it.

If I build a single plugin, can the recipient manually replace the plugin in a nightly build zip file?

The nightly build zip file is a p2 update site. There's XML in there that describes the IUs so manually replacing the plugin won't work.

Feature patches can work if you want to be able to update your changed plugin set using the p2 UI.

If you're just distributing one plugin for testing, say, the dropins folder should do the trick (and is likely the easiest way). NB if you don't increment the plugin's version number in the plugin manifest p2 will just ignore it!

Cheers,
James

Thanks for any suggestions

Marc

Marc Khouzam
Software Designer, Methods and Tools

Ericsson Canada Inc

EMC/Q
8500 Decarie Blvd.
H4P 2N2, Mont-Royal, Qc, Canada
www.ericsson.com

Office: +514 345 7900 x42350

Fax: +514 345 6159

Mobile: +514 951 7191

Email: Marc.Khouzam@...

Ce courriel est confidentiel et uniquement destiné à son ou ses destinataires. Il est défendu de le consulter, de l'utiliser, de le dévoiler ou de le diffuser sans autorisation. Si ce message vous est parvenu par erreur, merci d'en aviser l'expéditeur par retour de courrier et de le détruire sans le divulguer. Un courriel et ses pièces jointes peut être sans autorisation corrompu, interrompu, amendé, altéré et infecté. L'entreprise ne reçoit et n'envoie de courriel qu'avec l'entente qu'elle n'est responsable d'aucune corruption, interception, modification, altération, infection ou conséquence possible.

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

_______________________________________________
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

Christian W. Damus
Software Developer, IDE Team
QNX Software Systems

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

Re: Best way to send a patched CDT?

2009-12-07T07:48:21Z

2009/12/7 Marc Khouzam <marc.khouzam@...>

I'm trying to find the most efficient way to send a patched CDT to someone.
Sending all plugins is kind of big and I'd like to avoid it.

If I build a single plugin, can the recipient manually replace the plugin in a nightly build zip file?

The nightly build zip file is a p2 update site. There's XML in there that describes the IUs so manually replacing the plugin won't work.

Feature patches can work if you want to be able to update your changed plugin set using the p2 UI.

If you're just distributing one plugin for testing, say, the dropins folder should do the trick (and is likely the easiest way). NB if you don't increment the plugin's version number in the plugin manifest p2 will just ignore it!

Cheers,
James

Thanks for any suggestions

Marc

Marc Khouzam
Software Designer, Methods and Tools

Ericsson Canada Inc

EMC/Q
8500 Decarie Blvd.
H4P 2N2, Mont-Royal, Qc, Canada
www.ericsson.com

Office: +514 345 7900 x42350
Fax: +514 345 6159
Mobile: +514 951 7191
Email: Marc.Khouzam@...

Ce courriel est confidentiel et uniquement destiné à son ou ses destinataires. Il est défendu de le consulter, de l'utiliser, de le dévoiler ou de le diffuser sans autorisation. Si ce message vous est parvenu par erreur, merci d'en aviser l'expéditeur par retour de courrier et de le détruire sans le divulguer. Un courriel et ses pièces jointes peut être sans autorisation corrompu, interrompu, amendé, altéré et infecté. L'entreprise ne reçoit et n'envoie de courriel qu'avec l'entente qu'elle n'est responsable d'aucune corruption, interception, modification, altération, infection ou conséquence possible.

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

_______________________________________________
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

Re: Best way to send a patched CDT?

2009-12-07T07:40:51Z

Hi, Marc,

If your recipient installed CDT by unzipping it into the dropins/ folder, then P2 should find the update when the bundle JAR is replaced.

If CDT was installed from a P2 repos via the C/C++ package, then I think the standard answer is that a "patch feature" is required to deliver the update. It contains your updated bundle and would have to be delivered as a P2 repository (a PDE update-site project does all the work). ZIPping the repos is convenient, as it can be added in the P2 UI as is.

HTH,

Christian

On Mon, 2009-12-07 at 10:32 -0500, Marc Khouzam wrote:

Hi,

I'm trying to find the most efficient way to send a patched CDT to someone.

Sending all plugins is kind of big and I'd like to avoid it.

If I build a single plugin, can the recipient manually replace the plugin in a nightly build zip file?

Thanks for any suggestions

Marc

Marc Khouzam
Software Designer, Methods and Tools

Ericsson Canada Inc

EMC/Q
8500 Decarie Blvd.
H4P 2N2, Mont-Royal, Qc, Canada
www.ericsson.com

Office: +514 345 7900 x42350

Fax: +514 345 6159

Mobile: +514 951 7191

Email: Marc.Khouzam@...

Ce courriel est confidentiel et uniquement destiné à son ou ses destinataires. Il est défendu de le consulter, de l'utiliser, de le dévoiler ou de le diffuser sans autorisation. Si ce message vous est parvenu par erreur, merci d'en aviser l'expéditeur par retour de courrier et de le détruire sans le divulguer. Un courriel et ses pièces jointes peut être sans autorisation corrompu, interrompu, amendé, altéré et infecté. L'entreprise ne reçoit et n'envoie de courriel qu'avec l'entente qu'elle n'est responsable d'aucune corruption, interception, modification, altération, infection ou conséquence possible.

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

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

Christian W. Damus
Software Developer, IDE Team
QNX Software Systems

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

Best way to send a patched CDT?

2009-12-07T07:32:36Z

Hi,

I'm trying to find the most efficient way to send a patched CDT to someone.

Sending all plugins is kind of big and I'd like to avoid it.

If I build a single plugin, can the recipient manually replace the plugin in a nightly build zip file?

Thanks for any suggestions

Marc

Marc Khouzam
Software Designer, Methods and Tools

Ericsson Canada Inc

EMC/Q
8500 Decarie Blvd.
H4P 2N2, Mont-Royal, Qc, Canada
www.ericsson.com

Office: +514 345 7900 x42350
Fax: +514 345 6159
Mobile: +514 951 7191
Email: Marc.Khouzam@...

Ce courriel est confidentiel et uniquement destiné à son ou ses destinataires. Il est défendu de le consulter, de l'utiliser, de le dévoiler ou de le diffuser sans autorisation. Si ce message vous est parvenu par erreur, merci d'en aviser l'expéditeur par retour de courrier et de le détruire sans le divulguer. Un courriel et ses pièces jointes peut être sans autorisation corrompu, interrompu, amendé, altéré et infecté. L'entreprise ne reçoit et n'envoie de courriel qu'avec l'entente qu'elle n'est responsable d'aucune corruption, interception, modification, altération, infection ou conséquence possible.

This communication is confidential and intended solely for the addressee(s). Any unauthorized review, use, disclosure or distribution is prohibited. If you believe this message has been sent to you in error, please notify the sender by replying to this transmission and delete the message without disclosing it. Thank you. E-mail including attachments is susceptible to data corruption, interruption, unauthorized amendment, tampering and viruses, and we only send and receive e-mails on the basis that we are not liable for any such corruption, interception, amendment, tampering or viruses or any consequences thereof.

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