5 ms·

Aside from bugs and driver issues, Wayland has some unfortunate design limitations. For example, Dear ImGui multi-viewports don't work because "Wayland doesn't

by TillE 3y ago

Aside from bugs and driver issues, Wayland has some unfortunate design limitations. For example, Dear ImGui multi-viewports don't work because "Wayland doesn't let application read or write windows positions." https://github.com/ocornut/imgui/wiki/Multi-Viewports https://github.com/ocornut/imgui/wiki/Multi-Viewports This is a feature available on Windows, macOS, and of course X11. Making choices like this means desktop Linux becomes even more of a weird island that nobody wants to support.

wtallis 3y ago
Why can't ImGui applications do multiple windows while leaving the positioning up to somebody else (the user or their window manager)?
- kevingadd 3y ago
  How is the window manager going to handle the positioning in a scenario like multi-viewport? The user already conveyed their intent by dragging a window out of the application's viewport to create a new viewport, and Wayland is prohibiting the application from obeying the user.
  - wtallis 3y ago
    I'm just trying to understand why ImGui needs to read and write window positions, because it's not immediately obvious from that paltry description. It sounds like you're describing a use case where it needs to be able to set the position of a new window relative to an existing window. So APIs to read the position of the current window and write the position of the new window are probably what they're looking for—though I can readily imagine narrower APIs to handle that use case. Does that sound to you like an accurate explanation of their complaint? (None of the above explains why ImGui cannot in the interim accept a janky experience where newly created child windows pop up wherever the window manager puts them, as commonly happens for transient dialog boxes. This seems like a nice to have feature, but not a complete showstopper.)
    - Arnavion 3y ago
      AFAICT from looking at the imgui wiki page and the examples in the OP of the wayland-protocols MR, it seems to be entirely that either these libraries have existing API that allowed setting the window coordinates and thus they want to be able to continue providing them, or these applications (like gimp) want to be able to recreate those windows at their previous positions after the application is closed and restarted. It's also worth noting that that imgui wiki link says the feature doesn't work well in X11 either, though I didn't read the linked issue for what exactly is broken there.
    - vasvae3 3y ago
      You have some good examples here https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m...
    - kevingadd 3y ago
      The position being wrong isn't the only issue - if you can't programmatically reposition a window, you have to break the user's drag gesture into two drag gestures, one to 'pop out' the window and then the user has to find it and grab it again to move it.
      - wtallis 3y ago
        That's about what happens every time I tear out a browser tab. It's not perfect, but definitely not the showstopper ImGui seems to regard it as.
- jwells89 3y ago
  Imagine a program that utilizes several separate windows for palettes. If the program has no way to specify where to place those palettes, the user is going to be presented with a ton of palettes piled on top of their document window and that they’ll have to sort that out themselves, rather than a neatly organized immediately usable workspace. That’s not really an acceptable user experience no matter how you slice it. Multi-screen situations is another place where this comes up, which includes not just multi-monitor desktop setups but things like foldable devices, and it can be useful to have functionality that lets the user designate a screen for a particular function (for instance, putting sliders and knobs for audio production software on a touchscreen) and have it available regardless of the compositor the user is using.
  - Arnavion 3y ago
    >Imagine a program that utilizes several separate windows for palettes. One way this can work is: When the program starts up on first install with a brand new config, all those palettes are part of the program window. Then as the user decides to undock them one by one, they are removed from the main program window and a new window is drawn containing that palette. So the user isn't presented with "a ton of palettes"; they get them one at a time and can move them as they wish. The rest of that (maintaining their position next to the main window, restoring them when the application is restarted) would be solved by a protocol that allowed relative positioning, which was already suggested in the wayland-protocols MR discussion. >it can be useful to have functionality that lets the user designate a screen for a particular function (for instance, putting sliders and knobs for audio production software on a touchscreen) This can already work today if the compositor provides a way to do it, as long as the application tags such a window with some unique `app_id` or `title`. For example in sway the user can write config rules to match windows based on such criteria and run position etc commands on them. I assume KDE also has something like this because I remember it having a way to match windows using X properties in the KDE 4 days.
    - mrkstu 3y ago
      Of course the order of operations here was to break everything first and then start addressing the issues they feel like addressing when and if they get around to it. Kind of a real FU way of trying to move things forward...

by TillE 3y ago

wtallis 3y ago

Why can't ImGui applications do multiple windows while leaving the positioning up to somebody else (the user or their window manager)?

kevingadd 3y ago
How is the window manager going to handle the positioning in a scenario like multi-viewport? The user already conveyed their intent by dragging a window out of the application's viewport to create a new viewport, and Wayland is prohibiting the application from obeying the user.
- wtallis 3y ago
  I'm just trying to understand why ImGui needs to read and write window positions, because it's not immediately obvious from that paltry description. It sounds like you're describing a use case where it needs to be able to set the position of a new window relative to an existing window. So APIs to read the position of the current window and write the position of the new window are probably what they're looking for—though I can readily imagine narrower APIs to handle that use case. Does that sound to you like an accurate explanation of their complaint? (None of the above explains why ImGui cannot in the interim accept a janky experience where newly created child windows pop up wherever the window manager puts them, as commonly happens for transient dialog boxes. This seems like a nice to have feature, but not a complete showstopper.)
  - Arnavion 3y ago
    AFAICT from looking at the imgui wiki page and the examples in the OP of the wayland-protocols MR, it seems to be entirely that either these libraries have existing API that allowed setting the window coordinates and thus they want to be able to continue providing them, or these applications (like gimp) want to be able to recreate those windows at their previous positions after the application is closed and restarted. It's also worth noting that that imgui wiki link says the feature doesn't work well in X11 either, though I didn't read the linked issue for what exactly is broken there.
  - vasvae3 3y ago
    You have some good examples here https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/247 https://gitlab.freedesktop.org/wayland/wayland-protocols/-/m...
  - kevingadd 3y ago
    The position being wrong isn't the only issue - if you can't programmatically reposition a window, you have to break the user's drag gesture into two drag gestures, one to 'pop out' the window and then the user has to find it and grab it again to move it.
    - wtallis 3y ago
      That's about what happens every time I tear out a browser tab. It's not perfect, but definitely not the showstopper ImGui seems to regard it as.
jwells89 3y ago
Imagine a program that utilizes several separate windows for palettes. If the program has no way to specify where to place those palettes, the user is going to be presented with a ton of palettes piled on top of their document window and that they’ll have to sort that out themselves, rather than a neatly organized immediately usable workspace. That’s not really an acceptable user experience no matter how you slice it. Multi-screen situations is another place where this comes up, which includes not just multi-monitor desktop setups but things like foldable devices, and it can be useful to have functionality that lets the user designate a screen for a particular function (for instance, putting sliders and knobs for audio production software on a touchscreen) and have it available regardless of the compositor the user is using.
- Arnavion 3y ago
  >Imagine a program that utilizes several separate windows for palettes. One way this can work is: When the program starts up on first install with a brand new config, all those palettes are part of the program window. Then as the user decides to undock them one by one, they are removed from the main program window and a new window is drawn containing that palette. So the user isn't presented with "a ton of palettes"; they get them one at a time and can move them as they wish. The rest of that (maintaining their position next to the main window, restoring them when the application is restarted) would be solved by a protocol that allowed relative positioning, which was already suggested in the wayland-protocols MR discussion. >it can be useful to have functionality that lets the user designate a screen for a particular function (for instance, putting sliders and knobs for audio production software on a touchscreen) This can already work today if the compositor provides a way to do it, as long as the application tags such a window with some unique `app_id` or `title`. For example in sway the user can write config rules to match windows based on such criteria and run position etc commands on them. I assume KDE also has something like this because I remember it having a way to match windows using X properties in the KDE 4 days.
  - mrkstu 3y ago
    Of course the order of operations here was to break everything first and then start addressing the issues they feel like addressing when and if they get around to it. Kind of a real FU way of trying to move things forward...