Summary: | [9] Visibility, accessibility, observability of modules in the UI | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Stephan Herrmann <stephan.herrmann> |
Component: | UI | Assignee: | JDT-UI-Inbox <jdt-ui-inbox> |
Status: | NEW --- | QA Contact: | |
Severity: | enhancement | ||
Priority: | P3 | CC: | daniel_megert, sarika.sinha |
Version: | 4.7.1a | ||
Target Milestone: | --- | ||
Hardware: | PC | ||
OS: | Linux | ||
See Also: | https://bugs.eclipse.org/bugs/show_bug.cgi?id=526833 | ||
Whiteboard: | |||
Bug Depends on: | 526054 | ||
Bug Blocks: |
Description
Stephan Herrmann
2017-10-31 10:23:25 EDT
ideally for 4.7.2, not sure that's feasible, though. Obviously too late for 4.7.3, but ... @Dani, @Noopur, do you want to comment on this proposal / discuss it in your next call? (In reply to Stephan Herrmann from comment #0) > With these options on the table, I'm proposing the following: > * In the Build Path dialog: > - show only observable modules (after filtering) > * Module Contents dialog naturally shows all modules > * Package/Project Explorer > - show only modules read by the current module > > Since the last change may be undesired for some users/use cases, I could > think of a preference that lets you choose among the three levels. More details above. (In reply to Stephan Herrmann from comment #2) > Related question: How do we handle types with access restrictions in Open > Type, completion etc.? Do we happily advise users to use types that they > should not use, or do we have a means to hold back those types? (I haven't > checked). Take a look at the 'Type Filters' preference page. I am definitely against filtering the Open Type dialog. I could imagine that for Content Assist, Quick Assist/Fix and other things we treat modules like bundles where the types are filtered and then we offer a Quick Fix to add the module. The problem is with modules that are part of the JDK: the behavior would change as types would not be found instead of finding the type and adding the import automatically. I'm not yet sure what visibility you mean with regards to the Package Explorer. Can you give an example? (In reply to Dani Megert from comment #3) > (In reply to Stephan Herrmann from comment #2) > > Related question: How do we handle types with access restrictions in Open > > Type, completion etc.? Do we happily advise users to use types that they > > should not use, or do we have a means to hold back those types? (I haven't > > checked). > > Take a look at the 'Type Filters' preference page. Great, we could then add two more options: [X] Hide not-exported types [ ] Hide types from modules that are not read by the current module Defaults as indicated. If you still use a 'problematic' type, quick fix for the first would add --add-exports, quick fix for the latter would add 'requires'. > I'm not yet sure what visibility you mean with regards to the Package > Explorer. Can you give an example? I was thinking of the children of the JRE System Library node. This set could be large, medium or small: (1) All modules contained in JDK (2) Similar to (1) but with --limit-modules applied as a filter. (3) Only (the transitive closure of) those modules that are read by the current module. IMHO, (1) is just unnecessarily overwhelming. In particular (3) would much better resemble what we have in "* Dependencies" containers (PDE/Maven ...). (In reply to Stephan Herrmann from comment #4) I think we have to distinguish between JDK modules and others. "others" should be treated like PDE treats bundles, i.e. only show what's specified. Also, types from those would not appear automatically, but there would be Quick Fixes to add the module. Open Type would show them. For JDK modules we would show all and content assist would show their types. We can then add a filter (off by default) to hide unused JDK modules in the explorers. > Great, we could then add two more options: > [X] Hide not-exported types > [ ] Hide types from modules that are not read by the current module The first option makes sense. The second one would be unnecessary in my opinion if we make the distinction between JDK and other modules. WDYT? Moving it to M7. |