| Re: [ide-dev] Java IDEs comparison |
I've been following this with great interest...some thoughts (sorry but I can't give the attribution to the author in most cases since there have been so many posts):
Functional Deficiencies: These are the various language (mostly content assist?) deficiencies that we have in comparison to IDEA. If we can't provide *necessary* functionality then we can't carp when someone chooses to use an IDE that gives them the required help. We should of course fix this but I wonder whether using oracle internals would place us a risk for being submarined at some point ?
Content Marketing: This is sort of where I came in; we're getting our butts handed to us here. We simply have no 'marketing' focus and it's been pointed out that developers are notoriously bad at doing this type of thing (otherwise they'd be marketing folks). I don't have an answer but it's still an issue...let's say we fix all of the 'functional deficiency' issues, how do we get the word out to non-eclipse users (they don't read the N&N). We're pretty good at (p)reaching to the converted but anybody that is truly interested in determining which IDE to start using can currently come to only one conclusion (not us).
UX Issues: OK, consistency counts and many approaches to help with this have been proposed; some way is needed to address this. I'm in favor of some 'Ready for EPP' program where packages are checked and not allowed into an EPP package unless some standards are met. Note that the decision of whether or not the organization producing a package wants to spend resources on this is theirs but I suspect that many would do so in order to gain the (much) higher visibility of being included in an EPP.
While the language protocol API may help things if used I'm concerned that the API just isn't up to providing the complete set of functionality given by the JDT so we'll either have to get the API extended (how responsive will MS be to our needs?) or the resulting editor(s) will appear somewhat crippled when compared to JDT/CTD.
Functionality Overload: All UI packages come with their own version of the kitchen sink; every possible command / view along with their own perspective. When we aggregate these we simply add them all to the 'appropriate' buckets which causes large menus and toolbars and a large number of views and perspectives (only a small percentage of which are actually used). We end up with a collection of kitchen sinks...
One way to handle this would be to allow some new set of preferences which would allow for 'hiding' lesser used Commands, Views and Perspectives from the UI. I use preferences to allow Oomph and the the like to provide different options to users of different levels.
Perspectives: I agree that the perspective paradigm may need a re-visit. I'd be fine with two myself; 'Development' and 'Debug'. However simply using perspective extensions to add all the new views into these perspectives would result in tab folders containing a large number of views. The current problem is that a view's visibility is one way; once opened they stay open. Perhaps we can look at adding some sort of 'visibleWhen' hook to allow views to come and go based on context (i.e. the language of the currently active editor).
Eric
Bruno Medeiros ---09/09/2016 01:28:36 PM---On 9 September 2016 at 15:24, Mickael Istria <mistria@xxxxxxxxxx> wrote: > Hi,
From: Bruno Medeiros <bruno.do.medeiros@xxxxxxxxx>
To: Discussions about the IDE <ide-dev@xxxxxxxxxxx>
Date: 09/09/2016 01:28 PM
Subject: Re: [ide-dev] Java IDEs comparison
Sent by: ide-dev-bounces@xxxxxxxxxxx