|
Same here, btw. My primary use case for working sets is to have grouping in Package Explorer.
So -related but other topics- why keeping various inconsistent explorers, where we could all align on the Project Explorer (and its excellent CNF) ? Even if it's not about removing them, every perspective should
question whether the Project Explorer would be better than a *DT specific one.
Same story as with a lot of other things at Eclipse:
Today: there are three ways of doing things in Eclipse. Three?! Ridiculous! We need to develop one universal way that covers everyone's use case.
Soon: There are four ways of doing things in Eclipse.
Jokes aside, I never started using the Project Explorer. It was too buggy in the beginning and UX was better in the existing views (Navigator as well as Packages Explorer), which are still around today. It's probably a good idea to consolidate those things
in an Eclipse 5 release.
FWIW, CDT uses the Project Explorer and I often find myself working there on both C++ and Java projects at the same time. I really don’t think Java support is that far off from being good. We need to find out what’s left to do and try and get it done.
This leads to a common complaint I hear from any user who uses more than Java. Why do we have a Perspective per language? The silos you mention below have a lot to do with it but it really doesn’t make sense. When working on Code, I’d love to have a single
perspective that handles it all. We’ve managed to make that work with the Debug perspective. You’d think a Code perspective would be even easier. I’ll start a new thread on that when we get a chance to catch our breath.
Also keep in mind that - at least in the past - organizational structures contributed to the status quo, eg. project boundaries were team boundaries with delegated responsibilities: something was introduced at Platform, it was well adopted in JDT, less
well in WTP and likely not at all in other projects. Maybe it's possible to re-think the boundaries and giving people commit rights to everything in the IDE. Some really deserve it! It's a shame to see there enthusiasm at the Platform level being stopped by
unresponsive projects.
+1. That’s been discussed informally here and there. Having a single committer list for the entire IDE at Eclipse would help. But we’ll always have to deal with important projects that aren’t at Eclipse, like Pydev and Nodeclipse. We need to get better
at influencing anyway.
Why do I say Eclipse 5? Removing views, menus and actions is a breaking change. It's also time for a 5 from a marketing point of view .... the 4 series has its history. :)
I’m not sure that’s really breaking. But it certainly would be good to market all the good work we’ve been doing. The message isn’t getting out as it needs to.
However, we have to make a call with what's happening to e4 and the compatibility layer. A ton of plug-ins will be broken if we remove it. Is it work it? We already had the second product problem with e4. I do see the benefit of developing with a pure
e4 approach (DI to be precise) but it still feels half baked. Contributing via fragments feels brittle - might be because of lack of tooling and/or documentation. I find myself reading lot's of internal code just to discover if I can inject something or not.
Similar for other things. Tons of document/articles exist describing the 3.x approach and contributing via extension points.
For now, I don’t think it’s worth it. What we have now is working well enough IMHO. I’m not sure why e4 doesn’t work with the IDE Workbench, but I was pretty happy with how things were in e3. I’d be afraid to back out what e4 there is there though.
Anyway, there are probably too many ideas already in this thread. :)
Yes, feel free to create new threads. I think we need to be careful how many we have going in parallel. I had to ignore Outlook for a few hours today so I can get some other work done :).
Doug
|
