4 ms·

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

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...
  - Arnavion 3y ago
    Yes, normally when you make a new thing you start with a small base and then gradually make changes to it, instead of adding the whole kitchen sink from the start and defeating the purpose of making the new thing in the first place.
    - Ferret7446 3y ago
      Well, that's how you go about relearning old lessons. It reminds one of Chesterton's fence, where the ignorant tear down the fence and after much suffering end up building the fence back up.
    - Novosell 3y ago
      Gradually is fine and all, but wayland is 15 years old.
- mort96 3y ago
  > 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. What if the program doesn't want a single-window mode? Or what if the work to support a single-window mode isn't considered to be worth it when the only people who care are the 0.01% of users who are on Linux and care that the program isn't Wayland-native?
wtallis 3y ago
> That’s not really an acceptable user experience no matter how you slice it. What you're describing is what happens in most desktop environments any time you open multiple document windows at once. Why is it so much more unacceptable for this to happen to tool palette windows? Yeah, it's obviously not good behavior, but it's prevalent enough that it's clearly a manageable problem for end users and generally preferable to refusing to support multiple windows at all.
- jwells89 3y ago
  macOS will actually cascade multiple document windows opened at once so long as the dev has taken a moment to flag the windows as document windows, which still isn’t amazing but at least ensures that all opened windows are visible.
  - wtallis 3y ago
    I was assuming that Wayland window managers would also cascade multiple windows. In your experience, do they not do that?

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...
- Arnavion 3y ago
  Yes, normally when you make a new thing you start with a small base and then gradually make changes to it, instead of adding the whole kitchen sink from the start and defeating the purpose of making the new thing in the first place.
  - Ferret7446 3y ago
    Well, that's how you go about relearning old lessons. It reminds one of Chesterton's fence, where the ignorant tear down the fence and after much suffering end up building the fence back up.
  - Novosell 3y ago
    Gradually is fine and all, but wayland is 15 years old.
mort96 3y ago
> 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. What if the program doesn't want a single-window mode? Or what if the work to support a single-window mode isn't considered to be worth it when the only people who care are the 0.01% of users who are on Linux and care that the program isn't Wayland-native?

wtallis 3y ago

> That’s not really an acceptable user experience no matter how you slice it. What you're describing is what happens in most desktop environments any time you open multiple document windows at once. Why is it so much more unacceptable for this to happen to tool palette windows? Yeah, it's obviously not good behavior, but it's prevalent enough that it's clearly a manageable problem for end users and generally preferable to refusing to support multiple windows at all.

jwells89 3y ago
macOS will actually cascade multiple document windows opened at once so long as the dev has taken a moment to flag the windows as document windows, which still isn’t amazing but at least ensures that all opened windows are visible.
- wtallis 3y ago
  I was assuming that Wayland window managers would also cascade multiple windows. In your experience, do they not do that?