| Summary: | Per-virtual-desktop tiling layouts | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Wyatt Childers <kdebugs.81do7> |
| Component: | Custom Tiling | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | ASSIGNED --- | ||
| Severity: | wishlist | CC: | ajbtz74o, arendjr, armoire.mountable405, arnav0872, buddha, chermnykh2001, david.perez.ingeniero, emmaleduartec, fort.malvery, gik-kbugs, godlike64, hey, ivanmsosnov, jeisom, jerky79, jsardid, juliohm, kde, kv3f5ves, nate, nisselommerde, notmart, oded, p.r.worrall, postix, s00ner, sam.fb3a1, tristanwhaley |
| Priority: | NOR | ||
| Version: | 5.27.0 | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| See Also: |
https://bugs.kde.org/show_bug.cgi?id=465937 https://bugs.kde.org/show_bug.cgi?id=466019 |
||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Wyatt Childers
2023-02-18 19:53:48 UTC
I find this especially important, since most tiling window managers (at least all that I know of) makes heavy use of virtual desktops, so that the experienced tiling user is even more likely to use them than a normal user. This is really important and it should do it per activities too! Seconded. Thirded! Would really, really love to have this feature. I would like to re-iterate Gemmstone's comment, it would be very beneficial to be able to save the arrangement of applications to specific tiles on specific virtual desktops, as well has having the ability to have different tile layouts for each virtual desktop. I would also like this feature. Changing my tiling layout in one activity should not change the layout in a different activity. O yes, bring that please. Especially now, when Plasma 6 API changes made all KWin scripts non working. The tiling setup is also the same in all activities. We might want to differentiate tilings in those at least, as they represent a stronger division in general. *** Bug 471893 has been marked as a duplicate of this bug. *** As bug 471893 was resoled as a duplicate of this feature request, I must note that the issue of per-virtual-desktop (and per activity) tiling layout is also relevant to the quick tiling feature. I would say that it is much more important for the quick tiling feature mostly because quick tiling is much more discoverable by regular users and we start seeing reports of regular users who are often surprised that after doing "drag to edge" + "resize tile" in one virtual desktop, it resized their quick-tiled windows in other desktops. Oded Arbel: closing the quicktiling UX issue as a duplicate is a bit strange as they are two different user-discoverable features that need to be looked at from a user perspective as two different things. More specifically, a user using quick-tiling may never find out about the tiling feature at all. So any solutions in the tiling feature is not going to be relevant. Second: quick tiling is on purpose only 2 or 4 areas of the screen. It is from a UX perspective a very different feature. And as such merging the bugreport is weird. As I wrote on the now closed report: would it not be much better for the ‘left’/‘right’ quick-tile system to be rigurous and predictable while the tiles-editor is the way for people to do more complex stuff? I’m very much not happy that an accidental change in window size actually changes something other than the window. I mean, I ended up opening up two konsole’s and showing the number of columns / rows, just to allow me to get back to the 50/50 setup and correct the accidental resize. (i.e. it’s an expensive thing to fix!) If kwin must, let the resize of two windows ‘tiled’ end up resizing those windows with zero change of the quick-tiling data underneath. Which means that if I want to reset it, I just hit the shortcut again. And maybe let anything more complex be done with the tiling system which is opt-in. This is in progress with https://invent.kde.org/plasma/kwin/-/merge_requests/6085. *** Bug 489175 has been marked as a duplicate of this bug. *** *** Bug 493254 has been marked as a duplicate of this bug. *** |