Repository navigation
UI/Layout issues #162
Description
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
Luro02 commentedon Nov 1, 2025
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:
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