That was merged, and this is basically done in Plasma 6 now.
- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
Jan 11 2024
Jul 8 2023
I will fix krfb, I know there are pending patches for yakuake to port to layer-shell which are ready to go when it can rely on Qt 6
Except for yakuake and krfb all of those are within Plasma, so if we do not manage to port all of them away in time for 6.0 we could move kwayland to Plasma
Remaining users of KWayland:
Feb 18 2023
From the QWheelEvent docs:
https://invent.kde.org/plasma/kdecoration/-/commit/4091b18bfef5e1ff8f2924ad18917ebbb14987b0 changes the deprecated posF() to position().
Nov 4 2022
This proposal will be implemented if and when https://invent.kde.org/plasma/kscreen/-/merge_requests/152 is merged!
Apr 30 2022
Oxygen shell, seat and pointer to get a serial for requesting a move
Some porting:
Apr 7 2022
This was fixed by me a few plasma versions ago
Feb 13 2022
late to the party question.
is this issue still pursued?
when I got my new laptop I noticed that it the new archlinux install UIs seemed too small.
my last laptop was an old 15.6" 1366x768 .
my new one is a 13.99' 1080
after a lot of changes I arrived at using 150% scale in kde display setting.
but I still have a lot of questions.
Dec 28 2021
Sep 29 2021
If you don't want to maintain an option in the UI - cause the amount of people using it - why not just add it to the config file. I would say, that the default does not really matter. Both solutions are working somehow, and most people won't notice the difference.
In D8388#157672, @graesslin wrote:And if there is one thing KDE is negatively famous about is that we have space shuttle control modules. Due to that we need to be careful when adding new options.
Sep 9 2021
No need for two places to discuss the same thing; Let's close this in favor of https://invent.kde.org/plasma/kwin/-/issues/10, and take the discussion there.
Sep 7 2021
If you want to make it official, would you be interested in helping to make tiling a part of KWin directly? https://invent.kde.org/plasma/kwin/-/issues/10
If it's bult-in then more integration could be done, for example with effects and the current quick tile system.
Please, excuse me for shameless plug, but I am currently working on a "new" tiling script extension to KWin here. I've observed, that the other tiling extensions' development was stale over the year and decided to fork one of them with the goal of making the code base more modern and new developer friendly. Also, I am aiming for the Wayland support and wanted to publish the script on the KDE Store once that's ready, but my Wayland session is not stable right now on Plasma 5.22, and I haven't found a good way to debug the script right now in the VM (I just want to see script logs for now). In the end, I really want the script to be an official KDE project and to be a part of default Plasma distribution once it's mature enough (don't want to be a perfectionist, so I am not sure where to draw a line here).
As far as tiling is concerned, there's a KWin script available: https://github.com/kwin-scripts/kwin-tiling
Sep 6 2021
@ngraham It's more like the window tabs in the titlebar like we had in KDE4. From what I've seen in the video posted the KDE4 version was a lot slicker than the PopOS one. Incidentally, I'd sooo wish to see this feature come back.
Jul 13 2021
Development has moved to https://invent.kde.org/plasma/kwin
Jul 4 2021
Jun 11 2021
May 22 2021
(post KF6 meeting 2021-05-22): there is a solid plan in motion, moving to "in progress" on the KF6 board (no real blockers for the release).
May 14 2021
Jan 27 2021
I think I missed some, so next try:
Jan 26 2021
Update from the sprint: We want to look into if we can fully deprecate KWaylandClient for KF6 and use QWaylandClientExtension everywhere. Current usage in KDE (searched KwaylandClient on lxr):
- plasmashell protoocl for positioning and plasmashell
- plasmashell and and dialog (of course)
- Yakuake
- krunner
- ksplash
- logout-greeter
- latte (and shadow)
- spectacle
- plasmashell protoocl for positioning and plasmashell
- FakeInput
- KDE Connect
- KWayland Integration uses a bunch of stuff for its plugins
- idletime
- keystate
- kwindowsystem plugin uses blur, contrast, slide, shadow, plasma window management, plasmashell, shm
- KScreen uses dpms and output
- Oxygen shell, seat and pointer to get a serial for requesting a move
- the platformtheme uses surface, appmenu and our decoration protocols
- KInfoCenter lists every interface and information about seats, keyboards and outputs by listening to the registry
- taskmanagement by the things that do task managemnt
- plasma phone components homescreen and taskpanel
- libtaskmanager
- powerdevil dpms
- xdg-desktop-portal-kde
- plasmawindowmanagement
- output
- fakeinout
- datatadevive by KWIn and klipper
- Of course KWaylandServer and KWin tests which should move to generated code according to the above plan
Jan 24 2021
Jan 12 2021
Dec 18 2020
Not a revert but rather rollback of SNI part:
https://invent.kde.org/plasma/kwin/-/merge_requests/560
We are going to revert this in favor of https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/181:
it supports all the existing functional here plus missing one (problem with short layout names was solved):
- flags and/or short text for the layouts
If any objections, please tell.
Dec 11 2020
In T13927#245985, @ngraham wrote:Ah ok, so you're asking for better tiling support to be built in.
Dec 10 2020
Dec 8 2020
In T13927#245985, @ngraham wrote:Ah ok, so you're asking for better tiling support to be built in.
In T13927#245985, @ngraham wrote:Ah ok, so you're asking for better tiling support to be built in.
Nov 18 2020
For reference xdg-session-management protocol is the work-in-progress replacement for XSMP in Wayland: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/18
Nov 16 2020
In T13582#244856, @ngraham wrote:Third party apps don't need to support Activities or anything Plasma-specific at all but just XSMP (X Session Management Protocol),
Gotcha. That's pretty clever.
Unfortunately the point still stands since tons of apps sadly don't support it. It's not just Firefox; Thunderbird, LibreOffice, and all Electron apps also don't seem to support it. I'm sure there are more too.
Nov 15 2020
Third party apps don't need to support Activities or anything Plasma-specific at all but just XSMP (X Session Management Protocol),
Nov 13 2020
Nov 11 2020
In T13582#244491, @ngraham wrote:Wow. Impressive.
This kind of leads me to what I consider the Achilles heel of activities: every individual app needs to be made activity-aware. That seems hard enough for KDE software over which we have total control, due to disagreements about the scope of what set of the app's settings should be activity-aware. But since 3rd-party apps don't support activities at all, the concept just breaks down if you want or need to use 3rd-party apps. :( 5 out of 11 of my pinned apps are non-KDE apps.
Nov 10 2020
This kind of leads me to what I consider the Achilles heel of activities: every individual app needs to be made activity-aware. That seems hard enough for KDE software over which we have total control, due to disagreements about the scope of what set of the app's settings should be activity-aware. But since 3rd-party apps don't support activities at all, the concept just breaks down if you want or need to use 3rd-party apps. :( 5 out of 11 of my pinned apps are non-KDE apps.
Nov 9 2020
In T13582#244379, @ngraham wrote:@alex-l You said:
I have a Firefox profile on each Activity with different favourites, history etc.
How did you do that? Does it let you have different sets of tabs per activity too?
Personally I've had the same experience as Noah: I find it easier to manage my workspace with just the task manager and Alt+Tab and whenever I try out Activities or Virtual Desktops, I don't stick with them. This goes for other platforms too which also implement these features, FWIW.
It's not that Virtual Desktops and Activities are not useful but they are just presented in a way that doesn't make obvious how to use them. I wrote some blog posts in Planet KDE years ago explaining (creative) way to use Activities. But in fact if you need to explain intended workflows with blog posts you have a UI/UX problem.
Kind of a shame that this extensive write-up has sat around for 2 months with no comments, but unfortunately, I don't have much to add. I don't really use virtual desktops or activities much and haven't seen a great need to, so it's hard for me to really see how they should work. I have tried them and they have been somewhat useful, but I never really stick with them. It's just easier for me to control everything with the task manager. I'm not saying your reasons for liking Virtual Desktops aren't valid, but perhaps one of the reasons why nothing moved forward is that a lot of people don't understand them, including KDE developers and designers like myself?
Nov 5 2020
The patch is now at https://invent.kde.org/plasma/kwin/-/merge_requests/325 btw
Nov 2 2020
A potential idea for fixing: allowing clients to request that the decoration be composited over their area. KWin/the KDecoration would be responsible for drawing the foreground, and the client would be responsible for drawing the background.
Oct 29 2020
see generic point
Is there a way to implement an "emulation" for applications that don't explicit support said back functionality?
Alright some notes from discussions:
There are 2 ways we can approach this: generic (sending mouse back events) and powerful (have a dedicated API for it)
There are pros and cons to each method
Generic:
- Pros: simple, doesn't require anything from app developers
- Cons: not extensible, won't work consistently with different apps, could lead to a poor experience nullifying the point
Powerful(API):
- Pros: Extensible, reliable, consistent
- Cons: Requires an implementation from developers (although gives users a good experience), not all apps will be supported
Oct 7 2020
In D21076#676560, @rjvbb wrote:You must be right about the greyscale effect; I don't see any actual calculation of the intensity (from the RGB values) in the code that gets installed. And that code is JavaScript (aka QtScript); up to you to determine if your effect could be implemented in that language...
Oct 6 2020
You must be right about the greyscale effect; I don't see any actual calculation of the intensity (from the RGB values) in the code that gets installed. And that code is JavaScript (aka QtScript); up to you to determine if your effect could be implemented in that language...
I have no idea how it works, but I imagine you create the build locally, possibly with the help of kpackagetool, and then upload it to some KDE server.
In the end, try to update KDE itself. I'm sure glitches were worse when I was using KDE 5.14. KDE 5.17 is definitely better
Is it? How does it work? It definitely requires distribution of a binary addon. Does KDE installer build binary addons?
In D21076#676555, @rjvbb wrote:
As I understand 3rdparty binary effects are harder to install, very unpopular and it will take 100 years to get it packaged in all distros...
Oct 5 2020
In D21076#676552, @rjvbb wrote:That's with the translucency effect for menus set just 1 tick non-opaque. The effect gets less the more opaque menus are made, but it seems wrong. My widget style and colour palette specify a white menu background and my colour correction profile clearly doesn't affect white noticeably.
I was maybe a little quick. Consider these differences
Yup, works for me now.
Are you sure you applied the newer patch? One with the tex *= modulation line in icc.frag? Also are you sure you installed the resulting libkwin4_effect_builtins.so correctly?
I got this one: https://github.com/vitalif/kwin/commit/83d69c928574de388d8f27ec6948f307b4eab3f2.patch following the link to your github repo you posted earlier, but I see no occurence of that modulation pattern in that commit. In fact, I now see that it looks like an old commit - so where is that newer one?
Hm, and by not working you mean that the translucency effect gets canceled, but the correction itself works, right?
Oct 4 2020
It doesn't work either for me with KWin 5.15.5 and that doesn't seem to be because of one of the other few effects I have activated.
Something has probably changed since 5.13.3, because translucency-while-moving works fine with my KWin 5.17.5...
still doesn't seem to work together with KWin's translucency-when-moving effect for me (with KWin 5.13.3; patch applies cleanly except for the inexistent effects kcm). And after a few KWin restarts the correction has either "stuck" or isn't being applied anymore.
Oct 2 2020
By the way, I've updated the patch for KDE 5.17 + fixed it to work with translucency effects correctly (I didn't use "modulation" in the previous version of the patch).
Sep 30 2020
Sep 26 2020
Apparently one can no longer contribute via email replies to the email notifications?!
Sep 25 2020
Updated for 5.17.5 + added "modulation" usage
I like solutions that work right here right now. Waiting for all apps to do color correction on their own is utopism. Sometimes I just turn the effect off when I don't need it.
I'm not "working" on color correction, I mean it's not a continuous process :) I don't have much time to develop it further, make it fit guidelines or patterns.
I NEEDED full-screen color correction and I solved my problem with this effect. I use it 24/7.
Sometimes there are glitches, for example sometimes the taskbar flickers and so on, but these are always there with KWin as I understand so they don't bother me much.
By the way, I've updated the patch for KDE 5.17 + fixed it to work with translucency effects correctly (I didn't use "modulation" in the previous version of the patch).
It's on github: https://github.com/vitalif/kwin ... OK I'll upload it here too ...
At first, I very much appreciate that somebody starts working on color correction in KWin again. There is certainly a need for it. However, and although I am by no means an expert in this area, I have certain concerns about the approach.
Sep 17 2020
Thanks! You can Abandon this now from the Add Action menu/button.
Rebased to current master and merge request created:
https://invent.kde.org/plasma/kwin/-/merge_requests/267
Sep 16 2020
We have since moved to GitLab. Would you mind re-opening this as a merge request at https://invent.kde.org/plasma/kwin/-/merge_requests/? Thanks!
Sep 14 2020
Thank you for this patch, I tested it on my 2017 ThinkPad X1 Yoga with openSuSE Tumbleweed (KWin 5.19, Kernel 5.8.4-1) and it works like a charm.
For enabling the monitor, I used QDBusViewer and called setCompositorBrightnessOutputNames() with eDP-1 manually.
Night mode also works out of the box. I'd love to see it upstream :)
Sep 10 2020
Sep 7 2020
Sep 4 2020
Aug 21 2020
Aug 11 2020
As I mentioned in T10568 we need IMHO better discoverability not yet another global shortcut.
Aug 10 2020
Just tested this with KWin 5.13.3 (of which I had a build all set up; the patch applies cleanly except for the .desktop file).
Something like this should be part of any self-respecting desktop; per-screen colour management ("ColorSync") has been in Mac OS X since its very early days and even with a simple software calibration utility (SuperCal for Mac, Calibrize for MSWin) you can really improve how your display looks (whether you go for absolute correctness or a calibration that makes things look at their best for your own perception).