Hi list, I wonder if someone has seen similar problems, and/or has an idea what might be causing it. Since many weeks my Tumbleweed laptop shows an embarassing behavior: If I shade a window, and unshade again, the window height is reduced to 1 character height for text windows, or one pixel for graphical ones. It's the same whether I use the mouse wheel or the window menu for shading. The irritating part is: My desktop at home, also running TW, does not show this. So I assume it is some setting - I just don't have the foggiest idea where to look. I've tried to recursively grep for 'shade' in ~/.config, but that didn't reveal anything. I had opened a bugreport (boo#1200007), but without any response, so I thought I ask here, maybe someone knows where to look... :( I'm running plasma/kwin
On Wed, 3 Aug 2022 10:57:24 +0100 Peter Suetterlin wrote:
Hi list,
I wonder if someone has seen similar problems, and/or has an idea what might be causing it.
Since many weeks my Tumbleweed laptop shows an embarassing behavior: If I shade a window, and unshade again, the window height is reduced to 1 character height for text windows, or one pixel for graphical ones. It's the same whether I use the mouse wheel or the window menu for shading.
The irritating part is: My desktop at home, also running TW, does not show this. So I assume it is some setting - I just don't have the foggiest idea where to look. I've tried to recursively grep for 'shade' in ~/.config, but that didn't reveal anything.
I had opened a bugreport (boo#1200007), but without any response, so I thought I ask here, maybe someone knows where to look... :(
I'm running plasma/kwin
Hi Peter, I don't have a 'silver bullet' for you, but I rely heavily on shading in my day to day work and this problem would absolutely /crush/ me until I got it fixed. Every time I've seen it (and I *have* occasionally seen it over several years in multiple DEs,) the underlying problem has been in how the the window area is being calculated, stored or read back on unshade. It could be the calculations are bogus (check display settings) or the values being stored are corrupted (or being misinterpreted) on unshade. Have you tried testing if a new user with a pristine environment and configuration is seeing the same behavior? This can help to narrow the problem down to one that is global or confined to your user space. Have you tested switching between higher and lower resolution display settings or at least verified that all of your current display settings are valid? I won't be able to see your reply or respond until later tonight (US Eastern) but I wanted to chime in because I definitely 'feel your pain' :) regards, Carl
Hi Carl, thanks for the spiritual support :D Yes, I use it a lot, too, so it *is* absolutely annoying. It definitely has to do with some configuration setting, as my home desktop doesn't have that problem. But with KDE not having any manpages it's hard to even figure out what to look for. One difference is that the laptop uses two monitors. Maybe it's related to that? Just tried it with a new user, and there shading works, also with two monitors. But I sort of expected that. I had already tried comparing my laptop setup with the desktop one at home. Again, if you don't know what to look for... :-( Do you have something special in mind regarding display settings? I can't check other resolutions at the moment, as kwin will then resize and shuffle around all windows, which are a lot right now. Will have to wait a while.
hey again Carl, Carl Hartung wrote:
I don't have a 'silver bullet' for you, but I rely heavily on shading in my day to day work and this problem would absolutely /crush/ me until I got it fixed. Every time I've seen it (and I *have* occasionally seen it over several years in multiple DEs,) the underlying problem has been in how the the window area is being calculated, stored or read back on unshade. It could be the calculations are bogus (check display settings) or the values being stored are corrupted (or being misinterpreted) on unshade.
just another thing: other window size related operations like maximize work fine. I'd assume if it were a problem in my display settings, those should also fail one way or another. Really puzzling....
On 2022-08-03 11:57, Peter Suetterlin wrote:
Hi list,
I wonder if someone has seen similar problems, and/or has an idea what might be causing it.
Since many weeks my Tumbleweed laptop shows an embarassing behavior: If I shade a window, and unshade again, the window height is reduced to 1 character height for text windows, or one pixel for graphical ones. It's the same whether I use the mouse wheel or the window menu for shading.
Hum. I have no idea what shading is. I had a mental image of using an umbrella to cover the screen from the sun, but that can not be it. Ah, google says it is rolling up a window. Ok, that's working fine here (leap 15.3, XFCE) -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
On 8/3/22 06:53, Carlos E. R. wrote:
Hum. I have no idea what shading is. I had a mental image of using an umbrella to cover the screen from the sun, but that can not be it.
Ah, google says it is rolling up a window. Ok, that's working fine here (leap 15.3, XFCE)
Always works fine here, mousewheel-fwd over titlebar - shades mousewheel-rev over titlebar - unshades I think Carl nailed the issue. Likely bogus window dimensions calculated for unshade. Modern KDE seems to auto-calculate the size of everything on the fly now, because it knows better than the user what the user wants to see (just try changing the clock font size in the task bar) I wouldn't be surprised if something in your config hasn't gotten corrupted which causes the unshade to fail. (which you would think the window dimensions would just be stored on shade and not need to be calculated) Even if the winsize is stored, if the config has a corrupt entry, then the result will be the same. Try rebuilding the system config cache with: $ kbuildsycoca5 --noincremental -- David C. Rankin, J.D.,P.E.
David C. Rankin wrote:
Always works fine here,
mousewheel-fwd over titlebar - shades
mousewheel-rev over titlebar - unshades
Seems the mouse setup isn't standard. I had just created a new user, there mouse doesn't work. But that's a different topic. For me, both using the mouse and the window menu result in the same error.
I think Carl nailed the issue. Likely bogus window dimensions calculated for unshade. Modern KDE seems to auto-calculate the size of everything on the fly now, because it knows better than the user what the user wants to see (just try changing the clock font size in the task bar) I wouldn't be surprised if something in your config hasn't gotten corrupted which causes the unshade to fail.
Yeah, the 1 Megadollar question is what....
Try rebuilding the system config cache with:
$ kbuildsycoca5 --noincremental
But would a cache error survive reboots etc? I've had many dups and reboots since this started.. Hope that doesn't kill things running. But it executed fine - and didn't change the behavior :(
On 8/4/22 11:24, Peter Suetterlin wrote: (yes, I configure the mouse that way -- very convenient)
But would a cache error survive reboots etc? I've had many dups and reboots since this started.. Hope that doesn't kill things running.
Yes, the cache (well depending on whether tmp is on tmpfs or a normal partition) will survive reboot. So if you have rebooted several times in the interim, then it is unlikely to be a cache issue.
But it executed fine - and didn't change the behavior :(
Yup... sorry no silver bullet this time. Were it me, I'd # useradd test (set passwd, etc..) start DM and login as test user and see if the problem remains, if it does, it's a solid bug/issue -- but may also be related to differing versions of libs if you have allowed vendor change on some of the Plasma stuff. Otherwise, it's a solid bug if no vendor change and it still affects new profiles. -- David C. Rankin, J.D.,P.E.
David C. Rankin wrote:
Yup... sorry no silver bullet this time. Were it me, I'd
# useradd test
(set passwd, etc..)
Yes, did this, as expected it works there. So it must be somehow configuration related, probably some old setting that got changed meanwhile or similar (the machine was installed 6 years ago, since then only updates). But I have no clue *where* the relevant config file is. ~/.config has 1GB. Finding something there isn't trivial. And nuking it is a no-go for sure. Would be easier if KDE wouldn't dump all configs directly under ~/.config, but in it's own subdirectory...
On 8/5/22 08:28, Peter Suetterlin wrote:
David C. Rankin wrote:
Yup... sorry no silver bullet this time. Were it me, I'd
# useradd test
(set passwd, etc..)
Yes, did this, as expected it works there. So it must be somehow configuration related, probably some old setting that got changed meanwhile or similar (the machine was installed 6 years ago, since then only updates).
But I have no clue *where* the relevant config file is. ~/.config has 1GB. Finding something there isn't trivial. And nuking it is a no-go for sure. Would be easier if KDE wouldn't dump all configs directly under ~/.config, but in it's own subdirectory...
Config corruption is the Achilles heel for KDE5/Plasma. It hasn't improved much since kde4. The painful solution is the same though, move your config directory (I don't even know what it is now, last time I fought with it Plasma was dumping all individual config files in ~/.config and polluting the lot rather than doing the sane thing and putting configs in ~/.config/plasma or ~/.plasma or ~/.kde5 or something similar. With KDE4 it was just move ~/.kde4 to ~/.kde4-sav (or similar) and restart the desktop. I hope all the plasma configs are now in a similar directory you can simply move and restart the desktop in the same way. If they are still all dumped as individual files under ~/.config --- that would be a Royal PITA. If the move of the config directory fixes your problem, you can start copying back your original configs from the save directory one-by-one (or a group at a time) and see when unshade breaks again. (I suspect it would have to be in kdeglobals or something similar) I'll have to load tumbleweed and Plasma and check what the current config setup is. KDE3 is just so damn reliable, like your favorite comfortable pair of slippers you wear on a cold night -- it's hard to trade that for fighting bugs again. Not to mention I could take a nap waiting for plasma to start compared to the 3-4 secs it take KDE3 to load... :) -- David C. Rankin, J.D.,P.E.
On Sat, 6 Aug 2022 23:55:01 -0500 David C. Rankin wrote: 8< - - - - - snipped for brevity - - - - - >8
Config corruption is the Achilles heel for KDE5/Plasma. It hasn't improved much since kde4. The painful solution is the same though, move your config directory (I don't even know what it is now, last time I fought with it Plasma was dumping all individual config files in ~/.config and polluting the lot rather than doing the sane thing and putting configs in ~/.config/plasma or ~/.plasma or ~/.kde5 or something similar.
With KDE4 it was just move ~/.kde4 to ~/.kde4-sav (or similar) and restart the desktop. I hope all the plasma configs are now in a similar directory you can simply move and restart the desktop in the same way. If they are still all dumped as individual files under ~/.config --- that would be a Royal PITA.
If the move of the config directory fixes your problem, you can start copying back your original configs from the save directory one-by-one (or a group at a time) and see when unshade breaks again. (I suspect it would have to be in kdeglobals or something similar) 8< - - - - - snipped for brevity - - - - - >8
Assuming the test user space still exists, as root, in a terminal, create a backup of the broken configuration directory and decompress it in a safe testing space. Likewise, the properly functioning directory (remember to chmod the uid:gid.) Then throw a 'kitchen sink' of our powerful *nix cli tools at them. :) The -n "dry run" flag, below, writes no changes to disk; the standard output redirect creates a log of the changes that rsync would write if the -n flag were dropped. rsync -rvn ./brokenconfig/ ./workingconfig > rsync-log-broke-to-good.txt rsync -rvn ./brokenconfig/ ./workingconfig > rsync-log-good-to-broke.txt Scroll casually top to bottom through each of these files side-by-side and take notes. This is actually quite fun, as well as educational, if you haven't tried it. :) I prefer (and recommend) 'less' for this part simply because these files are likely to be very, very long. In a third terminal, you can employ grep with redirects to copy desired sections of interest out into smaller files that can be more easily opened and edited in your favorite text editor (Kate is fantastic for this IMHO.) The goals (at least /my/ goals) would be to a) locate and inspect the file or files that are responsible for the undesired behavior so I can safely test various edits one at a time until I find a 'fix' that works, and, b) create a master line by line listing of unnecessary (stale unused unneeded) files and directories so I can test to see if they can be safely eliminated from my working configuration. I realize this approach is kind of tedious. In certain situations, it might actually make more sense to migrate your data and any locally installed programs into the new (unbroken) user space and then swap them out (so you can ultimate delete the test user with the broken configuration and recover those computing resources.) These types of filesystem 'surgeries' are precisely why we have tools like rsync, chown and chmod available. :) That's my 2 cents and I wish you good luck! :) Carl
On 2022-08-07 06:55, David C. Rankin wrote:
On 8/5/22 08:28, Peter Suetterlin wrote:
David C. Rankin wrote:
Yup... sorry no silver bullet this time. Were it me, I'd
# useradd test
(set passwd, etc..)
Yes, did this, as expected it works there. So it must be somehow configuration related, probably some old setting that got changed meanwhile or similar (the machine was installed 6 years ago, since then only updates).
But I have no clue *where* the relevant config file is. ~/.config has 1GB. Finding something there isn't trivial. And nuking it is a no-go for sure. Would be easier if KDE wouldn't dump all configs directly under ~/.config, but in it's own subdirectory...
Config corruption is the Achilles heel for KDE5/Plasma. It hasn't improved much since kde4. The painful solution is the same though, move your config directory (I don't even know what it is now, last time I fought with it Plasma was dumping all individual config files in ~/.config and polluting the lot rather than doing the sane thing and putting configs in ~/.config/plasma or ~/.plasma or ~/.kde5 or something similar.
With KDE4 it was just move ~/.kde4 to ~/.kde4-sav (or similar) and restart the desktop. I hope all the plasma configs are now in a similar directory you can simply move and restart the desktop in the same way. If they are still all dumped as individual files under ~/.config --- that would be a Royal PITA.
XFCE has ~/.config/xfce4, but there is also ~/.cache/xfce4, plus many other programs that are part of xfce which have their own private config directories, so not fully clear that renaming the xfce4 directory would work. Example: ~/.config/autostart Then there are files in .config that are dated a decade ago... example: .config/pulse/cookie (2019) .config/suse/gnome-11.4-wallpaper-migrated (2011) I can not know if they are still used. -- Cheers / Saludos, Carlos E. R. (from 15.3 x86_64 at Telcontar)
in 15.4, kde desktop i can search (just enter type the word shade) for this feature on the kde start menu. or right click on any normal gui window title bar, and there is a menu submenu named "more actions"... and there is a shade stuff in there. never used this before.
* cagsm <cumandgets0mem00f@gmail.com> [08-04-22 16:47]:
in 15.4, kde desktop i can search (just enter type the word shade) for this feature on the kde start menu. or right click on any normal gui window title bar, and there is a menu submenu named "more actions"... and there is a shade stuff in there.
never used this before.
systemsettings5 -> window behavior -> titlebar actions in the topmost config section "titlebar actions", change double-click and/or mouse wheel to shade/unshade jftr: same place for quite a few years now. and it is not always known as "shade", sometime "rollup/rolldown" outside of plasma5/kde5. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet oftc
participants (6)
-
cagsm -
Carl Hartung -
Carlos E. R. -
David C. Rankin -
Patrick Shanahan -
Peter Suetterlin