Anything you can do in GNOME you can do in Plasma.
Just beware that for the first time in your GNU/Linux life, you can CHOOSE how everything works, instead of being forced into a specific paradigm. For some reason some GNOME users find it disturbing 😅 (it's a joke guys calm down).
i have kde on a ThinkPad x1 yoga and the experience from plasma 5 to 6 got a whole lot smoother. try it Out. could ne that you need to configure a few things but its awesome
I just installed it in this very moment and I'm texting you from the new Fedora KDE Spin installation - Touchpad gestures work ootb, I just find some design choices kinda... uhm, questionable I'd say. Nevertheless, it runs fine overall!
Gentoo supports slots; which allows for concurrent installations of things like desktop environments. Not sure if it's configured that way right now though.
If you use BTRFS you could install gentoo on a subvolume and boot into it when needed too.
@arran4@voracread With some specific packages there are conflicts between different versions, so you can only have one at a time installed even if they have different slots. I think a few of the core KDE packages are like that. I know that I had to remove some parts of KDE 5 when I installed KDE 6 on my Gentoo system.
I'm not using Ansible myself, but I do use kreadconfig and kwriteconfig, and well, it does just have 4 parameters to identify a setting and its value, so that Ansible module does look like it's sufficient for that.
One tip I have, is that you can figure out which GUI setting corresponds to which config file change, by setting up a Git repo in ~/.config and looking at the diff. So, basically:
cd ~/.config
git init
git add .
git commit -m "original config"
# now change setting in UI
git diff
When you're done transferring that into Ansible, you can commit or stage the changes and tweak another UI setting, or if you're completely done, then just rm ~/.config/.git/.
I guess, you could also use this Git repo to roll back all the settings and see if your Ansible automation works as expected.
This is a completely different perspective from the current "grid" layout. The idea here is:
We have exactly N rows.
We have a list of "items", where an "item" is either a pinned (unopened) icon or a button for an opened application/window with a title (will call it "button" here for short, can't come up with a better term).
The row height should never change while opening/closing windows (applications).
The width of (unopened) icons should never change.
The width of "buttons" should be determined dynamically, depending on the number of items and space available. But I imagine that it should start from something like 300 px - something that could be considered wide enough to display "enough" of the title text (maybe 'px' is not the best unit, but just to illustrate the point), and only decrease the width when needed (i.e. no space left).
In the simple case when N=1, let's say the available space is with width W units, there are P pinned icons and their width is K units, then the available space for all "buttons" could be calculated with something like buttons_total_space = (W - (P*K)). To get the target single button width, we could do something like button_width = min(300, buttons_total_space / buttons_count) (not sure if the case of "too small button_width" should be handled in any special way - IMO probably not worth it).
To handle the N>1 case, the formula would become more complicated of course, as it would need to account for different available horizontal space in each row and figure out how many buttons to put in each row. For example, if N=3 and we have 8 pinned unopened icons, they will probably fit in the first row. Then we might end up with, say, 480px left in the first row and 800px in the other two, so if we need to distribute 10 buttons, we might decide to put 2 buttons (with width 240px) in the first row and 4 buttons (with width 200px) on each of the remaining 2 rows.
KDE
Newest