Skip to content

UI/Layout issues #162

Open
Open

Description

@Luro02

The code uses swing for ui elements like IntelliJ does.

In swing a LayoutManager decides how widgets are supposed to be displayed, depending on how much space is visible. Swing itself provides a lot of different layout managers to choose from, making it overwhelming. This library uses MigLayout for this, which uses a combination of string properties on the constructor and the rows to define how widgets should be laid out.

Problems with the current code

Each UI element that uses a panel defines its own MigLayout. Some UI elements do not flow/scale correctly, and many layouts use the same constraints.

You can observe broken layouts in for example the panel on the right where you start a new submission. When you start resizing the panel, a scrollbar will appear, instead of the individual elements being shrunk.

Another example is the button panel, which uses a fixed number of buttons in a row, instead of the UI adjusting the number of buttons in a row based on the available width. These are all minor, but they add up. Ideally we would have some kind of Flex Layout like in CSS and many other modern UI frameworks.

Another issue is that MigLayout is complicated and difficult to understand/get it to work the way you want it to. Every time I try to fix one of these minor UI issues, it ends up in a huge fight with me trying to coerce MigLayout to work the way I want it to.

Solutions

I think my time could be better spent looking for alternatives that bundle the awful stuff or replace it altogether.

1. Custom LayoutManager

While looking at other IntelliJ plugins, I noticed that SonarLint defines it's own layout manager called FlowWrapLayout. They only use it for the filter panel, but I think this layout could be applied for most panels.

Another reference could be whatever the IntelliJ UI DSL is using as layoutmanager. The behavior is described here, it sounds promising.

2. Rewrite all panels in Kotlin with the IntelliJ DSL

I obviously don't want to do that, because it will end up in the plugin becoming mostly kotlin, and this sounds like a huge amount of work.

3. Use jetpack compose

I haven't looked too far into it, but there is a template for a plugin that uses Jetpack Compose, again this would involve porting most UI elements to kotlin and rewriting the code.

4. Find some library that does the layout manager stuff and just works

Ideally, someone has already written a solution, and it only has to be found. Will have to look some more into potential alternatives.

Activity

  1. Luro02 commented on Nov 1, 2025

    @Luro02
    CollaboratorAuthor

    From what I researched, a one layout manager for everything seems to be a unicorn (will be difficult to find).

    How should the UI behave?

    Minimum behavior

    Each component has three properties for size:

    1. The minimum,
    2. preferred
    3. and maximum size.

    By default components should try to expand to use up most of the space. Depending on the layout, one may be fixed and another can be dynamic. For example in a form, the label text would be mostly fixed and the input field should expand to occupy most of the space.

    Here it would be important that the fixed components should first be expanded to their preferred size, then the dynamic ones should grow?

    If the available space shrinks, the components should adapt to it. Effectively the inverse of the expansion.

    Ideal behavior

    • TODO: When to wrap instead of expanding?
    • TODO: When to have scroll bars? Maybe try to do the UI without scrollbars for the most part?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions