Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

User:Wmills.ti.com

Bill Mills @ Texas Instruments

I am involved in Linux development. I am mostly interested in Eclipse from a C cross development POV. I am interested in Base Eclipse + CDT and also with plug-ins from Yocto, Android, and TI's Code Composer Studio. (I am not a member of the CCS team.)

However, I believe the strength of Eclipse as a Cross development IDE comes from the fact that it can also be the IDE for Host development. I am a great believer in developing software so it can run on the desktop and deployed to the target system.

I also use Eclipse for my own Java development and am interested in exploring Eclipse for JavaScript and Python development and for structured data editing such as XML, etc.

I am interested in efforts that imporove Eclipse in the following areas:

  • easier to use for new users (Students & more casual programmers)
  • work better on smaller screens like netbooks
  • work better on limited resource machines like netbooks
  • make Eclipse more flexible to adapt to a projects existing structure instead of dictating its own
  • have Eclipse sync with and adapt to a file structure instead of insisting that it create the structure

Rants

In general I have a love/hate relationship with Eclipse. I do like a GUI IDE at times but I don't want it to rule my project. I like Eclipse OK once a project is setup but I find getting a project setup incredibly frustrating. Importing an existing project into Eclipse is hard because Eclipse has a very rigid view of how a project should be structured. Creating a new project is hard because of the myriad choices of wizards and options. The choice is not the issue, the problem arises because the wizards hide what they are doing and each one is so specialized to a specific scenario. I find I need to try many of them out and look at the result until I find the one that does what I want. A simple solution would be to add a paragraph of text to the start of each wizard that explained exactly what it will do and what are the assumptions it makes.

For example:

I wanted to bring the readmetool example in from a jar file. First question: Do I use new or import? New "imports' from CVS but not jar, so I guess its import. Import from archive only imports to a project already created. Import existing project only imports if the jar file contains a .project file (which the readmetool source jar does not. Back to New. If I create a "new" java project on top of my manually created directory contents it sees that and adapts to it. However, New plugin project does not seem to do this. What are the important bits that make a project a plugin vs a java project. Can I create these manually? In the end I used the new wizard to create a plugin project from a template and then used external tools to extract the jar file to a different directory and matched the structure. This reverse engineering was easier and less frustrating than exploring the N1*N2 possibilities of the wizards with most being blind alleys.

Back to the top