Usages: Add means to disable code preview

[pgifford]

Description

Add means to disable or hide code preview in Usages results.

Use case/motivation

I code on a monitor in portrait orientation.

Motivation for request

1. The code preview in Usages takes up over 2/3 of the window width covers about 50% of the horizontal extent of the results tree
2. The Usages code preview cannot be resized so it is not visible. When the divider is dragged as far as possible to the right, line numbers are still visible.
   • The Search Results code preview can be completely hidden by dragging the divider all the way to the right.
3. Usages code preview does not respect user preferences. Each invocation returns the divider to the default position which means I have to drag it back to the right to be able to read the results without having to scroll.
   • Once hidden (i.e. divider moved fully right) the Search Results code preview remains hidden even when NetBeans is closed and reopened.

NetBeans has been my daily driver for over 20 years and I have rarely wished for a code preview in usages (or search results). It should be an optional element and not forced upon everyone, especially when the implementation is in such a rough state.

Related issues

No response

Are you willing to submit a pull request?

No

[mbien]

point 3 was an oversight and should be fixed in master #8105, #8089

The preview toggle was intentionally left out and will be only added if it is also added to all windows which with similar functionality to keep things consistent. #7694 (comment) has a screenshot with some of the windows

[pgifford]

The preview toggle was intentionally left out and will be only added if it is also added to all windows which with similar functionality to keep things consistent.

Things are already inconsistent in the screenshot (depending on the window line numbers are in the results, the preview, and both) so what’s one more? 😁

You added the “Contribution welcome” label…what did you have in mind?

[mbien]

Things are already inconsistent in the screenshot (depending on the window line numbers are in the results, the preview, and both)

The search preview does not only have line numbers it also does not use the semantic layer in the preview panel since this would require a dependency from search API to the netbeans editor modules. Even if this is determined to be ok, it would have to be verified that this doesn't cause other problems, e.g cluster activations caused by browsing through search results - so it might not be worth it.

[matthiasblaesing]

For the record: I agree, that a toggle that makes it possible to switch previews off would be good. I also agree, that the consistency argument is moot, as the problem (forced preview) was added as a feature, so switching to the previous situation is IMHO a no-brainer (else the feature is an issue and should be reverted).

I think we should not blow up the consistency argument. It is good if the use-cases converge, but if it is not possible and just realises the orginally thought about switching option, I don't see a problem.

Now it only needs someone to implement.

[mbien]

Now it only needs someone to implement.

it already was implemented (for search) and dropped after discussion that such feature should be added to all semantically similar views. The duplicated code situation isn't great, adding a toggle after looking through all splitpanels-with-preview would certainly lead to more maintainable code, more UX consistency and overall less work than implementing it one by one over multiple releases in n different ways.

edit: at the very least it should be added for search and refactoring/inspection views in one go since users already expect search and usage to work and look the same

[neilcsmith-net]

The search preview does not only have line numbers it also does not use the semantic layer in the preview panel since this would require a dependency from search API to the netbeans editor modules.

That is of course the reason I've been getting frustrated that the search view doesn't support ctrl+click recently despite it never doing so! 😄

Direct dependency into the editor modules is of course not feasible. Enhancing the search SPI to allow custom result preview and/or seeing if this can be implemented via openide.text might be. I agree that cluster activations via the search window might be a problem to consider, although perhaps no more of an issue than flicking through the options dialog.

Incidentally, the kit lookup in the other views should possibly be via openide.text too? https://bits.netbeans.org/23/javadoc/org-openide-text/org/openide/text/CloneableEditorSupport.html#getEditorKit-java.lang.String-

[mbien]

Incidentally, the kit lookup in the other views should possibly be via openide.text too? https://bits.netbeans.org/23/javadoc/org-openide-text/org/openide/text/CloneableEditorSupport.html#getEditorKit-java.lang.String-

The other previews do something like this ((BaseTextUI) editorPane.getUI()).getExtComponent() to get the extended editor component (hidden behind utility methods). The editor kit does change fine but I don't think that a plain old JEditorPane can morph into the typical NB editor.

[neilcsmith-net]

Sure, I'm aware of that - that's the second step. The point was that unless an existing utility via openide.text will already achieve that for us (when available) then either an enhancement to the API there to do that and/or an SPI displayer that can handle it would be good.