3 ms·

>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

>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?

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?