Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Are too many packages actually hurting Eclipse?

It's funny. The feature bloat and UI confusion mainly stems from projects that think they are the only thing installed and show their UI always and everywhere. That's why I am convinced we need a higher organization that watches these cross project issues and pushes for simplification. Again, the Uber package would be a way to show how bad things are.

From: Greg Watson <g.watson@xxxxxxxxxxxx>
Reply-To: Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
Date: Tuesday, 30 July, 2013 8:45 AM
To: Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
Subject: Re: [cross-project-issues-dev] Are too many packages actually hurting Eclipse?

On Jul 30, 2013, at 6:13 AM, Konstantin Komissarchik <konstantin.komissarchik@xxxxxxxxxx> wrote:

> so they are actually useful to end-users.
Actually, we have no evidence that users find packages useful. They download them because what else is there for them to do. Then if they are experienced, they know what’s included and how to install the missing pieces. If not, they thrash on forums wondering why Eclipse for Java Developers doesn’t come with an XML editor.

In the parallel computing community, we have plenty of evidence that the package is useful. We get lots of feedback that our all-in-one package is much preferred over having to install packages into Eclipse. Our users did this for years and it was a never ending source of complaints.

However, if the process was changed to downloading Eclipse, then when you first started Eclipse it displayed a screen that said something like "What would you like to use Eclipse for", then presented a list similar to the current list of packages, then our users would probably still be happy.

I wouldn't support the idea of creating a single download with the entire aggregated repository at all. Apart from being huge, it would contain many features that users would never use, but would add to the feature bloat and UI confusion. This is exactly the opposite of where we should be heading. Users have been saying for years that they want a simpler and more functional UI, so we should be focussing on how to make this happen.


Back to the top