JakeStanger/ironbar

Fork 0

mirror of https://github.com/JakeStanger/ironbar.git synced 2026-07-11 06:15:21 +01:00

[GH-ISSUE #1259] Popups can't be displayed if they exceed monitor height/width #8809

New issue

Open

opened 2026-05-23 03:54:25 +01:00 by JakeStanger · 3 comments

JakeStanger commented

2026-05-23 03:54:25 +01:00

Owner

Originally created by @postsolar on GitHub (Nov 25, 2025).
Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/1259

Describe the bug

This is a regression, not sure how recent.

Popups won't display if their content exceeds monitor's height or width. This applies to (at least) the modules Custom and Clipboard.

To reproduce
Steps to reproduce the behavior:

{
  "name": "bar1",
  "start": [
    {
      "type": "custom",
      "name": "bindmode-hints",
      "bar": [
        {
          "type": "button",
          "on_click": "popup:toggle",
          "widgets": [
            {
              "type": "bindmode"
            }
          ]
        }
      ],
      "popup": [
        {
          "label": "#bindmode-hints",
          "type": "label"
        }
      ]
    }
  ]
}

ironbar var set bindmode-hints "$(seq 100)"
Click popup
Observe popup wont open
ironbar var set bindmode-hints "$(seq 10)"
Click popup
Observe popup would open

Same for exceeding monitor width.

Expected behavior

Not sure if it should be:

Displayed and just exceed the monitor (previous behavior)
Displayed but clipped
Displayed but wrapped in a ScrolledWindow

I didn't think it through yet. I guess as a quick initial fix just exceeding (previous behavior) is fine.

System information:

Distro: NixOS
Compositor: Hyprland
Ironbar version: current master @ 7a73438

Configuration

Additional context

Seems to be related to GTK4 rewrite and also #1248

Screenshots

Originally created by @postsolar on GitHub (Nov 25, 2025). Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/1259 **Describe the bug**  This is a regression, not sure how recent. Popups won't display if their content exceeds monitor's height or width. This applies to (at least) the modules Custom and Clipboard. **To reproduce** Steps to reproduce the behavior: ```json { "name": "bar1", "start": [ { "type": "custom", "name": "bindmode-hints", "bar": [ { "type": "button", "on_click": "popup:toggle", "widgets": [ { "type": "bindmode" } ] } ], "popup": [ { "label": "#bindmode-hints", "type": "label" } ] } ] } ``` 1. `ironbar var set bindmode-hints "$(seq 100)"` 2. Click popup 3. Observe popup wont open 4. `ironbar var set bindmode-hints "$(seq 10)"` 5. Click popup 6. Observe popup would open Same for exceeding monitor width. **Expected behavior**  Not sure if it should be: - Displayed and just exceed the monitor (previous behavior) - Displayed but clipped - Displayed but wrapped in a ScrolledWindow I didn't think it through yet. I guess as a quick initial fix just exceeding (previous behavior) is fine. **System information:** - Distro: NixOS - Compositor: Hyprland - Ironbar version: current master @ [7a73438](https://github.com/JakeStanger/ironbar/commit/7a73438113121e2c127436c1084da50c4ec68f1f) **Configuration**  **Additional context**  Seems to be related to GTK4 rewrite and also #1248 **Screenshots**

JakeStanger added the

labels

2026-05-23 03:54:25 +01:00

JakeStanger commented

2026-05-23 03:54:25 +01:00

Author

Owner

@JakeStanger commented on GitHub (Nov 25, 2025):

Hm, this behaviour seems to come from GTK4 directly - the popover widget is told to popup but simply does not, and nothing's created in the widget tree.

I can't find anything about this in the docs or any open issues, other than potentially this: https://gitlab.com/inkscape/inkscape/-/issues/5870

Is this a scenario you're hitting often? It feels like if popups are getting that big, there's another issue at hand anyway.

@JakeStanger commented on GitHub (Nov 25, 2025): Hm, this behaviour seems to come from GTK4 directly - the popover widget is told to popup but simply does not, and nothing's created in the widget tree. I can't find anything about this in the docs or any open issues, other than potentially this: https://gitlab.com/inkscape/inkscape/-/issues/5870 Is this a scenario you're hitting often? It feels like if popups are getting that big, there's another issue at hand anyway.

JakeStanger commented

2026-05-23 03:54:25 +01:00

Author

Owner

@postsolar commented on GitHub (Nov 25, 2025):

Normally I never hit it. Just noticed it when testing Clipboard module.

But this would happen to, AFAIU, any module if the user has it unconfigured and module provides no defaults (off the top of my head: at least clipboard #1050, volume, bluetooth #1245).

I think checking for monitor width/height and force-adding a ScrolledWindow (non-configurable) is a sane default for any module, less confusing for sure.

@postsolar commented on GitHub (Nov 25, 2025): Normally I __never__ hit it. Just noticed it when testing Clipboard module. But this would happen to, AFAIU, any module if the user has it unconfigured and module provides no defaults (off the top of my head: at least clipboard #1050, volume, bluetooth #1245). I think checking for monitor width/height and force-adding a ScrolledWindow (non-configurable) is a sane default for any module, less confusing for sure.

JakeStanger commented

2026-05-23 03:54:25 +01:00

Author

Owner

@JakeStanger commented on GitHub (Nov 25, 2025):

It sounds like that would be the sensible approach. I'm not regarding this as a blocker for the port, and I'm treating it as a low priority issue, but if you want to tackle this yourself go for it.

I think it probably makes sense to tackle the modules first, in that they should have sensible defaults that prevent this from happening in the first place. The clipboard module, for example, should probably truncate text (at least vertically) before it becomes a problem.

@JakeStanger commented on GitHub (Nov 25, 2025): It sounds like that would be the sensible approach. I'm not regarding this as a blocker for the port, and I'm treating it as a low priority issue, but if you want to tackle this yourself go for it. I think it probably makes sense to tackle the modules first, in that they should have sensible defaults that prevent this from happening in the first place. The clipboard module, for example, should probably truncate text (at least vertically) before it becomes a problem.