| Summary: | Switching activity also switches virtual desktop / virtual desktop layout differs from one activity to another | ||
|---|---|---|---|
| Product: | [Plasma] kwin | Reporter: | Vincent de Phily <moltonel> |
| Component: | activities | Assignee: | KWin default assignee <kwin-bugs-null> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | normal | ||
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
After experimenting a bit, it seems like the behaviour is actualy "go back to the VD that was current the last time we were in that activity". If that's the case (in the rest of this comment, I'll assume it is), I'm seeing a feature and feeling it's a bug.
You might argue (and be semantically right) that I have flawed expectations and that, activities beeing unrelated, their VDs should be unrelated too. But I don't think I'll be able to wrap my head around the implemented behaviour :
* When I switch to an activity, I have long forgoten which VD I was in the last time, so the VD I arrive in with the current behaviour is effectively "random" instead of "expected", and it takes me that much longer to reorient myself (I do not display desktop names when switching, and do not have the VD widget visible most of the time).
* I have a fairly spacial memory, and in my head virtual desktops are beside one another while activities are on top of one another. So the current activity-switching behaviour moves in 3 dimentions (updown, leftright, frontback) instead of one (frontback).
Opinions will surely differ here, so I guess I'm asking for a configuration option. Something along the lines of
> system settings -> workspace behaviour -> workspace
> (... existing options)
> When switching workspace
> [*] go back to the previous virtual desktop
> [ ] keep the current virtual desktop
> Shortcuts
> (not related to current bug, but would make a lot of sense in that context)
Does that sound reasonable ? I do not like contributing to option creep, but as explained above, I do not think I'll be able to adapt to the current behaviour.
As you figured out yourself: it is not a bug, but a feature. In fact it's a feature which had been highly requested and IIRC even contributed by non-core developers. I do not see a need for a config option, though. This is so specific that a config option does not make any sense in my opinion. Furthermore I have to point out that a config option could earliest be added for 4.10 to be released in January 2013. It should be possible to restore the desktop through a KWin script. See http://techbase.kde.org/Development/Tutorials/KWin/Scripting By "this is so specific" do you mean that people who would prefer the old behaviour are too small a minority ? Everybody is biased towards his own opinion of course, but I like to think I'm far from unique in this case. I've reopened the bug as "waiting for info". If nobody comments "me too" here within a reasonable timeframe (say early 2013 ?) we can close this bug, otherwise reopen it as valid ? Meanwhile, I'll have a look at kwin scripting to see if it can provide a workaround (I've long been curoius about kwin scripting anyway). setting to resolve invalid again, as: a) watingforinfo means "closed", too b) nobody comments on bug reports c) even if someone would comment, how many comments would we need? One, ten or maybe 10.000 to get a representative opinion? If you want to gather user feedback please use brainstorm.forum.kde.org Meh :/ I know bugzilla isn't a voting platform, but none of the other available mediums are much better ? Lacking a usability study, all we have to go by is a collection of "me too" comments and some gut feeling. (And there again I demonstrate that I write too quickly - I'll have a go with brainstorm.forum.kde.org) |
Switching activities switches virtual desktop as well. Reproducible: Always Steps to Reproduce: 1. Configure multiple activities and virtual desktops 2. Note which virtual desktop you are currently looking at (say "top left") 3. Switch to another activity (using either "Win+Tab" shortcut or "mousewheel on desktop") 4. Note the virtual desktop you arrived at in the new activity Actual Results: The virtual desktop has changed ("top left -> top right" or somesuch; I haven't found an understandable correlation yet). Expected Results: Remain on the same virtual desktop when switching activites. * This looks like a regression from a couple of releases ago. Unless I just hadn't triggered the setup bug yet (even though I've had the same virtual desktop / activity setup for ages). * I have tried "resetting" the virtual desktop layout by adding/removing VDs and changing the number of rows, but it did nothing. * If bug #251267 ever gets implemented, we'll need a "least-surprise" algorythm to determine how different VD layouts are linked.