Regarding inclusion of XML Editor in EPP packages, here is a run-down of which one include it. For ones that don’t, I have opened enhancement requests to consider adding it.
Included
Eclipse IDE for Java EE Developers
Eclipse IDE for Java Developers
Eclipse IDE for PHP Developers
Eclipse IDE for Java and DSL Developers
Eclipse IDE for RCP and RAP Developers
Eclipse IDE for Automotive Software Developers
Eclipse IDE for Java and Report Developers
Eclipse IDE for Parallel Application Developers
Not Included
Eclipse IDE for C/C++ Developers (https://bugs.eclipse.org/bugs/show_bug.cgi?id=480141)
Eclipse IDE for Eclipse Committers (https://bugs.eclipse.org/bugs/show_bug.cgi?id=480142)
Eclipse Modeling Tools (https://bugs.eclipse.org/bugs/show_bug.cgi?id=480143)
Eclipse for Testers (https://bugs.eclipse.org/bugs/show_bug.cgi?id=480144)
Eclipse for Scout Developers (https://bugs.eclipse.org/bugs/show_bug.cgi?id=480145)
It once again strikes me that the high number of minutely-differentiated packages isn’t actually helping our users. It certainly reflects the result of decentralized product planning, which is hurting our competitive position. This group could work towards encouraging packages with largely overlapping user profiles to merge.
For instance, a combined Java IDE could be the union of:
Eclipse IDE for Java EE Developers
Eclipse IDE for Java Developers
Eclipse IDE for Java and DSL Developers
Eclipse IDE for RCP and RAP Developers
Eclipse IDE for Java and Report Developers
Eclipse IDE for Eclipse Committers
Eclipse Modeling Tools
A combined C++ IDE could be the union of:
Eclipse IDE for C/C++ Developers
Eclipse IDE for Parallel Application Developers
What leads to proliferation of packages is projects getting rejected by owners of an existing package. We could consider moving the responsibility for defining what packages are produced and what they include to one of the councils. That doesn’t mean that every project that asks would get included, but should ensure better representation for all projects in the decision process. It would also provide an essential push-back for projects trying to use the EPP process as a promotional vehicle. For instance, I doubt that Scout is so widely used that it warrants inclusion in a package, let alone it’s own package.
Note that the download numbers can be deceptive as a measure of need. For instance, the long flat tail of the popularity graph currently floats at 23k to 27k level. This indicates that we are likely dealing with roughly 20k downloads initiated by automated actors that download all packages.
Thanks,
- Konstantin
From: Daniel Megert
Sent: Monday, October 19, 2015 8:27 AM
To: Discussions about the IDE
Subject: Re: [ide-dev] Ctrl-1 driven development
I finally caught up with that thread, which - like so often - heavily diverged from the initial and well-focused suggestion from Mickael :-)
> So an easy way to improve Eclipse IDE would be to add to the Ctrl+1 the operations that users likes in this very narrow context.
This suggestion in Mickael's initial e-mail is a very good one, and we can discuss which things to add via bug 480131. Please add your comments there.
The other mentionable topics I saw in that thread:
- XML Editor
Packages can decide to include this. Even CDT can do so. Hence, I do not consider this a big issue - maybe it should just be part of all packages these days. There is no need to restructure any projects or move code around.
- Install hell for our users
I totally agree with this. Even with EPP it is hard for a user to pick the right package, e.g. the 'Eclipse IDE for Java Developers' package contains the XML Editor but 'Eclipse IDE for Eclipse Committers ' does not. In our Eclipse Vision meetings from last year our hope was that Oomph (the new Eclipse installer) would help to fix this. So, maybe we need to push more on this. Another idea that we discussed in those meetings and was also mentioned in this thread is a hook, so that when a user opens a certain file and no editor is available, we suggest to install the corresponding (small) feature(s). I think the latter is definitely worth working on and could qualify for FEEP.
- Hard to know all our cool features
I like the idea of more aggressively advertising our IDE features on the web pages and especially on a combined IDE page. JDT is definitely willing to participate here, but only to provide the content and not the design. Like Doug and Ian, I don't think FEEP money would be good spent here.
Dani
From: Mickael Istria <mistria@xxxxxxxxxx>
To: "'Discussions about the IDE'" <ide-dev@xxxxxxxxxxx>, jdt-dev@xxxxxxxxxxx
Date: 14.10.2015 18:21
Subject: [ide-dev] Ctrl-1 driven development
Sent by: ide-dev-bounces@xxxxxxxxxxx
Hi all,
I've spent some times asking former Eclipse RCP developers now converted to the 300$/year IDE on what they thing are the best things that are missing in Eclipse IDE.
What they tell first is the quality of the "quick-fixes" in IntelliJ. But when you get into details, what makes the difference isn't really that IJ has editing/refactoring operations that Eclipse IDE doesn't have, but more that IJ shows the useful ones (and only the useful ones) on their Alt+Enter.
In Eclipse, a lot of operations are available under Source and Refactor context menu, but it's a lot of menus to browse, it takes a lot of time, mostly requires to use mouse, requires to read a lot of entries that are contextual to the editor but not to the active selection... It's complicated.
Eclipse has the very good Ctrl+1 menu, which is basically meant to host such small operations that are in the context of the selection in an editor. Eclipse IDE (precisely JDT UI) already shows a few relevant ones, but some other good ones are missing.
So an easy way to improve Eclipse IDE would be to add to the Ctrl+1 the operations that users likes in this very narrow context. If you get such an idea, please report it to JDT/UI and share it. I believe fixing that isn't a too difficult task, with no risk at all, and that it would provide much user satisfaction. It could even be a great topic for a hackathon.
I plan to make a more direct comparison of these quick-fixes one day (cannot be more precise, so don't wait for me if you're faster) and to come up with a list of the ones that are missing in Eclipse IDE to make this Ctrl+1 so efficent that user won't have to dig in the context-menu and will always get their favorite operation in a few keystrokes.
Cheers,
--
Mickael Istria
Eclipse developer at JBoss, by Red Hat
My blog - My Tweets_______________________________________________
ide-dev mailing list
ide-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ide-dev
