- User Since
- Apr 15 2015, 5:07 PM (196 w, 5 d)
Wed, Jan 16
Tue, Jan 15
Another bugs that needs fixing: https://bugs.kde.org/show_bug.cgi?id=403226
Requesting re-review due to significant behavior changes following @fvogt's comment
Fix comments and make code reflect comment intent
Sat, Jan 12
The pro-parity argument is mostly: Eventually I/we will stop testing X11, and X11-only features carry a maintenance burden. I'll think about it, nothing we need to solve for 5.15 though I guess.
Yeah, I agree with you. The question is, should I just remove it from the X11 version so we have parity then?
We've made progress since the last TODO comment. Here's an updated one:
Fri, Jan 11
Forgot a hunk when moving to 5.12 branch.
Add BUG to message.
Here's my take: https://phabricator.kde.org/D18182
Thanks for the ping, it worked :)
The desktop cube shows everything flat, desktop grid is configurable (and hardcoded).
Wed, Jan 9
As per this, progress on this is currently blocking wrapping up Wayland virtual desktops support for 5.15.
Sun, Jan 6
Sorry about this, thx for fixing :)
Sat, Jan 5
Wed, Jan 2
Dec 22 2018
I don't think it's necessary to optimize the dataChanged emits at this time - in the common case the roles the delegate is visualizing (label, icon) will always change, and the other rules are lazy-evaluated by the current UI (e.g. the context menu actions are constructed on-demand). Realistically, computing the roles delta to figure out the roles will likely eat more CPU time unless the users of the module show a different usage pattern. I'm OK with this with a "// TODO: Could be optimized by ... if needed" in the code.
Yes and no, the problem with temporary "workarounds" is that they often become permanent. So, I still suggest to go with the "right" approach even if it'll cause that regression.
Dec 20 2018
unrelated addition of empty line
I agree with you, although I'll add that not having the setting at all in the KCM is a regression, but not having the model is not as the old KCM didn't have that ability. Sometimes we reject patches without thinking about the end-user picture.
What I guess I'm asking is: Do we even have category metadata for the plugins? From the above I'm guessing the answer is yes.
Cool, thanks for the update. I'm a bit flooded before the Christmas holidays, but I'll try to make sense of this in early 2019.
Dec 19 2018
Thanks for your submission. Could you provide a description for this patch? What does it fix, why does it fix it?
Dec 18 2018
To clarify, it's possible to DND a window from desktop to desktop. "Can't move yet" refers to within a desktop by dragging the window a few pixels.
I'm now aware of the following remaining todos:
Closed with https://phabricator.kde.org/D14542
- Add missing upper bound to the Rows spinbox (cf. 06a9a2a468df).
- Change 'msec' to 'ms'.
Dec 15 2018
Apply button working for me: https://youtu.be/LvMhpCLxdWY
Alrighty, I'll go in with the majority opinion then. Consistency is certainly an improvement by itself. Go go go!
Dec 14 2018
Fix initial state
@ngraham From a UX perspective your comments make perfect sense, but unfortunately KWin currently has a flat list of desktops divided by number of rows so I need to decline that for now. It's out of scope for 5.15 for sure.
Dec 10 2018
It turns out we all collectively forgot about the "Switching" tab in the original KCM.
Add back nav wrap and OSD settings.
Dec 9 2018
Dec 8 2018
Can we patch Dolphin instead? I think the order there is pretty bad, with weird random dividers etc. (From the screenshots in the original user bug.) I prefer FV's.
Dec 5 2018
I'm no longer aware of bugs in this, please re-review it.
Further fixes to sync & co
Revamp KWin restart handling
Nov 30 2018
Handle KWin restarts
Rebase on master for good measure
Fix syncing to server.
Nov 29 2018
Well, the entire point of activities existing is that they go beyond the limitations of desktops - you can add a window to 2 out of 5 activities, not just one or all. If it's the same, we don't need both.