[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 429168] wayland: taskmanager and icons-only taskmanager only show pinned, no running
https://bugs.kde.org/show_bug.cgi?id=429168 --- Comment #34 from Duncan <1i5t5.dun...@cox.net> --- With today's updates (previous update was a week ago) I suddenly had running windows showing up! =:^) Without actual bisecting I believe the problem was resolved by: kwin commit 9c65d61b9 utils/serviceutils: compare executablePath against canonical path of exec fields in .desktops Quoting its comment: | /proc/%/exec always points to the canonical/real path of a binary, | the exec field of a .desktop might contain a symlink and therefore | differ from canonical path. | Explicitely canonicalizing the path in exec prevents this mismatch. As I noted in an earlier comment, I have a "reverse usr-merge" with my /usr being a symlink /usr -> . so all of /usr ends up actually directly under /, but still accessible under /usr via the symlink. The (gentoo/kde overlay live-git) installation, however, is still to /usr, so that's what the paths in the *.desktop files presumably use. This commit adjusts to use the canonical path, so the paths started matching and the X_KDE_Wayland_Interfaces= line in the *.desktop file actually took effect! Regardless of whether that's the fix or not, the bug as I filed it appears to be fixed. However, there's a bunch of others duped to this bug now that were more intermittent and thus may well be different bugs that aren't fixed yet. So pending other reports that those are fixed too I'll leave the bug open for now... -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 450326] Does Plasma Desktop really need to offer the Desktop containment layout?
https://bugs.kde.org/show_bug.cgi?id=450326 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added CC||1i5t5.dun...@cox.net --- Comment #1 from Duncan <1i5t5.dun...@cox.net> --- [Found in last-24-hour search while looking for something else. CCing and commenting as I find it interesting.] Count me as one of the "hate desktop icons" users. Since the location's adjustable I'm not against it in general but some random thoughts as a live-git tester/user both pro and con. Evaluate their worth and proceed accordingly. =:^) * FWIW I use the "Desktop" dir as a "working" dir dumping ground for current downloads and (in a subdir) whatever else I might be working on, because it's not just icons on the desktop (which I don't want) but also a default central "Place", easily accessible from many apps including non-kde apps that don't necessarily have the "Places" flexibility that kde/plasma does. So while I (and others in the "hate" group) could of course simply point the plasma desktop to some other empty dir, the implications of desktop containment removal /are/ rather larger than comment #0 implied. * Of course this will trigger a bunch of hubbub in the community, likely a bunch of extra filed bugs, etc. It /will/ be seen (at best) by those affected as "change for change sake." Is it worth it? (It may be, I'm not the one to say, but the question should be considered given the predicted community view.) * Certainly eliminating the choice (since the location can be pointed at an empty dir in any case) will simplify things, changing the "plasma lost its settings again and I gotta reset from defaults" procedure from "switch to desktop containment before doing anything else or you'll lose the other changes", to "at your leasure, re-point the location to an empty dir", as well as the one-less-config-option simplification. That's a positive, but arguably less of one for me and others like me, because the required customization step will be changed, not eliminated. * Note that (presumably) the other shells don't have as high a usage as plasma-desktop. In particular, I suspect it's likely that most of your "live-git" (me) and beta-tester users are using the desktop shell. Thus, if the desktop containment is retained only for those other shells the highest cost (from the CI perspective at least) is likely to be in not catching any desktop-containment-specific bugs as quickly, potentially resulting in a worse experience for release users of the other shells. Given that the folder containment includes all the functionality anyway that may not be seen to be an issue, but if it is, it may be that the desktop containment needs either kept or dumped in its entirety, including for the other shells. Whether it's useful enough there to actually be required is something I can't evaluate, but much of the code simplification benefit will only occur if it's dumped entirely, and given the above cost factors of losing it, it may simply not be worth it to do part way. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 450359] New: kwin commit e1024d38d broke the slidingpopups and startupfeedback effects builds
https://bugs.kde.org/show_bug.cgi?id=450359 Bug ID: 450359 Summary: kwin commit e1024d38d broke the slidingpopups and startupfeedback effects builds Product: kwin Version: git master Platform: Gentoo Packages OS: Other Status: REPORTED Severity: normal Priority: NOR Component: effects-various Assignee: kwin-bugs-n...@kde.org Reporter: 1i5t5.dun...@cox.net Target Milestone: --- [ On gentoo's live-git master packages at kwin commit 648b2a5bf ] commit e1024d38d cmake: Specify link libraries per effect target ... broke building the slidingpopups and startupfeedback effects and thus building kwin. The error (for slidingpopups in this case) is: effects/slidingpopups/slidingpopups.cpp:14:10: fatal error: QApplication: No such file or directory 14 | #include The fix is adding Qt::Widgets to the slidingpopups and startupfeedback CMakeLists.txt files under target_link_libraries. With that they and kwin build again. -- You are receiving this mail because: You are watching all bug changes.
[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 Status|REPORTED|NEEDSINFO Resolution|--- |WAITINGFORINFO --- Comment #12 from Duncan <1i5t5.dun...@cox.net> --- Anyone else still seeing this bug? Pending that I'm setting status to NEEDSINFO/WAITINGFORINFO FWIW I've been wayland-only for awhile now and in fact don't have xorg installed at all any longer -- the only X I have is xwayland on kwin_wayland (with weston as a backup compositor), so for me this is obsolete. I believe the needsinfo/waitingforinfo status will auto-resolve after a few weeks if nobody says they're still seeing it and resets the status. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 450359] kwin commit e1024d38d broke the slidingpopups and startupfeedback effects builds
https://bugs.kde.org/show_bug.cgi?id=450359 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #9 from Duncan <1i5t5.dun...@cox.net> --- Verified fixed and building as of 886173cab. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 450582] Some change between 5.24.0 and 5.24.1 broke windows shade/shutter feature
https://bugs.kde.org/show_bug.cgi?id=450582 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added CC||1i5t5.dun...@cox.net Summary|Some change between 5.24.0 |Some change between 5.24.0 |and 5.24.1 broke windows|and 5.24.1 broke windows |shutter feature |shade/shutter feature --- Comment #6 from Duncan <1i5t5.dun...@cox.net> --- (In reply to Vlad Zahorodnii from comment #2) > What's window shutter? Window Shade, I believe (took me a moment to figure out too). Retitling bug to reflect... (Running git-master plasma/frameworks here but I don't use the shade feature often enough to notice any changes myself and I can't test ATM as at least on wayland shade seems to be a disabled option in the window menu ATM??) -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 454933] New: Saving to network fails
https://bugs.kde.org/show_bug.cgi?id=454933 Bug ID: 454933 Summary: Saving to network fails Product: okular Version: 20.12.3 Platform: Ubuntu Packages OS: Linux Status: REPORTED Severity: critical Priority: NOR Component: general Assignee: okular-de...@kde.org Reporter: dun...@lithgow-schmidt.dk Target Milestone: --- SUMMARY *** NOTE: If you are reporting a crash, please try to attach a backtrace with debug symbols. See https://community.kde.org/Guidelines_and_HOWTOs/Debugging/How_to_create_useful_crash_reports *** STEPS TO REPRODUCE 1. Open a PDF file from a network directory (smb) 2. Work in the file, adding markups 3. Try to save with a new name (probably name makes no difference) OBSERVED RESULT The 'save as' dialogue closes without complaining but the file has not been saved and Okular is now frozen and can't be closed by the usual GUI methods. EXPECTED RESULT In order of preference 1. The files should be saved 2. Okluar should report that it cannot save the file because ." ... " SOFTWARE/OS VERSIONS GNU/Linux: Ubuntu 22.04 Gnome: 42.1 ADDITIONAL INFORMATION The smb share is on a Synology NAS running updated DSM OS. This same operation works fine with LibreOffice files and a PDF opened and saved with the default Document Viewer -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 454933] Saving to network fails
https://bugs.kde.org/show_bug.cgi?id=454933 --- Comment #2 from duncan --- The path is already mounted and a LibreOffice file is saving a document around the same time to the same directory. The path looks like this: /run/user/1000/gvfs/smb-share:server=kiwinest2.local,share=storage/Gyldenmuld_4/Gyldenmuld_renovering/Tegninger Gyldenmuld_2022.05.29_dli.pdf I notice that Okular cannot open the file itself when I navigate to the file. It can only open the file from my file manager by specifying Okular (rather than the current default PDF viewer). It can also open the file by the recent files list from the file manager. The file is not listed in Okulars own recent files list. So now I'm wondering if Okular can even see the file in that location. I'm not sure how to test what might be going on to see if this has much to do with Okular at all or is a wider problem. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 454933] Saving to network fails
https://bugs.kde.org/show_bug.cgi?id=454933 --- Comment #3 from duncan --- So after chatting with some Ubuntu folks I tried to install Okular as a flatpak instead of as a snap (default method). This is just to let you know that it made no difference and Okular behaved the same. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 454933] Saving to network fails
https://bugs.kde.org/show_bug.cgi?id=454933 duncan changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |REPORTED -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 454933] Saving to network fails
https://bugs.kde.org/show_bug.cgi?id=454933 --- Comment #5 from duncan --- Hi Nate Yes this is Gnome in a very vanilla and fresh Ubuntu install of 22.04. Sadly I cannot paste a file path into the default file manager anywhere ... But if I navigate to the path fully (/run/user/1000/gvfs/ etc) it opens. It does not open using the shortcut/bookmark in the file manager (smb//kiwinest2.local/storage). Even if opened with the full path I cannot save the file to that location afterwards. Full path - yes. Via bookmark - no. Saving - no. -- You are receiving this mail because: You are watching all bug changes.
[kdeplasma-addons] [Bug 455062] New: PotD: Setting a provider on multi-monitor sets all of them to the same one
https://bugs.kde.org/show_bug.cgi?id=455062 Bug ID: 455062 Summary: PotD: Setting a provider on multi-monitor sets all of them to the same one Product: kdeplasma-addons Version: git-master Platform: Gentoo Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Picture of the Day Assignee: plasma-b...@kde.org Reporter: 1i5t5.dun...@cox.net CC: i...@guoyunhe.me, qydwhotm...@gmail.com Target Milestone: --- This is on git-master frameworks/plasma using the gentoo/kde live-git ebuilds, on qt 5.15.4. Current kdeplasma-addons commit f3db2b5c84c7e1a7aa1f8f2bef32a8b8ecbf34b0 . I'm running on wayland without X (other than xwayland) installed. (Tho I do have weston installed as a wayland compositor backup; I /am/ running live-git kwin/kde, after all.) Since the PotD rework in April/May, my dual-monitor (side-by-side) layout cannot setup different PotDs for each monitor. Setting one will either set both to the same PotD provider or do nothing. ( As best I've been able to work out, setting it to PotD from image on one monitor will set it on both, after which I cannot set it to another PotD on the other -- but setting it to a different PotD on the first will reset it to that one on both. However, I'm not /entirely/ sure that's the specific behavior, while I /am/ sure I can't set different ones on each, sometimes it ignores the setting, sometimes it resets both.) Despite not being able to set different PotD providers on each monitor, the positioning settings remain distinct -- I can set one to scaled while the other is set to scaled-and-cropped, for instance, and that is honored. Further, I can still set (local) image (and presumably the other non-PotD choices) separately, both to separate images, and with both set to (the same) PotD, I can set either one to an image. I just can't set different PotD providers on each one. The result is that if I want different images on each monitor with a PotD, I must choose a single PotD first and set it, then change the other to a (local) image. (And while you are looking at this PotD bug, could you see about the long-standing broken-PotD-centering-option bug #389623 as well. It has existed since at least 2018 as that's when the bug was filed.) -- You are receiving this mail because: You are watching all bug changes.
[kdeplasma-addons] [Bug 389623] potd "Centered" positioning behaves exactly as "Tiled" somewhy
https://bugs.kde.org/show_bug.cgi?id=389623 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Ever confirmed|0 |1 Status|REPORTED|CONFIRMED CC||1i5t5.dun...@cox.net --- Comment #2 from Duncan <1i5t5.dun...@cox.net> --- This is a long-standing bug I still see. Confirming and CCing. (And also mentioning in a new PotD bug 455062. They're working on PotD ATM thus creating that bug; maybe they can finally fix this one too.) Actually, what I'd consider *ideal*, tho it'd require additional UI, would be adjustable zoom/pan so the portion of the image shown could be selected, be that top-left, centered at 100%, bottom-right, or other. And of course make it so such a choice can be applied to either PotD or local images. Alternatively, remove the "centered" option for PotD since it's just broken, and has been for years. -- You are receiving this mail because: You are watching all bug changes.
[kdeplasma-addons] [Bug 389623] potd "Centered" positioning behaves exactly as "Tiled" somewhy
https://bugs.kde.org/show_bug.cgi?id=389623 --- Comment #3 from Duncan <1i5t5.dun...@cox.net> --- CCing Fushan Wen as he seems to have been doing all the recent PotD work. Maybe he can fix this one while he's at it. =:^) -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 466126] Issues with panel autohide on specific monitor setup
https://bugs.kde.org/show_bug.cgi?id=466126 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Resolution|--- |DUPLICATE CC||1i5t5.dun...@cox.net Status|REPORTED|RESOLVED --- Comment #2 from Duncan <1i5t5.dun...@cox.net> --- This is almost certainly a duplicate of bug #351175. Marking it as such. However, I'm just another user with another dupe, not a dev, so if you think it's not a dupe, feel free to reverse that and explain the difference. Briefly, the problem is with "internal" borders/edges (aka "struts") between monitors. As long as the panel is on a true edge of the bounding rectangle things are fine, but put it on a strut that's "internal", not on the bounding rectangle edge, and the autohide does the immediate re-popup thing exactly as you describe. Unfortunately fixing this bug doesn't appear to be a priority, despite the number of dupes and thus users obviously affected. Two known workarounds: 1) Change your layout and/or panel position to avoid placing panels on such "internal" struts. (This one's obvious once the problem is understood. For me, it was the excuse I needed to upgrade my older FullHD monitor to a second 4K so they'd match sizes and I'd have no need to place a panel on the previously partial seam between them.) 2) It has been reported that separating the monitors in the kscreen layout so they don't logically touch eliminates the issue as it fools the logic into thinking all the edges are external, while still allowing the pointer to move between screens (which I thought would be broken, but apparently not). IMO that's quite clever and I really wish I had thought to try it before throwing money at the problem (but of course that would have done away with my excuse to upgrade =:^) *** This bug has been marked as a duplicate of bug 351175 *** -- 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 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added CC||fre...@bananateam.nl --- Comment #49 from Duncan <1i5t5.dun...@cox.net> --- *** Bug 466126 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[kpat] [Bug 466229] New: Spider segfaulting, new solver (417bdc2ec) bug?
https://bugs.kde.org/show_bug.cgi?id=466229 Bug ID: 466229 Summary: Spider segfaulting, new solver (417bdc2ec) bug? Classification: Applications Product: kpat Version: unspecified Platform: Gentoo Packages OS: Linux Status: REPORTED Severity: crash Priority: NOR Component: solver Assignee: co...@kde.org Reporter: 1i5t5.dun...@cox.net CC: kde-games-b...@kde.org Target Milestone: --- Live-git version updated yesterday (Feb 20, 2023), using the gentoo/kde project overlay's live-git packages, reported as 23.03.70 (both unlisted so I can't set that version above), with live-git frameworks-5 as well. Qt is 5.15.8 (current as of yesterday with gentoo's regular sub-version update patchsets) . Spider has started segfaulting on me recently (the other kpat games I play regularly, klondike and freecell, are fine), with several weeks of further updates not fixing it yet. The timing and spider-specificness suggest it's due to a race or nul-deref in the new solver, tho I'm filing this with the info I have before bisecting to confirm that. Maybe happenstance, but at first it /seemed/ to happen nearly immediately after starting a spider round, often on (before ?) the first move, but something (maybe just another rebuild, or an update of libkdegames, some framework, or qt5, as I see no further kpat code changes gitlogged, only l10n/appstream) seems to have decreased the frequency of the issue since and I can often get in a number of moves now before the segfault. Once I was even able to finish a round and I hoped for a moment the problem was fixed, but it segfaulted on the second round. The output when started from konsole is unhelpful; an initial complaint from QFont::setPixelSize that appears unrelated as it happens well before the segfault, then nothing as I play until the segfault: QFont::setPixelSize: Pixel size <= 0 (0) Segmentation fault For reference here's the suspect commit (email addresses despammed for posting): * commit 417bdc2ec | Author: Stephan Kulow | AuthorDate: Fri Jan 20 10:51:07 2023 +0100 | Commit: Albert Astals Cid | CommitDate: Sun Jan 22 22:33:51 2023 + | | Replace spider solver with a self serving solution | | This is something I had lying around (don't ask). It's generally | slower (as it tries harder to find an optimal solution), but finds | solutions more reliably - and is possibly easier to debug for | other people :) -- You are receiving this mail because: You are watching all bug changes.
[kpat] [Bug 466229] Spider segfaulting, new solver (417bdc2ec) bug?
https://bugs.kde.org/show_bug.cgi?id=466229 --- Comment #1 from Duncan <1i5t5.dun...@cox.net> --- Bisecting confirms it's the new solver. 417bdc2ec (the new solver) bad. 3c581787e (the commit previous to that) seems to be fine. (Well, at least it played a full round without segfaulting, tho as I mentioned above that did happen -- once -- with the bad code, too.) -- You are receiving this mail because: You are watching all bug changes.
[kpat] [Bug 466229] Spider segfaulting, new solver (417bdc2ec) bug?
https://bugs.kde.org/show_bug.cgi?id=466229 --- Comment #3 from Duncan <1i5t5.dun...@cox.net> --- (In reply to Stephan Kulow from comment #2) > Hi, can you export KDE_DEBUG=1 before starting it from console? Then > something useful should appear in coredumpctl (typing from memory as I'm not > having a computer around). Kernel CONFIG_COREDUMP=n, so coredumpctl never gets the cores from the kernel. I could change that if necessary (tho would rather not deal with figuring out all that config), but what about running via gdb instead? Meanwhile , dmesg does say SolverThread SIGSEGV ... error 6 in kpat ... Currently the gdb likely isn't much help due to stripped binaries, but here's what I get ATM... A bunch of New Thread ... Thread exited pairs, apparently one per move, I guess for the solver threads. Then at the SIGSEGV... [New Thread 0x7fffd99fc6c0 (LWP 13533)] Thread 381 "SolverThread" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffd99fc6c0 (LWP 13533)] 0x555d762e in ?? () (gdb) bt #0 0x555d762e in ?? () #1 0x555d8546 in ?? () #2 0x555d9726 in ?? () #3 0x555da057 in ?? () #4 0x5558eab7 in ?? () #5 0x764cb05f in ?? () from /usr/lib64/libQt5Core.so.5 #6 0x75ee042d in ?? () from /usr/lib64/libc.so.6 #7 0x75f5943c in ?? () from /usr/lib64/libc.so.6 (gdb) I'll have to look up again how to build unstripped, with debugging enabled (IIRC gentoo/kde has a guide I'll need to reread, I've done it once before for something and it wasn't difficult) to fill in the ??s. Hopefully this weekend... -- You are receiving this mail because: You are watching all bug changes.
[kpat] [Bug 466229] Spider segfaulting, new solver (417bdc2ec) bug?
https://bugs.kde.org/show_bug.cgi?id=466229 --- Comment #4 from Duncan <1i5t5.dun...@cox.net> --- (In reply to Duncan from comment #3) > I'll have to look up again how to build unstripped, with debugging enabled This is more like it. (The - bit is gentoo's normal live-git package version-numbering.) Again, a bunch of new-thread/thread-exited per-move as the solver-thread starts and exits, then... [New Thread 0x7fffd9da96c0 (LWP 74954)] Thread 159 "SolverThread" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffd9da96c0 (LWP 74954)] 0x75ef3c0b in memmove () from /usr/lib64/libc.so.6 (gdb) bt #0 0x75ef3c0b in memmove () from /usr/lib64/libc.so.6 #1 0x555c060e in memcpy (__len=, __src=0x7fffb80ce700, __dest=0x7fffa4020ea8) at /include/bits/string_fortified.h:29 #2 Deck::update (this=this@entry=0x7fffa4020e28, other=other@entry=0x7fffb80ce680) at ../kpat-/src/patsolve/spidersolver2.cpp:656 #3 0x555c169e in Deck::applyMove (this=this@entry=0x7fffb80ce680, m=..., newdeck=...) at ../kpat-/src/patsolve/spidersolver2.cpp:677 #4 0x555c1bfd in Deck::shortestPath (this=, cap=cap@entry=150) at ../kpat-/src/patsolve/spidersolver2.cpp:802 #5 0x555c1eaa in SpiderSolver2::patsolve (this=0x56e473f0, max_positions=-1) at ../kpat-/src/patsolve/spidersolver2.cpp:941 #6 0x55586979 in SolverThread::run (this=0x55dddfe0) at ../kpat-/src/dealer.cpp:157 #7 0x764cb05f in ?? () from /usr/lib64/libQt5Core.so.5 #8 0x75ee042d in ?? () from /usr/lib64/libc.so.6 #9 0x75f5943c in ?? () from /usr/lib64/libc.so.6 (gdb) glibc-2.36-r7 (r7 being the gentoo package revision), gcc-12.2.1_p20230121-r1, qtcore-5.15.8-r3. For the debug I built kpat with C(XX)FLAGS="-ggdb -Og", which I'll leave in place for the moment in case you need something beyond the simple bt. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 413645] Can't remember desktop widget positions after reboot
https://bugs.kde.org/show_bug.cgi?id=413645 --- Comment #35 from Duncan <1i5t5.dun...@cox.net> --- (In reply to Aaron Rainbolt from comment #34) > I can also resolve the problem by entirely removing the "ItemGeometries" > line and leaving the "ItemGeometriesHorizontal" line. However, again, this > line is recreated at login, and if left at logout, the widget will again > "wander" and then snap. So something about the two entries coexisting is > causing things to go wrong. Those floating-point values look suspect. Does manually setting them to integer values (767 and 688) help? If not or if it doesn't stick, try the following... This bug has been around awhile, but there was a workaround I initially described in https://bugs.kde.org/show_bug.cgi?id=389141 that (with a bit of updating) presumably still works (see below): With the plasmoids in the desired location (either with the ItemGeometries lines deleted or with them set as desired, not sure which), set plasma-org.kde.plasma.desktop-appletsrc (normally found in ~/.config unless you set $XDG_CONFIG_HOME) read-only. This should prevent it from being overwritten with the bad config but unfortunately you'll still need to manually restart the initially started mixed-up plasmashell (plasmashell --replace, unfortunately at each login, tho it can be scripted as described below) in ordered to get it to take, since that initial start is what goes haywire. You can try the --replace from krunner. If that works as I expect it will, automate it with a script set to autostart (see the autostart kcontrol/systemsettings module), with a few seconds sleep to let the system stabilize before the --replace command. Of course with the desktop-appletsrc file set readonly reconfiguring things will work only for that plasmshell session so you'll have to remember to toggle it back read-writable if you want to reconfigure... (I believe the bug trigger here was a multi-monitor setup with different resolutions for each monitor, one full-HD one 4K. When I upgraded to matching-resolution 4Ks it stopped triggering for me so I've not seen the bug in awhile. Thus the "presumably still works" qualification above.) -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 413645] Can't remember desktop widget positions after reboot
https://bugs.kde.org/show_bug.cgi?id=413645 --- Comment #44 from Duncan <1i5t5.dun...@cox.net> --- (In reply to Aaron Rainbolt from comment #42) > [T]he problem might actually be the > result of a resolution change during early startup Yes. In my (different resolution dual-monitor) case the problem was definitely the resolution switch, in that case on the high resolution monitor (actually a 4K TV), switching from the resolution of the low-resolution monitor (a Full-HD TV). What was happening is that all the widgets on the high-res monitor were moved to fit within the confines of the low-res monitor, thus all repositioning in the top-left quadrant of the high-res monitor. It was pretty obvious -- once I noticed it. =:^\ The problem went away when I switched to both 4K monitors so there wasn't a resolution-switch. Before that I worked around it by setting the rc-file read-only (so the bad startup wouldn't overwrite the good config) and setting up a start-up script that slept for a few seconds then did a plasmashell restart, basically doing via user script exactly what you suggested, waiting until after the resolutions settled in before (re)starting plasmashell. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 470328] New: LSP Client: Kate's LSP parser does not support codeDescription from a server
https://bugs.kde.org/show_bug.cgi?id=470328 Bug ID: 470328 Summary: LSP Client: Kate's LSP parser does not support codeDescription from a server Classification: Applications Product: kate Version: 22.12.3 Platform: Ubuntu OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: general Assignee: kwrite-bugs-n...@kde.org Reporter: kde.b...@cricalix.net Target Milestone: --- SUMMARY Kate's LSP handler (https://github.com/KDE/kate/blob/master/addons/lspclient/lspclientserver.cpp#L829) does not handle a returned codeDescription attribute of a Diagnostic. STEPS TO REPRODUCE 1. Use a LSP that returns a codeDescription for a diagnostic 2. Trigger a diagnostic that includes that codeDescription attribute OBSERVED RESULT No rendering of a codeDescription entry in the JSON diagnostic EXPECTED RESULT Kate is able to render the `href` attribute of the codeDescription as part of the diagnostic data, linking the user to documentation that explains the diagnostic in detail. SOFTWARE/OS VERSIONS Operating System: Kubuntu 23.04 KDE Plasma Version: 5.27.5 KDE Frameworks Version: 5.106.0 Qt Version: 5.15.8 Kernel Version: 6.2.12-060212-generic (64-bit) Graphics Platform: X11 Processors: 24 × AMD Ryzen 9 5900X 12-Core Processor Memory: 31.2 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 3060 Ti/PCIe/SSE2 ADDITIONAL INFORMATION Based on the linked source code, `relatedInformation` is processed, but this attribute of a Diagnostic is for "these other document locations are affected". I'm currently scratching an itch of having Meta's Pyre type checker integrated as a plugin for `python-lsp-server`, but have run into the stumbling block that Kate won't render a `codeDescription` attribute. `codeDescription` was added in 2020 to the specification - https://microsoft.github.io/language-server-protocol/specifications/specification-3-16/#diagnostic -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 471173] New: git okular build cmake error at 9f498c7f5
https://bugs.kde.org/show_bug.cgi?id=471173 Bug ID: 471173 Summary: git okular build cmake error at 9f498c7f5 Classification: Applications Product: okular Version: unspecified Platform: Gentoo Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: okular-de...@kde.org Reporter: 1i5t5.dun...@cox.net Target Milestone: --- Okular (and frameworks5/plasma/many-other-kde-apps) from git, using the gentoo/kde project overlay live-git packages. Currently reporting 23.07.70 but bugzi's version selector has no git option nor 23.07.70, so unspecified it is. Yesterday/today I updated to qt 5.15.10 and okular was on the triggered reverse-deps-rebuild list. At head 0c383d8cf it failed both the initially triggered rebuild and further rebuild attempts after finishing the system update and doing a full smart-live-rebuild (all packages with git updates available, but for okular of course due to this bug). A bisect points to culprit (emails despammed): commit 9f498c7f5 Author: Sune Vuorela AuthorDate: Thu Apr 20 16:17:41 2023 +0200 Commit: Nate Graham CommitDate: Wed Jun 14 17:47:41 2023 + Allow new signatures to have image backgrounds The reported cmake error is: CMake Error at generators/poppler/CMakeLists.txt:40 (target_compile_definitions): Cannot specify compile definitions for target "imageScalingTest" which is not built by this project. Note that I have build-testing turned off (Portage's FEATURES=-test, the okular package's USE=-test). Noting the named imageScalingTest target and assuming testing/CI has testing on suggests a likely testing-option-off logic error. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 471173] git okular build cmake error at 9f498c7f5
https://bugs.kde.org/show_bug.cgi?id=471173 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added CC||n...@kde.org, ||s...@vuorela.dk --- Comment #1 from Duncan <1i5t5.dun...@cox.net> --- CCing author/committer. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 471173] git okular build cmake error at 9f498c7f5
https://bugs.kde.org/show_bug.cgi?id=471173 --- Comment #2 from Duncan <1i5t5.dun...@cox.net> --- (In reply to Duncan from comment #0) > commit 9f498c7f5 > Noting the named imageScalingTest target and > assuming testing/CI has testing on suggests a likely testing-option-off > logic error. Confirmed that testing option logic error. Setting USE=test (without FEATURES=test it still doesn't actually run the tests) allows it to build. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 471173] git okular build cmake error at 9f498c7f5
https://bugs.kde.org/show_bug.cgi?id=471173 --- Comment #3 from Duncan <1i5t5.dun...@cox.net> --- Downstream gentoo bug at https://bugs.gentoo.org/908740 -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 468779] Fails to build without KActivities (wrong #if check)
https://bugs.kde.org/show_bug.cgi?id=468779 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added CC||1i5t5.dun...@cox.net --- Comment #1 from Duncan <1i5t5.dun...@cox.net> --- Created attachment 158576 --> https://bugs.kde.org/attachment.cgi?id=158576&action=edit #ifdef HAVE_KACTIVITIES -> #if HAVE_KACTIVITIES patch Confirmed bisect to b99f6f50e. Confirmed it builds with (gentoo) USE=kactivites. Here's the error without: src/global.cpp:20:10: fatal error: KActivities/Consumer: No such file or directory 20 | #include And a patch confirmed to fix it since I have it. I'm not a dev and don't know how to do PRs, but given cfeck's #IFDEF -> #IF hint and the commit, on gentoo a patch was trivial to do and test, so I might as well post it. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 468779] Fails to build without KActivities (wrong #if check)
https://bugs.kde.org/show_bug.cgi?id=468779 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED --- Comment #2 from Duncan <1i5t5.dun...@cox.net> --- Fixed with c3fb0dc15 -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 448532] Dolphin crashed while copying files to external hard drive
https://bugs.kde.org/show_bug.cgi?id=448532 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Status|RESOLVED|REOPENED CC||1i5t5.dun...@cox.net Resolution|FIXED |--- --- Comment #18 from Duncan <1i5t5.dun...@cox.net> --- (In reply to Méven Car from comment #17) > Git commit 6bea074739d5a75920d5540bc266549df5642511 by Méven Car, on behalf > of Akseli Lahtinen. > Committed on 15/12/2023 at 09:48. > Pushed by meven into branch 'kf5'. > > WidgetsAskUserActionHandler: Use QPointer to check the validity of parent > widgets This commit breaks a (kf5) kio rebuild (kf6 kio is fine at 25add040d, which includes the parallel bdef648ed from a couple weeks ago), at least on a hybrid kf5/kf6 system updating from yesterday using the gentoo/kde overlay. Occurs immediately after [381/472] in the build process. The errors are below. (5.239. is gentoo/kde's pseudo-version used for the kf5 frameworks live-git slot.) ../kio-5.239./src/widgets/widgetsaskuseractionhandler.cpp: In member function 'virtual void KIO::WidgetsAskUserActionHandler::requestUserMessageBox(KIO::AskUserActionInterface::MessageDialogType, const QString&, const QString&, const QString&, const QString&, const QString&, const QString&, const QString&, const QString&, const KIO::MetaData&, QWidget*)': ../kio-5.239./src/widgets/widgetsaskuseractionhandler.cpp:411:42: error: 'parentWidget' was not declared in this scope 411 | d->sslMessageBox(text, metaData, parentWidget); | ^~~~ ../kio-5.239./src/widgets/widgetsaskuseractionhandler.cpp: In member function 'void KIO::WidgetsAskUserActionHandlerPrivate::sslMessageBox(const QString&, const KIO::MetaData&, QWidget*)': ../kio-5.239./src/widgets/widgetsaskuseractionhandler.cpp:491:29: error: 'd' was not declared in this scope 491 | QWidget *parentWidget = d->getParentWidget(parent); | ^ ninja: subcommand failed -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 448532] Dolphin crashed while copying files to external hard drive
https://bugs.kde.org/show_bug.cgi?id=448532 --- Comment #21 from Duncan <1i5t5.dun...@cox.net> --- (In reply to Méven from comment #20) > Git commit b1820506f20088fad311d68f41aa4e35853ad436 > > WidgetsAskUserActionHandler: fix backport Indeed. Builds fine now. =:^) Thanks. -- You are receiving this mail because: You are watching all bug changes.
[kdeplasma-addons] [Bug 478807] New: kde-plasma-addons git-master build error against plasma5support git-master
https://bugs.kde.org/show_bug.cgi?id=478807 Bug ID: 478807 Summary: kde-plasma-addons git-master build error against plasma5support git-master Classification: Plasma Product: kdeplasma-addons Version: git-master Platform: Gentoo Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: General Assignee: plasma-b...@kde.org Reporter: 1i5t5.dun...@cox.net Target Milestone: --- At kde-plasma-addons f29b44f0e against plasma5support 22eb517de attempting to build kde-plasma-addons yields: CMake Warning at /usr/share/ECM/find-modules/FindKF6.cmake:52 (find_package): Could not find a configuration file for package "KF6Plasma5Support" that is compatible with requested version "5.91.90". The following configuration files were considered but not accepted: /usr/lib64/cmake/KF6Plasma5Support/KF6Plasma5SupportConfig.cmake, version: 5.91.0 /lib64/cmake/KF6Plasma5Support/KF6Plasma5SupportConfig.cmake, version: 5.91.0 That kills the build,, and no wonder, since it's looking for 5.91.90 (kde-plasma-addons version as of a9ec97b8b ) but plasma5support has only been updated (in HEAD, 22eb517de) to 5.91.0 . (Given the latest commits to both were less than 24 hours ago, I did a 24-hour search before filing, turning up nothing apropos.) -- You are receiving this mail because: You are watching all bug changes.
[kdeplasma-addons] [Bug 478807] kde-plasma-addons git-master build error against plasma5support git-master
https://bugs.kde.org/show_bug.cgi?id=478807 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added CC||j...@jriddell.org --- Comment #1 from Duncan <1i5t5.dun...@cox.net> --- CCing jriddell for release bumping. -- You are receiving this mail because: You are watching all bug changes.
[kdeplasma-addons] [Bug 478807] kde-plasma-addons git-master build error against plasma5support git-master
https://bugs.kde.org/show_bug.cgi?id=478807 --- Comment #2 from Duncan <1i5t5.dun...@cox.net> --- Manually bumping plasma5support to 5.91.90 (following the pattern of 22eb517de) and rebuilding it does the trick. But my git-foo is user/admin not dev side, so I know not how to do PRs... -- You are receiving this mail because: You are watching all bug changes.
[plasma-browser-integration] [Bug 478812] New: plasma-browser-integration e0a1a18cb bumps to 5.91.90, fails build against plasma-workspace f4129cf0f, still 5.91.0
https://bugs.kde.org/show_bug.cgi?id=478812 Bug ID: 478812 Summary: plasma-browser-integration e0a1a18cb bumps to 5.91.90, fails build against plasma-workspace f4129cf0f, still 5.91.0 Classification: Plasma Product: plasma-browser-integration Version: unspecified Platform: Gentoo Packages OS: Other Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: k...@privat.broulik.de Reporter: 1i5t5.dun...@cox.net Target Milestone: --- CMake Error at CMakeLists.txt:47 (find_package): Could not find a configuration file for package "LibTaskManager" that is compatible with requested version "5.91.90". The following configuration files were considered but not accepted: /usr/lib64/cmake/LibTaskManager/LibTaskManagerConfig.cmake, version: 5.91.0 /lib64/cmake/LibTaskManager/LibTaskManagerConfig.cmake, version: 5.91.0 -- You are receiving this mail because: You are watching all bug changes.
[plasma-browser-integration] [Bug 478812] plasma-browser-integration e0a1a18cb bumps to 5.91.90, fails build against plasma-workspace f4129cf0f, still 5.91.0
https://bugs.kde.org/show_bug.cgi?id=478812 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added CC||j...@jriddell.org --- Comment #1 from Duncan <1i5t5.dun...@cox.net> --- CCing jriddell for the version bump. Manually bumping plasma-workspace to 5.91.90 (following the pattern of 8620a0aec ) and rebuilding allows plasma-browser-integration to build as well. (I don't know how to do a PR.) -- You are receiving this mail because: You are watching all bug changes.
[plasma-browser-integration] [Bug 478812] plasma-browser-integration e0a1a18cb bumps to 5.91.90, fails build against plasma-workspace f4129cf0f, still 5.91.0
https://bugs.kde.org/show_bug.cgi?id=478812 --- Comment #2 from Duncan <1i5t5.dun...@cox.net> --- (In reply to Duncan from comment #1) > Manually bumping plasma-workspace to 5.91.90 ... allows plasma-desktop (which failed to build as well) to build too. Which would seem to make it a plasma-workspace failure-to-bump bug, not plasma-browser-integration or plasma-desktop either one except that they got bumped without first bumping the plasma-workspace dependency. But I don't see a plasma-workspace product to file against... -- You are receiving this mail because: You are watching all bug changes.
[kdeplasma-addons] [Bug 478807] kde-plasma-addons git-master build error against plasma5support git-master
https://bugs.kde.org/show_bug.cgi?id=478807 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Resolution|NOT A BUG |FIXED --- Comment #4 from Duncan <1i5t5.dun...@cox.net> --- Seems I was correct filing it as a bug after all (and the resolved/notabug, not my change, was wrong), fixed by plasma5support commit 8c9878917, which did exactly what I did locally to work around it, bumping the version to 5.91.90. So changing to the now correct resolved/fixed. -- You are receiving this mail because: You are watching all bug changes.
[plasma-browser-integration] [Bug 478812] plasma-browser-integration e0a1a18cb bumps to 5.91.90, fails build against plasma-workspace f4129cf0f, still 5.91.0
https://bugs.kde.org/show_bug.cgi?id=478812 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Resolution|NOT A BUG |FIXED --- Comment #4 from Duncan <1i5t5.dun...@cox.net> --- fanzhuyifan's notabug was in error. It's now fixed by plasma-workspace (despammed emails): * commit 678b3dedb (HEAD, master) | Author: Luca Beltrame | AuthorDate: Thu Dec 21 08:36:47 2023 +0100 | Commit: Luca Beltrame | CommitDate: Thu Dec 21 08:36:47 2023 +0100 | | Put version to 5.91.90 | | A bunch of other things looks for this version all around Plasma | repositories | | If in error, please revert, but at least this allows building. | | CMakeLists.txt | 2 +- | 1 file changed, 1 insertion(+), 1 deletion(-) Marking it as such. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kglobalaccel] [Bug 480304] Add support for second stroke shortcuts (feature request)
https://bugs.kde.org/show_bug.cgi?id=480304 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added CC||1i5t5.dun...@cox.net --- Comment #9 from Duncan <1i5t5.dun...@cox.net> --- TLDR summary: Brief kde multi-key global hotkeys history and current status, discussion of available user workarounds. FWIW this remains a long-term regression from the kde3 era where multi-key hotkeys worked fine, including even a popup menu after the first one showing configured second-key choices. Only now it's worse, at least on wayland, because unlike X where every app could see the keys entered (including passwords!!) entered on any other app, thereby allowing third-party global hotkey apps, that choice is gone on wayland (where apps other than the compositor only see keys entered while they are in focus) due to its higher security, so a standardized the third-party solution is out (but see option #3 below... and out at least until a wayland protocol extension is agreed that makes it possible, the mechanism by which third-party screenshotting apps can arrange for access to the visual contents of windows of other wayland apps, for instance). Available workarounds: 1) Stick to X and (continue to) use third-party X-based global hotkey solutions. Biggest downside is that X platform support is now second-class and gets less testing, with the problem only getting worse as time progresses, but if you already have other things keeping you on X and already have a third-party X hotkey app setup, this should work reasonably for awhile, anyway. But I'd *not* recommend this to people who haven't setup such an app yet as the timeframe it'll be viable is limited. Upgrade path would presumably be thru #2, below. 2) On wayland, configure "Legacy X11 App Support" (plasma system settings > security & privacy > application permissions) to "Allow legacy X11 apps to read keystrokes in all apps" to "always". Again, use a third-party X-based global hotkeys solution. This should continue to be supported much longer than #1 and is the likely upgrade path thru which people on #1 will move. As such it's much more viable. There's still a security tradeoff in that all X apps will be seeing your wayland keys as well, but security-wise, it's not worse than the X we used for decades, and is at least a step on the way, since wayland apps will at least not see each others keys even if X apps still do. The upgrade path from this will presumably be through #3, once a wayland protocol extension is standardized to make third-party wayland hotkey apps more viable. Meanwhile, this is likely the simplest solution, even if it is someone time-limited (but less than #1). 3) There is apparently at least one wayland third-party hotkey app, but I don't remember the name ATM (egg-something maybe?) and due to wayland's security which would normally break it, I believe it actually hooks into the input stream below wayland (at the /dev/input/* device-file level), which likely requires fiddling with device-file permissions. I've not looked into it further but have been meaning to as in theory that would have many of the same upsides as the #4 choice I took before I knew about this one, with less of the major downside, complexity, tho there'd still be some in getting the permissions correct and just learning its config. Eventually, wayland/XDG will likely standardize a protocol extension to make third-party global hotkey apps work without the degree of permission-changes, etc, now necessary, and there will be more of these third-party wayland-based apps, enough so as long as the compositor implements the extension, much like the existing situation on X, users won't be locked into whatever the desktop natively provides -- or fails to provide. This is thus the eventual ideal target. 4) Take advantage of the insight that multi-key can be seen as sequential keys, not all of which must be processed by the same app-instance, to cobble together a solution out of available components, with plasma only processing the initial hotkey to launch the cobbled-together solution to handle the second and further keys. This is in fact what I did back when the regression first hit with kde4, and what I still do today, altho I've changed the primary component I use since then. (I initially rolled my own bash script for the menu, but eventually switched to pdmenu...) Ideally, this would work like so: Configure a single plasma/kwin hotkey to launch a third-party menu app, which would then see and process the second and subsequent keys as it would then be the in-focus app. If more than one initial launcher keys are configured, each would conceptually launch the third party app as if it were a sub
[plasma-integration] [Bug 429403] Changing shortcut for "Move to Trash" breaks Delete key in text fields/editors
https://bugs.kde.org/show_bug.cgi?id=429403 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added CC||1i5t5.dun...@cox.net --- Comment #6 from Duncan <1i5t5.dun...@cox.net> --- CCing. THIS is why "delete" has very frustratingly not done text-delete for me for ages (since kde3 era I believe, certainly it was broken in kde/plasma5 and remains broken on 6, but not sure about 4)! Being an old-timer even the confirm-on-delete is a luxury and I just learned to be careful, tho I still find delete-confirmation a useful luxury so enable it where possible. But trash?! Bah-humbug! It just gets in the way of actually freeing the space I wanted free or I'd not be deleting the file in the first place! Unfortunately, kde/dolphin doesn't appear to allow actually disabling trash, but it's set to the smallest possible size (0.01%, ~2MB on my 20 gig /home) and time (24 hours), warn-on-full, which means a warning (I've gotten one in ~20 years!) if I mistakenly trash instead of delete a file over 2MB, (hopefully) delete with a llloonnggg latency of a 24 hours if it's under that. Meanwhile, the unused trash functionality shortcut is disabled, and delete is configured to do what it says on the label -- delete (albeit with confirmation). Now I find out that having delete configured to actually do what it says on the label (the key is NOT labeled "trash"!) for files is unintuitively killing the other normal delete-key functionality, text-deletion! =:^( At least now I can go digging in the source to see about changing the default shortcuts so delete actually does what it says on the label without me having to customize the shortcut, thus triggering this bug... -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 445447] Window Placement Centered Appears not to be Working on Wayland
https://bugs.kde.org/show_bug.cgi?id=445447 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added CC||1i5t5.dun...@cox.net --- Comment #1 from Duncan <1i5t5.dun...@cox.net> --- Two questions/comments: 1) Is it still happening with updates from Nov 14/15? I'm on live-git plasma/wayland (only, no X but xwayland, with weston as my falllback if plasma/kwin fails) using gentoo/kde's live-git packages here, updated late yesterday (14th) and again today (to see if an unrelated bug is fixed yet, it isn't and I came across this going thru new bugs looking to see if it's filed yet), and as of yesterday's update anyway, the new default-to-centered-placement worked. I prefer minimal overlapping however and immediately switched back to that. 2) Of course some apps will remember positioning (unless you have window rules set to prevent that) and will go to wherever they were last, which given the previous default to minimal-overlap, would have likely been in a corner. So I'm wondering if you just caught the updates at the wrong point (#1) and it's now fixed, or if you possibly only tried with apps that remember their position and went back to it, thus not getting the centering. Because the new centered-by-default definitely took here, likely with an update a few hours to a day after yours, and I had to reset it to my preferred mimimal-overlap behavior. If it's still not centering after a new update (and you didn't deliberately reset to minimal-overlap as I did), then yes, you definitely are seeing a continuing bug (that I'm not), as it definitely worked here. (Not sure whether as another user it'd be polite/reasonable to set bug status to NEEDSINFO or not, so I'll defer on that, but that's what I'd consider it now, because with luck you just updated at the wrong time and it's already fixed if you update again.) -- You are receiving this mail because: You are watching all bug changes.
[frameworks-plasma] [Bug 445428] Widgets that have been manually added but subsequently removed shall appear after restart.
https://bugs.kde.org/show_bug.cgi?id=445428 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added CC||1i5t5.dun...@cox.net --- Comment #2 from Duncan <1i5t5.dun...@cox.net> --- User running most of kde/plasma live-git here, and I /think/ this may now be fixed, by the following commit to plasma-framework (select-copied from git log), not sure what release version it should appear in, but frameworks version is reported as 5.89.0 ATM, here (with that commit), so should be in frameworks 5.89 if it didn't make 5.88 (which is what you reported). So if it's not fixed in 5.89, a similar fix needs applied elsewhere. In the mean time a couple workarounds. 1) Here, I've found running the following command from krunner saves plasmashell config as it quits and restarts. killall plasmashell; sleep 1; plasmashell 2) Judging by the comment in the git log below, another workaround may be to add a panel and immediately remove it, thereby triggering plasma to save its config. * commit 1f0df3dd2 | Author: Jan Blackquill | AuthorDate: Tue Oct 5 12:56:42 2021 -0400 | Commit: Jan Blackquill | CommitDate: Tue Oct 5 13:04:48 2021 -0400 | | Corona: save after ending edit mode | | Plasma can be somewhat amnesiac if you make changes to it that don't | involve adding/removing panels and it subsequently unexpectedly ends, | such as when it or the compositor crashes. | | Calling requireConfigSync after edit mode ends guarantees that any changes | made by the user in edit mode will be applied. | | src/plasma/corona.cpp | 4 | 1 file changed, 4 insertions(+) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 445412] Zoom effect causes screen to stop updating
https://bugs.kde.org/show_bug.cgi?id=445412 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added CC||1i5t5.dun...@cox.net --- Comment #3 from Duncan <1i5t5.dun...@cox.net> --- Seeing this myself (also on live-git, here from the gentoo/kde overlay live-git packages) and was just searching bugzi to see if the bug had been already filed before filing it myself. =:^) Highly frustrating as I use zoom often enough it's instinctual, and find myself forgetting I can't ATM because its broken! (I'm wayland-only but for xwayland, having uninstalled xorg, tho I'm comfortable at the CLI and have weston installed as a backup wayland compositor if plasma/kwin_wayland live-git gets too broken.) Additional information on dual monitor behavior: On zoom, one monitor seems to continue working normally, while the other freezes and is subject to VT-switching-locked refresh-rate, as you put it. =:^) My keyboard has three keys I have dedicated to zoom, in/out/actual. After zooming in, I can zoom out, and *often* the frozen monitor comes back to life and starts refreshing normally. However, the actual-size key is broken and won't return me to normal/actual, even on the still-refreshing monitor -- I have to use the zoom-out key. I haven't fully qualified when I can get the second monitor back working and when not, but it seems that if I move the pointer to the frozen-while-zoomed monitor, it stays frozen. Sometimes the cursor disappears and I can't get it back even moving back over the otherwise working monitor, other times it stays visible on the otherwise frozen monitor and the cursor changes if I move it over something where it would normally change, even with the rest of that monitor (including a conky sysmon I'd normally see update every second) stays frozen. Since xorg isn't installed I can't test behavior there, tho you already did. But I'm considering trying one of the other zoom effects (I'm on full-display zoom ATM) to see if it's broken too -- guessing it is. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 445412] Zoom effect causes screen to stop updating
https://bugs.kde.org/show_bug.cgi?id=445412 --- Comment #4 from Duncan <1i5t5.dun...@cox.net> --- (In reply to Duncan from comment #3) > I'm considering trying one of the other zoom effects (I'm on > full-display zoom ATM) to see if it's broken too -- guessing it is. Can't get looking glass effect to work at all (not sure whether it was before the recent changes or not). Magnifier works but is bugged with an apparently unrelated bug that could have been there all along on wayland (three rectangles instead of one, center is the expected size but outline-only, unmagnified inside the outline, with two half-size rectangles splitting the actual magnified area to the left and right of the center rectangle). Guess I'll see about filing one on that after this bug gets resolved, if it's still there. But with looking-glass apparently broken entirely (not triggering at all), looks like I can set that to disable zoom so I don't keep forgetting its broken and end up disabling my desktop until I kwin_wayland --replace. =:^) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 445412] Zoom effect causes screen to stop updating
https://bugs.kde.org/show_bug.cgi?id=445412 --- Comment #5 from Duncan <1i5t5.dun...@cox.net> --- Attempting bisect, regressed kwin back to (commit) bad575211, committed Nov 10, which kills eglstream, and zoom is still broken. f91ae3e97 is the immediately previous commit and won't build with an error about missing eglstream.h (or similar) in kwayland-server, so regressing kwin to before bad575211 seems to require regressing kwayland-server back to when it supported eglstream as well. Not sure whether I'll try regressing both together any further, but that should eliminate /some/ possibilities. (FWIW I'm on amdgpu so eglstream itself, being nvidia, shouldn't directly affect me at all. Glad to be rid of its complications in kwin, but the removal is complicating this bisect.) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 445412] Zoom effect causes screen to stop updating
https://bugs.kde.org/show_bug.cgi?id=445412 --- Comment #6 from Duncan <1i5t5.dun...@cox.net> --- Bisected both and got a working hit: * kwayland-server back to 6cc372683, immediately b4 eglstreams removal * kwin back to efa08b1f3, before scenes move. That works! So assuming the breakage is in kwin not kwayland-server, we're looking at the range efa08b1f3 (Nov 8) to bad575211 (Nov 10). Looks like ~36 commits. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 445412] Zoom effect causes screen to stop updating
https://bugs.kde.org/show_bug.cgi?id=445412 --- Comment #7 from Duncan <1i5t5.dun...@cox.net> --- Bisect results, kwin on top of kwayland-server 6cc372683 to get eglstreams back: e2a086384 works, a07aae828 broken and thus the culprit! * commit a07aae828 | Author: Xaver Hugl | AuthorDate: Fri Oct 8 10:52:01 2021 +0200 | Commit: Xaver Hugl | CommitDate: Tue Nov 9 22:15:31 2021 +0100 | | platforms/drm: delay presentation for modesets | | Currently KWin is combining modesets with presentation, which causes problems | when multiple monitors are used and crtcs need to be switched around, because | taking away a CRTC from another output causes the driver to disable the | other output. In order to avoid such problems, delay presentation until | all pipelines are ready to present and then do a modeset with a single atomic | commit. To process the resulting page flip events properly this commit also | ports KWin to page_flip_handler2 and changes how the pageFlipped and | notifyFrameFailed signals are processed. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 445412] Zoom effect causes screen to stop updating
https://bugs.kde.org/show_bug.cgi?id=445412 --- Comment #8 from Duncan <1i5t5.dun...@cox.net> --- Unfortunately a07aae828 won't direct-revert on top of current, so I can't easily double-check the bisect result on current. Not being a dev, with the size of the patch and patch reporting multiple failing chunks, I'm afraid attempting to do it manually is out of my league. But at least we have a culprit commit to work with, now, which is dramatic progress. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 445846] "Bi-directional text rendering" should be renamed to something like "Support for complex scripts"
https://bugs.kde.org/show_bug.cgi?id=445846 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added CC||1i5t5.dun...@cox.net --- Comment #2 from Duncan <1i5t5.dun...@cox.net> --- "Support for complex scripts" doesn't work in konsole AKA terminal context because there, many (most?) would think "scripts" refers to shell-scripts -- I was browsing new bugs and was *very* confused seeing the bug title. Would "complex fonts" be the correct term? But that would get tangled up with font choice. Maybe "complex character rendering"? -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 445805] Konsole freezes when printing certain characters
https://bugs.kde.org/show_bug.cgi?id=445805 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Status|REPORTED|CONFIRMED Ever confirmed|0 |1 CC||1i5t5.dun...@cox.net Keywords||regression --- Comment #1 from Duncan <1i5t5.dun...@cox.net> --- Seeing this here too. Konsole's basically unusable so I reverted to 83113f561 (immediately prior to the culprit 8d9cdd1b0). Haven't yet tried reverting the culprit on HEAD. Sets the CPU fan to high also, tho I think it's only 1 core maxing (didn't think to look but heard the fan, but with the rest of the system remaining responsive I think it's just the one core/thread going whacko). -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 445805] Konsole freezes when printing certain characters, bisected to 8d9cdd1b0
https://bugs.kde.org/show_bug.cgi?id=445805 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Summary|Konsole freezes when|Konsole freezes when |printing certain characters |printing certain ||characters, bisected to ||8d9cdd1b0 -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 445805] Konsole freezes when printing certain characters, bisected to 8d9cdd1b0
https://bugs.kde.org/show_bug.cgi?id=445805 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added CC||tcanabr...@kde.org -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 445805] Konsole freezes when printing certain characters, bisected to 8d9cdd1b0
https://bugs.kde.org/show_bug.cgi?id=445805 --- Comment #2 from Duncan <1i5t5.dun...@cox.net> --- Won't revert on HEAD. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 445616] Update broke keys and colors in Midnight Commander.
https://bugs.kde.org/show_bug.cgi?id=445616 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added CC||1i5t5.dun...@cox.net --- Comment #3 from Duncan <1i5t5.dun...@cox.net> --- FWIW I believe the color thing was now-fixed bug #435309. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 445846] "Bi-directional text rendering" should be renamed to something like "Support for complex scripts"
https://bugs.kde.org/show_bug.cgi?id=445846 --- Comment #4 from Duncan <1i5t5.dun...@cox.net> --- (In reply to Ahmad Samir from comment #3) > To disambiguate, "Support for complex scripts (RTL, Chinese, Urdu ...etc)" ? Works for me! =:^) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 445412] Zoom effect causes screen to stop updating
https://bugs.kde.org/show_bug.cgi?id=445412 --- Comment #10 from Duncan <1i5t5.dun...@cox.net> --- (In reply to Zamundaaa from comment #9) > From my wayland-session.log when reproducing this it seems like buffer swap > is failing with EGL_BAD_SURFACE, but why it does that I can't explain yet. > The only cause for the error I can see in Mesa is when > gbm_surface_lock_front_buffer doesn't get called after eglSwapBuffers - but > it is getting called every time. The gbm surface has a free buffer every > time we call eglSwapBuffers, too, and KWin isn't even doing a modeset when > the effect gets activated, or creating new test buffers or anything else > that I think could be caused by the commit directly. Consider the non-duplicated multi-monitor/ctrc case. Some time ago now kwin_wayland split the formerly monolithic global surface into separate surfaces per ctrc/monitor, and that has been working. But when that first happened it broke zoom with somewhat similar but not as bad behavior (it was possible to trigger updating again with that bug) until a later commit fixed it. That was bug #429377, fixed back in February by https://invent.kde.org/plasma/kwin/commit/523ad8e25c34eb0e683f6e29ad15c3b9a7cdad31 I suspect the same faulty assumption is behind both bugs. Keep in mind that once zoomed, part of the desktop will appear on a different monitor than at 100% and presumably need to be drawn to a different ctrc. If the code assumption is it's on the same one that would explain the bad surface errors, correct? Nate's original report doesn't mention multi-monitor, tho, so I'm assuming this bug's occurring on single-monitor as well, and I'm not at all sure this explains the single-monitor case, unless the zoom triggers bad-surface for now-off-screen area as well, not just on-other-screen area. Meanwhile, admin's intuition (as I'm not a dev) says the problem is in the page-flip processing changes mentioned in the commit message as fixups to the modeset/delay-presentation changes that seems to have been the main thrust of the commit. That'd be why it's happening in the absence of the modesets that the culprit commit was "about". -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 429377] Wayland: zoom effect reverting to proportional mouse-tracking
https://bugs.kde.org/show_bug.cgi?id=429377 --- Comment #9 from Duncan <1i5t5.dun...@cox.net> --- (In reply to Duncan from comment #3) > Created attachment 133516 [details] > hackpatch: prevent fallback to MouseTrackingProportional Commit 1f318a224: effects/zoom: Rework how cursor texture is managed ... removes the ZoomEffect::recreateTexture my hackpatch touched so that patch no longer applies locally. I've not yet built and tested the new code but it looks like it might fix this bug (as well as the more recent and severe bug #445412 which the commit was created against). I guess I'll soon find out. =:^) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 429377] Wayland: zoom effect reverting to proportional mouse-tracking
https://bugs.kde.org/show_bug.cgi?id=429377 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #10 from Duncan <1i5t5.dun...@cox.net> --- (In reply to Duncan from comment #9) > Commit 1f318a224: effects/zoom: Rework how cursor texture is managed Yes, that fixes it. For those not on live-git, kwin_wayland --version reports 5.23.80. Presumably that means the fix will be in release 5.24. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 445412] Zoom effect causes screen to stop updating
https://bugs.kde.org/show_bug.cgi?id=445412 --- Comment #14 from Duncan <1i5t5.dun...@cox.net> --- (In reply to Vlad Zahorodnii from comment #12) > Git commit 1f318a2245f9f887a2bf8aa320dc905a012842df by Vlad Zahorodnii. > Committed on 29/11/2021 at 12:48. > Pushed by vladz into branch 'master'. > > effects/zoom: Rework how cursor texture is managed Confirming that fixes it (as well as older and less severe bug #429377, which as bug filer I just set RESOLVED/FIXED) here. I'll let Nate or Vlad do the honors here. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 445412] Zoom effect causes screen to stop updating
https://bugs.kde.org/show_bug.cgi?id=445412 --- Comment #15 from Duncan <1i5t5.dun...@cox.net> --- BTW, whatever optimizations you've done to kwin_wayland since the a07 commit above, have had a *BIG* positive effect. While my decade-old AMD bulldozer-1 fx6100 (2011) with half-decade-old (2016) Radeon rx460 graphics could (with some stress) do 4k60 in vlc, in firefox on youtube not so much -- I could get 4k50 with some stuttering, but @4k60, the image would freeze on many videos and often not come back until I hit pause momentarily to let it resync. With the recent optimizations I'm now doing 4k60 with some stuttering, same firefox, about the same stuttering as 4k50 before, so on my system the optimizations have been good for ~20%! FWIW this is the video I've been using for testing, a 5 minute 4k60 Costa Rica nature video: https://youtu.be/LXb3EKWsInQ Again, while I still get some stutter, for the first time I could play it clear through without having to pause the video to resync -- it will still freeze occasionally now but much less and now it always comes back without me having to touch pause, where before it'd stay frozen until I paused to resync, and it'd do that repeatedly, making it effectively unplayable at the full 4k resolution unless I slowed it down. So it's a BIG difference! =:^) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 453609] New: kwin commit 4cb3ab09e: build error: kwinanimationeffect.cpp:14:10 fatal error: QAction: No such file or directory:
https://bugs.kde.org/show_bug.cgi?id=453609 Bug ID: 453609 Summary: kwin commit 4cb3ab09e: build error: kwinanimationeffect.cpp:14:10 fatal error: QAction: No such file or directory: Product: kwin Version: git master Platform: Other OS: Other Status: REPORTED Severity: normal Priority: NOR Component: effects-various Assignee: kwin-bugs-n...@kde.org Reporter: 1i5t5.dun...@cox.net Target Milestone: --- kwin commit 4cb3ab09e (thru e1cec89dd HEAD) won't build. The previous commit (46bbe4ff0) builds fine. The error is: src/libkwineffects/kwinanimationeffect.cpp:14:10: fatal error: QAction: No such file or directory 14 | #include I'm on git master for kde-frameworks/-plasma/(most)-gear, using the live-git ebuilds from the gentoo/kde overlay and /usr/include/qt5/QtWidgets/QAction (and qaction.h) exist. Missed dep in CMakeLists.txt? (Not investigated yet.) (I should also mention, actually here the canonical location is /include/... as I'm running reverse-usrmerge, with a /usr symlink: /usr -> . But it's normally all found just fine, and other qt libs are found in this case, but not that one.) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 453609] kwin commit 4cb3ab09e: build error: kwinanimationeffect.cpp:14:10 fatal error: QAction: No such file or directory:
https://bugs.kde.org/show_bug.cgi?id=453609 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added CC||notm...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 453609] kwin commit 4cb3ab09e: build error: kwinanimationeffect.cpp:14:10 fatal error: QAction: No such file or directory:
https://bugs.kde.org/show_bug.cgi?id=453609 --- Comment #1 from Duncan <1i5t5.dun...@cox.net> --- (In reply to Duncan from comment #0) > Missed dep in CMakeLists.txt? (Not investigated yet.) Indeed. But while I already have it and might as well post it, I'm not dev-side-git familiar enough for a PR to be an option and patchfiles submitted here seem to be studiously ignored (to be fair the warning says as much, but that doesn't help people who don't know how to do a PR but already have the patch from troubleshooting the problem and might as well post it), so we'll see if posting it as text is as studiously ignored as patchfiles seem to be. --- a/src/libkwineffects/CMakeLists.txt 2022-05-09 21:26:13.964236519 -0700 +++ b/src/libkwineffects/CMakeLists.txt 2022-05-09 22:21:46.805839417 -0700 @@ -55,6 +55,7 @@ target_link_libraries(kwineffects KF5::WindowSystem XCB::XCB PRIVATE +Qt::Widgets Qt::Quick KF5::I18n kwinglutils -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 454243] Window glitching and blinking after closing
https://bugs.kde.org/show_bug.cgi?id=454243 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added CC||1i5t5.dun...@cox.net --- Comment #2 from Duncan <1i5t5.dun...@cox.net> --- I was seeing similar from a couple weeks ago, tho here the blinking continued until I triggered a repaint (usually by focusing a different window, triggering the dim-inactive effect and thus a repaint of the previously focused window as well as the newly focused one). * Fall-apart effect was on and turning it off eliminated the problem. (I left it off for now.) * git-master frameworks/plasma (and most gear) using the gentoo/kde overlay live ebuilds (so it's not just arch) * amdgpu (so it's not nvidia-specific) I hadn't upgraded again until yesterday and have other problems (systemsettings, krunner, plasmashell segfaults triggered on first geometry-changed, possibly due to a missing rebuild of something after upgrading to qt-5.15.4 but that's what I'm looking at new bugs for) ATM so can't get into the config to try turning it back on to see if the problem's still there. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 454243] Window glitching and blinking after closing
https://bugs.kde.org/show_bug.cgi?id=454243 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Ever confirmed|0 |1 Status|REPORTED|CONFIRMED --- Comment #3 from Duncan <1i5t5.dun...@cox.net> --- Status: Confirmed. Problem is still there. I found the fix for the segfaulting issue that was preventing me testing for resolution of this bug, turned the fall-apart effect back on, and the problem returned against the fresh git-master build I did today. So fall-apart is back off again for the moment as a workaround. Wish all workarounds were that simple, but it'd be nice to have it back working one of these days. =:^) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 450582] Some change between 5.24.0 and 5.24.1 broke windows shade/shutter feature
https://bugs.kde.org/show_bug.cgi?id=450582 --- Comment #11 from Duncan <1i5t5.dun...@cox.net> --- (In reply to Duncan from comment #6) > on wayland shade seems to be a disabled option in the window menu ATM?? Can anyone confirm whether shade is /supposed/ to work on wayland? Presumably it wouldn't work on client-side-decorations, but kwin_wayland remains server-side-decorated (IIRC that was a kwin_wayland and thus wayland-protocol for kde/kwin must-have feature/option from the get-go), and I'd hope shading will at least eventually work. One can posit that since the shade option remains disabled on wayland (at least here), the code for it may not have been written yet, but can anyone confirm that, and assuming so, is the feature planned and just not done yet, or no dev has even considered it yet, or the feature simply can't (within reasonable coding and support limits) be made to work on wayland even with kwin's server-side-decorations given current upstream wayland protocols state. And if it's the latter, what's the chance of protocol evolution to allow it? Anyone know? And as this bug's presumably x11-context, does that mean I need a new feature-request bug for kwin_wayland window shading? (FWIW I no longer even have a stand-alone X (xorg) installed, only xwayland running on top of wayland. Tho I do have weston as a backup wayland compositor, which given that I'm running live-git-master frameworks/plasma, I have actually had to resort to on occasion.) -- You are receiving this mail because: You are watching all bug changes.
[kmymoney] [Bug 452894] New: When entering new ledger entries, previous payee is kept without category
https://bugs.kde.org/show_bug.cgi?id=452894 Bug ID: 452894 Summary: When entering new ledger entries, previous payee is kept without category Product: kmymoney Version: 5.1.2 Platform: Other OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: ux-ui Assignee: kmymoney-de...@kde.org Reporter: kde.b...@cricalix.net Target Milestone: --- SUMMARY The ledger entry payee field has a behaviour that I find frustrating - it remembers the previous payee, but doesn't remember the previous category OR use the default category if one is assigned for that payee. A workaround is to delete the last letter of the pre-filled payee, then down-arrow to select the full match on the existing payee. Depending on the autofill settings in Settings > Ledger > Data Entry, you then either get the autofill popup from previous transaction (Same transaction if amount differs..) or what looks like the default category (With previously most often used..). This is frustrating, and slows down my data entry. It looks as though the pre-fill is not triggering whatever trigger is used when selecting a payee from the dropdown typeahead. STEPS TO REPRODUCE 1. Open kMyMoney to a ledger view 2. Enter a back-dated transaction for an existing payee, to save it 3. Tab over to Dolphin to open new PDF 4. Move Okular window a bit 5. Tab back to kMyMoney 6. Ctrl+Ins to start new ledger entry I'm not sure 3/4/5 matter much, but it's what I'm doing, so I'm including it. OBSERVED RESULT Previous payee from step 2 appears in the ledger entry area, defaulting as an Increase. The category is not set, regardless of the tickbox value and dropdown value for "default category". Pressing tab to move to the category field does not fill the category if default category is ticked and set. EXPECTED RESULT One of two options. 1) The payee is not kept. 2) The payee is kept, but if the default category is set, the category field is populated. SOFTWARE/OS VERSIONS Operating System: Kubuntu 21.10 KDE Plasma Version: 5.24.4 KDE Frameworks Version: 5.92.0 Qt Version: 5.15.2 Kernel Version: 5.13.0-40-generic (64-bit) Graphics Platform: X11 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kmymoney] [Bug 452918] New: Payee > Account Numbers > IBAN does not accept pasted content with a space at the start
https://bugs.kde.org/show_bug.cgi?id=452918 Bug ID: 452918 Summary: Payee > Account Numbers > IBAN does not accept pasted content with a space at the start Product: kmymoney Version: 5.1.2 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: ux-ui Assignee: kmymoney-de...@kde.org Reporter: kde.b...@cricalix.net Target Milestone: --- SUMMARY The IBAN and BIC fields in the per-payee Account Numbers does not accept pasted content from the clipboard on X11 if the content has whitespace at the beginning STEPS TO REPRODUCE 1. Open Kate 2. Type an IBAN, placing an extra space at the start 3. Highlight the IBAN 4. Ctrl-C to copy the IBAN 5. Open kMyMoney 6. Choose a payee 7. Choose Account Numbers 8. Select IBAN & BIC 9. Double-click the IBAN & BIC that shows up to show the entry fields 10. Place cursor in IBAN field 11. Try to paste with Ctrl-V or Ctrl-Shift-Ins OBSERVED RESULT Paste does not happen EXPECTED RESULT One of 1. Acceptance of the pasted content, with the leading whitespace stripped. 2. An error dialog explaining why the content was not accepted. Given the UI will reformat an IBAN of the format IE48ICON11223344556677 into IE48 ICON 1122 3344 5566 77, I would advocate for the first option; apply strip() to the input, then validate that it's in the appropriate form for an IBAN. If it's still not appropriate, *tell* the person that it's not valid - don't silently fail. SOFTWARE/OS VERSIONS Operating System: Kubuntu 21.10 KDE Plasma Version: 5.24.4 KDE Frameworks Version: 5.92.0 Qt Version: 5.15.2 Kernel Version: 5.13.0-40-generic (64-bit) Graphics Platform: X11 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kmymoney] [Bug 452918] Payee > Account Numbers > IBAN does not accept pasted content with a space at the start
https://bugs.kde.org/show_bug.cgi?id=452918 --- Comment #1 from Duncan --- Where I ran into this was double-clicking an IBAN in wise.com's interface to select it, copying it with Ctrl-C, and then attempting to paste it. Something about the copied HTML places a space at each end of the text, and this whitespace is not obvious unless you paste into a program like Kate and notice the extra space on the highlight. -- You are receiving this mail because: You are watching all bug changes.
[kmymoney] [Bug 452918] Payee > Account Numbers > IBAN does not accept pasted content with a space at the start
https://bugs.kde.org/show_bug.cgi?id=452918 --- Comment #2 from Duncan --- Clarity for step 3 of the reproduction - highlight including the space at the start. -- You are receiving this mail because: You are watching all bug changes.
[kmymoney] [Bug 452918] Payee > Account Numbers > IBAN does not accept pasted content with a space at the start
https://bugs.kde.org/show_bug.cgi?id=452918 --- Comment #5 from Duncan --- Thank you Thomas. I had looked in that validator code, but my C++ knowledge is about zero, so couldn't offer a patch (and didn't know fixup() existed either). -- You are receiving this mail because: You are watching all bug changes.
[kmymoney] [Bug 452935] New: I18N_ARGUMENT_MISSING in CSV import Columns screen
https://bugs.kde.org/show_bug.cgi?id=452935 Bug ID: 452935 Summary: I18N_ARGUMENT_MISSING in CSV import Columns screen Product: kmymoney Version: 5.1.2 Platform: Other OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: ux-ui Assignee: kmymoney-de...@kde.org Reporter: kde.b...@cricalix.net Target Milestone: --- Created attachment 148336 --> https://bugs.kde.org/attachment.cgi?id=148336&action=edit Annotated screenshot SUMMARY The Columns setup for CSV import displays "Memo columns: (I18N_ARGUMENT_MISSING)" where is the selected columns STEPS TO REPRODUCE 1. Start the CSV import process 2. Get to the stage of selecting columns 3. Look at the text after the italicised "Memo columns" OBSERVED RESULT With no memo column selected, "None(I18N_ARGUMENT_MISSING)" With a memo column selected, replace None with the column, rest of text is the same. EXPECTED RESULT Don't know. Can't tell if this is a failure to pass a flag to a method, or some other issue with a translation. SOFTWARE/OS VERSIONS Operating System: Kubuntu 21.10 KDE Plasma Version: 5.24.4 KDE Frameworks Version: 5.92.0 Qt Version: 5.15.2 Kernel Version: 5.13.0-40-generic (64-bit) Graphics Platform: X11 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kinfocenter] [Bug 452937] New: CPU view in Info Center cuts off CPU flags
https://bugs.kde.org/show_bug.cgi?id=452937 Bug ID: 452937 Summary: CPU view in Info Center cuts off CPU flags Product: kinfocenter Version: 5.24.4 Platform: Kubuntu Packages OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: kde.b...@cricalix.net CC: hubn...@gmail.com Target Milestone: --- Created attachment 148338 --> https://bugs.kde.org/attachment.cgi?id=148338&action=edit Annotated screenshot SUMMARY The rendering of the Flags section of CPU Info does not show the last few elements of the flags; they're wrapped onto a line that's hidden below the bottom of the window. If the window is then resized enough to cause a text reflow, it becomes possible to scroll all the way down and see the last flags. STEPS TO REPRODUCE 1. About this system 2. Show More Information 3. Devices 4. CPU 5. Scroll the CPU output down OBSERVED RESULT The last few elements from the CPU flags are not rendered properly in the text box. EXPECTED RESULT All CPU flags are shown. SOFTWARE/OS VERSIONS Operating System: Kubuntu 21.10 KDE Plasma Version: 5.24.4 KDE Frameworks Version: 5.92.0 Qt Version: 5.15.2 Kernel Version: 5.13.0-40-generic (64-bit) Graphics Platform: X11 Processors: 24 × AMD Ryzen 9 5900X 12-Core Processor ADDITIONAL INFORMATION The text box is not showing "rdpid overflow_recov succor smca fsrm", but the screenshot shows that the text is there; you can see the top of the d, i, and d in rdpid, and the fl in overflow, and the f in frsm. -- You are receiving this mail because: You are watching all bug changes.
[kmymoney] [Bug 452935] I18N_ARGUMENT_MISSING in CSV import Columns screen
https://bugs.kde.org/show_bug.cgi?id=452935 --- Comment #3 from Duncan --- (In reply to Thomas Baumgart from comment #1) > I am unable to duplicate this here. I tried with en_US.UTF-8 and > de_DE.UTF-8. Which language setting do you use? $ env | grep LAN LANGUAGE=en_IE:en LANG=en_IE.UTF-8 -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 454933] Saving to network fails
https://bugs.kde.org/show_bug.cgi?id=454933 --- Comment #7 from duncan --- It opens the file (when I remove the spaces) but as soon as I try and do anything it freezing, says 'not responding', fails to close for a long time before eventually closing. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 454933] Saving to network fails
https://bugs.kde.org/show_bug.cgi?id=454933 --- Comment #9 from duncan --- Hi Nate. Please suggest a different KDE app you'd like me to use for testing, also where to install it from snap/repo/flatpack ... -- You are receiving this mail because: You are watching all bug changes.
[kdialog] [Bug 427414] --slider dialog needs documentation and usage instructions
https://bugs.kde.org/show_bug.cgi?id=427414 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added CC||1i5t5.dun...@cox.net --- Comment #1 from Duncan <1i5t5.dun...@cox.net> --- Just trying to find some --slider documentation myself. With a bit of experimentation I had guessed it was text/min/max/increment, but at least here... kdialog --slider "test" 0 10 2 ... increments by 1, not 2, and an increment of .1 or 0.1 increments by 1 as well, so it seems "increment" isn't doing what I expected and after not seeing information about that in the --help output or on the page linked in the README, here I am looking at bugs, still trying to confirm that "increment" is indeed the third argument (beyond text), and whether I'm formatting it correctly if so. -- You are receiving this mail because: You are watching all bug changes.
[kdialog] [Bug 427414] --slider dialog needs documentation and usage instructions
https://bugs.kde.org/show_bug.cgi?id=427414 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Ever confirmed|0 |1 Status|REPORTED|CONFIRMED -- You are receiving this mail because: You are watching all bug changes.
[kdialog] [Bug 455994] New: kdialog README needs updated (is kdialog currently maintained?)
https://bugs.kde.org/show_bug.cgi?id=455994 Bug ID: 455994 Summary: kdialog README needs updated (is kdialog currently maintained?) Product: kdialog Version: unspecified Platform: Other OS: Other Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: br...@frogmouth.net Reporter: 1i5t5.dun...@cox.net Target Milestone: --- Is kdialog maintained any longer? Bugs are assigned to bradh@ (not kde, frogmouth, but avoiding full address for spam control for not logged in) but his last commit to the repo seems to have been in 2006 (!!), and the last bug he commented on on bugzi (find his comments on any bug, sort by bug ID) was one he filed in 2011, during the port to kde4 (!). The README seems to be rather dated too, with multiple issues: 1) Tutorial link is still http and is dated: http://techbase.kde.org/Development/Tutorials/Shell_Scripting_with_KDE_Dialogs ... which says it has moved (but doesn't redirect) to (https this time): https://develop.kde.org/deploy/kdialog/ 2) README says for functionality changes/adds, contact bradh@, but ... 3) It also says current maintainer David Faure (faure@), who is at least reasonably currently active, but git log says last faure commit to kdialog was mid 2020, the only recently closed kdialog bugs seem to have been closed by others (often the original filer), no real activity there, and that's not where the bugzilla assignments are going. Further, at least the --slider option isn't documented in the tutorial, and mandatory arguments (presumably min/max/increment, are not documented in the --help output. Further, there seems to be no kdialog handbook entry to look at and no manpage (which would be nice for a scriptable like kdialog). That's bug #427414, but it illustrates the lack of maintenance. And the kdialog_progress_helper binary seems entirely undocumented. No --help output, no mention in the README or tutorial (which demonstrates --progressbar without the helper), no manpage or handbook... Bug #450015 but another illustration of missing maintenance. kdialog does seem to be kept building and working, and seems to be a native wayland app at least, but beyond that, any actual maintenance, or is it effectively abandonware that's only kept minimally working by others? (I do see montel@ added Qt6 CI support with 8236e4711 back on May 24, so at least there's hints of continued life support into qt6, but that's still minimal life support even if continued, not proper maintenance.) Version: kdialog along with plasma and frameworks on git master (using gentoo/kde's overlay live ebuilds), but git master is not listed as a version option. (Tho I've not updated in a bit over a week, but given the time points and lack of maintainer bug activity above, status is unlikely to have changed in that time.) -- You are receiving this mail because: You are watching all bug changes.
[kdialog] [Bug 455994] kdialog README needs updated (is kdialog currently maintained?)
https://bugs.kde.org/show_bug.cgi?id=455994 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added CC||fa...@kde.org --- Comment #1 from Duncan <1i5t5.dun...@cox.net> --- CCing dfaure@ based on README. -- You are receiving this mail because: You are watching all bug changes.
[kdialog] [Bug 450015] KDialog progress bar doesn't go to 100%
https://bugs.kde.org/show_bug.cgi?id=450015 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added CC||1i5t5.dun...@cox.net --- Comment #2 from Duncan <1i5t5.dun...@cox.net> --- Not sure kdialog's actually actively maintained any longer (tho it is kept building and working, including running as a native wayland binary and current qt6 porting work). For more on that see bug #455994 which I just filed: https://bugs.kde.org/show_bug.cgi?id=455994 Meanwhile, I've not had occasion to use --progressbar and wasn't aware of this bug until the pre-bug-file search for the above, but as it hasn't been mentioned yet, kdialog should now ship with a kdialog_progress_helper binary (depending on your distro packaging, of course), which I /assume/ does what its name indicates, and that it's "the modern way" to deal with kdialog progressbars. Unfortunately it's entirely undocumented AFAICT, nothing on the tutorial (which uses the bare kdialog --progressbar), nothing in the README, no manpages or kde handbook entries for kdialog at all, and it doesn't even have the --help output that kdialog itself has. And it's an elf binary so can't just open it in a text editor like a script to see what it does. So it seems it's "read the source" (if you can) or try your luck with experiments. =:^( -- You are receiving this mail because: You are watching all bug changes.
[kdialog] [Bug 427414] --slider dialog needs documentation and usage instructions
https://bugs.kde.org/show_bug.cgi?id=427414 --- Comment #2 from Duncan <1i5t5.dun...@cox.net> --- Not sure kdialog's currently maintained beyond "minimal life support" level (keeping it building and running, it is a native wayland app running on wayland, and I see hints of qt6 support in git so should hopefully outlast qt5). See bug #455994 which I just filed for more on that: https://bugs.kde.org/show_bug.cgi?id=455994 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 456655] New: plasma-workspace bf4dd6353 broke building without kpipewire, fed29855f didn't fix
https://bugs.kde.org/show_bug.cgi?id=456655 Bug ID: 456655 Summary: plasma-workspace bf4dd6353 broke building without kpipewire, fed29855f didn't fix Product: plasmashell Version: master Platform: Compiled Sources OS: All Status: REPORTED Severity: normal Priority: NOR Component: Task Manager and Icons-Only Task Manager Assignee: plasma-b...@kde.org Reporter: 1i5t5.dun...@cox.net Target Milestone: 1.0 This is for plasma-workspace from git master using the gentoo/kde overlay ebuilds. Unfortunately there's no "plasma-workspace" product so I had to choose the closest fit I could find. (FWIW frameworks and the rest of plasma are git-master as well, tho I don't believe it matters for this bug.) The first following plasma-workspace commit broke building without kpipewire (the previous commit 2a7a7fd14 builds fine), and the second one didn't fix it: * commit bf4dd6353 Author: Aleix Pol AuthorDate: Wed Jun 29 16:27:01 2022 +0200 Commit: Aleix Pol CommitDate: Tue Jul 5 12:47:56 2022 +0200 libtaskmanager: Use KPipeWire * commit fed29855f | Author: Aleix Pol | AuthorDate: Fri Jul 8 20:10:10 2022 +0200 | Commit: Aleix Pol Gonzalez | CommitDate: Sun Jul 10 15:48:23 2022 + | | KPipeWire isn't actually required | | Just some features will be missing Doing the build, I get this during the configure step: -- The following features have been disabled: * PipeWire, Required for Wayland screencasting But the following screencasting-related errors (plus many more of the same) never-the-less occur: /x86_64-pc-linux-gnu/gcc-bin/12.1.1/../../../lib/gcc/x86_64-pc-linux-gnu/12.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: libtaskmanager/declarative/CMakeFiles/taskmanagerplugin.dir/taskmanagerplugin.cpp.o: in function `int qmlRegisterUncreatableType(char const*, int, int, char const*, QString const&) [clone .isra.0]': taskmanagerplugin.cpp:(.text+0x2a): undefined reference to `Screencasting::staticMetaObject' /x86_64-pc-linux-gnu/gcc-bin/12.1.1/../../../lib/gcc/x86_64-pc-linux-gnu/12.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: taskmanagerplugin.cpp:(.text+0x167): undefinedreference to `Screencasting::staticMetaObject' /x86_64-pc-linux-gnu/gcc-bin/12.1.1/../../../lib/gcc/x86_64-pc-linux-gnu/12.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: taskmanagerplugin.cpp:(.text+0x195): undefinedreference to `Screencasting::staticMetaObject' Why is it still trying to reference screencasting despite it being specifically disabled? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 456655] plasma-workspace bf4dd6353 broke building without kpipewire, fed29855f didn't fix
https://bugs.kde.org/show_bug.cgi?id=456655 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added CC||aleix...@kde.org --- Comment #1 from Duncan <1i5t5.dun...@cox.net> --- CCing aleixpol@ as the author/committer of both commits. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 456655] plasma-workspace bf4dd6353 broke building without kpipewire, fed29855f didn't fix
https://bugs.kde.org/show_bug.cgi?id=456655 --- Comment #2 from Duncan <1i5t5.dun...@cox.net> --- See also downstream gentoo: https://bugs.gentoo.org/848771#c11 (I tried to put it in the see also field as well, but kdebugs says it's the wrong format and doesn't seem to have/list a gentoo exception like it does for debian. That bug is about a related gentoo plasma-desktop problem, but the linked comment mentions this plasma-workspace issue as a followup and has more complete error output.) -- You are receiving this mail because: You are watching all bug changes.
[ksudoku] [Bug 457951] New: ksudoku commit 6e9d941ce with an existing theme config results in a blank play-space and qpainter engine errors
https://bugs.kde.org/show_bug.cgi?id=457951 Bug ID: 457951 Summary: ksudoku commit 6e9d941ce with an existing theme config results in a blank play-space and qpainter engine errors 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: --- On git-master (for frameworks/plasma/gear all three) using the gentoo/kde project overlay live-git ebuilds. Current ksudoku HEAD 64ec262ee For a couple months ksudoku would run, but attempting to actually play a game resulted in a blank play-space, with the number-selector space blank as well. Running from konsole gave me this pair of errors, twice at the select game screen (which seemed to work), many many times when starting a game and getting the blank play-space: QPainter::begin: Paint device returned engine == 0, type: 2 QPainter::end: Painter not active, aborted I finally had some time to bisect it tonight, with the culprit being (emails masked): commit 6e9d941ce Author: Friedrich W. H. Kossebau AuthorDate: Sun Jun 19 19:40:16 2022 +0200 Commit: Friedrich W. H. Kossebau CommitDate: Sun Jun 19 19:40:16 2022 +0200 Port away from deprecated KGameTheme & KGameThemeSelector Given that clue I rebuilt at HEAD, then tried reconfiguring my theme, and sure enough, ksudoku gave me a proper play-space (and no qpainter errors in konsole) once again. =:^) So then I wondered what in the ksudokurc file it had been choking on. A diff against a backup revealed this in the [Themes] section: Old: theme=themes/default.desktop New: theme=/usr/share/ksudoku/themes/default.desktop So the code in the above commit does absolute paths while the old code apparently saved the path relative to the system theme location, and the new code doesn't know how to interpret that, resulting in a null theme, in turn resulting in the null/0 qpainter engine error above. -- You are receiving this mail because: You are watching all bug changes.
[ksudoku] [Bug 457951] ksudoku commit 6e9d941ce with an existing theme config results in a blank play-space and qpainter engine errors
https://bugs.kde.org/show_bug.cgi?id=457951 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added CC||kosse...@kde.org --- Comment #1 from Duncan <1i5t5.dun...@cox.net> --- CCing kossebau@ as the author/committer of the culprit commit. -- You are receiving this mail because: You are watching all bug changes.
[ksudoku] [Bug 457951] ksudoku commit 6e9d941ce with an existing theme config results in a blank play-space and qpainter engine errors
https://bugs.kde.org/show_bug.cgi?id=457951 --- Comment #4 from Duncan <1i5t5.dun...@cox.net> --- (In reply to Friedrich W. H. Kossebau from comment #3) > Then it generates the theme id by first turning the desktop file path > to a canonical version That rings a bell. My system has a reverse-usrmerge, /usr -> . so everything installed to /usr ends up in /. Up to probably about a year ago that was causing a problem with canonical/non-canonical path comparisons against the *.desktop file path that was supposed to give plasmashell the special privs it needs from kwin to get the wayland running tasks info (not a problem with insecure X), so none of the taskmanager plasmoids could actually see running tasks and all they were showing were the pinned launchers. That problem turned out to be in whatever framework was doing the resolution, fixed when someone traced down an apparently unrelated instance of the same bug, and as soon as I saw the git log I knew what was going on with my bug and that it was probably fixed with that commit, which it was. > Are you capable to add some fprint debug lines to libkdegames yourself to > get insight into the respective values used there? Give me a debug/test patch and I can apply it for local testing, no sweat, but coding it is another story... (Effectively I can and sometimes do hack existing patches when necessary, but I'm not a dev so coding my own, even for trivial debugging like this, if possible at all, typically takes me hours of bumbling.) -- You are receiving this mail because: You are watching all bug changes.
[ksudoku] [Bug 457951] ksudoku commit 6e9d941ce with an existing theme config results in a blank play-space and qpainter engine errors
https://bugs.kde.org/show_bug.cgi?id=457951
--- Comment #8 from Duncan <1i5t5.dun...@cox.net> ---
(In reply to Friedrich W. H. Kossebau from comment #6)
> Please try the attached patch for libkdegames
> Interesting will be all the log output starting with "THEMELOADING"
For clarity this is at libkdegames c5848c0d6 and $HOME=/h/x (with
$XDG_CONFIG_HOME=$HOME/config), but having visited Egypt I /really/ like that
theme and I haven't felt the need to HNS any themes, so (/usr)/share/ksudoku is
the only location with any.
THEMELOADING considering locations ("/h/x/config/share/ksudoku",
"/usr/local/share/ksudoku", "/usr/share/ksudoku")
THEMELOADING considering desktop file
"/usr/share/ksudoku/themes/abstraction.desktop"
THEMELOADING canonical path "/share/ksudoku/themes/abstraction.desktop"
THEMELOADING id "/usr/share/ksudoku/themes/abstraction.desktop"
THEMELOADING considering desktop file
"/usr/share/ksudoku/themes/default.desktop"
THEMELOADING canonical path "/share/ksudoku/themes/default.desktop"
THEMELOADING id "/usr/share/ksudoku/themes/default.desktop"
THEMELOADING considering desktop file
"/usr/share/ksudoku/themes/ksudoku_scrible.desktop"
THEMELOADING canonical path "/share/ksudoku/themes/ksudoku_scrible.desktop"
THEMELOADING id "/usr/share/ksudoku/themes/ksudoku_scrible.desktop"
--
You are receiving this mail because:
You are watching all bug changes.
[ksudoku] [Bug 457951] ksudoku commit 6e9d941ce with an existing theme config results in a blank play-space and qpainter engine errors
https://bugs.kde.org/show_bug.cgi?id=457951 --- Comment #10 from Duncan <1i5t5.dun...@cox.net> --- (In reply to Friedrich W. H. Kossebau from comment #9) > https://invent.kde.org/games/libkdegames/-/merge_requests/20.diff Good and bad news: Good: The relative style ksudokurc theme entry works with that patch. Bad: The full-path style does not. If there hasn't been a release with the now-existing code that creates the full-path entry I imagine the bad news can be ignored (unless we want to give people hand-editing their ksudokurc files the choice of doing full paths, too). If there has been a release, the question is do we want to cover both styles and thus cover the short-period code that additionally only writes the full path for symlinked paths, or are we willing to sacrifice the narrow segment who both ran the new release and have in-path symlinks, most of who likely were upgrades already and thus had to do the blow-away/hand-edit process once already in ordered to get that full path entry in the first place? Alternatively or as well, how difficult would it be to code up a "this entry doesn't make sense, ignore it and use/rewrite the default" solution? I'd personally prefer that, as then the worst-case (triggered by say a fully corrupted entry or one pointed at a missing theme) would be losing the configured theme and resetting to default, instead of showing blank/broken game-play areas thus breaking the games in question. -- You are receiving this mail because: You are watching all bug changes.
[ksudoku] [Bug 457951] ksudoku commit 6e9d941ce with an existing theme config results in a blank play-space and qpainter engine errors
https://bugs.kde.org/show_bug.cgi?id=457951 --- Comment #11 from Duncan <1i5t5.dun...@cox.net> --- (In reply to Duncan from comment #10) > [H]ow difficult would it be to code up a "this entry > doesn't make sense, ignore it and use/rewrite the default" solution? ... maybe with a warning, to STDERR, notification or dialog depending on evaluated priority of the user actually seeing it, saying the existing entry was corrupted (or whatever better wording) so it reverted to default. -- You are receiving this mail because: You are watching all bug changes.
[ksudoku] [Bug 457951] ksudoku commit 6e9d941ce with an existing theme config results in a blank play-space and qpainter engine errors
https://bugs.kde.org/show_bug.cgi?id=457951 --- Comment #12 from Duncan <1i5t5.dun...@cox.net> --- Yikes! The patch breaks kpat's Egyptian theme (at least with my existing kpatrc). In the kpat case, however, it *does* revert to something else (default?) instead of blanking, as I proposed for ksudoku. However, unlike ksudoku, I can't reset it to Egyptian -- it simply doesn't take -- tho I *can* set at least some other themes and they will take. It took all I tried (several, it ships way more than the three ksudoku ships) /except/ Egyptian. Which is weird, as again, I've not HNS-ed additional themes so they're all as-shipped. What makes kpat's Egyptian different so it won't take it? -- You are receiving this mail because: You are watching all bug changes.
[ksudoku] [Bug 457951] ksudoku commit 6e9d941ce with an existing theme config results in a blank play-space and qpainter engine errors
https://bugs.kde.org/show_bug.cgi?id=457951 --- Comment #13 from Duncan <1i5t5.dun...@cox.net> --- (In reply to Duncan from comment #12) > What makes kpat's Egyptian different so it won't take it? User mistake. I didn't read the tabs and was changing card decks instead of game themes, not realizing they were separate. Once I changed game theme to Egyptian as well, it took. I'm not entirely sure whether the card deck was changing to Egyptian all the time and I didn't notice it as I was staring at the (to me[1]) blinding green-blaze background, or whether it only took once I changed the game theme to Egyptian as well, but in any case, I can say the card deck Egyptian did take once I set the game theme Egyptian. But we're still left with the fact that the patch breaks the existing kpatrc theme choice, tho not as badly as ksudoku's breakage, as kpat does at least revert to a usable default instead of blanking. Both honor resetting the theme, but kpat's breakage is less as it reverts to a usable (if personally uncomfortable) default instead of breaking game play. --- [1] I wear rigid gas-perm contacts with a rather high nearsightedness correction of ~ -10 diopters. The combination of the strongly negative correction and rigid lenses means too bright backgrounds star-flare-reflect in the contacts and eventually give me a headache as my eyes and brain try to compensate and see around/through the flare-reflections. It took me years to figure out, but that's why I strongly prefer a "reversed" light-on-dark color-scheme as at least then the flares are smaller than when the entire background is bright. The brown-sand Egyptian background is perfect for that, plus I visited and find the idea of the theme rather pleasing as well! -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 458775] New: File type detection fails on reload after external change
https://bugs.kde.org/show_bug.cgi?id=458775 Bug ID: 458775 Summary: File type detection fails on reload after external change Product: kate Version: 22.04.3 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: application Assignee: kwrite-bugs-n...@kde.org Reporter: kde.b...@cricalix.net Target Milestone: --- SUMMARY Mutating a file outside of Kate causes Kate to offer a reload option. Taking that option will result in Kate "forgetting" that the file is of a particular type (Python in my case), and disables type-specific behaviours like syntax highlighting and LSP usage. STEPS TO REPRODUCE 1. Install pylsp 2. Install black, flake8 plugins for pylsp 3. Edit a python file with Kate - ensure the file type is detected as Python, with syntax highlighting etc 4. Save the file with content that black will fix (extra long lines or whatever) 5. Mutate the file outside of Kate with black 6. Back to Kate, accept the reload of the file OBSERVED RESULT Syntax highlighting and LSP support stop working; Kate appears to treat the file as text/plain, not Python. Detected language in the bottom right is still Python. Clicking the detected language, and then clicking the already-ticked Python causes Kate to re-apply syntax highlighting and LSP support for Python. EXPECTED RESULT Upon reload, Kate considers the file to be Python still, with syntax highlighting and LSP support. SOFTWARE/OS VERSIONS Operating System: Kubuntu 22.04 KDE Plasma Version: 5.24.6 KDE Frameworks Version: 5.95.0 Qt Version: 5.15.3 Kernel Version: 5.15.0-47-generic (64-bit) Graphics Platform: X11 Processors: 24 × AMD Ryzen 9 5900X 12-Core Processor Memory: 31.3 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 3060 Ti/PCIe/SSE2 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 458775] File type detection fails on reload after external change
https://bugs.kde.org/show_bug.cgi?id=458775 --- Comment #1 from Duncan --- Created attachment 151860 --> https://bugs.kde.org/attachment.cgi?id=151860&action=edit Screen capture of issue -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 442866] New: discover commit 3bc879cf9 breaks build: can't find QAction or QApplication
https://bugs.kde.org/show_bug.cgi?id=442866 Bug ID: 442866 Summary: discover commit 3bc879cf9 breaks build: can't find QAction or QApplication Product: Discover Version: git-master Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: discover Assignee: lei...@leinir.dk Reporter: 1i5t5.dun...@cox.net CC: aleix...@kde.org Target Milestone: --- With frameworks/plasma/apps all from live-git (using the gentoo/kde overlay live-git - ebuilds), commit 3bc879cf9 breaks the build, which remains broken at d199868c0 (current HEAD). qt is 5.15.2, with some qt component updates earlier in my update today. (Gentoo uses qt5 snapshots from kde's qt repo.) The immediately previous 889b28038 builds fine. The first failure is: discover/DiscoverDeclarativePlugin.cpp:12:10: fatal error: QAction: No such file or directory 12 | #include | ^ Two additional failures are: discover/main.cpp:19:10: fatal error: QApplication: No such file or directory 19 | #include | ^~ discover/DiscoverObject.cpp:17:10: fatal error: QAction: No such file or directory 17 | #include | ^ -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 442866] discover commit 3bc879cf9 breaks build: can't find QAction or QApplication
https://bugs.kde.org/show_bug.cgi?id=442866 Duncan <1i5t5.dun...@cox.net> changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #3 from Duncan <1i5t5.dun...@cox.net> --- Verified fixed. Thanks. -- You are receiving this mail because: You are watching all bug changes.
