Hello!
I activated the option under Desktop effects, but it doesn’t run …
Does everyone know, how to get this function running?
About my System:
OS: OpenSUSE Leap 15.6
KDE-Plasma: 5.27.11
KDE-Framework: 5.115.0
Qt: 5.15.2
Grafic: X11
Interesting - Meta= does it for me…
Works fine, but the screenshot doesn’t capture the magnification… but then this is on Wayland.
However, I haven’t seen 5.27 for years, we’re on 6.3.5 now… (Manjaro Testing).
Hi ben2talk
yes, the box on my PC looks like exactly as at yours. Due to the issue I changed the action keys as try, but without effort.
About the KDE version: OpenSUSE Leaps are very stable, but they only offer quite older KDE versions. And it is not possible for simple users to update KDE because dependencies.
However, I remember, I used the magnifying function a couple of years ago and it did run. So I think now, maybe there is another setting on KDE, that blocks magnifying, but which one?
1 Like
First shot - create a new user, log in and try there.
Second shot - mv ~/.config ~/.configFUK 
Log out/log in and try again, that tests your config folder.
If that’s clear, then you have to copy back contents of your .configFUK until the error returns, then you’ll know what it was…
Good idea!
I created a new user and with him Magnify runs.
So, it is certainly something wrong in any config files.
Now it’s time to find which one and really, I don’t like to copy step to step each single config file from the current user to new one and every time to test if it runs …
Behind all the configs in the current user are years of tests and settings. And that’s maybe the reason, why many little things don’t run any more. But to rebuild a lot of configurations, which run well implicates a many hours job!
In fact, since KDE 4.0 I have been using the same /home/user head directory. That means, there are surely a lot of config files, which are obsolete and that maybe conflict with the new settings.
So I’m considering, if there is another way to handle this:
It is possible to identify (with a KDE tool?), which directories are absolutely old and could be deleted without damaging the functionality?
If yes, I might open a new thread for this.
is this what you are looking for?
the choice is between magnifying then entire desktop or just an area under the cursor.
the shortcut keys are the same.
if it’s not working in plasma 6, then it’s a bug.
if you are using wayland, try it in X11
yes, I do.
About the question Wayland vs X11:
do you have the option for magnifying the entire desktop?
and does that work?
i’m wondering if you are not missing a package somewhere.
skyfishgoo, sorry for this rude question, but I think, you did not read the posts before, did you?
not rude at all, and i did read them… it’s not clear to me if you have the other zoom option because i have both as you can see here:
but since they are radio buttons, you can only choose one or the other.
Then you can follow my brainless plan to track that down… Just be sure to take a fresh backup before you start (it’s good to have a backup of the config folder to pull files back from).
mv ~/.config ~/.configFUK- Log out and in again, open Dolphin, press F3
- Left pane go to
~/.configand right pane~/.configFUK.
So the game now is to move configs back trying not to recreate the error.
- Try to select half, move it across ShiftF5
- Log out and in again, test…
- If error didn’t return, repeat from 4 to 5.
Hi ben2talk,
yes, I know the procedure … and I take a backup of /home almost every 5 days.
My resistance to that is: How many configs are there? And which ones should I try to “reactivate” = copy back. Surely not all that, because, as already mentioned, there are a lot of obsolete config-files under /home.
That’s the reason asking: maybe there is a KDE tool, that identifies obsolete (not more useful) configs could be surely deleted. In this manner, the amount of config files is considerably reduced.
Is there a tool like this?
the triage is to move back half of them at a time until the last file is restored or the problem reappears.
when it reappears you know that the problem config file has to be located in that batch of files.
so then you start over and only move back half of that batch until it reoccurs again.
and so on until it’s down to two files and then you can tell which one is the issue and exclude it from the final copy back of ALL but that one file.
it’s a club rather than a scalpel, but it works.
as for how to best clean out old unused configs, that’s kind of a manual process
on debian systems you can try sudo apt purge, but i’ve not found it does what you would want it to do.
you can use kfind to sort config files by last accessed… that should point you to stuff that’s not being used.
1 Like
It doesn’t matter how many configs there are.
If you have 1000 items, you move 500 and test. If the test is fine, then you move another 250, then 125, then maybe 60.
If you’re down to less than 30 items and the problem didn’t re-occur, then start looking at those carefully - it should be in there… move another 15, then move 7, then 4, 2, 1.
It cannot fail… no intelligence is required to execute the maneuvure which is why I suggest it works if you’re not able to think of a more proper troubleshooting strategy.
Using Dolphin, you can view the files by order they are last accessesd - so you know when the files were last read and this can tell you which are not used and can be left behind for deletion later on…
You almost certainly just have X11 compositing turned off, which makes all effects impossible.
Just turn it on and it should work. Or switch to Wayland, where things can’t break that way.
2 Likes
Eureka!
This was! After turned compositing on and re-login, it runs.
Thank you a lot !