RFR: 8294148: Support JSplitPane for instructions and test UI

Alexey Ivanov aivanov at openjdk.org
Wed Feb 14 19:16:03 UTC 2024


On Wed, 14 Feb 2024 18:47:55 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> This enhancement adds three methods to `PassFailJFrame.Builder`:
>> 
>> 1. **`splitUIRight`** to display test UI to the right of the instructions;
>> 2. **`splitUIBottom`** to display test UI to the bottom of the instructions;
>> 3. `splitUI`: a convenience method for a default split orientation, currently defaults to `splitUIRight`.
>> 
>> If UI of a test is simple, it's reasonable to embed the test UI into the instruction UI. In this case, there's only one frame the tester will be interacting with.
>> 
>> The implementation is similar to that of `testUI` provided under [JDK-8294156](https://bugs.openjdk.org/browse/JDK-8294156). The `splitUI-` method accept a reference to `PanelCreator` interface. Instead of creating an entire frame, you create only a component, usually a `JPanel` or `Box`, which contains all the test UI.
>> 
>> For example,
>> 
>> 
>>         PassFailJFrame.builder()
>>                       .instructions("Instructions for the test")
>>                       .splitUI(() -> {
>>                           JPanel panel = new JPanel();
>>                           panel.add(new JButton("Click Me"));
>>                           return panel;
>>                       })
>>                       .build()
>>                       .awaitAndCheck();
>> 
>> 
>> In addition to it, there's an advanced `testUI` method which accepts `PanelCreator`; in this case the test UI is hosted in `JDialog` with the instruction frame being its owner. Because the test UI is in a modeless owned dialog, it always displays above the instruction frame, switch to the test app brings up both the instructions and test UI. I don't expect it'd be used often, yet it's easy to implement.
>
> test/jdk/java/awt/regtesthelpers/PassFailJFrame.java line 1229:
> 
>> 1227:          * @throws IllegalArgumentException if {panelCreator} is {@code null}
>> 1228:          */
>> 1229:         public Builder splitUI(PanelCreator panelCreator) {
> 
> Suggestion:
> 
>         public Builder splitUI(PanelCreator panelCreator, int splitUIOrientation ) {
> 
> 
> 
> Would it be easier if we use `splitUIOrientation` or an enum similar to [Position](https://github.com/openjdk/jdk/blob/b823fa44508901a6bf39795ab18991d055a71b4e/test/jdk/java/awt/regtesthelpers/PassFailJFrame.java#L191) to determine the split than have three different methods - `splitUI, splitUIRight & splitUIBottom`? And eliminate the private `splitUI()` and have the orientation logic within public `splitUI()`

I don't think so… I find the `Position` cumbersome too.

Using `JSplitPane.HORIZONTAL_SPLIT` or `JSplitPane.VERTICAL_SPLIT` in a public method of Builder exposes the internal detail that `JSplitPane` is used. What if we decide to implement it differently? After all, the UI could be placed into a horizontal or vertical [`Box`](https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/javax/swing/Box.html)? Passing an `int` as the orientation is not type-safe, we'll need to verify the parameter or let `JSplitPane` constructor do it.

An enum is type-safe but it's cumbersome to type:


splitUI(() -> new JPanel(), PassFailJFrame.SplitOrientation.HORIZONTAL)
// or
splitUI(() -> new JPanel(), JSplitPane.HORIZONTAL_SPLIT)

does not look as good to me as

splitUIRight(() -> new JPanel())

`-Right` explicitly conveys the chosen position and is much shorter than the above samples with `enum` or constants from `JSplitPane`.

Initially, I wanted to re-use `Position` but decided not to … for flexibility. Split UI could be combined with additional test UI windows… Not that I see a use case for such a use…

The three methods make the `Builder` more crowded for the sake of brevity of its usage in the test code. I expect it would be `splitUI` in majority of cases.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17845#discussion_r1489943955


More information about the client-libs-dev mailing list