I’m out of the loop, but I used to use Slackware – largely because the distro didn’t get mad when I just installed things from source directly onto the filesystem. No dependency tracking ;)
But I had a lot of experience before that with other distros.
Good choices are probable OpenSuse (tumbleweed), Arch, or Neon. Actually, I don’t know the current state of Neon… is that still a thing?
Mandrake introduced me to it. I think I moved over from fvwm, so the difference was huge.
I stuck around until KDE4 - At which point I couldn’t get it to run for long without crashing. That and I think the Amorok guys started phoning it in. Many years of DE/WM hopping finally ended with 5.21. The wait was worth it!
Nice! Mandrake was really great when it was new – Basically redhat(clone)+KDE+Mandrake Control Center. Compared to the pain of getting KDE installed on redhat (originally), it was quite a slick system. It was my third linux distro, and I rode it up until the Mandrake+Connectiva merger.
After the aforementioned redhat pains, but prior to Mandrake, I also dabbled with Caldera. This was so slick at the time: www.linuxjournal.com/article/3563 – a pity they “enshittified” before the word was coined, because that’s exactly what happened haha. It was the first distro with a graphical install process, which just seems normal now but was quite revolutionary at the time. Plus it came with KDE preconfigured.
After the connectiva merger, I moved to slackware and stayed there until I exited KDE development. It was a great development box because the systems were so minimal and just sort of stayed out of the way. At the KDE 4.0 release event, we even managed to get Patrick Volkerding to attend – which is sort of like meeting your own personal linux hero. That was fun.
i haven’t looked too deeply into it, but a lot of kde config files already have some sort of update and version data. transitioning to new locations shouldn’t be TOO difficult. I think everyone can agree it should be done. I imagine that naming and specific locations could turn into bikeshedding though.
It’s been tempting for me to use some LD_PRELOAD magic to clean things up. I’m the kind of person that keeps my home directory read-only and uses custom environment variables for particularly egregious applications.
The proposal isn’t mine, I just read and shared it :-) The blog post has a paragraph or two about multpile subfolders, as I read it, the specification is not clear on whether thats supported? But actually: at first glance I think this would be better to have, because it would possibly make synchronizing to a new PC/Laptop even easier. However, this only works if any machine-specific settings (e.g. “offset /size of window”) are not stored in config, as that might break if you sync config between a multi-monitor setup and a single-monitor setup. This requires a lot of thought…
That feels way too nested to be useful IMHO. It’s great for packaging dev tools, but not really for handling config directories for user space apps. I just want ~/.config/KDE/<app>
If you mean migrating the files yourself, it’s just a matter of copying the file from the old place ~/.config/yourconfigrc to ~/.config/yourapp/yourconfigrc.
If you mean you want the application to manage the migration itself, that’s an implementation detail I hadn’t thought about yet, but which I assume wouldn’t be difficult to do with KConfig.
Just for clarification: this would be a one-time process per application, right? I’m sure this will work for 99% of users, but there’ll always be the one (or a couple of users) that synchronizes their .config directory, then doesn’t update all machines at the same time and all hell breaks loose - a.k.a xkcd.com/1172/ :-) But I’d say that’s probably not worth losing the advantages of a cleaner .config-directory, so this might be one of those “tough-luck” situations… 🤷
i agree with all of this, and in fact would go a step further to say: nicer names in general. what in the nine is plasma-org.kde.plasma.desktop-appletsrc‽ why not just plasma-appletsrc?
i think the real problem is the manpower to do it all though
Would this mean a copy and a paste of the config folder would bring up a new KDE system to my personalizing without going through konsave juggling?
I think that’s my biggest complaint that I don’t know how to import my desktop config (window decorations, panel layout, desktops, activities, fonts, application themes) into a new install easily or the “proper” way
this is a seperate issue, and no, it wouldn’t fix the issue, maybe improve it a little though. as stated in the article, not everything would be in ~/.config/kde, and IME there are files scattered over ~/.local/share that you might also consider config you want to export.
Personally, I’ve tracked down 80-90% of the settings I care about and put them in git, but it was tedious, and some things can’t really be shared across machines, while some other things need to be cleared of machine specific information to work as a new “default base config”
I’m not sure (not the author) and I think syncing config is a lot more difficult than it would seem at first glance. Eg Panel Layout: Imagine syncing between a multi-monitor-setup (work PC) and a single-monitor-setup (Laptop) - how’s that supposed to work? The panel might be on the second screen on the PC, but once synchronized to the Laptop, that would mean either
missing panel (off screen)
double panel (stacked on top of each other)
hidden second panel (one below the other)
…
Syncing .config would (at first glance) work best for device independent settings (e.g.: Indentation in Kate with Tabs vs. Spaces) - but even “fonts” in Kate might already not be a good idea, as a font might not be installed in both systems (and it might get worse with font-sizes, scale-factors…)
yeah I know, but on certain types of wallpapers they are not needed, so I was wondering if it was possible to remove or perhaps change the text decoration to (e.g.) outline, bold, …
KDE
Newest