Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ui-best-practices-working-group] [ide-dev] Working sets (WAS: Re: Java IDEs comparison)

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. 

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.

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. :)

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.

Anyway, there are probably too many ideas already in this thread. :)


Gunnar Wagenknecht

Back to the top