[plasma4] [Bug 321781] kde 4.14.1+ git (with kde-workspace 4.11 git branch) back to 4.10.80: always new plasma activity at kde start.
https://bugs.kde.org/show_bug.cgi?id=321781 --- Comment #35 from Duncan <1i5t5.dun...@cox.net> --- FWIW, on kf5/plasma5 now and for I think a year or so now, and no sign of this bug. So anyone still on kde4/plasma4 and struggling with it, know that it does appear to be fixed in kf5/plasma5 -- you may wish to upgrade. =:^) (Meanwhile, my previous comment was worrying about semantic-desktop/baloo, whether it was required for plasma5. FWIW, until a few days ago it was indeed officially required for both plasma-desktop-5 and plasma-workspace-5, tho patching out the requirement and skipping build of the plasma components that required it was reasonably trivial and I was doing exactly that. But I can happily report that as of a few days ago, it's officially optional now, at least in live-git-kf5/plasma5, which I run via the gentoo/kde overlay live-git packages. =:^) And gentoo has already enabled the option again as the semantic-desktop USE flag, as well, at least for the live-git builds, tho it'll likely take some time to be released upstream and then to filter down to ~arch and stal^Hble for gentooers. But it's coming in gentoo, and for those who care enough to build it themselves, it's actually possible to use the official option to turn the baloo deps off at build-time, now, instead of having to carry their own patches to do it. So I'm reasonably happy with kde/plasma, now, and shouldn't have to worry about having to switch desktop environments for awhile. =:^) -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 372332] New: mouse kcm, advanced tab, pointer threshold minimum should be 0, not 1
https://bugs.kde.org/show_bug.cgi?id=372332 Bug ID: 372332 Summary: mouse kcm, advanced tab, pointer threshold minimum should be 0, not 1 Product: systemsettings Version: unspecified Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: kcm_mouse Assignee: unassigned-b...@kde.org Reporter: 1i5t5.dun...@cox.net CC: unassigned-b...@kde.org Target Milestone: --- In the mouse kcm, on the advanced tab, for the pointer threshold setting... The current minimum threshold is 1 pixel. It should be 0 pixels. The documentation I know of for this is the xset (1) manpage. Under option mouse (m), it says this about the threshold setting: > If the `threshold' parameter is provided and 0, the `acceleration' parameter will be used in the exponent of a more natural and continuous formula, giving precise control for slow motion but big reach for fast motion, and a progressive transition for motions in between. Recommended `acceleration' value in this case is 3/2 to 3, but not limited to that range. < That's exactly what I wanted, so I had my threshold set to 0 here... until I tried to adjust some other setting in the mouse kcm and set its minimum 1 px threshold instead. Now every time I restart kde/plasma I have a mouse that appears to be stuck in molasses, and while I can xset m 31/10 0 to get the speed back, it's back stuck in molasses when I restart kde again, because the 1 px minimum that plasma's mouse kcm sets apparently stuck! =:^( And indeed, xset q reports 31/10 1. So the mouse kcm needs to allow a 0 threshold, in ordered to enable people to set the "natural and continuous formula" acceleration by setting a 0 threshold. I guess I'll try to patch it myself, here, and will attach the patch here as well, if I get to it before someone from plasma does. Meanwhile, I suppose I'll have to dig thru thru the config files to find that setting and manually kill it, to get my 0 threshold "natural" acceleration formula back. =:^( (I'm running KF5/plasma live-git. kcmshell5 --version reports 5.8.90, ATM, but that's not an available choice in the version field above... and chances are it has had a 1 px minimum for some time, anyway, and I just got snared by it today.) -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 374310] Cannot build plasma-desktop without AppStreamQt installed
https://bugs.kde.org/show_bug.cgi?id=374310 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added CC||1i5t5.dun...@cox.net --- Comment #3 from Duncan <1i5t5.dun...@cox.net> --- Here's the reviewboard discussion and patches that made appstream required. https://git.reviewboard.kde.org/r/129697/ Third bullet-point in that list: "Drops PackageKit-Qt optional dependency, adds a required AppstreamQt dependency instead." You can read the discussion, but the decision was deliberate in that patch, and none of the core devs reviewing it objected. FWIW the Gentoo bug I opened on it, to either get appstreamqt in the gentoo/kde overlay (where the kde-live ebuilds are) and ultimately the main tree, and added as a (possibly patched to USE-flag optional) plasma-desktop dep, now for the live build, later for releases, or get the dependency patched back out or at least made optional. https://bugs.gentoo.org/show_bug.cgi?id=604356 But Gentoo's general policy, and certainly the gentoo/kde general policy, is to follow upstream where possible, tho the packagekit-qt dependency remained optional (via packagekit USE flag) as it was upstream, and masked via base-profile packagekit use-mask (as unready...) so unavailable unless users deliberately unmasked it as well, so the option was deliberately difficult to turn on. But gentoo/kde wouldn't make the baloo dependency optional until upstream did, so I was having to patch it out here on my own, as all that thing did here was cause trouble.[1] Which unfortunately looks like what I might be trying to do with this appstream thing, too, at least temporarily, to get plasma-desktop building again. The individual commit is of course easy enough to (effectively) revert, but how many commits going forward will be based on that one, potentially ultimately making patching it out unmaintainable in practice, is unknown. But it may be the easiest short-term solution to get plasma-desktop-live building again, until gentoo gets the appstream-qt package in-tree and initial deps worked out, at least. Beyond that, and actually even that since I've not actually tried the revert yet, to see what newer commits already depend on it, remains to be seen. Yea for freedomware, where we at least have the /option/ to do our own builds, including out-of-upstream patches if found necessary. =:^) --- [1] Baloo trouble: Build trouble due to weird symlink-related cmake issues that I never resolved since it was easier just to run an earlier cmake version and ultimately to patch out the baloo dep since I had no intention of using baloo anyway, and as with various kde4 tech indexes, space trouble if baloo was actually allowed to run because my /home's space budget doesn't include gigabytes extra for otherwise unnecessary and of little use indexing files. At least I'm 64-bit so baloo's known 32-bit index-file-size crashing issues didn't affect me. Hopefully this doesn't read too much like a rant. Baloo is officially optional on the plasma desktop again now, after all, thanks to plasma's devs making it so. But I was glad I was running freedomware and the option to patch it out was there (and relatively easy thanks to both plasma and gentoo making it so), when it wasn't officially optional. =:^) Credit where it's due! =:^) Hopefully appstream will ultimately be officially optional again, as well. =:^) Duncan -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 374310] Cannot build plasma-desktop without AppStreamQt installed
https://bugs.kde.org/show_bug.cgi?id=374310 --- Comment #5 from Duncan <1i5t5.dun...@cox.net> --- (In reply to Duncan from comment #4) > I'm going to try the d3923 patch to make appstream optional, next. FWIW, works fine here. I was able to update plasma-desktop for the first time in several days, and am now running my fresh builds. =:^) -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 374310] Cannot build plasma-desktop without AppStreamQt installed
https://bugs.kde.org/show_bug.cgi?id=374310 --- Comment #4 from Duncan <1i5t5.dun...@cox.net> --- Update: The devs are discussing a patch that makes appstream optional in d3923 on phabricator: https://phabricator.kde.org/D3923 Gentoo/kde did get an appstream-git ebuild in their overlay, and I hadn't tried patching the appstream dep out yet so I thought I'd try it, but appstream failed to build for me at head and at the 0.10.5 and 0.10.4 tags. Something about no *.gmo files in the po dir. So after updating the gentoo bug (which you can look at for the details, link's above) and now this one, I'm going to try the d3923 patch to make appstream optional, next. The good news is that the appstream dep /does/ appear to be reasonably lite, as these things go. No huge deps chain. While having it required is certainly irritating, assuming the broken building can be fixed, it looks like the dep is relatively lite, so a decision to keep it required isn't as severe as it might be. -- You are receiving this mail because: You are watching all bug changes.
[Plasma Workspace Wallpapers] [Bug 379003] Wallpaper "Picture of the Day" from National Geographics only changing after reboot or not at all.
https://bugs.kde.org/show_bug.cgi?id=379003 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added CC||1i5t5.dun...@cox.net --- Comment #1 from Duncan <1i5t5.dun...@cox.net> --- I run live-git plasma and frameworks via the gentoo/kde overlay, and saw this on the plasma-devel list, which I follow. The NatGeo PotD module seems to be broken, ATM, and doesn't work for me either. =:^( AFAIK, the change is on the NatGeo side, probably either a change to their POTD URL/page so the plasma natgeo-potd module doesn't pick it up any longer, or possibly it's their firewall interpreting all these automated update queries as abuse and blocking them based on for instance number of queries within N hours from the same IP address (would still work for new users for a short time), or on useragent (would be broken for all plasma users), or something else from the queries they can log and block. I hope it can be updated to fix the problem, but if it is indeed a NatGeo firewall block, any fix is likely to be temporary, unless it's actually coordinated with the NatGeo website folks. But FWIW, the bing PotD is now working. When I first noticed it, attempting to select and apply would crash plasmashell and attempting to restart would would only crash it again, until the config file was manually edited to point to something other than the bing potd. I saw a recent commit that said it should fix that, and indeed, now the bing potd actually works. =:^) Well at least you know it's not only you, now. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kcoreaddons] [Bug 387983] New: kcoreaddons git commit fbc5881b9 breaks kwin build
https://bugs.kde.org/show_bug.cgi?id=387983 Bug ID: 387983 Summary: kcoreaddons git commit fbc5881b9 breaks kwin build Product: frameworks-kcoreaddons Version: unspecified Platform: Gentoo Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: mp...@kde.org Reporter: 1i5t5.dun...@cox.net CC: kdelibs-b...@kde.org Target Milestone: --- kcoreaddons commit fbc5881b9 (current head) breaks building kwin. I'm running gentoo, with most kde packages from live-git using the gentoo/kde overlay. Today, kwin refused to update, and even pinning to the currently installed commit wouldn't allow it to build due to an automoc error. I traced it down to kcoreaddons, and bisected there to current head, fbc5881b9. Using the previous commit, kwin builds fine. Here's the error from the log: make[2]: Entering directory '/tmp/portage/kde-plasma/kwin-/work/kwin-_build' AutoMoc: Checking: /tmp/portage/kde-plasma/kwin-/work/kwin-/kcmkwin/kwinscripts/main.cpp AutoMoc error - "/tmp/portage/kde-plasma/kwin-/work/kwin-/kcmkwin/kwinscripts/main.cpp" The file contains a K_PLUGIN_FACTORY macro, but does not include "main.moc"! Consider to - add #include "main.moc" - enable SKIP_AUTOMOC for this file AutoMoc: Checking: /tmp/portage/kde-plasma/kwin-/work/kwin-/kcmkwin/kwinrules/detectwidget.cpp AutoMoc: Checking: /tmp/portage/kde-plasma/kwin-/work/kwin-/kcmkwin/kwinrules/kcm.cpp AutoMoc: Checking: /tmp/portage/kde-plasma/kwin-/work/kwin-/kcmkwin/kwinrules/kwinsrc.cpp AutoMoc: Checking: /tmp/portage/kde-plasma/kwin-/work/kwin-/kcmkwin/kwinrules/ruleslist.cpp AutoMoc: Checking: /tmp/portage/kde-plasma/kwin-/work/kwin-/kcmkwin/kwinrules/ruleswidget.cpp AutoMoc: Checking: /tmp/portage/kde-plasma/kwin-/work/kwin-/kcmkwin/kwinrules/detectwidget.h AutoMoc: Checking: /tmp/portage/kde-plasma/kwin-/work/kwin-/kcmkwin/kwinrules/kcm.h AutoMoc: Checking: /tmp/portage/kde-plasma/kwin-/work/kwin-/kcmkwin/kwinrules/ruleslist.h make[2]: *** [kcmkwin/kwinscripts/CMakeFiles/kcm_kwin_scripts_autogen.dir/build.make:58: kcmkwin/kwinscripts/CMakeFiles/kcm_kwin_scripts_autogen] Error 1 The full failing kwin build log and additional info can be found in the gentoo bug (opened before I figured out the problem) https://bugs.gentoo.org/show_bug.cgi?id=641436 -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 393412] Dolphin fails to build with disabled support for Baloo
https://bugs.kde.org/show_bug.cgi?id=393412 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added CC||1i5t5.dun...@cox.net -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 393881] Desktop widget position lost after reboot
https://bugs.kde.org/show_bug.cgi?id=393881 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added CC||1i5t5.dun...@cox.net --- Comment #3 from Duncan <1i5t5.dun...@cox.net> --- This is very likely a dup of (my) bug #389141, filed back when the problem was probably still in unreleased live-git only. Unfortunately it wasn't fixed, tho I can't say my bug report was as good a quality as I'd have liked and I never did get the bisect done I wanted to do. I too have two displays, one a 4k/3840x2160, the other a full-hd/1920x1080. Tho in my case the problem appeared after the screen-blanker activated (no lockscreen configured) and the monitors, having no signal any longer, automatically turned off, when I turned them back on -- no actual need to logout/reboot. Another difference, my higher-res 4k primary is to the right of the full-hd secondary, while in your case it's to the left. But an additional behavior detail I noticed after I filed the bug, that I had been meaning to add, that from your screenshots applies in your case to: Plasmashell is apparently mistakenly repositioning the widget to conform to the lower full-hd resolution of the /other/ monitor in an effort to keep it in-frame/on-monitor, failing to account for the larger 4k resolution of the monitor it's actually on. With the monitor-relative 0,0 origin at top-left and the 4k monitor being twice the resolution of the smaller one in each direction, the top-left quadrant is the monitor-relative size and position of the smaller monitor, so the repositioning is into it. Thus, anything outside the top-left quadrant will be repositioned into it, while anything in it should stay where it is. Hopefully with this additional description of the apparent repositioning trigger for the bug we're both seeing, they can figure out what's going wrong and patch it. =:^) Meanwhile, here's a workaround (assuming you can't just put your widgets into the top-left quadrant as a workaround) that I've been using here that should help: Find the plasma-org.kde.plasma.desktop-appletsrc file in your config (my settings are customized but check in ~/.config and its subdirs) and set it read-only when it has the correct config (as it should if you setup the widgets as you want and then killall plasmashell, you can restart it again from krunner after setting the file readonly). That should prevent the bad positioning from being written to the file, but note that you'll need to set it writable again to make other changes to your widgets and panels or most of them (the ones saved in that file) won't save either. With the file set read-only, I'm not sure if plasma will set the correct position at bootup/login, it may depend on the monitor detection and setup sequence as plasma starts up, but if not you can always killall plasmashell and restart it again, and it should then load the correct config. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 393881] Desktop widget position lost after reboot
https://bugs.kde.org/show_bug.cgi?id=393881 --- Comment #4 from Duncan <1i5t5.dun...@cox.net> --- *** Bug 389141 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 389141] plasmoids won't stay put after monitors off for a few hours (live-git regression I believe only a few days old)
https://bugs.kde.org/show_bug.cgi?id=389141 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Duncan <1i5t5.dun...@cox.net> --- This is almost certainly a dup of bug #393881 . That's a later bug but it has screenshots and a cleaner description, so I'm making this one a dup of it. *** This bug has been marked as a duplicate of bug 393881 *** -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 393788] Window rules editing broken
https://bugs.kde.org/show_bug.cgi?id=393788 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Status|UNCONFIRMED |CONFIRMED Ever confirmed|0 |1 --- Comment #5 from Duncan <1i5t5.dun...@cox.net> --- (In reply to Martin Flöser from comment #4) > I found the change which introduced the regression and have a patch for it: > https://phabricator.kde.org/D12706 > > Luckily it's only in master branch. Applied locally and confirmed that it fixes the bug here. Nice to have new rule changes working again! Lots easier than editing the file manually! Thanks. Looking forward to seeing it in git after review. =:^) -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 395555] New: konsole commit e1f7107cc breaks -e option
https://bugs.kde.org/show_bug.cgi?id=39 Bug ID: 39 Summary: konsole commit e1f7107cc breaks -e option Product: konsole Version: master Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: konsole-de...@kde.org Reporter: 1i5t5.dun...@cox.net Target Milestone: --- I have a number of scripts that call konsole with the -e option. After my last update, they broke -- konsole -e no longer executes the given command, it simply gives me the usual command prompt. A bisect says it's e1f7107cc to blame. The commit before that still works. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 395555] konsole commit e1f7107cc breaks -e option
https://bugs.kde.org/show_bug.cgi?id=39 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Status|UNCONFIRMED |CONFIRMED Ever confirmed|0 |1 --- Comment #1 from Duncan <1i5t5.dun...@cox.net> --- Confirming it's commit e1f7107cc. Reverting that on top of current 48448131e gives me a working -e option. (It's gentoo/kde live-git packages so I can apply a patch by simply dropping it in the appropriate dir and rebuilding, as I did here for the revert, redirecting the output of git show -R, if you need me to test further patches.) -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 395925] gwenview main menu broken
https://bugs.kde.org/show_bug.cgi?id=395925 --- Comment #1 from Duncan <1i5t5.dun...@cox.net> --- e41d0a9b5, merge 17.12 on March 2, is good. 785281b76, March 19 and master side of merge c6e514eef branch 18.04 on March 20, is bad. So the culprit is in the series of master-side commits between e41d0a9b5 on March 2 and 785281b76 on March 19. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 395925] gwenview main menu broken
https://bugs.kde.org/show_bug.cgi?id=395925 --- Comment #2 from Duncan <1i5t5.dun...@cox.net> --- And the culprit is... 9631043c1 March 2, 2018 Expose slideshow to MPRIS controllers 8bd2f625c, the previous commit, is fine. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 395925] gwenview main menu broken
https://bugs.kde.org/show_bug.cgi?id=395925 --- Comment #3 from Duncan <1i5t5.dun...@cox.net> --- FWIW... I'm not a dev, so while I can bisect and read the source of a culprit commit, it doesn't necessarily tell me what might be wrong like it might to a dev. But it may be worth noting that I have (gentoo/kde's) semantic-desktop USE flag turned off. That means no baloo or kfilemetadata here. Related? And based on the qdbus in the commit code, suspecting the version of it I'm running might make a difference. It's qdbus-5.11.0_rc2 (qt 5.11-rc2 being the latest available in the gentoo tree, satisfying the > 5.10 dep of parts of plasma now, as there's no qt-5.10 in the gentoo tree). -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 395807] Closing an application crashes Kwin (aurora on x11)
https://bugs.kde.org/show_bug.cgi?id=395807 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Summary|Closing an application |Closing an application |crashes Kwin|crashes Kwin (aurora on ||x11) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 395807] Closing an application crashes Kwin (aurora on x11)
https://bugs.kde.org/show_bug.cgi?id=395807 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Flags||X11+ -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 395807] New: Closing an application crashes Kwin
https://bugs.kde.org/show_bug.cgi?id=395807 Bug ID: 395807 Summary: Closing an application crashes Kwin Product: kwin Version: git master Platform: Gentoo Packages OS: Linux Status: UNCONFIRMED Severity: crash Priority: NOR Component: aurorae Assignee: kwin-bugs-n...@kde.org Reporter: 1i5t5.dun...@cox.net CC: familieku...@arcor.de, k...@davidedmundson.co.uk, kwin-bugs-n...@kde.org, now.im@gmail.com, pmaiol...@gmail.com Depends on: 395346 Target Milestone: --- +++ This bug was initially created as a clone of Bug #395346 +++ kwin git master head at e69da579f, using gentoo/kde's overlay repo kde live-git packages and qt-5.11.0-rc2 (latest available in gentoo main repo). Git commit 275b7ee0f apparently fixed a crash on kwin-wayland with aurora windecos, referring to the bug I cloned for this one. But it breaks kwin_x11 in the same way it fixes kwin_wayland -- closing a window with an aurora windeco set crashes kwin_x11! Confirmed that it's aurora windecos only by trying breeze (ok), oxygen (ok) and plastik (broken, believed to be aurora). Confirmed that reverting just that commit on current master head ( e69da579f ) fixes the problem. Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=395346 [Bug 395346] Closing an application crashes Kwin -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 395346] Closing an application crashes Kwin
https://bugs.kde.org/show_bug.cgi?id=395346 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Blocks||395807 Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=395807 [Bug 395807] Closing an application crashes Kwin -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 395925] New: gwenview main menu broken
https://bugs.kde.org/show_bug.cgi?id=395925 Bug ID: 395925 Summary: gwenview main menu broken Product: gwenview Version: Git (add output of "git log -1 --oneline" to description) Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: gwenview-bugs-n...@kde.org Reporter: 1i5t5.dun...@cox.net Target Milestone: --- git master of pretty much anything kde, including gwenview, frameworks, plasma, etc, built from the gentoo/kde overlay, which has the live-git kde ebuild versions. For gwenview, currently at ef1244b1c . Gwenview's main menu has been broken for some months now, leading to a delay of some time while launching gwenview, apparently waiting for some timeout. I don't use the menu a lot so it took me awhile to figure out what the problem was, but a few days ago I straced a gwenview's startup and it stopped for a long time at some menu related stracing output. After it did finally show the gwenview window, I tried the menu (now launched from a button in the titlebar), and got no response -- no menu showed, tho that wasn't surprising after I had seen where the strace output stopped as gwenview started. I've noticed no other apps with menu issues, only gwenview. With further experimenting, I discovered that if I took the menu button off the titlebar in kde system settings, windecos, buttons tab, then started gwenview, which of course wouldn't have a menu button in the titlebar at that point and would start normally, /then/ added the titlebar menu button back in kde system settings, /then/ gwenview would have a menu. Further, quitting gwenview and restarting it once it had the menu, it would start fast and have the menu each time... until I quit and restarted kde/plasma, after which gwenview would take a long time to startup again, and the menu button wouldn't work. However, just toggling the windeco menu button off, applying, and back on, applying, without starting gwenview while the windeco menu button was turned off, would not be enough to get gwenview showing its menu again -- I had to actually start gwenview with the menu button disabled, then add it again, for gwenview to actually have a menu and startup fast again for the rest of that plasma session. So tonight I started trying to bisect when the problem appeared. I've not finished the bisect yet, but as of the d0d97b8e1 merge of the 18.04 branch on April 8, the problem was already happening, while if I go back to the 2522e7e7e merge of 17.12 back on Feb 27, the menu was still working fine. Since I can revert back to Feb 27's state and get a working menu, the problem has been demonstrated to be in gwenview's code since then, so I thought I'd file this bug before finishing the bisect, on the off change a gwenview dev both had a good idea what might have caused it and had time to work on it before I finished the bisect. I'll continue the bisect and file an update as I have time. (I should be sleeping as I have work in a few hours.) -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 395555] konsole commit e1f7107cc breaks -e option
https://bugs.kde.org/show_bug.cgi?id=39 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #7 from Duncan <1i5t5.dun...@cox.net> --- Verified fixed, thanks. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 393788] New: Window rules editing broken
https://bugs.kde.org/show_bug.cgi?id=393788 Bug ID: 393788 Summary: Window rules editing broken Product: kwin Version: git master Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: rules Assignee: kwin-bugs-n...@kde.org Reporter: 1i5t5.dun...@cox.net Target Milestone: --- The window rules kcm GUI won't save changes. It will load existing rules from kwinrulesrc (as does kwin itself) and changes will appear to save -- hitting the apply button causes it to go inactive, but: 1) kwin doesn't actually act on them (even after hitting apply). 2) switching to another kcm (say kwin scripts) and back to window rules, the changes were not saved and I get the same rule as when I loaded it the first time. 3) kwinrulesrc isn't actually changed (yes, it's appropriate 0600 perms). Running gentoo/kde's live-git of frameworks and plasma as well. Currently running qt-5.11.0_beta4 as plasma-live-git is now requiring > 5.10, and gentoo doesn't have 5.10 in-tree, only 5.11_beta4. However, this bug triggered before that upgrade. This has apparently been broken in kwin on X at least for months, as when I unmerged superkaramba (my last kde4 app, so I could unmerge kde4/qt4, still nothing with superkaramba's full set of features for plasma5 that I can find, but this bug isn't about that...) and setup ksysguard graphing to replace what I could of superkaramba, I ended up having to manually edit kwinrulesrc in ordered to get a working rule for ksysguard, and that was a couple months ago or so. I have a somewhat large but reasonably stable set of kwin window rules and hadn't needed to edit any of them for some time before that, so I've no idea how long it has actually been broken. Fortunately, I can still edit the kwinrulesrc file manually and the changes do take (after restarting kde/plasma, and I think after simply running kwin_x11 --replace, tho I'd have to check that again to be sure), but it'd sure be nice to have a working GUI editor back again! (The current trigger to file the bug was full-screening a game that changed the resolution and left the desktop a mess. I quit and restarted kde/plasma/X, and got the desktop back, but firefox restarted at 0,15 which on my multi-monitor setup is offscreen. I tried to edit an existing window rule for it to reposition it onscreen, but found the GUI editor still not saving changes, so that didn't work. Fortunately I have wmctrl installed, and a wmctrl -R firefox did the trick!) I suppose none of the devs have seen it due to running wayland these days. (BTW, is plasma-wayland usable now, and can you point me at a good article describing how to configure it analogous to xorg.conf.d? Or is the only way to configure plasma-wayland via the plasma-wayland GUI? I haven't had much luck with multi-monitor config GUIs such as kscreen on X/kde/plasma -- while they do work sometimes, they're often broken bad enough to be unusable (leaving me with a sufficiently broken desktop that I must restart X/kde/plasma, I had to studiously avoid that kcm for awhile, as even opening it would screw things up!), so I tend to avoid them, and while xrandr has at least worked more consistently, simply configuring the layout in xorg.conf.d and not touching it from the GUI has been most reliable. So you can see why I'm hoping there's a wayland analog to xorg.conf.d, despite my not seeing /anything/ about it in the various Linux-related news feeds I follow. So a link to a good article on the topic would be extremely useful!) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 393788] Window rules editing broken
https://bugs.kde.org/show_bug.cgi?id=393788 --- Comment #2 from Duncan <1i5t5.dun...@cox.net> --- (In reply to Martin Flöser from comment #1) > Which KWin version are you using? All of kde/plasma/frameworks is live-git. kwin --version reports 5.12.80, and git show in kwin's repo reports c0226fe74 from Apr 26, but as I said it has been at least a few weeks because (see original report). > I consider it very unlikely that such a > central part of KWin could be broken. I at least created a window rule on > X11 today. Did it actually apply and save? Note that I can create and change rules, and hitting OK on the individual rule dialog and then apply in the kcm /appears/ to create and save it -- no visible errors -- but it doesn't actually get saved or affect the window it's supposed to, either -- when I switch to a different kcm and back to reload, the edited rule is just as it was before the edit, and new rules simply aren't there any more. What I'm /wondering/ is if whatever framework actually saves the changes changed out from under the API the kcm is using to invoke it and the kcm wasn't synced to the changes, with the changes not enough to error out, just enough so the save isn't happening (or maybe it is but to a different location, so it's written to one but read from another). What framework might that be? I might try rolling it back a couple months and see if it makes a difference. Of course if I knew which one I could report specific git commit on it then as well. There are a few non-default factors in my setup that could be involved as well. In particular, I have KDEHOME, KDETMP, KDEVARTMP, XDG_CACHE_HOME, XDG_CONFIG_HOME, and XDG_DATA_HOME set. If there's a hard-coded path (maybe a place where the default path isn't overridden in the var is set) or one using a different var for read vs. write, it would lead to exactly this sort of symptoms, that would likely not duplicate at all on a system with these vars unset so it uses the default settings. >From konsole (so with the KDE/X env): $ export | grep 'KDE\|XDG\|HOME' declare -x HOME="/h/x" declare -x KDEHOME="/h/x/kde" declare -x KDETMP="/h/x/tmp/kde" declare -x KDEVARTMP="/h/x/tmp/cache" declare -x KDE_FULL_SESSION="true" declare -x KDE_NO_IPV6="1" declare -x KDE_SESSION_UID="501" declare -x KDE_SESSION_VERSION="5" declare -x KDE_UTF8_FILENAMES="1" declare -x PROFILEHOME="~" declare -x XDG_CACHE_HOME="/h/x/tmp/cache" declare -x XDG_CONFIG_DIRS="/etc/xdg" declare -x XDG_CONFIG_HOME="/h/x/config" declare -x XDG_CURRENT_DESKTOP="KDE" declare -x XDG_DATA_DIRS="/usr/local/share:/usr/share" declare -x XDG_DATA_HOME="/h/x/config/share" declare -x XDG_RUNTIME_DIR="/run/user/501" declare -x XDG_SEAT="seat0" declare -x XDG_SESSION_ID="c1" declare -x XDG_VTNR="1" -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 389141] New: plasmoids won't stay put after monitors off for a few hours (live-git regression I believe only a few days old)
https://bugs.kde.org/show_bug.cgi?id=389141 Bug ID: 389141 Summary: plasmoids won't stay put after monitors off for a few hours (live-git regression I believe only a few days old) Product: plasmashell Version: master Platform: Gentoo Packages OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Desktop Containment Assignee: se...@kde.org Reporter: 1i5t5.dun...@cox.net CC: plasma-b...@kde.org Target Milestone: 1.0 Live-git of frameworks/apps/plasma (tho not kdelibs4, still around to run superkaramba since there's no known non-coder plasma5 alternative to it and I've not had time to test and configure a non-kde alternative), built from the gentoo/kde overlay live-build ebuilds. I frequently sleep with a multi-hour rain video playing, turning off the monitors. A couple days ago I did that, and when I turned the monitors on when I woke up, the plasmoids had repositioned themselves, with two (of three) on top of each other in the center of the monitor, and one centered vertically but hard-left. Just shutting the monitors off for a couple minutes doesn't seem to duplicate the issue, but I had it happen again last nite (monitors off but no video playing this time, to see if it would trigger again), so it seems duplicable if I leave the monitors off for long enough... over nite or so. I do have two monitors and the plasmoids did stay on the correct one, just repositioned from where they were supposed to be. I only have the one activity, however, so don't know if it would have affected other activities. The single configured panel appears unaffected. The frustrating thing is that despite my having widgets locked, restarting plasmashell left them repositioned, so their new location is being written to what /was/ the working just fine rc file, and I have to manually unlock widgets to reposition them back where they belong. This is, unfortunately, giving me flashbacks to plasma4 bug 321781 (filed against the beta where it first appeared and should have been easy to trace, unfortunately without dev comment until far later when it was far harder to trace, so never fixed, hopefully this one fairs better), which I ended up coping with by setting the affected config files read-only so they wouldn't be overwritten and I could restart plasma-desktop, now plasmashell, and get my setting sback. I'm going to try to bisect this one, but may end up trying the same read-only config file and restarting plasmashell trick. (I already have a hotkey for it... along with others to restart kwin, krunner, sni-proxy, etc. A bit like replacing critical parts of a plane in mid-air, but I must say it works surprisingly well most of the time!) I can try uninstalling kscreen as well. I've had problems with it screwing up my perfectly satisfactory xorg.conf configuration in the past and had it uninstalled for awhile to prevent that, but it's installed again now, and things had been fine for months until this bug showed up, apparently within the last week or so. More information to follow once I try bisecting and/or without kscreen, but I decided I better file this now, or I might not end up filing it at all. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 395925] gwenview main menu broken
https://bugs.kde.org/show_bug.cgi?id=395925 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Attachment #113637|0 |1 is obsolete|| --- Comment #10 from Duncan <1i5t5.dun...@cox.net> --- Created attachment 113829 --> https://bugs.kde.org/attachment.cgi?id=113829=edit Updated hack-around partial-revert patch Only the mainwindow.cpp mainwindow::mainwindow chunk of the original commit/patch needs reverted -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 395925] gwenview main menu broken
https://bugs.kde.org/show_bug.cgi?id=395925 --- Comment #11 from Duncan <1i5t5.dun...@cox.net> --- (In reply to Duncan from comment #8) > (In reply to Henrik Fehlauer from comment #6) > > @Duncan: Could you quantify how long regular and slow startup is taking for > > you each, i.e. barely noticable, seconds, or minutes? > > Regular startup: Under 1 second. > Slow startup: I've not timed it I've (rough-)timed it now. 25 seconds, +/-2, to window appearance. As I said I'm on ssd and used to near-instant, so it's definitely long enough to get bored and fire up a kpat or ksuduko to play while I wait, tho of course I don't /finish/ a game before it appears. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 395925] gwenview main menu broken
https://bugs.kde.org/show_bug.cgi?id=395925 --- Comment #12 from Duncan <1i5t5.dun...@cox.net> --- (In reply to Duncan from comment #3) > And based on the qdbus in the commit code, suspecting the version of it I'm > running might make a difference. It's qdbus-5.11.0_rc2 (qt 5.11-rc2 being > the latest available in the gentoo tree, satisfying the > 5.10 dep of parts > of plasma now, as there's no qt-5.10 in the gentoo tree). Updated to qt-5.11.1 now. Didn't change things. Further notes: Based on a the menu timeout stalling the creation of the window and a hunch I tried simply patch-moving the mpris setup call to /after/ the createGUI() and loadConfig() calls instead of deleting it as in the current hack-around patch... and gwenview loaded fine, its menu worked, etc, with no ill effects that I could see (tho the media keys didn't work in the slide-show, but then they never have for me so that's not a change). I see both the kipi and osx ifdefs are after createGUI and loadConfig too. If the mpris ifdef could likewise be moved lower in the function, and still work to setup mpris, that does seem to solve the menu problem I'm seeing too. mpris? Perhaps this requires a component that I don't have installed, that's not tested for and optionally required to enable this functionality, simply assumed to be installed? Dumb non-dev speculation, but maybe it's actually an mpris dbus call that's not getting a response, because whatever it's trying to call isn't installed, and that's blocking the menu setup dbus call so it doesn't get a response either? If so and you guys have that mystery mpris component installed, that could explain why you're not duplicating. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 389141] plasmoids won't stay put after monitors off for a few hours (live-git regression I believe only a few days old)
https://bugs.kde.org/show_bug.cgi?id=389141 --- Comment #1 from Duncan <1i5t5.dun...@cox.net> --- Removing kscreen and libkscreen didn't help. I'm testing a read-only plasma-org.kde.plasma.desktop-appletsrc next. I suspect (based on using the technique in plasma4 with the previously mentioned bug) the plasmoids will still move out of place, but hopefully the new place won't be saved so at least a simple plasmashell restart will get them back in place. Another possibility I thought of, I'm running kernel 4.15-rc8+ (live-git just like my kde stuff), and it seems the drm changed a bit this cycle. Now when I start X or after several hours with the monitors off, I get kernel-drm log entries when I turn the monitors back on. Those are new with 4.15, so it's possible they're triggering the new plasmashell behavior as well. If so and plasmashell behavior isn't changed, get ready for more bug filings when it releases and especially when distros start shipping it. Something else I need to test... -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 389141] plasmoids won't stay put after monitors off for a few hours (live-git regression I believe only a few days old)
https://bugs.kde.org/show_bug.cgi?id=389141 --- Comment #2 from Duncan <1i5t5.dun...@cox.net> --- As suspected, setting ...plasma.desktop-appletsrc read-only resulted in the bug still occurring but in live memory only, so restarting plasmashell got me back a desktop with the plasmoids at their configured locations. So at least I know how to keep the screwed up locations from saving now and I can easily get back to the properly configured layout. =:^) -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 391504] New: spectacle git 3b69ac3a7 fails to build, deletes a needed #include line from KSMainWindow.cpp
https://bugs.kde.org/show_bug.cgi?id=391504 Bug ID: 391504 Summary: spectacle git 3b69ac3a7 fails to build, deletes a needed #include line from KSMainWindow.cpp Product: Spectacle Version: unspecified Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: General Assignee: m...@baloneygeek.com Reporter: 1i5t5.dun...@cox.net Target Milestone: --- spectacle git commit 3b69ac3a7 says: Test Plan: If it compiles, all is fine. Unfortunately, it doesn't, and all is /not/ fine. =:^( Long story short, the commit removes an #include line from KSMainWindow.cpp and that breaks the build. With just that include line reinserted the build completes and spectacle appears to run just fine. The details... Running gentoo/~amd64 with most of my kde packages from live-git using the live ebuilds in the gentoo/kde overlay, I had /just/ updated the general system and then all my kde-live-git packages and spectacle built fine, then ran a redo to check in more detail a couple other packages that wouldn't build and happened to catch this commit within minutes of its merge... gcc-7.3.0, qt*-5.9.4, and interestingly based on the error below, the brand new and just updated xcb-proto-1.13 (as it happens I follow the xorg announce list and it was announced on Monday, March 5, 2018, so indeed brand new, the gentoo xorg folks are on the ball =:^). However, I tried downgrading to xcb-proto-1.12 (gentoo -r2 revision), the previously installed version, and the spectacle build still failed with the same error, so it does /not/ appear to be related to the new xcb-proto version after all. Here's the first set of errors and sure enough, KSMainWindow.cpp was touched by the above commit. Looking at the commit and the error, and testing, it's actually the removal of the #include line. If I reinsert just that line, the build completes and spectacle runs just fine: [ 95%] Building CXX object src/CMakeFiles/spectacle.dir/spectacle_autogen/2Z24QZD4NU/qrc_QmlResources.cpp.o cd /tmp/portage/kde-apps/spectacle-/work/spectacle-_build/src && /usr/lib64/ccache/bin/x86_64-pc-linux-gnu-g++ -DKCOREADDONS_LIB -DQT_CONCURRENT_LIB -DQT_CORE_LIB -DQT_DBUS_LIB -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_NO_CAST_FROM_ASCII -DQT_NO_CAST_TO_ASCII -DQT_NO_DEBUG -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_NO_URL_CAST_FROM_STRING -DQT_PRINTSUPPORT_LIB -DQT_QML_LIB -DQT_QUICK_LIB -DQT_USE_QSTRINGBUILDER -DQT_WIDGETS_LIB -DQT_X11EXTRAS_LIB -DQT_XML_LIB -D_GNU_SOURCE -D_LARGEFILE64_SOURCE -I/tmp/portage/kde-apps/spectacle-/work/spectacle-_build/src -I/tmp/portage/kde-apps/spectacle-/work/spectacle-/src -I/tmp/portage/kde-apps/spectacle-/work/spectacle-_build/src/spectacle_autogen/include -isystem /usr/include/qt5 -isystem /usr/include/qt5/QtConcurrent -isystem /usr/include/qt5/QtCore -isystem /usr/lib64/qt5/mkspecs/linux-g++ -isystem /usr/include/qt5/QtDBus -isystem /usr/include/qt5/QtPrintSupport -isystem /usr/include/qt5/QtWidgets -isystem /usr/include/qt5/QtGui -isystem /usr/include/qt5/QtQuick -isystem /usr/include/qt5/QtQml -isystem /usr/include/qt5/QtNetwork -isystem /usr/include/KF5/KCoreAddons -isystem /usr/include/KF5 -isystem /usr/include/KF5/KDBusAddons -isystem /usr/include/KF5/KWidgetsAddons -isystem /usr/include/KF5/KNotifications -isystem /usr/include/KF5/KConfigCore -isystem /usr/include/KF5/KI18n -isystem /usr/include/KF5/KIOWidgets -isystem /usr/include/KF5/KIOCore -isystem /usr/include/KF5/KService -isystem /usr/include/KF5/KJobWidgets -isystem /usr/include/KF5/KCompletion -isystem /usr/include/KF5/KWindowSystem -isystem /usr/include/KF5/KXmlGui -isystem /usr/include/qt5/QtXml -isystem /usr/include/KF5/KConfigWidgets -isystem /usr/include/KF5/KCodecs -isystem /usr/include/KF5/KConfigGui -isystem /usr/include/KF5/KAuth -isystem /usr/include/KF5/KDeclarative -isystem /usr/include/KF5/KPackage -isystem /usr/include/KF5/KNewStuff3 -isystem /usr/include/KF5/KNewStuff3/KNS3 -isystem /usr/include/KF5/KNewStuff3/knscore -isystem /usr/include/KF5/KNewStuff3/kns3 -isystem /usr/include/KF5/KNewStuff3/KNSCore -isystem /usr/include/KF5/Attica -isystem /usr/include/qt5/QtX11Extras -DQT_NO_DEBUG -DNDEBUG -march=native -pipe -O2 -fmerge-all-constants -fgcse-sm -fgcse-las -fgcse-after-reload -ftree-vectorize -std=c++0x -fno-operator-names -fno-exceptions -Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef -Wnon-virtual-dtor -Woverloaded-virtual -Werror=return-type -Wvla -Wdate-time -fvisibility=hidden -fvisibility-inlines-hidden -fPIC -std=gnu++11 -o CMakeFiles/spectacle.dir/spectacle_autogen/2Z24QZD4NU/qrc_QmlResources.cpp.o -c /tmp/portage/kde-apps/spectacle-/work/spectacle-_build/src/spectacle_autogen/2Z24QZD4NU/qrc_QmlResources.cpp
[gwenview] [Bug 395925] gwenview main menu broken
https://bugs.kde.org/show_bug.cgi?id=395925 --- Comment #8 from Duncan <1i5t5.dun...@cox.net> --- (In reply to Henrik Fehlauer from comment #6) > > gwenview would take a long time to startup again > @Duncan: Could you quantify how long regular and slow startup is taking for > you each, i.e. barely noticable, seconds, or minutes? Note that I'm on (btrfs on) ssd, so even cold-cache startups /should/ be fast. Regular startup: Under 1 second. I suspect the kwin slide-in effect is actually delaying the window appearance. (I have gwenview's clear-thumbnails on exit option set, and actually have the thumbnails dir pointed to tmpfs, so from cold-cache it does take a slight bit of time to generate the thumbnails on the start-page's recent-folders tab, but the dir icons themselves show up effectively instantly and the thumbnails on them populate in under 10 seconds, I'd say.) Slow startup: I've not timed it and perception is notoriously unreliable, but the window doesn't show up for long enough I can launch say kpat and start playing a game, before it shows up. Stracing a slow-start it's quite clear there's some sort of timeout (later diagnosed as the menu load timeout) it waits for, as there's the usual rush of multiple pages of output as it reads all the libs/icons/fonts/config/etc, followed by a pause of I'd say at least 30 seconds, perhaps a minute or two (it was long enough I could select some strace output so I could scroll back to it after the window /did/ show to see where things stopped and notice it was menu related, the clue I needed to test and see that the menu button in the titlebar wasn't responsive), while nothing at all is printed, before it resumes printing more pages of output as the window appears and it regenerates thumbnails for the start page. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 395925] gwenview main menu broken
https://bugs.kde.org/show_bug.cgi?id=395925 --- Comment #9 from Duncan <1i5t5.dun...@cox.net> --- Created attachment 113637 --> https://bugs.kde.org/attachment.cgi?id=113637=edit Hack-around partial-revert patch Once I bisected to a single commit I had a patch I could try to revert. But based on the error when I tried there were a couple files that have further changed in that area since then and the revert wouldn't cleanly apply. So I semi-blind (as I'm not a dev) deleted the chunks that added (and the revert would have deleted) the new files, along with the two conflicting chunks (lib/slideshow.(cpp|h)), and tried that, not even knowing whether gwenview at head would build then, let alone run, but it did. And it indeed did eliminate the problem -- I have my gwenview menus back, on (yesterday's) current gwenview, with the partial revert, of course. Here's that semi-blind hack-around partial revert patch. While I don't expect it to help much in getting a proper fix, it does confirm that commit as the culprit, and lets you see what I did to get a menu on otherwise-current gwenview back. I can test debugging or alternative patches too, if needed. Gwenview rebuilds fast, especially with a hot ccache. =:^) -- You are receiving this mail because: You are watching all bug changes.
[ksudoku] [Bug 405422] ksudoku live-git (commit 09814312d) small-game generation fails with "Unable to generate a puzzle of the chosen variant"
https://bugs.kde.org/show_bug.cgi?id=405422 --- Comment #2 from Duncan <1i5t5.dun...@cox.net> --- (In reply to Ian Wadham from comment #1) > I used to be maintainer/developer for KSudoku, but am out of touch with it > now. However I will try to help narrow this problem down. Thanks. > The message you are getting seems to be from the "welcome" screen (where you > choose a puzzle type). It was added to the code in April 2017, see > https://phabricator.kde.org/D5671. I did grep the error in the source, trying to see if I as a non-coder but reasonably experienced gentoo user/admin who routinely runs live-git of selected packages, reading git logs and sometimes generating patches on my own (I had some basic and pascal classes back in the day and back before I left MS behind did intermediate visual basic, but only really know bash on Linux), could figure out what was triggering it, but no real luck beyond finding out it was in the welcome-screen code, as you mention. I'm not familiar with the (from memory) color-coding generation as mentioned in the comments, so saw the numbers lists associated with some of the games but don't understand the generation mechanism and was too tired to reason it further, so left it at that. > Do you stay on the welcome screen after you see the message? Please confirm. Yes. I stay on the welcome (aka game chooser) screen. The message is a popup asking me to choose another game, so staying on the chooser screen is to be expected. > Please can you give me a precise list of the names of the puzzle types for > which you get the message. For example, which "6x6" are you using, the one > with rectangular blocks or the Mathdoku - Settable Size with size set to > 6x6? Or maybe both? > > You say that games smaller than 9x9 seem to fail, but what about variant > (non-Classic) games of size 9x9, such as Killer Sudoku, Aztec, Jigsaw or > even Samurai? Looks like it's not just size; almost everything fails. These are the only ones that don't generate the error: Standard-9x9, Roxdoku-9-3x3x3, Sudoku-16x16, Sudoku-25x25, Roxdoku-16-4x4x4, Roxdoku-25-5x5x5. I don't believe I had tried Mathdoku-settable-size so didn't know how the size was set, but it appears to be an option in the ksudoku config. Neither the existing size of 6, nor the maximum 9 nor minimum 3, would give me a game, only the now familiar error. > Your comments about compiler and Qt changes may also be a clue. There is > some very old code in KSudoku (2007-08 vintage) that I have never dared > touch. Perhaps some of that has been rendered invalid or works differently > now. Before investigation I suspected it might be something like an xml-parser update breaking parsing of whatever generator rules files were used, but the files don't seem to be XML-based so that's out. But whatever it was that changed, is obviously now treating perfectly valid "rules files" (for lack of a better term at this point) as invalid. I checked for file corruption, etc, too, and came up empty. > I regret that I cannot actually build and test the latest KSudoku code, > because I now work on an Apple Macbook and am unable to build KF5 and Qt5. > > BTW, it does not surprise me that the clock wraps around, but I think you > might find Samurai (five 9x9 grids) more fun than a 25x25... :-) The 25x25 was an accidental click (touchpad...), that I decided to actually try once it was generated and displayed. Fine to do once to say I did it but I doubt I'll do it again, especially now that it's getting the negative association of this bug, tho it most likely had nothing to do with it and that's only chance. But it's a negative association, none-the-less, and those don't have to be logical to be powerful... Anyway, For that sort of longer puzzle I'd prefer a larger size Palapeli/jigsaw, and have done ~900 pieces on it before, as my family used to do jigsaws and it takes me back. My main 65-inch 4K TV-as-monitor is about the size of the boards we'd put the puzzles on, too. =:^) I do I believe it's ksudoku windmill (unfortunately can't confirm ATM...) occasionally tho and like it. Samurai looks to be similar. I'll check it (and Sohei) out when I get things working again. Thanks. =:^) -- You are receiving this mail because: You are watching all bug changes.
[kdeplasma-addons] [Bug 395496] Weather applet layout offset to the right and not visible with long city names
https://bugs.kde.org/show_bug.cgi?id=395496 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added CC||1i5t5.dun...@cox.net --- Comment #3 from Duncan <1i5t5.dun...@cox.net> --- Same problem here for some time, on gentoo, running live-git (live-git ebuilds from the gentoo/kde overlay) of pretty much everything kde related including all the frameworks and plasma, thus including kdeplasma-addons. (In reply to Friedrich W. H. Kossebau from comment #2) > It is caused by the weather applet being used here inside the systemtray > popup container, which has a hardcoded(?) aize. While the weather applet now > (>= Plasma 5.13) assumes it can grow to the size it needs, always trying to > show e.g. all forecast days. The apparently hard-coded size does indeed seem to be the problem. > A fix will need to have the applet adapt to the available size in some way. > > No idea yet, needs me to sit down some longer time for it. The hints here (length of city name and system-tray hard-coded size limits) *did* suggest a workaround, however, which I can confirm works, having just tried it after reading this bug. =:^) Note that there's *TWO* ways to add a weather-report plasmoid, either nested inside the system-tray plasmoid, which in turn can be placed in a panel (as is traditional) or directly on the desktop activity (when it's in desktop/widgets mode, not folderview mode). Adding it nested in the system-tray is done via simple checkmark in the system-tray config, and nested in the system-tray is where the popup sizes are constrained, so this is the problem location. But, it's also possible (with widgets unlocked) to select add-widgets, either from the (desktop-mode) desktop config menu, or from the panel config menu, then in the popup window with all the widgets/plasmoids displayed, scroll toward the bottom and find the weather report widget/plasmoid, and drag it to the desired location on the desktop or in the panel. This second method, adding the weather-report plasmoid directly to the panel (or desktop if preferred), instead of nesting it inside the system-tray plasmoid, avoids the popup-window size constraints of the system-tray, thus avoiding the problem. =:^) Thanks for the hints that allowed me to figure that out. This had been frustrating me for quite some time, and now at least I have a workaround while we wait for a fix to the system-tray nesting constraints, putting it directly in the panel instead of nested in the system-tray. =:^) -- You are receiving this mail because: You are watching all bug changes.
[ksudoku] [Bug 405422] New: ksudoku live-git (commit 09814312d) small-game generation fails with "Unable to generate a puzzle of the chosen variant"
https://bugs.kde.org/show_bug.cgi?id=405422 Bug ID: 405422 Summary: ksudoku live-git (commit 09814312d) small-game generation fails with "Unable to generate a puzzle of the chosen variant" Product: ksudoku Version: unspecified Platform: Gentoo Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: iandw...@gmail.com Reporter: 1i5t5.dun...@cox.net CC: kde-games-b...@kde.org Target Milestone: --- This just started happening a few days ago. I like a quick 6x6 game so that's my normal default, but games smaller than standard 9x9 seem to fail with "Unable to generate a puzzle of the chosen variant", now. However, given that ksudoku has had only a single GIT_SILENT commit since Jan 11, and it worked well after Jan 11, I suspect the trigger to be an update of some dependency. So what might trigger the above error on particularly smaller games? (Note that I'm running live-git of nearly everything kde related, including all frameworks and plasma packages, so if it's a kde-related dep it's likely live-git, while other deps are reasonably recent, being gentoo/~amd64, aka testing. For toolchain, glibc-2.28-r5 updated on Mar 10, I /think/ after the problem already appeared, and gcc-3.3.0 updated on Feb 24, I believe before the problem altho I wouldn't have rebuilt kde packages until they had a commit, and qt-5.12.1 on Feb 14 as parts of live-git plasma require qt-5.12 now...) Also, out-of-routine I recently tried a big 25x25 which took me a couple of days to solve (BTW, the timer apparently wrapped at some point as it said only a few hours, but that'd be a different bug I've not actually filed yet, is it known or should I file a bug on it). AFAIK the 6x6 games were working before that, and broken very soon after, but I tried deleting (well, renaming) the ksudokurc file and it didn't solve the problem, so if it's corrupted state it must be elsewhere. -- You are receiving this mail because: You are watching all bug changes.
[ksudoku] [Bug 405422] ksudoku live-git (commit 09814312d) small-game generation fails with "Unable to generate a puzzle of the chosen variant"
https://bugs.kde.org/show_bug.cgi?id=405422 --- Comment #7 from Duncan <1i5t5.dun...@cox.net> --- Just a couple notes for the moment, pending testing of the fix, since the bug has been traced to qt5's tmpfile handling: When I first noticed the bug and when reported, I was on qt 5.12.1. Since then I upgraded to 5.12.2. Unfortunately that didn't solve the problem. On my system, both system and user tmp are tmpfs, so the copy from installed to a tmpfile is cross-filesystem. It's possible that may be the complicating factor that explains why I have the bug while others on qt 5.12.x may not. (Apparently one tester had a single filesystem containing both the installation and tmp, so it wasn't a cross-filesystem copy for him.) It's now my weekend and I should be doing routine system and git-build updates later today or tomorrow. If the potential fix isn't on master before that I plan on switching branches and verifying the fix one way or the other, so we should have confirmation then. -- You are receiving this mail because: You are watching all bug changes.
[ksudoku] [Bug 405422] ksudoku live-git (commit 09814312d) small-game generation fails with "Unable to generate a puzzle of the chosen variant"
https://bugs.kde.org/show_bug.cgi?id=405422 --- Comment #10 from Duncan <1i5t5.dun...@cox.net> --- (In reply to Jeremy Whiting from comment #6) > Git commit 40e80d73866634c954dce212f2da43cd0fdce8d6 by Jeremy Whiting. > > Don't use KIO copy and QTemporaryFile to load xml definition files. Confirmed: With this on master now, all games seem to work again. Thanks. =:^) -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 407750] New: panel will not autohide on multi-monitor internal struts, works fine on external struts
https://bugs.kde.org/show_bug.cgi?id=407750 Bug ID: 407750 Summary: panel will not autohide on multi-monitor internal struts, works fine on external struts Product: plasmashell Version: master Platform: Gentoo Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Panel Assignee: plasma-b...@kde.org Reporter: 1i5t5.dun...@cox.net Target Milestone: 1.0 On live-git (via gentoo/kde overlay live-git ebuilds) but the bug has been around for a few months now. Currently on qt-5.12.2 but I believe it triggered on qt-5.11 as well. This may or may not be a dup of bug #401168. I can test proposed fixes within a few days. This applies to plasma on X, with multiple monitors. My monitor layout is like this (ascii-art works best with monospace fonts): 1 ++ 2| 2160p |3 5 | pri| +++ 6||7 4 -> 1080p video/secondary ++ 8 If that doesn't display correctly, here's the setup from xrandr: HDMI-A-0 connected primary 3840x2160+1920+0 DisplayPort-0 connected 1920x1080+0+2160 So the primary is 4K with the top-left corner at 1920,0, with the secondary FHD diagonally to the left and below, top-left corner at 0,2160. Edges 1,3,6,8 are at the external edge of the bounding rectangle (aka external struts), and an autohide panel placed on them works just fine. Edges 2,4,5,7 are internal to the bounding rectangle (aka internal struts), and an autohide panel placed on them doesn't work. The panel stays visible and over top any windows in the same area. On the broken edges, hovering the pointer over the panel and then exiting does trigger an autohide, but the panel immediately pops back out, above other windows, as if the pointer had hit the trigger area again, despite actually being nowhere near it. Unfortunately, I want my panel on a broken internal-strut edge, #4, and it won't stay hidden there at all! =:^( Fortunately, the clue that it works on external-strut edges, but breaks on internal-strut edges, should help pin down the bug, and the fact that I'm on live-git and can rebuild with test patches and report results within a few days should help as well. =:^) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 415313] New: Severe kwin_x11 (on amdgpu) compositing performance regression: bisected to 00bf75d06
https://bugs.kde.org/show_bug.cgi?id=415313 Bug ID: 415313 Summary: Severe kwin_x11 (on amdgpu) compositing performance regression: bisected to 00bf75d06 Product: kwin Version: git master Platform: Gentoo Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: compositing Assignee: kwin-bugs-n...@kde.org Reporter: 1i5t5.dun...@cox.net Target Milestone: --- git kwin_x11 (on amdgpu/polaris 11) can currently be effectively unusable: can take minutes to switch windows with various effects on and a video playing (or trying to), tho it's only "a bit choppy" if I turn the trouble effects off and don't try doing too much window managing at once without stopping to let kwin catch up. KWIN_USE_INTEL_SWAP_EVENT=0 kwin_x11 --replace doesn't appear to help (it's an AMD CPU and GPU but I thought I'd try it). Problem effects (that I normally run and had to turn off until I could bisect) are wobbly-windows, pretty much all of the popup-sliding/fading/etc stuff, blur-behind, and repeat-zoom (as with key auto-repeat, seems kwin can process about 5 zoom events a second, gets behind if auto-repeat is set any higher). Bisected to 00bf75d06, so I'm pinned one commit back from that at a55dee3bd for the moment. This is with current kwin HEAD d72e96802 (gentoo/kde overlay live-git packages for kde-frameworks and plasma). Two big-screen 4k TVs as monitors in side-by-side configuration, if it matters. kwin_x11 reports (I don't see qt version listed, it's 5.14.0): OpenGL vendor string: X.Org OpenGL renderer string: AMD Radeon (TM) RX 460 Graphics (POLARIS11, DRM 3.35.0, 5.4.0-dirty, LLVM 9.0.1) OpenGL version string: 4.5 (Core Profile) Mesa 19.3.0 OpenGL shading language version string: 4.50 Driver: RadeonSI GPU class: Arctic Islands OpenGL version: 4.5 GLSL version: 4.50 Mesa version: 19.3 X server version: 1.20.6 Linux kernel version: 5.4 Requires strict binding:no GLSL shaders: yes Texture NPOT support: yes Virtual Machine:no -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 415313] Severe kwin_x11 (on amdgpu) compositing performance regression: bisected to 00bf75d06
https://bugs.kde.org/show_bug.cgi?id=415313 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Status|NEEDSINFO |REOPENED Ever confirmed|0 |1 Resolution|WAITINGFORINFO |--- --- Comment #2 from Duncan <1i5t5.dun...@cox.net> --- (In reply to Roman Gilg from comment #1) > Can you give me a step-by-step rundown on how to reproduce it? Do I need to > have a certain load on the CPU or GPU? No specific load needed, it was quite apparent pretty much immediately after reboot and restarting X/plasma after the update (certainly when I first tried to move a window or zoom, which are routine enough to be nearly immediately after starting X/plasma), but your lack of reproduction reminded me I run an aurorae-based windeco (black square, originally downloaded from kdelook some years ago, I guess it'd be kde store now), so I tried with breeze (after a quick rebuild to HEAD and kwin_x11 --replace, of course, ccache is cool =:^). I /think/ breeze windeco helps a bit compared to aurorae/black-square, but it's still extremely easy to trigger a kwin lag-out when moving a window with breeze, if wobbly-windows is enabled. I'm not sure whether it makes the problem worse (that is, kwin more laggy), but playing a video (qt5-based minitube, FWIW) when attempting the window move makes it more apparent, as the video will drop frames and sometimes freeze all or part of the video (texture artifact?) when kwin's lagged out on the wobbly-window move or >5 zooms/sec. The lines from snap-helper freeze when kwin lags out too, but that doesn't seem to be a problem effect, it just makes the wobbly-window-induced lag-out more apparent when the snap-lines don't disappear when you quit moving the window. Similarly, fall-apart doesn't appear to trigger lag (while concurrent zoom and window-close for fall-apart would be rare, I did just try to test it, and the fall-apart did pause slightly during the repeat-zoom, but that's a rare enough combo I'm not entirely sure it wouldn't do that when things are working correctly). > I have a single 4K monitor connected. Do you experience the issue only when > both your 4K monitors are connected or also with only one connected? It hadn't occurred to me to try with just one (it's a desktop system and the two 4Ks are normally permanently connected), but great idea... Using xrandr to turn off one output for testing, then turn it back on and reposition it correctly. (FWIW I confirmed that xrandr reports the smaller framebuffer when the one is off and kwin moves everything to the remaining output.) The problem remains with just one 4k connected. It's hard to tell for sure, but it's possible it's a bit less laggy. Which prompts the question, what about smaller (say 1080p) resolutions, one or two outputs? (Switching to arandr for this... FWIW kscreen/krandr have been broken or have interacted badly with plasmashell often enough over the years that I stick to xrandr/arandr and don't even have the k* versions installed, tho of course libkscreen is a plasma-workspace dep so it has to be, but it hasn't seemed to break anything on its own.) Tried 1080p on just one output (other one off) or both, and it didn't seem to markedly affect the problem; it's still easily triggered, regardless. I tried setting just one output and doing the kwin_x11 --replace thing, too, just in case kwin still had some stale two-output state left, and that didn't change the results either -- the problem remains. > I just tried on Intel and AMD graphics and was not able to reproduce the > issue with Wobbly Windows or Zoom. What generation AMD graphics? Maybe it's generation dependent? As posted I'm on Polaris 11/Arctic-Islands, so it's "a bit" dated now, but new enough to be comfortably within the amdgpu driver range (one of the reasons I upgraded to it, actually), not the older radeon driver. So I don't know what those swap events are that were being setup in that commit series (actually, reading the commit log I thought they were intel-only, but maybe not...) and thus don't know if the following questions even make sense. Does my polaris11 support them? Maybe it claims to but they're buggy or "emulated" on the CPU for my card/driver combo? Certainly, forcing to cpu might explain the slowdown, but one would expect that'd trigger CPU usage spikes on at least one core and I don't see that when kwin lags out, either. I looked. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 415313] Severe kwin_x11 (on amdgpu) compositing performance regression: bisected to 00bf75d06
https://bugs.kde.org/show_bug.cgi?id=415313 --- Comment #7 from Duncan <1i5t5.dun...@cox.net> --- So I was out a few weeks due to death in the family. =:^( Given the reverts in https://mail.kde.org/pipermail/kwin/2020-January/002999.html (including the bisected-to 00bf75d06) is this still relevant? If no longer relevant, resolved/fixed or resolved/worksforme or ??? (Resolved/obsolete may be most appropriate, but it doesn't appear to be an option on kde's bugzy instance.) (I just rebuilt/kwin-replaced and a quick test says the last ~20% of the regression is gone now, but it's too soon to say for sure.) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 415313] Severe kwin_x11 (on amdgpu) compositing performance regression: bisected to 00bf75d06
https://bugs.kde.org/show_bug.cgi?id=415313 --- Comment #5 from Duncan <1i5t5.dun...@cox.net> --- FWIW, kwin master as of 054cfc1c8 seems to be /vastly/ improved, altho not /quite/ back to where it was. I'd say 75-80% (aka 3/4 to 4/5) of the original regression performance loss has been regained. I can run all my usual effects now, but still noticed a bit of slow-down until I tweaked configs a bit, adjusting the wobbly-windows config for normal windows and bumping animation speed (workspace behavior, general behavior, animation speed slider) for plasma (autohide panel showing speed, panel plasmoid hover popup morphing speed). It's fast enough now if I was new to plasma I'd never suspect the regression and would just tweak things if the default seemed slow until they worked as I wanted, and it's only that I had it tuned to what I wanted before and it was still slightly too slow with that config that hints at the far greater regression before. (In reply to Roman Gilg from comment #4) > Please check out if this solves the problem for you: > https://phabricator.kde.org/D26216 I take it that's not yet applied to master? Do I still need to try it? And/or would bisecting the commit at which I got most of the performance back still help? (While fiddling with the config I noticed the FPS effect once again. Too bad I didn't think to try enabling it when kwin was lagging out so badly. It'd have been nice to get real numbers, tho of course I still could by pinning the bad commit and rebuilding...) (My regular updates included a gcc-9.2.0 gentoo patch revision early in the update sequence, a mesa update from 19.3.0 to 19.3.1, and an llvm and clang update from 9.0.1-rc3 to 9.0.1 release, of interest given their usage with amdgpu for shader-compiling, etc. While kwin's 00bf75d06 commit did indeed regress something, it's possible that it was only as severe as I was seeing due to a bug in one of the above packages and that updating that package, not a kwin commit since then-head d72e96802, gave me back most of what I saw lost in that regression.) I've a couple more days off due to Christmas, and (if only for my own curiosity) may well do some more rebuild testing to pin down exactly what gave me that performance back, as well as testing D26216, but FWIW it's definitely workable now and as such I'd be OK with closing the bug, even if I didn't get 100% of the pre-regression performance back. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 421542] [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Whole Window Class
https://bugs.kde.org/show_bug.cgi?id=421542 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Summary|[kcm/kwinrules X11] |[kcm/kwinrules X11] |KWinRules KCM Redesign: |KWinRules KCM Redesign: |Fallout: Whole Window |Fallout: Whole Window Class |Class, Window Role | --- Comment #2 from Duncan <1i5t5.dun...@cox.net> --- (In reply to Ismael Asensio from comment #1) > This looks like two distinct bugs: detect whole window class, and window > role being hidden. > Would you mind to create a new bug report for the second one Done. Bug #421583. Editing this one's title to reflect its now more limited scope. (I had just created like four bugs on the redesign and didn't want to overdo it so grouped them slightly and both here were window match props, so... But happy to split it on the request. =:^) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 421583] [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Window Role
https://bugs.kde.org/show_bug.cgi?id=421583 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Depends on|421542 | Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=421542 [Bug 421542] [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Whole Window Class -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 421583] New: [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Window Role
https://bugs.kde.org/show_bug.cgi?id=421583 Bug ID: 421583 Summary: [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Window Role Product: kwin Version: git master Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: rules Assignee: kwin-bugs-n...@kde.org Reporter: 1i5t5.dun...@cox.net CC: isma...@gmail.com, kwin-bugs-n...@kde.org, n...@kde.org Depends on: 421542 Target Milestone: --- +++ This bug was initially created as a clone of Bug #421542 +++ [Frameworks/plasma git-master, so this is the redesigned window rules kcm. qt-5.15.0_rc ] [Split from above bug on request.] When adding a new rule window role doesn't originally appear. Not only is it not in the original matching list, but hitting add properties, it doesn't (originally) appear either -- tho the first slot under window matching is blank, and if you begin to type the first two letters of "role" (so "ro") in the search box, it does appear. If you then close the add/select properties box and click add properties again (after searching for it the first time), it shows up in the position that was previously blank. Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=421542 [Bug 421542] [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Whole Window Class, Window Role -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 421542] [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Whole Window Class, Window Role
https://bugs.kde.org/show_bug.cgi?id=421542 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Blocks||421583 Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=421583 [Bug 421583] [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Window Role -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 421542] [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Whole Window Class
https://bugs.kde.org/show_bug.cgi?id=421542 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Blocks|421583 | Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=421583 [Bug 421583] [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Window Role -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 421540] [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Slow loading
https://bugs.kde.org/show_bug.cgi?id=421540 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Blocks||421586 Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=421586 [Bug 421586] [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Placement -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 421586] [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Placement
https://bugs.kde.org/show_bug.cgi?id=421586 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Depends on|421540 | Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=421540 [Bug 421540] [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Slow loading -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 421540] [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Slow loading
https://bugs.kde.org/show_bug.cgi?id=421540 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Blocks|421586 | Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=421586 [Bug 421586] [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Placement -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 421586] New: [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Placement
https://bugs.kde.org/show_bug.cgi?id=421586 Bug ID: 421586 Summary: [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Placement Product: kwin Version: git master Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: rules Assignee: kwin-bugs-n...@kde.org Reporter: 1i5t5.dun...@cox.net CC: isma...@gmail.com, kwin-bugs-n...@kde.org, n...@kde.org, schwanc...@protonmail.com Depends on: 421540 Target Milestone: --- +++ This bug was initially created as a clone of Bug #421540 +++ [Frameworks/plasma git-master, so this is the redesigned window rules kcm. qt-5.15.0_rc ] Yet another bug with the new rules kcm implementation. Apparently the placement setting has a problem at least somewhat similar to the window sizing items. It doesn't seem to load properly when a ruleset is loaded, and while applying a change to something else doesn't /always/ seem to modify the placement setting (that wasn't deliberately changed), when it /does/ get overwritten, it seems to always be with force, top-left. Once changed to that, it appears to be impossible to change it to anything else from the kcm as nothing sticks. IOW, there's some inconsistency in when it's rewritten that I haven't quite pinned down. The specific scenario here is that I have two konsole profiles with two separate rulesets applying to them, the normal one that's set for 1280x1080 (1/6 of a 4k monitor, 1/2 height, 1/3 width) no placement, and a bit less opacity, and a "popup" one that's set to a smaller 720x450 size, a bit higher opacity, and placement "under mouse". Something happened, I guessed related to whole window class processing (bug #421542) but possibly not, anyway, I went to toggle off the full window class match as I /thought/ it didn't seem to be working any more on the main konsole ruleset because opacity seemed to be too high. So I adjusted the main entry's full window class, testing that it was matching again by adjusting opacity, since I wanted to tweak it a bit anyway. That worked, but then I needed to adjust the opacity on the popup profile's konsole as well. Somewhere along the line, both the popup konsole's ruleset and the main konsole's ruleset got forced to top-left placement, tho I hadn't touched that at all! I first noticed it with the popup when I tried to hotkey-launch it and it didn't appear under the mouse as expected. But after trying to launch it again and not seeing it, I realized what I had been working in lost focus, so went looking, and there the popups were, clear over on the far left of the left-hand 75-inch monitors, literally nearly 2 meters/yards from where I was expecting them due to the size of the monitors! In trying to fix that I launched a normal konsole and realized it was launching at the top-left as well, so both rulesets had been affected. I quickly found out that setting the placement back to default for the main konsole ruleset, and under mouse for the popup one, just didn't work from the kcm. The setting in the rules kcm would change but it wouldn't affect anything and would appear to be set to default when I reloaded the ruleset in the kcm. Fortunately I had some other rulesets with placement set similar that I hadn't messed with and that thus hadn't been affected, so I could find the settings in kwinrulesrc for them and manually edit the konsole sessions appropriately. A kwin_x11 --replace later and the behavior was restored. After that I tested a bit, but I couldn't quite figure out exactly what it was doing, only that sometimes changing another setting and hitting apply screwed up the placement setting too, while sometimes it seemed to leave it alone. It /did/ seem that the placement setting more consistently got rewritten if I changed opacity compared to some of the other settings, but I'm not 100% sure on that either, only that something's rewriting the placement settings /sometimes/ but as best I could figure out, not /always/. It didn't seem entirely consistent, which was almost as disturbing as the fact that it was rewriting the placement when I hadn't touched it, in the first place! Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=421540 [Bug 421540] [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Slow loading -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 421586] [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Placement
https://bugs.kde.org/show_bug.cgi?id=421586 --- Comment #2 from Duncan <1i5t5.dun...@cox.net> --- (In reply to Ismael Asensio from comment #1) > Git commit fdd9ed53d9a67089764d2879754c511f58da889e by Ismael Asensio. Could you merge the 5.19 branch into Master? I'm on Master and am not seeing that commit here. The last two commits I'm seeing are current HEAD be245e2f8 (the no-phabricator patch that seems to be being applied pretty universally to kde products due to the gitlab migration), and 923340e6b from Friday, which merged the 5.19 branch (with db7fb26ee, your fix for bug #421055, the rules kcm size properties bug I reported). So I'm not seeing this one yet. But I've downloaded the patch and applied it manually (gentoo, so dropped it into /etc/portage/patches/kde-plasma/kwin and remerged the kwin- live-git package from the gentoo/kde overlay), and yes, I can confirm that with it applied, changing a placement rule works as expected once again. Thanks. =:^) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 421540] New: [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Slow loading
https://bugs.kde.org/show_bug.cgi?id=421540 Bug ID: 421540 Summary: [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Slow loading Product: kwin Version: git master Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: rules Assignee: kwin-bugs-n...@kde.org Reporter: 1i5t5.dun...@cox.net CC: isma...@gmail.com, n...@kde.org Depends on: 421055 Target Milestone: --- +++ This bug was initially created as a clone of Bug #421055 +++ [Frameworks/plasma git-master, so this is the redesigned window rules kcm. qt-5.15.0_rc ] Testing the above bug I loaded, changed and reloaded the new window-rules kcm quite a bit, and noticed that sometimes (but not always) it takes /much/ longer than it should to load up, sometimes 30+ seconds. It's as if it's waiting for a timeout, perhaps on a dbus call, before loading. In my testing, it seems not to happen on the first load (which loads at pretty normal speed, perhaps a slight pause loading the rules kcm), but I was changing some window rule, applying, then clicking to some other KCM and back to see if my change "took". I'm not sure if it /always/ takes longer on later reloads or not (if it loads normally I'd not notice it), but it certainly does sometimes. If I entirely close the plasma systemsettings window and restart it instead of simply clicking to a different kcm and back, the window-rules kcm seems to load faster again. When it slow-loads, for some tens of seconds it continues to display the previous kcm, to the point I think it missed my click or something (I timed it once and it was over 30 seconds "frozen" on the previous kcm, before even loading the rules kcm). Then, finally, it'll load the rules kcm, but it says empty, no rules, for some tens of seconds longer, which of course triggered quite some panic the first time I saw it and still causes my heart to jump into my throat, as I've something like 50 rules which I think I just lost! (I could retrieve them from backup if I had to, but it still triggers that heart-in-throat moment!) Finally, it actually loads the rules list, and my heart quits racing and I can breath again! As you can imagine this is quite irritating. I know I'm on live-git so can live with it for the time being, but I'd seriously /hate/ to see it released like this. Because it happens on a reload of the rules kcm it's obviously hot-cache so it's not waiting on disk (besides I'm on a reasonably fast ssd so it'd hardly be 30+ seconds waiting on disk even from cold-cache, unless it's loading on the order of gigs of something), but it's obviously waiting on /something/, thus the dbus timeout hypothesis above, as I've actually seen that one elsewhere. Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=421055 [Bug 421055] [kcm/kwinrules X11] Window sizing rules broken since a04b40dad: KWinRules KCM Redesign -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 421055] [kcm/kwinrules X11] Window sizing rules broken since a04b40dad: KWinRules KCM Redesign
https://bugs.kde.org/show_bug.cgi?id=421055 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Blocks||421540 Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=421540 [Bug 421540] [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Slow loading -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 421542] New: [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Whole Window Class, Window Role
https://bugs.kde.org/show_bug.cgi?id=421542 Bug ID: 421542 Summary: [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Whole Window Class, Window Role Product: kwin Version: git master Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: rules Assignee: kwin-bugs-n...@kde.org Reporter: 1i5t5.dun...@cox.net CC: isma...@gmail.com, kwin-bugs-n...@kde.org, n...@kde.org Depends on: 421055, 421540 Target Milestone: --- +++ This bug was initially created as a clone of Bug #421540 +++ [Frameworks/plasma git-master, so this is the redesigned window rules kcm. qt-5.15.0_rc ] The rules kcm redesign seems to have no way to actually get the whole window class in ordered to match it. The detection button will detect window class, but not whole window class (that I can figure out how, anyway, if it's there it's seriously unintuitive), and the match whole window class option doesn't appear to change that, so the only way to actually get the whole window class would be to use some third-party app (like xprop) to get it, and then fill it in manually. And window role doesn't originally appear. Not only is it not in the original matching list, but hitting add properties, it doesn't (originally) appear either -- tho the first slot under window matching is blank, and if you begin to type the first two letters of "role" (so "ro") in the search box, it does appear. If you then close the add/select properties box and click add properties again (after searching for it the first time), it shows up in the position that was previously blank. Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=421055 [Bug 421055] [kcm/kwinrules X11] Window sizing rules broken since a04b40dad: KWinRules KCM Redesign https://bugs.kde.org/show_bug.cgi?id=421540 [Bug 421540] [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Slow loading -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 421540] [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Slow loading
https://bugs.kde.org/show_bug.cgi?id=421540 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Blocks||421542 Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=421542 [Bug 421542] [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Whole Window Class, Window Role -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 421540] [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Slow loading
https://bugs.kde.org/show_bug.cgi?id=421540 --- Comment #1 from Duncan <1i5t5.dun...@cox.net> --- Once at the rule list, both add new, and loading an existing rule in the editor, can take more time than they should as well. I'm not sure it always does, but I'm definitely noticing it as I work in the kcm to file these related bugs. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 421544] New: [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Edit Rule, Delete Rule
https://bugs.kde.org/show_bug.cgi?id=421544 Bug ID: 421544 Summary: [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Edit Rule, Delete Rule Product: kwin Version: git master Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: rules Assignee: kwin-bugs-n...@kde.org Reporter: 1i5t5.dun...@cox.net CC: isma...@gmail.com, kwin-bugs-n...@kde.org, n...@kde.org Depends on: 421540 Target Milestone: --- +++ This bug was initially created as a clone of Bug #421540 +++ [Frameworks/plasma git-master, so this is the redesigned window rules kcm. qt-5.15.0_rc ] This one's arguably a new feature, but I call it a bug, particularly the delete aspect as that's an unnecessary risk to existing rules. Perhaps it's because I'm a computer person used to working with a mouse/touchpad/trackball/etc, not a cell-phone person used to dealing with touch, but... I'm used to being able to double-click an entry to "modify" it, and now that doesn't work; double-clicking a rule does nothing. I have to slide the pointer several inches over to the right (75-inch 4K TV as a monitor, so it's /literally/ several inches on the display!) and hit the (relatively) small edit button in ordered to modify, instead of just being able to double-click anywhere in the (relatively) larger entry. Meanwhile, deleting seems to be much more dangerous now. There's no confirmation, and hitting the delete button means I'm focused all the way to the right on it, and don't see that the entry name to the left is different with the deletion so a different rule's delete button is now under my pointer. As nothing seems to have happened, my reaction is that there was no response and to try hitting the delete button again! Obviously, doing that repeatedly could quickly decimate my existing rules, instead of deleting only the one I initially intended to delete. (And that's not even considering the possibility of hitting it by accident.) Preferably there'd both be some sort of delete confirmation to avoid an accidental delete, and some sort of delete animation or something, so I can tell something happened even if I'm focused on the delete button and don't notice that a different rule filled the spot of the deleted one. But at least one of the two would be better than the current situation and should be strongly considered before a release with the new design. I'm just glad I /didn't/ hit that button again! Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=421540 [Bug 421540] [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Slow loading -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 421544] [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Edit Rule, Delete Rule
https://bugs.kde.org/show_bug.cgi?id=421544 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Depends on|421540 | Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=421540 [Bug 421540] [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Slow loading -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 421540] [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Slow loading
https://bugs.kde.org/show_bug.cgi?id=421540 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Blocks|421544 | Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=421544 [Bug 421544] [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Edit Rule, Delete Rule -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 421540] [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Slow loading
https://bugs.kde.org/show_bug.cgi?id=421540 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Blocks||421544 Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=421544 [Bug 421544] [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Edit Rule, Delete Rule -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 421542] [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Whole Window Class, Window Role
https://bugs.kde.org/show_bug.cgi?id=421542 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Depends on|421055, 421540 | Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=421055 [Bug 421055] [kcm/kwinrules X11] Window sizing rules broken since a04b40dad: KWinRules KCM Redesign https://bugs.kde.org/show_bug.cgi?id=421540 [Bug 421540] [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Slow loading -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 421055] [kcm/kwinrules X11] Window sizing rules broken since a04b40dad: KWinRules KCM Redesign
https://bugs.kde.org/show_bug.cgi?id=421055 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Blocks|421542 | Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=421542 [Bug 421542] [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Whole Window Class, Window Role -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 421055] [kcm/kwinrules X11] Window sizing rules broken since a04b40dad: KWinRules KCM Redesign
https://bugs.kde.org/show_bug.cgi?id=421055 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Blocks|421540 | Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=421540 [Bug 421540] [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Slow loading -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 421540] [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Slow loading
https://bugs.kde.org/show_bug.cgi?id=421540 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Blocks|421542 | Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=421542 [Bug 421542] [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Whole Window Class, Window Role -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 421540] [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Slow loading
https://bugs.kde.org/show_bug.cgi?id=421540 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Depends on|421055 | Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=421055 [Bug 421055] [kcm/kwinrules X11] Window sizing rules broken since a04b40dad: KWinRules KCM Redesign -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 421055] [kcm/kwinrules X11] Window sizing rules broken since a04b40dad: KWinRules KCM Redesign
https://bugs.kde.org/show_bug.cgi?id=421055 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Blocks||421542 Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=421542 [Bug 421542] [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Whole Window Class, Window Role -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 421544] [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Edit/Delete/Reorder Rule buttons
https://bugs.kde.org/show_bug.cgi?id=421544 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Summary|[kcm/kwinrules X11] |[kcm/kwinrules X11] |KWinRules KCM Redesign: |KWinRules KCM Redesign: |Fallout: Edit Rule, Delete |Fallout: |Rule|Edit/Delete/Reorder Rule ||buttons --- Comment #1 from Duncan <1i5t5.dun...@cox.net> --- Adding the reorder button to the list too. The reorder button icon (ascii-art)... ^ = v ... appears to be two (or three) separate buttons, especially to someone used to having separate up/down buttons from before the redesign. I clicked the up-arrow to move a rule up, and there was no response. Clicking the down arrow did nothing either. Then I realized it was a single drag-only button now, and I had to /drag/ the thing! =:^( And moving-via-drag a rule several pages of rules up/down to the top/bottom is a serious chore! IIRC that was a single button-click before. (Right now it's even worse due to the currently dismal performance of the redesigned kcm; dragging up/down more than a page's worth means waiting for the entries to veerryyy leisuuurrlly scroll by one or a handful at a time, but that's bug #421540 and response speed will hopefully be far better before an actual release.) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 421055] [kcm/kwinrules X11] Window sizing rules broken since a04b40dad: KWinRules KCM Redesign
https://bugs.kde.org/show_bug.cgi?id=421055 --- Comment #4 from Duncan <1i5t5.dun...@cox.net> --- (In reply to Ismael Asensio from comment #3) > Proposed patch: https://phabricator.kde.org/D29764 Confirming, that patch works for me. =:^) Tried loading an existing rule and the size parameters loaded. Changing something and saving, they saved, and reloading, they loaded again. Additionally, setup a new rule and it saved and worked. So looks like that fixes it. =:^) (Testing this I've become aware of 2-3 other bugs and/or "unwanted behavior changes" that might otherwise be considered "new features", but I'll file those separately as they're not /this/ bug (and FWIW don't seem quite as breaking).) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 419178] New: kwin git 9b7ab4d16 segfault-loops on X
https://bugs.kde.org/show_bug.cgi?id=419178 Bug ID: 419178 Summary: kwin git 9b7ab4d16 segfault-loops on X Product: kwin Version: git master Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: core Assignee: kwin-bugs-n...@kde.org Reporter: 1i5t5.dun...@cox.net Target Milestone: --- kwin (kwin_x11) git 9b7ab4d16 builds but segfault-loops, while the previous commit 80d3f148e builds and runs fine. Distro/arch-level: Gentoo/~amd64 Frameworks/plasma version: git master using the gentoo/kde overlay ebuilds Qt version: 5.14.1 Kernel: Linux 5.6-git (currently rc7+2, commit 979e52ca0) Graphics environment: xorg-server 1.20.7, mesa 20.0.2 Graphics hardware: AMD Radeon RX 460 (Polaris 11), freedomware drivers Screen layout: 2 4K TVs as monitors, side-by-side layout for a total 7680x2160 resolution. Upon reboot and restarting X/plasma (startx with plasma as the session) after an update, I got the kwin crashed too many times dialog. I don't have any other window managers installed so there wasn't much to do but rebuild it from an earlier commit. Fortunately I have ccache setup so the rebuild doesn't take long. I had updated only a few days previously so there weren't many commits to bisect and it turned out head (9b7ab4d16) was the culprit. I normally run an aurora windeco and multi-monitor but tried breeze and single monitor, but that didn't help. Additionally, I tried suspending compositing, to no avail. That commit simply won't run. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 419178] kwin git 9b7ab4d16 segfault-loops on X
https://bugs.kde.org/show_bug.cgi?id=419178 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Platform|Other |Gentoo Packages -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 419178] kwin git 9b7ab4d16 segfault-loops on X
https://bugs.kde.org/show_bug.cgi?id=419178 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #7 from Duncan <1i5t5.dun...@cox.net> --- Fix verified. Thanks. =:^) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 421055] New: [kcm/kwinrules X11] Window sizing rules broken since a04b40dad: KWinRules KCM Redesign
https://bugs.kde.org/show_bug.cgi?id=421055 Bug ID: 421055 Summary: [kcm/kwinrules X11] Window sizing rules broken since a04b40dad: KWinRules KCM Redesign Product: kwin Version: git master Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: rules Assignee: kwin-bugs-n...@kde.org Reporter: 1i5t5.dun...@cox.net Target Milestone: --- Since the window rules kcm redesign in ao4b40dad (or my first update after that anyway, pretty close), none of the normal-mode window sizing rules, size, minimum size, maximum size, seem to work at all, in X at least. (Other geometry-related rules such as position and maximize-horizontally/vertically continue to work just fine.) I have dual 75-inch/1.9m 4K TVs as monitors so have a /lot/ of screen real estate. In normal operations I'll run a fullscreen youtube or the like on one monitor, while my normal work goes on the other one. I've standardized most of my normal working apps, firefox (when not full-screened), often multiple konsole windows, claws for mail and feeds, pan for news (nntp), kpat and ksudoku for games, and an always-open ksysguard in the corner, to 1280x1080, thus letting me tile my working windows in a 3x2=6 grid across the "working" monitor, with the 1280x1080 sizes enforced as necessary by appropriate window rules. Only now none of that size enforcement is working and it's playing havoc with my grid setup. =:^( There's a potential hint at the problem in that loading up existing window rules in the new kcm, the size rules are there, but with the sizes all zeroed out. If I hit detect, the values fill in, but hit apply (with no actual window sizes changing if they were changed), leave the ruleset and come back to it, and the values are zeroed out again. Further, checking the kwinrulesrc file, the size values for anything I've changed in the kcm are apparently reset to defaults, 0 for size and min/max values for those, 1 for min, 32767 for max, and the zeroed-out sizes are apparently deleted/not-stored. Some of the ones I've not changed remain as they were in kwinrulesrc, but a couple, firefox and claws in particular as those are where I noticed the rules misbehaving and went to check-on/adjust, are screwed up. So it appears the default values are overriding the actually set values once the individual window ruleset is loaded into the kcm, and that gets written back to the kwinrulesrc file. Something also triggered the window rulesets for claws and firefox to misbehave causing me to visit their rulesets in the kcm in the first place, as well, but I'm not sure if that was kwin's fault or not, while I do know that once a change is made in the kcm, the sizes get broken, and that it was working before the kcm redesign. kde-frameworks and kde-plasma are git master. Current qt is 5.15.0-beta4. xorg-server-1.20.8, mesa-20.0.6, xf86-video-amdgpu, kernel 5.7-rcs (but 5.6.0 does it too). Current kwin was updated with today's update, to d5e5e2f1c, after which I did the usual quit X/plasma, restart updated services, remount root ro again, and restart X/plasma, dance. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 421540] [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Slow loading
https://bugs.kde.org/show_bug.cgi?id=421540 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Blocks|421848 | Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=421848 [Bug 421848] [kcm/kwinrules X11] KWinRules KCM Redesign Fallout: Clicking Select Properties Scrollbar kills the properties list -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 421848] New: [kcm/kwinrules X11] KWinRules KCM Redesign Fallout: Clicking Select Properties Scrollbar kills the properties list
https://bugs.kde.org/show_bug.cgi?id=421848 Bug ID: 421848 Summary: [kcm/kwinrules X11] KWinRules KCM Redesign Fallout: Clicking Select Properties Scrollbar kills the properties list Product: kwin Version: git master Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: rules Assignee: kwin-bugs-n...@kde.org Reporter: 1i5t5.dun...@cox.net CC: isma...@gmail.com, kwin-bugs-n...@kde.org, n...@kde.org, schwanc...@protonmail.com Depends on: 421540 Target Milestone: --- +++ This bug was initially created as a clone of Bug #421540 +++ [Frameworks/plasma git-master, so this is the redesigned window rules kcm. qt-5.15.0_rc ] Yet another bug with the new rules KCM: Clicking the Select Properties list scrollbar kills the list! To reproduce: 1. Add a new rule. 2. Hit Add Properties. 3. Assuming the list of properties is long enough to get a scrollbar (it's a long list so that's fairly likely), click it to scroll down. The list of properties vanishes instead of scrolling and staying viewable. Watching closely it does appear that the list scrolls before it disappears. Or at least the scrollbar position, the part I can catch the redraw on before it disappears, does. Using the scrollwheel instead of clicking the scrollbar scrolls as it should. Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=421540 [Bug 421540] [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Slow loading -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 421848] [kcm/kwinrules X11] KWinRules KCM Redesign Fallout: Clicking Select Properties Scrollbar kills the properties list
https://bugs.kde.org/show_bug.cgi?id=421848 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Depends on|421540 | Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=421540 [Bug 421540] [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Slow loading -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 421540] [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Slow loading
https://bugs.kde.org/show_bug.cgi?id=421540 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Blocks||421848 Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=421848 [Bug 421848] [kcm/kwinrules X11] KWinRules KCM Redesign Fallout: Clicking Select Properties Scrollbar kills the properties list -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 421055] [kcm/kwinrules X11] Window sizing rules broken since a04b40dad: KWinRules KCM Redesign
https://bugs.kde.org/show_bug.cgi?id=421055 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Blocks|421892 | Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=421892 [Bug 421892] [kcm/kwinrules X11] KWinRules KCM: Redesign Fallout: Position rule caps to 4098 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 421892] [kcm/kwinrules X11] KWinRules KCM: Redesign Fallout: Position rule caps to 4098
https://bugs.kde.org/show_bug.cgi?id=421892 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Depends on|421055 | Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=421055 [Bug 421055] [kcm/kwinrules X11] Window sizing rules broken since a04b40dad: KWinRules KCM Redesign -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 421892] New: [kcm/kwinrules X11] KWinRules KCM: Redesign Fallout: Position rule caps to 4098
https://bugs.kde.org/show_bug.cgi?id=421892 Bug ID: 421892 Summary: [kcm/kwinrules X11] KWinRules KCM: Redesign Fallout: Position rule caps to 4098 Product: kwin Version: git master Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: rules Assignee: kwin-bugs-n...@kde.org Reporter: 1i5t5.dun...@cox.net CC: isma...@gmail.com, n...@kde.org Depends on: 421055 Target Milestone: --- +++ This bug was initially created as a clone of Bug #421055 +++ Yet another window rules kcm redesign bug... Setting a position rule to >4098 (at least X coordinate) is impossible via the new GUI. =:^( Scenario: * Dual 4K TVs as monitors in side-by-side orientation, giving me a framebuffer width of 3840*2=7680. * Most of my main work windows are standardized to 1280x1080, thus allowing me to fit a grid of 3x6 windows on my main work monitor, which happens to be the one to the right (with the one on the left often playing a full-screen video). * That means the right-most grid slot's X coordinate is 6400 (for a 1280-width range of 6400-7679). * I like to keep a ksysguard window (RIP superkaramba, unfortunately) in the top-left grid-slot, and I have a window rule to force that position, 6400,0. * I just had occasion to edit that ksysguard window ruleset for some other reason, and found kwin forcing it to X=4098 after that. Opening the ruleset I found that the position had been changed to 4098,0, and that while I could reduce that number I couldn't increase it back to the 6400 it should be -- the GUI refused to let me set anything above 4098, either with the spinner or typing it in, or rather, I could type it in, but the window was moved to 4098 and that's what was saved in kwinrulesrc upon upon hitting apply, despite the thing saying 6400 as I actually hit that apply! * Manually textediting the kwinrulesrc file and running a kwin_x11 --replace allowed me to reset the 6400 position that was supposed to be there, but opening up that ruleset in the kcm to check it, it wanted to reset 4098 again. Obviously a 4098 cap on position value simply isn't sufficient, especially with 8K displays out (if still prohibitively expensive but hopefully they'll be more reasonable in a couple years) and the possibility of someone running multiple of /those/. I'd say 16K minimum, if not maxint. Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=421055 [Bug 421055] [kcm/kwinrules X11] Window sizing rules broken since a04b40dad: KWinRules KCM Redesign -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 421055] [kcm/kwinrules X11] Window sizing rules broken since a04b40dad: KWinRules KCM Redesign
https://bugs.kde.org/show_bug.cgi?id=421055 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Blocks||421892 Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=421892 [Bug 421892] [kcm/kwinrules X11] KWinRules KCM: Redesign Fallout: Position rule caps to 4098 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 421586] [kcm/kwinrules X11] KWinRules KCM Redesign: Fallout: Placement
https://bugs.kde.org/show_bug.cgi?id=421586 --- Comment #3 from Duncan <1i5t5.dun...@cox.net> --- (In reply to Duncan from comment #2) > (In reply to Ismael Asensio from comment #1) > > Git commit fdd9ed53d9a67089764d2879754c511f58da889e by Ismael Asensio. > > Could you merge the 5.19 branch into Master? I'm on Master and am not > seeing that commit here. Branch w/ patch merged. Thanks. =:^) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 421892] [kcm/kwinrules X11] KWinRules KCM: Redesign Fallout: Position rule caps to 4098
https://bugs.kde.org/show_bug.cgi?id=421892 --- Comment #2 from Duncan <1i5t5.dun...@cox.net> --- (In reply to Duncan from comment #1) > Created attachment 128681 [details] > Patch maximum position to 65535 > 65535 should be enough for awhile... not yet tested, tho. Tested (to 6500 at least, I can still see that on-screen, and 65535 doesn't appear to break anything, tho the current kcmutils bug had me worried for a moment) now. Works. =:^) (I had rebuilt kcmutils in the same update and HEAD's buggy ATM. Couldn't find /any/ kcms and I thought my 65535 patch here broke it for a moment. HEAD-1 got it back tho so I could test this. Now to file the kcmutils bug if nobody's ahead of me...) -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kcmutils] [Bug 421898] New: commit 53b41bc90 broken: kcmshell5 and systemsettings5 can't find any modules
https://bugs.kde.org/show_bug.cgi?id=421898 Bug ID: 421898 Summary: commit 53b41bc90 broken: kcmshell5 and systemsettings5 can't find any modules Product: frameworks-kcmutils Version: unspecified Platform: Gentoo Packages OS: Linux Status: REPORTED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: kdelibs-b...@kde.org Reporter: 1i5t5.dun...@cox.net CC: a.samir...@gmail.com, chris.tay...@cantab.net, fab...@ritter-vogt.de, fa...@kde.org, hithaishi.malden...@gmail.com, nailspah...@gmail.com, n...@kde.org, rikmi...@kde.org, rnjohnso...@gmail.com, wba...@tmo.at, whilesh...@gmail.com Depends on: 421566 Target Milestone: --- +++ This bug was initially created as a clone of Bug #421566 +++ The "fix" for the above bug, commit 53b41bc90, breaks *all* kcms (well, all I tried, several) here. In kde-plasma's systemsettings, the left panel with the icons shows up, and the startup frequently used icons show up on the right, but attempting to load anything simply prints a couple text messages on the right saying it can't find the *.desktop file. For instance loading the single kcm Colors: Top: Colors Down a bit: The module Colors could not be found. Toward the bottom: The diagnosis is: The desktop file kcm_colors.desktop could not be found. Bottom button row: Help Defaults Reset ... Apply (The last two disabled.) Attempting to load a group, for instance, Window Management, loads the group list submenu on the left, but the right has the correspondingly same error messages and buttons for the top/default single kcm, in this case Window Behavior. Again, clicking any of the other entries on the left produces similar results on the right. If I try to run for instance "rules" from krunner (which pops up only a single choice, the kwin window rules kcm), it loads the Windows Management group on the left with Window Rules selected, and the same Window Rules error messages on the right as if I'd loaded it from the broken plasma systemsettings. Pinning the build to the previous commit c76836d67 gets me a working kcmshell5 and systemsettings5 once again, so it is indeed 53b41bc90 that's broken. This is a live-git build using the *- git-master packages from the gentoo/kde project overlay, so it's git-master all kde-* frameworks/plasma/apps packages. Unfortunately there's no git-master version choice for the version drop-down. Qt5 is qt-5.15.0_rc2 from the gentoo/qt project overlay. Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=421566 [Bug 421566] System setting crash -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kcmutils] [Bug 421566] System setting crash
https://bugs.kde.org/show_bug.cgi?id=421566 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Blocks||421898 Referenced Bugs: https://bugs.kde.org/show_bug.cgi?id=421898 [Bug 421898] commit 53b41bc90 broken: kcmshell5 and systemsettings5 can't find any modules -- You are receiving this mail because: You are watching all bug changes.
[bugs.kde.org] [Bug 421899] New: bugs.kde.org add attachment still points to phabricator for patches
https://bugs.kde.org/show_bug.cgi?id=421899 Bug ID: 421899 Summary: bugs.kde.org add attachment still points to phabricator for patches Product: bugs.kde.org Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: sysad...@kde.org Reporter: 1i5t5.dun...@cox.net CC: she...@kde.org Target Milestone: --- bugs.kde.org still points to phabricator for patch submissions. With the gitlab migration that's outdated and should be changed as appropriate. 1. Hit the add attachment button on any bug entry 2. Observe that it still points to phabricator for patches. -- You are receiving this mail because: You are watching all bug changes.
[bugs.kde.org] [Bug 399636] Integrate Phabricator and Bugzilla
https://bugs.kde.org/show_bug.cgi?id=399636 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added CC||1i5t5.dun...@cox.net --- Comment #1 from Duncan <1i5t5.dun...@cox.net> --- FWIW KDE's migrating to gitlab and is phasing out phabricator, so this bug should probably be resolved, I guess as unmaintained? (Some bugzi installations have a resolved as obsolete option for that purpose, but I don't see that choice here.) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 421892] [kcm/kwinrules X11] KWinRules KCM: Redesign Fallout: Position rule caps to 4098
https://bugs.kde.org/show_bug.cgi?id=421892 --- Comment #1 from Duncan <1i5t5.dun...@cox.net> --- Created attachment 128681 --> https://bugs.kde.org/attachment.cgi?id=128681=edit Patch maximum position to 65535 [Hmm... bugzi's a bit dated and still says phabricator for patches... Maybe I should file a bug on that too?] Easy enough to grep 4098 and generate a patch even if I'm a gentooer not a dev... 65535 should be enough for awhile... not yet tested, tho. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 351175] Panel on screen edge between two monitors does not auto hide
https://bugs.kde.org/show_bug.cgi?id=351175 --- Comment #21 from Duncan <1i5t5.dun...@cox.net> --- (In reply to Duncan from comment #19) > But I gotta actually find the code in question and see if I can hack-patch it > first. We'll see... Breadcrumb: plasma framework: plasma/src/scriptengines/qml/plasmoid/containmentinterface.cpp Line 991 mentions bug #344205, panels were auto-hiding when their context menus were shown. The bug was reported in 2015 and fixed in 2017, git commit f3dcff28b8fbc635467252706641c9d37f094090 to plasma framework. That looks like it could be the git commit pointing the way to the relevant code that I was saying made developing a hack-patch so much easier. The code surrounding the mentioned line may or may not be the code to patch, but if not, the calls made there should be greppable. So we have a path to explore now, at least. =:^) That it worked in kde/plasma4 and actually hides in plasma5 now but immediately unhides, demonstrates it should be possible to setup some sort of condition test and stop the immediate unhide under specific conditions. Whether coding the specific condition set is within my limited coding capacities or not remains to be seen, but with a path to follow now we're already closer than we were. Also: plasma API spec: https://api.kde.org/frameworks/plasma-framework/html/index.html And another potential hint in comment #8, ignored NETWM spec for panel struts in plasma5. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 351175] Panel on screen edge between two monitors does not auto hide
https://bugs.kde.org/show_bug.cgi?id=351175 --- Comment #22 from Duncan <1i5t5.dun...@cox.net> --- (In reply to Duncan from comment #21) > Breadcrumb: plasma framework: Breadcrumb: plasma-workspace: Bug #351823 commit 2d8b4e1dec26c5976dd75c238c3ae8a4700b8dd9 shell/panelview.cpp and .h -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 351175] Panel on screen edge between two monitors does not auto hide
https://bugs.kde.org/show_bug.cgi?id=351175 --- Comment #23 from Duncan <1i5t5.dun...@cox.net> --- So while working on this I got thinking about another workaround people may find useful until a fix is available to them. (Doesn't mean I've stopped trying to do a hack-patch, tho, this is just a different workaround.) There are command-line window-management tools like wmctrl and xdotool available. Command-line of course means scriptable, which makes these especially handy (and I use them personally) for hotkey launching and other dynamic use, where kwin's window rules aren't appropriate because they apply all the time and you want the rule only applied on demand and/or you want for instance two different window sizes and/or positions invokable when kwin's window rules can only handle one. There's also xprop, which allows you to read window properties, and when combined with grep in a script, test for specific window property matches (like window rules do) as necessary to ensure you're matching the intended window. It should therefore be possible to setup a script that can toggle panel-visibility (as generally possible with any window) using a hotkey, tho if plasma or kwin keeps trying to override it, it may be necessary to, for instance, have the script force-position the window off-screen in "hidden" mode, and position it back to screen-edge in "shown" mode. The script could then be configured to launch with either a hotkey or potentially when the mouse hits a hot-edge (xdotool's behave_screen_edge function, note that I've never used this personally so I'm not sure how it works with "internal" borders), triggering panel show or hide. If no one else gets inspired to create and attach such a script, if I decide I can't hack-patch plasma to fix this or decide I need a break from my attempts, I'll try a script, something I'm much more comfortable doing, so am 90% sure I can do (the 10% uncertainty being in how insistent plasma's going to be in trying to override the script's show/hide and/or placement), vs. only perhaps 30-40% sure at current status (up from 20-30% before I found those breakcrumbs) that my limited skills are up to hack-patching plasma to fix the problem. So one way or another I'm reasonably sure I can do either a hack-patch fix or a workaround script, one or the other, but it may well involve having to install some scriptable window management tools and assigning hotkeys to a script to take over the hide/show plasma panel(s) functionality from plasma. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 351175] Panel on screen edge between two monitors does not auto hide
https://bugs.kde.org/show_bug.cgi?id=351175 --- Comment #25 from Duncan <1i5t5.dun...@cox.net> --- Script update: TLDR: More pieces for the script falling in place. Dependencies... 1) xdotool windowmap/windowunmap seems more direct than the wmctrl positioning I mentioned in the last update. 2) Based on #1, for the actual operation using a preset winid ($panel) and using xwininfo -id $panel | grep 'Map State:" will yield "Map State: IsViewable" or "Map State: IsUnMapped. That state can then be the condition for the xdotool windowmap/windowunmap toggle. 3) Dependencies: Looks like xdotool and xwininfo. Also grep and coreutils (for cut) but they should be part of core system and thus already installed on most distros. The script will be bash and will probably use some bash-specific functionality, so dash, etc, may not work unless someone else wants to modify and post a version for that. Not wmctrl as xdotool seems more elegant for this, and probably not xprop as it appears xwininfo exposes what I need more directly, tho I won't be able to say for sure on that until the window match code comes a bit more into focus (I've just been selecting manually for experiments to this point). 4) Played with xdotool behave_screen_edge a bit. Unfortunately it doesn't appear to work on "interior" edges. Additionally, since xdotool doesn't have builtin conditionals the edge-trigger would have to invoke (xdotool) exec on a script with the conditional, with the exec being run using the blogging --sync option as without that xdotool has a bug in that it doesn't harvest process zombies after execution, which is fine for an immediate job and terminate, but with a long-running xdotool behave_screen_edge they just pile up. =:^( 5) So the behave_screen_edge thing will have to be separate from the hide/show script in any case, which means people can use whatever launcher they want, hotkey-invoked, third-party launcher (I may use gkrellm's launch feature here, it's between that and hotkey-invoked), or xdotool behave-screen-edge. Too bad plasma's native screen-edge triggering can't be configured to launch arbitrary executables, only kwin-native stuff like window-switcher, cube, etc, or that'd likely replace the xdotool behave_screen_edge option as a more native approach. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 351175] Panel on screen edge between two monitors does not auto hide
https://bugs.kde.org/show_bug.cgi?id=351175
--- Comment #26 from Duncan <1i5t5.dun...@cox.net> ---
Script update: TLDR: Window selection. Some limitations.
Window selection is the last major piece to figure out before I start putting
it all together in a proper script.
Unfortunately it's also the hardest, with plasmashell making things
particularly difficult as there's way too many windows with the same generic
"Plasma" name and "plasmashell" class and classname/wholeclass. As I've been
experimenting today I've seen anywhere from 1-2 dozen in the list. Years ago
there used to be window roles to sort on and panels had distinct if somewhat
generic roles such as (IIRC) panel#1, panel#2, etc, so all you had to do was
detect the role once and then match on it. But plasma hasn't been filling in
window roles for years now, I'd guess because wayland probably doesn't have a
directly parallel concept.
The other generally characterizing aspect is the window position/size/geometry.
But I'm getting three matching windows for that, two parents of the window I'm
targeting, too, and size/position/geometry alone isn't a safe enough exclusive
match in any case.
But a combination of the two, window name/class/wholeclass, and window
position/size/geometry, seems to do the trick at least /reasonably/ reliably.
But position/size/geometry will obviously differ by individual config.
So what I'm considering now is asking the user to pick the window so we can get
size/position at setup time, and of course again if they change their panel
position/size, but storing it in a config file so they only have to do it once
unless they do change position/size.
Then I can read the stored size info from the config at startup and fill it in
to do something like this:
xwininfo -tree -root | grep ' "Plasma": ("plasmashell" "plasmashell") *383x50'
| sed -e 's/^ *//' | cut -d' ' -f1
xwininfo -tree -root lists all windows along with their size and position.
That's piped to grep looking for plasma windows of the specified size (or
adjust it a bit for position or both). That should spit out the line we need,
but there will be some initial spaces that the sed eliminates, leaving the
window-id as the first space-separated field for cut to select.
After the grep but before the sed and cut the line should look like this
(variable number of initial spaces):
0x240004d "Plasma": ("plasmashell" "plasmashell") 383x50+0+0
+7296+2110
After the sed and cut it'll be only the 0x240004d, which is the window-ID to
feed back to xwininfo to check the mapping state to see which way to toggle it,
and then to xdotool window(un)map as described in comment #25.
The kink in this is that panel size (and therefore position) can normally
dynamically grow/shrink within min/max constraints depending on what's shown --
for panels with a systray startup a new app that adds a systray icon, for
instance, and that will often grow the systray and thus the containing panel.
Similarly for clock displays, weather displays, etc.
The simplest way around that is to configure the panel with the same min-size
and max-size so it can't grow/shrink, which I may require at least for the
initial script posting. There's ways around that, either finding something
else to match and potentially grepping individual window results for it, or
using something other then grep to fuzzify the size/position matching within
given constraints, but they get complicated pretty fast.
And as you can see sed's a likely dep now too, but as with grep, it's going to
be a core-system package and thus likely already installed for most distros.
Getting close now to putting all the pieces together into a postable script,
tho, even if it's going to be a bit flexibility-limited. If you want to try
playing around with xwininfo and xdotool, along with xprop if you want a few
more matching options, better matching ideas welcome! And of course if you
have the skills to do the real code patch and do away with the need for all
this scripting in the first place, you're /more/ than welcome to do it!
(I've not given up hope for a patch here, either, but the chances remain under
50% that I can do it, and it could well take me months of on and off work and
some chance inspiration before it clicks and I can put it all together in a
patch, even if I do ultimately do it. But a script, while a definitely hacky
and limited workaround, may well be something I can put together, pre-post
test, and post along with instructions for others to try, by the end of the
week.)
--
You are receiving this mail because:
You are watching all bug changes.
[plasmashell] [Bug 351175] Panel on screen edge between two monitors does not auto hide
https://bugs.kde.org/show_bug.cgi?id=351175 --- Comment #24 from Duncan <1i5t5.dun...@cox.net> --- An update on the scripted approach. TLDR: 99+% chance on the scripting now; the positioning trick I mentioned in comment #23 works; just gotta assemble everything. Testing and this works: Reposition the window outside the display area to hide it, then reposition it back to normal to show it, using... wmctrl -ir <0xID> -e 0,,-1,-1,-1 Parameters explained: -r = window specifier supplied -i = interpret specifier as WinID, the 0x of course indicates it's in hex. -e = positioning: gravity,x,y,w,h, with 0=default-gravity, for the others -1=keep-existing. So say 0,-32000,-1,-1,-1 will shove the window waaayyy left to x=-32000 while keeping other geometry properties the same. Position values appear to be 16-bit signed so wrap @ ~+/-32767. xdotool should be able to do it too. Still gotta script up the property-matching to match only the desired window tho I've done similar for other scripts, and figure out where/how to store the on-screen location while in the off-screen state (tempfile?). Also play around with xdotool's behave-screen-edge and see if it's practical, or whether hotkey invocation is better, and if the latter, a single-invocation toggle or two separate ones, hide and show? I was also considering the separate-executable plasma-windowed alternative, but the positioning trick seems to work and should be both simpler and less disturbing to the otherwise-native panel workflow, making the plasma-windowed alternative unnecessary. Still hoping for a patch too, but that's (still) well out of my comfort zone and remains under 50% likely. I've pretty much demonstrated it's possible using the positioning trick I just tested with wmctrl if nothing else, but the skills are likely beyond me, leaving the scripted hack-around I'm well within my comfort zone doing. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 351175] Panel on screen edge between two monitors does not auto hide
https://bugs.kde.org/show_bug.cgi?id=351175 --- Comment #19 from Duncan <1i5t5.dun...@cox.net> --- (In reply to Sergio from comment #18) > Still an issue as of: > KDE Plasma Version: 5.18.5 > KDE Frameworks Version: 5.68.0 > Qt Version: 5.12.8 > > @David Edmunson, can you please clarify what limitation exists in X making > it impossible to have an autohiding panel on a screen edge that is also the > edge of another monitor? > > As a matter of fact, in my system when you hover on the panel, right after > it *does* autohide perfectly. The problem is that immediately an unhide is > triggered even if there is no reason for that. FWIW I worked around the bug here with hardware, getting a second TV/Monitor the same size and 4K resolution so I didn't have the half-border (I ran into the bug while running a 4K and a FHD monitor, with a layout triggering the bug on an internal-border panel that needed to be there due to the different sizes), which let me change the logical layout so I could put my panels on the external borders where the bug doesn't happen. But the bug's still irritating. I'm not a dev, but I do run gentoo so build from source, and have been running the live-git packages from the gentoo/kde overlay for probably the better part of a decade now. While I can't really do new code, during that time I've gotten reasonably good at at least hack-patching, particularly when I have a recent commit pointing me at the code I'm interested in. But I recently proved to myself that a recent commit pointing the way isn't always necessary (unrelated to this bug, Oxygen theme titlebar height actually, see bug #425874 if interested), I just have to find the current behavior even more irritating since it's more work to find the code in question. Of course then the code has to be clear, well organized, and commented enough for me to figure out even as a non-dev, but thankfully, kde/plasma code tends to be just that, clear, well organized and well commented, so at least sometimes it can be possible. And this bug is irritating! So no promises, but if it works out and I can find and at least hack-patch demonstrate that a fix is possible, perhaps the real devs will use that as a start to a real patch to fix it properly. But I gotta actually find the code in question and see if I can hack-patch it first. We'll see... -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 425864] New: Aurorae-based windecos vanishing with libglvnd
https://bugs.kde.org/show_bug.cgi?id=425864 Bug ID: 425864 Summary: Aurorae-based windecos vanishing with libglvnd Product: kwin Version: git master Platform: Gentoo Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: aurorae Assignee: kwin-bugs-n...@kde.org Reporter: 1i5t5.dun...@cox.net Target Milestone: --- So Gentoo's currently switching from a manual selection of the X/Mesa OpenGL driver (using Gentoo's eselect-opengl tool) to automatic, using libglvnd. After doing the necessary rebuilds (mesa and xorg-server, plus switching between the mutually blocking eselect-opengl and libglvnd) and restarting X/plasma, my windecos were all transparent! After various troubleshooting, it seems all aurorae-based windecos, including kwin's native plastik, are affected, while oxygen and breeze work just fine. Additionally, everything else appears to be fine, so it's only aurorae-based windecos affected. I did note that with kwin's blur-behind-semi-transparent effect on, the area where the windeco should be was blurred (well, just the titlebar, since I have the no-borders option set). Additionally, while the titlebar buttons are as invisible as the titlebar itself, they still respond to clicks. (Of course with blur-behind off, the titlebar area was entirely invisible.) Hardware/Software: All frameworks/plasma/kde-apps live-git versions from the gentoo/kde overlay (- master versions), on a Radeon rx460 card (Polaris11), running the native freedomware kernel/mesa/xf86-video-amdgpu drivers. Possibly relevant version numbers: Gentoo/~amd64, Linux 5.8/5.9-rcs (tested/current), Qt-5.15.0, xorg-server-1.20.8-r1, mesa-20.1.6/20.2.0_rc2 (tested/current). Further testing revealed that with either the opengl-3.1 or opengl-2.0 backends set in the compositor kcm, aurorae-based titlebars were transparent, while xrender, as expected, rendered fine, tho of course slower and disabling opengl-only effects like wobbly-windows. Disabling compositing of course rendered the titlebars too, but disabled effects such as zoom and window transparency that I would have serious trouble doing without (especially transparency due to old-eyes). The gentoo/xorg folks suggested I try restarting kwin_x11 from a terminal window to see if I got any useful diagnostics. Unfortunately, as I pointed out, most kde apps, kwin_x11 included, spit out all sorts of alarming looking output even when they're (to all appearances) working just fine so such output tends to be effectively useless unless you can get a diff between the output in the good and bad cases. Fortunately I was able to rebuild multiple times for testing, toggling between eselect-opengl and libglvnd mediated mesa, so getting the good/bad outputs to diff wasn't /too/ horribly difficult, just inconvenient. Unfortunately even the kwin_x11 good/bad output diff, while smaller, was still incredibly noisy. Manually cutting it down further based on messages the diff had already excluded, the result was two lines appearing only in the bad/libglvnd case, in order with some noise in between: QQuickRenderControl::initialize called with incorrect current context QOpenGLVertexArrayObject::destroy() failed to make VAO's context current Further testing indicated that (as one might expect) the ::initialize error appears at kwin_x11 --replace load time, while the ::destroy() error appears later, when closing a window. Typically, regardless of the windeco (so running unaffected breeze/oxygen as well as affected aurorae-based), kwin_x11 --replace will crash a few times then come up with the other-wm dialog. With no other wms installed I just hit OK with the pre-filled kwin_x11, but by then it has restarted without composite and doesn't crash further. *But* I can then turn composite back on and it still doesn't crash, aurorae-based windecos simply go transparent, while oxygen/breeze windecos and kwin effects work normally. I'll only crash kwin again if I do another --replace, at which point it starts the multi-crash, return-with-compositing-disabled, renable-compositing to be stable again but with transparent aurorae-based windecos, routine all over again. Given that the bug originally triggered with the Gentoo switch to libglvnd (with the older eselect-opengl masked and set to be removed in a month, now perhaps 3 weeks), I originally filed a bug there, but the bug now appears to be in kwin/aurorae, so I'm filing it here. Two other points of interest on the Gentoo bug are: 1) A gentoo/kde dev tested as well and couldn't duplicate for whatever reason. He was running a Radeon of some sort, he didn't say what, and versions he said were similar to mine. I'd guess he's running a newer Radeon and the difference is either the hardware itself or down to hardware-specific drivers, but of course on gentoo there's all sorts of possible
[kwin] [Bug 425864] Aurorae-based windecos vanishing with libglvnd
https://bugs.kde.org/show_bug.cgi?id=425864 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added URL|https://bugs.kde.org/show_b | |ug.cgi?id=425864| --- Comment #2 from Duncan <1i5t5.dun...@cox.net> --- (In reply to Duncan from comment #1) > Adding the upstream kwin bug URL here as a comment and to the URL field: > https://bugs.kde.org/show_bug.cgi?id=425864 Oops, wrong bugzi tab! =:^) -- You are receiving this mail because: You are watching all bug changes.
[Oxygen] [Bug 425874] New: Shorter titlebar (without smaller font) option needed: less padding
https://bugs.kde.org/show_bug.cgi?id=425874 Bug ID: 425874 Summary: Shorter titlebar (without smaller font) option needed: less padding Product: Oxygen Version: unspecified Platform: Other OS: Other Status: REPORTED Severity: wishlist Priority: NOR Component: win deco Assignee: unassigned-b...@kde.org Reporter: 1i5t5.dun...@cox.net Target Milestone: --- So this is a follow-on to bug #425864, an aurorae-based windecos bug. As I worked on that bug I realized once again the reason I was running an aurorae-based windeco in the first place -- I needed a relatively short-height titlebar without forcing the font to microscopic in ordered to get it. Put differently, oxygen and breeze are both far too empty-space vertical-padding-heavy for users who like titlebars but don't want to /waste/ space, with no option other than hacking the code itself to reduce padding to something reasonable for a minimal-height titlebar just tall enough to fit the chosen font size. Years ago I found an aurorae-based windeco (black square) on kde-look that was quite close to what I wanted/needed, and being aurorae-based, finding and editing the height to cut just a couple extra pixels was relatively simple. While aurorae-based did mean it lacked some of the fancy options that breeze and oxygen had, it did what I needed and worked fine for years... until my distro (Gentoo) decided to switch to libglvnd for automatic handling of the opengl driver, thus triggering the unfortunate 100% transparent titlebars bug with aurorae-based windecos I just mentioned, above. It turned out that neither the oxygen nor breeze windecos had that bug, but they still had the horribly fat vertical-padding issue that had driven me to looking for alternatives on the then kde-look in the first place, alternatives that were almost all aurorae-based. So here I am filing this bug, wanting some option to reduce the vertical padding for oxygen/breeze, so I can get back those fancy titlebar effects without wasting all that empty space real window content can put to better use! Now I'm running gentoo so build from sources all the time, and for kde-frameworks/plasma/apps I run the live-git versions from the gentoo/kde overlay and regularly bisect and file bugs, etc. So applying patches locally isn't a big deal, and while I'm not a dev, occasionally, especially when pointed at the right place by a commit, I can modify or create my own patches that do what I want to do. In this case I didn't have commits to point my way, but finding where and patching Oxygen to "reduce the fat" turned out to be far easier as a git-literate advanced gentooer but never-the-less non-dev, than figuring out how to patch aurorae to fix the bug with it! So that's what I did, I hack-patched oxygen, reducing the titlebar vertical padding so I could have a reasonably sized actually readable font (8pt Noto Sans)... and still limit my titlebars to the 15 px high I was using on black-square with the same font! I knew was possible because I /did/ have black-square doing it, and after a long day of hack-patching, I finally had the oxygen windeco doing the same thing. By contrast, without the patches even the absolute minimum and totally unreadable 4 pt font size was heavier weight height-wise, and anything readable was effectively double the height, 30 px or more! A couple days later, to my surprise, I found that the hack-patches I had only applied to oxygen reduced the fat-padding on breeze as well, and it too could now handle 8 pt Noto Sans titlebar fonts at 15 px titlebar height. Now these are only hack-patches; I'm not a dev and don't-know-how/didn't-bother-to-try-to-figure-out-how, to setup proper padding options. But I figure if I found these useful enough to spend 12-hours plus reading and experimentally hack-patching to get it to work, surely, there's others out there that could use the same features I hack-patched, especially if all they have to do is spend a few seconds to select an option to get them. So that's what I'm asking for, the option. I'll upload my hack-patches so you can see exactly what I changed, and hopefully, proper patches to do the same thing with options aren't too much trouble, and don't violate the guidelines badly enough that they can't at least be made options. Else if it's simply too far out of policy, now that I have the hack-patches I can keep hack-patching for my own needs with little further trouble, any maintenance will after all have git commits pointing the way, unlike these initial hack-patches, but surely, some others will find the option useful, if it's there for them to find at all. =:^) See also bug #418904 (filed by someone else), but that's style/widgets not titlebar/windeco. Demo hack-patches to come, but it's a few days after my 12+ hour hackathon, and on pre-posting second-look I
