Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ide-dev] what about doing less?

> So as another crazy idea, we could make the Platform (plus Marketplace
client) the 
> default download, and focus on making it easy to build the IDE that's
right for you 
> from there (one part of that could be the changes to the Marketplace
mentioned by 
> Marcel in the other thread).

This sort of approach is something that a few power users would appreciate,
but a typical user is just not interested in finely tuning their IDE
composition. I have seen too many frustrated questions from users regarding
why their Eclipse doesn't understand XML files (for instance), when Netbeans
has no issue with them. No amount of improvements to Eclipse Marketplace is
going to make users feel good about having to manually pick the technologies
that they want to use and then hope that they install without issues.

Rather than trying to ignore performance issues by including less, a good
item for the IDE working group to tackle is interop between projects when
many projects are installed concurrently. There are performance issues that
are not evident when only a few plugins are installed. There are UI
pollution issues. Like, why do we need a dozen views to show external
resources, like app servers, databases, source repos, task repos, etc. when
other IDEs can get away with a single view.

- Konstantin


-----Original Message-----
From: ide-dev-bounces@xxxxxxxxxxx [mailto:ide-dev-bounces@xxxxxxxxxxx] On
Behalf Of Fabian Steeg
Sent: Friday, October 25, 2013 3:23 PM
To: Discussions about the IDE
Subject: Re: [ide-dev] what about doing less?

Hi,

I really like the general idea of doing less. I think a lot of grief around
Eclipse today is rooted in one of its actual strengths: a large, open
ecosystem.

Some like using advanced tools, and gladly work around their bugs and
limitations, but others prefer to stick to a rock solid text editor and the
terminal instead of using a feature rich editor that hangs while you're
typing. So why not give people that option?

On my current machine, the latest stable Platform build (4.4M2) starts up in
5 seconds something. That's not quite the 2 seconds mentioned by Martin yet,
but it's pretty close, and it's a start. As an easily achievable goal, we
could avoid adding more to that than really required by a given user. And
this is not just about startup time, but overall user experience, like tools
running background tasks etc.

So as another crazy idea, we could make the Platform (plus Marketplace
client) the default download, and focus on making it easy to build the IDE
that's right for you from there (one part of that could be the changes to
the Marketplace mentioned by Marcel in the other thread).

The open platform and focussed tools that made Eclipse great 10 years ago
are still here, but maybe seeing them has become more difficult over the
years, and is almost impossible for new and casual users today.

Cheers,
Fabian

On 24.10.2013, at 08:57, Max Rydahl Andersen <manderse@xxxxxxxxxx> wrote:

> On Wed, Oct 23, 2013 at 11:20:00AM +0200, Mickael Istria wrote:
>> On 10/23/2013 09:38 AM, Max Rydahl Andersen wrote:
>>> Dart editor "solves" it by removing anything but Dart required
dependencies.
>> FWIW, It's already what Tycho does with tycho-surefire-plugin by default:
it generates the minimal application for a test to run. So we don't need
anything new to have something similar working.
> 
> Not following why that is relevant ? 
> Tycho's minimal application is rarely actually usable by users because 
> it doesn't take into account add-ons that aren't related to your specific
tests.
> 
>>> I think for this specific issue (performance) putting together
plan/resources to revive or reimplement focus on performance would help
alot.
>> Performance tests by themselves are generally a bit tricky to analyze,
but coupling them with a profiler (yourkit-maven-plugin) could make them
much more relevant.
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=420149
> 
> Eclipse already have or at least had plenty of performance tests which
junit output usecase specific performance numbers instead of more generic
profiler output.
> 
> There were tests for "opening workspace", "load of eclipse", import of 
> project etc. which were then tracked to not have to big of a % difference
over time.
> 
> Not saying having easy access to profiler data but doing it 
> generically will probably not solve end-user problem faster IMO.
> 
> /max
> 
>> --
>> Mickael Istria
>> Eclipse developer at JBoss, by Red Hat <http://www.jboss.org/tools> 
>> My blog <http://mickaelistria.wordpress.com> - My Tweets 
>> <http://twitter.com/mickaelistria>
> 
>> _______________________________________________
>> ide-dev mailing list
>> ide-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/ide-dev
> 
> _______________________________________________
> ide-dev mailing list
> ide-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ide-dev

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



Back to the top