[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [ide-dev] Ctrl-1 driven development
|
Thanks Konstantin!
What about the "pure" SDK builds? It includes ant editor but not xml editor. Which product is responsible for adding xml editor to SDK?
Am 19. Oktober 2015 18:58:30 MESZ, schrieb Konstantin Komissarchik <konstantin.komissarchik@xxxxxxxxxx>:
>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,
--
Kind regards,
Andrey Loskutov
http://google.com/+AndreyLoskutov