Let's back up here for a moment and let me state the obvious.
We are discussing issues and proposals on at least three different levels: performance improvements, bugs, and usability/UI issues. All these areas indeed deserve improvements and there is not a single item that will solve all issues users complain about.
But what's the point of discussing startup times or other improvements in a yes/no fashion? It feels rather like an interesting mental exercise of a few (including me myself) than a real attempt to change things.
All discussions without any actions taken are simply a useless (how is the image viewer thread going. Is it dead or is something going on behind the scenes?).
Yatta signalized they would be interested in joining a working group and help shaping improvements in JDT. I think these are the statements we should be looking for. There are enough sites out there that tell us what's wrong with Eclipse. IMHO they don't need to be repeated on this list.
See you at the IDE BoF [1] - hopefully with a bit more in our pockets than ideas how someone could fix Eclipse on code level.
– Marcel
My point is that will not work. The user reaction is not going to be
positive. A common description of Eclipse is already "some assembly
required" while other IDEs work out of the box. Turning "some assembly" into
"a lot of assembly" isn't going to improve user perception of Eclipse.
- Konstantin
-----Original Message-----
From: ide-dev-bounces@xxxxxxxxxxx [mailto:ide-dev-bounces@xxxxxxxxxxx] On
Behalf Of Fabian Steeg
Sent: Friday, October 25, 2013 5:42 PM
To: Discussions about the IDE
Subject: Re: [ide-dev] what about doing less?
I also prefer a feature rich IDE, and I'm happy enough with some parts of
Eclipse to view the others as challenges on the way to the ultimate IDE. So
personally, I totally agree. It just bugs me that people seem to hate
Eclipse for what it's trying to be, instead of loving it for what it is and
looking forward to what it might become. The things that really shine and
attract users and contributors seem to get missed. The platform nature,
customizability, and plugin ecosystem are some of these things, so maybe
it's better to actively get users into that, instead of trying to hide it.
Cheers,
Fabian
On 26.10.2013, at 00:38, Konstantin Komissarchik
<konstantin.komissarchik@xxxxxxxxxx> wrote:
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
_______________________________________________
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
|
