[kmail2] [Bug 486835] New: Composer window geometries are mixed up with kmail main window geometries
https://bugs.kde.org/show_bug.cgi?id=486835 Bug ID: 486835 Summary: Composer window geometries are mixed up with kmail main window geometries Classification: Applications Product: kmail2 Version: 6.0.2 Platform: openSUSE OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: composer Assignee: kdepim-b...@kde.org Reporter: h...@urpla.net Target Milestone: --- First of all, still running on X11 because bko#377162, sorry! With earlier kmail versions, the composer windows managed its own geometries, e.g. creating a new mail used the window size and position of the last composer window. With 24.02.2, this behaviour is lost, and kmail main window geometries are mixed up with composer window geometries: a new composer window inherits the main window size. In my setup, I'm running kmail main window vertically expanded on a huge 30" screen (since ages). But now, new composer windows are drawn with the same size. Before, it maintained the composer window geometries independently of the main window, and appeared a lot smaller in my setup. Another indication of this new behaviour and the mix-up is reproduced like this: Start up kmail. Resize vertical size to take the full screen height (up to the control panel, of course). Open a new mail. Resize the composer window to a different size, say half of the main window. Close the main window. Close the composer window. Restart kmail, et voilà, the main window appears with the size of the last composer window. This is a regression from my point of view. The kmail main and composer windows should manage their geometries independently. The new behaviour looks and feels ugly, as well as usability is awkward. Also, semantically, main and composer windows act quite different semantically, hence their geometries should be managed separately as well. Operating System: openSUSE Tumbleweed 20240429 KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.1.0 Qt Version: 6.7.0 Kernel Version: 6.8.7-7-preempt (64-bit) Graphics Platform: X11 Processors: 24 × AMD Ryzen 9 3900X 12-Core Processor Memory: 62.4 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 3060/PCIe/SSE2 Manufacturer: ASUS kmail 24.02.2 -- You are receiving this mail because: You are watching all bug changes.
[kmag] [Bug 485291] New: Does not work at all
https://bugs.kde.org/show_bug.cgi?id=485291 Bug ID: 485291 Summary: Does not work at all Classification: Applications Product: kmag Version: 24.02.1 Platform: openSUSE OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: sar...@users.sourceforge.net Reporter: e...@waeltis.ch Target Milestone: --- Hello I can start the program. But it does not work at all. openSUSE Tumbleweed 20240407 (x86_64) -- You are receiving this mail because: You are watching all bug changes.
[kamoso] [Bug 469137] MKV is a dinosaur format from the 1990's.
https://bugs.kde.org/show_bug.cgi?id=469137 Firlaev-Hans changed: What|Removed |Added CC|firlaevhans.fiete@protonmai | |l.com | -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 475077] Show non-linear virtual desktop arrangements again
https://bugs.kde.org/show_bug.cgi?id=475077 Firlaev-Hans changed: What|Removed |Added CC||firlaevhans.fiete@protonmai ||l.com --- Comment #20 from Firlaev-Hans --- Another argument in favor of always showing the VD bar in the overview is, for me anyways, that the desktop bar lets you quickly and conveniently add, remove and, at least on P5, rename (though unfortunately not rearrange) desktops on the fly, which the grid doesn't. (I suppose that functionality could be added to the grid, but I think it makes more sense in the bar). (Also, adding or removing VDs on the fly when they are arranged in a grid may be confusing if doing so changes their layout, I don't have a good solution for that off hand) Besides that I find it rather inconsistent to show the bar only under certain circumstances without even letting the user know about it. I like having two rows because it makes navigating the desktops with touchpad gestures easier, but also want the desktop bar in the overview for various reasons including those mentioned above. (In reply to postix from comment #13) > Created attachment 166253 [details] > Mockup: Overview with row indicator > > To further decrease any confusion about a different layout some users may > have due the linearization I'd suggest to add a row indicator to the VD > preview bar. Please see the mockup. I believe this makes it pretty obvious > and clear. :) I like that proposal. I personally don't think it is necessary but if there is any concern about confusing the users about the layout, this should fix that (besides, as I said I think the status quo on Plasma 6 is more confusing) -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 479690] Panel becomes unresponsive to mouse clicks when it moves between screens
https://bugs.kde.org/show_bug.cgi?id=479690 Firlaev-Hans changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED --- Comment #8 from Firlaev-Hans --- Seems to be fixed on 6.0 as well as far as I can tell. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 479690] Panel becomes unresponsive to mouse clicks when it moves between screens
https://bugs.kde.org/show_bug.cgi?id=479690 --- Comment #6 from Firlaev-Hans --- I experienced this with AMD Vega 3 graphics, so it's not Intel specific. It does seem to be fixed now in Neon unstable though, don't know about the Plasma 6.0 branch as I haven't had a chance to test that yet. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 479690] Panel becomes unresponsive to mouse clicks when it moves between screens
https://bugs.kde.org/show_bug.cgi?id=479690 Firlaev-Hans changed: What|Removed |Added Ever confirmed|0 |1 Status|REPORTED|CONFIRMED CC||firlaevhans.fiete@protonmai ||l.com --- Comment #1 from Firlaev-Hans --- Can confirm. When I unplug my external screen, which makes the primary panel move to the internal screen, the panel doesn't visually freeze, but can't be interacted with. As I dock and undock my laptop very frequently throughout the day, I would see this issue quite often. -- You are receiving this mail because: You are watching all bug changes.
[sieveeditor] [Bug 477755] rule:[] as opposed to 'SCRIPTNAME: '
https://bugs.kde.org/show_bug.cgi?id=477755 --- Comment #7 from Hans Dijkema --- Great! Thank you. Hope it will find it's way to debian 12 soon... -- You are receiving this mail because: You are watching all bug changes.
[sieveeditor] [Bug 477755] rule:[] as opposed to 'SCRIPTNAME: '
https://bugs.kde.org/show_bug.cgi?id=477755
--- Comment #4 from Hans Dijkema ---
Actually,
You are doing nothing wrong. It's more of a 'synchronization' thing
between different sieve editors.
I sometimes need tot use the Web Sieve Editor, and this removes all
'SCRIPTNAME' comments of your
sieve editor.
I thought, maybe as kind of a work-around you could support both ways of
script naming conventions.
Or detect the managesieve 'rule' naming convention and reuse it.
Op 30-11-2023 om 10:40 schreef Laurent Montel:
> https://bugs.kde.org/show_bug.cgi?id=477755
>
> --- Comment #3 from Laurent Montel ---
> In your example
> #SCRIPTNAME: Deel 5 van script
> # rule:[invest filter]
> if anyof (header :contains "subject" "Invest in Films"
> , header :contains "subject" "Invest in Lithium Mining in Australia"
> , header :contains "subject" "Invest in"
> )
> {
> setflag [ "\\Seen" ];
> fileinto "Spam";
> }
>
> sieveeditor keeps comments no ?
>
> What do you want that I fix ?
>
--
You are receiving this mail because:
You are watching all bug changes.
[sieveeditor] [Bug 477755] rule:[] as opposed to 'SCRIPTNAME: '
https://bugs.kde.org/show_bug.cgi?id=477755 --- Comment #2 from Hans Dijkema --- See also: https://github.com/roundcube/roundcubemail/issues/9231 -- You are receiving this mail because: You are watching all bug changes.
[sieveeditor] [Bug 477755] New: rule:[] as opposed to 'SCRIPTNAME: '
https://bugs.kde.org/show_bug.cgi?id=477755 Bug ID: 477755 Summary: rule:[] as opposed to 'SCRIPTNAME: ' Classification: Applications Product: sieveeditor Version: 5.22.3 Platform: Other OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: general Assignee: mon...@kde.org Reporter: h...@dijkewijk.nl Target Milestone: --- I'd like to submit a feature request. Sieve Editor and the Sieve editor of Roundcube Webmail (managesieve) use different ways of naming a sieve filter. managesieve uses 'rule:[]' sieveeditor uses 'SCRIPTNAME: ' Actually sieveditor leaves 'rule:[]' alone, but managesieve removes 'SCRIPTNAME:'. Maybe sieveeditor can add a flag to use 'rule:[]' as well? -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 469699] SIGABRT in libldap
https://bugs.kde.org/show_bug.cgi?id=469699 --- Comment #2 from Hans-Peter Jansen --- Thanks for the hint, Stefan! -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 440456] Dolphin become slow/unresponsive after playing a video or audio from the information panel
https://bugs.kde.org/show_bug.cgi?id=440456 Firlaev-Hans changed: What|Removed |Added Resolution|--- |FIXED Status|CONFIRMED |RESOLVED Version Fixed In||24.01.75 --- Comment #5 from Firlaev-Hans --- Works as expected without glitches in KF6/Qt6 builds of Dolphin -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 448673] Cannot move panels to a different side and the dragged panel has a titlebar
https://bugs.kde.org/show_bug.cgi?id=448673 Firlaev-Hans changed: What|Removed |Added Status|CONFIRMED |RESOLVED Version Fixed In||24.01.75 Resolution|--- |FIXED --- Comment #2 from Firlaev-Hans --- This now works in Qt6/KF6 builds of Dolphin. The recently introduced frameless view introduced a different issue related to dragging the panels though: Bug 476877 -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 476877] New: Dolphin's panels cannot be dragged (back) to a side of the window that that borders the main content directly
https://bugs.kde.org/show_bug.cgi?id=476877 Bug ID: 476877 Summary: Dolphin's panels cannot be dragged (back) to a side of the window that that borders the main content directly Classification: Applications Product: dolphin Version: 24.01.75 Platform: Neon OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: dolphin-bugs-n...@kde.org Reporter: firlaevhans.fi...@protonmail.com CC: kfm-de...@kde.org Target Milestone: --- Created attachment 163073 --> https://bugs.kde.org/attachment.cgi?id=163073=edit Screen recording of described issue SUMMARY When you unlock the panels in Dolphin, you can e. g. drag the information panel to a different side, but you won't be able to drag it back, because there's nothing to drag to as the main view (now that the frameless view is implemented) extends right up to the edge of the window. An exception to that is when the scrollbar is shown, you can drag panels to the right side. The same of course won't work for the left side because there's no scroll bar there. STEPS TO REPRODUCE 1. Right click on one of the panels (e. g. places or information) 2. Try to drag it to a side of the window where the main content of dolphins window touches its borders OBSERVED RESULT As you can see in the video, I'm unable to drag the panel to a side that doesn't already have a panel, until I show hidden files, which makes the scroll bar show up. After that, I can drag the panel as expected. But if you happened to have moved all panels away from the left side, the only way to get them back there is to delete dolphins config files. EXPECTED RESULT Dragging any panel to any side of the window should allow the user to place the panel there, in all cases. SOFTWARE/OS VERSIONS KDE Plasma Version: 5.81.0 KDE Frameworks Version: 5.245.0 Qt Version: 6.6.0 Wayland -- You are receiving this mail because: You are watching all bug changes.
[sieveeditor] [Bug 476456] New: No scrollbar in simple editing mode
https://bugs.kde.org/show_bug.cgi?id=476456
Bug ID: 476456
Summary: No scrollbar in simple editing mode
Classification: Applications
Product: sieveeditor
Version: 5.22.3
Platform: Debian stable
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: mon...@kde.org
Reporter: h...@dijkewijk.nl
Target Milestone: ---
SUMMARY
Sieve Editor does not produce a scrollbar if the number of items in a condition
grows too large.
STEPS TO REPRODUCE
1. Create a long rule in advanced mode, e.g.:
#SCRIPTNAME: subject filter
# rule:[subject filter]
if anyof (header :contains "subject" "kalkvrij water"
, header :contains "subject" "10 Days Detoxication"
, header :contains "subject" "Dit is uw kans"
, header :contains "subject" "PEEK antiaanbaklaag"
, header :contains "subject" "spataderen kwijt zonder operatie"
, header :contains "subject" "Nespresso Vertuo"
, header :contains "subject" "Detox Programma Nuubu"
, header :contains "subject" "Ryoko Portable Wi-fi"
, header :contains "subject" "Derila Kussen"
, header :contains "subject" "Directe tweetalige taalvertaler"
, header :contains "subject" "Removio"
, header :contains "subject" "Online store for best price"
, header :contains "subject" "De beste pillen"
, header :contains "subject" "Renforce le système cardiovasculaire"
, header :contains "subject" "Individuele prognose voor gewichtsverlies"
, header :contains "subject" "De beste site om"
)
{
setflag [ "\\Seen" ];
fileinto "Spam";
}
2. Enter simple mode
OBSERVED RESULT
A long list with conditions, without a scrollbar. The rule cannot be edited
anymore.
Also the window is enlarged and cannot be made smaller anymore.
The simple rule editing widget simply grows over the border of the screen size.
The application becomes unusable.
EXPECTED RESULT
A scrollbar to make sure the whole rule can be edited.
SOFTWARE/OS VERSIONS
Windows:
Besturingssysteem: Debian GNU/Linux 12
KDE Plasma-versie: 5.27.5
Versie van KDE-Frameworks: 5.103.0
Qt-versie: 5.15.8
Kernel-versie: 6.1.0-13-amd64 (64-bits)
Grafisch platform: Wayland
Processors: 4 × 11th Gen Intel® Core™ i3-1115G4 @ 3.00GHz
Geheugen: 30,9 GiB RAM
Grafische processor: Mesa Intel® UHD Graphics
ADDITIONAL INFORMATION
--
You are receiving this mail because:
You are watching all bug changes.
[digikam] [Bug 444160] Facing matching is guess work at best
https://bugs.kde.org/show_bug.cgi?id=444160 --- Comment #9 from Hans Lauter --- Created attachment 162319 --> https://bugs.kde.org/attachment.cgi?id=162319=edit Wrong image recognition An example: If I go on the suggestions for myself as a person in digikam. Around 50-100 different people are suggested there, several flowers, a dog, a package of burger king and dumbledore is assigned to me. In case of the flowers and the package of burger king: Ok the image detection failed. But why are they assigned to me? Its ok to have them in the category "unknown", but they have nothing to do with me (considering the accuracy is set to 90%). Moreover, the 50-100 people look totally different than me. Nevertheless, they all tag-suggested as me. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 444160] Facing matching is guess work at best
https://bugs.kde.org/show_bug.cgi?id=444160 Hans Lauter changed: What|Removed |Added CC||lavaw...@getnada.com --- Comment #8 from Hans Lauter --- I have the same problem. The suggestions of face recognition output many wrong results. Around 20-40% of all suggestions are right. This makes the manual rework quite tedious (the benefit of using a face recognition evaporates). Digikam suggests faces, which are completely different from each other. For example a young boy gets assigned to the same person like the ones from a 80 yo lady. It makes no sense at all. On the other side images which are completely similar to already labelled ones, are not suggested, but are put in the group "unknown". So yeah, I can confirm, this recognition is guess work. Face detection works quite good (it sometimes detects objects as people, but the failure rate is here is acceptable), but face recognition malperforms. Some additions: - Deleting all databases and rebuilding them did not help - Retraining the model (maintenance/...) did not help - Changing the accuracy slider from the default 70% to 90% did not help (maybe it changed the quantity, but not quality). I use digikam 8.1.0. Sidenote: I noted that if I did labeled just a few pictures (~10) for a person, then the suggestions are way better but also much less. So if I label 10 pictures to a person X, the algortihm returns lets sa 5-20 pictures, which are actually that person. But for a person Y, if I label > 100 more pictures, the suggestion become really bad. Isn't it the opposite, that AI get better, the more you give? You might say: Then I gave many bad labelled images to person Y. But no, the pictures for person Y are in a good quality, similar facial expression, so the variance is not too high. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 475161] The night color at current location doesn't work properly as manual location
https://bugs.kde.org/show_bug.cgi?id=475161 Firlaev-Hans changed: What|Removed |Added CC||firlaevhans.fiete@protonmai ||l.com Keywords||regression --- Comment #1 from Firlaev-Hans --- Interestingly it's the exact opposite for me. Current location, which worked previously (before Frameworks 5.100), now keeps my screen in day mode. Manual location with the same coordinates works just fine. -- You are receiving this mail because: You are watching all bug changes.
[XWaylandVideoBridge] [Bug 473599] XWaylandVideoBridge only shares white screen
https://bugs.kde.org/show_bug.cgi?id=473599 Firlaev-Hans changed: What|Removed |Added Status|NEEDSINFO |RESOLVED Resolution|WAITINGFORINFO |FIXED --- Comment #3 from Firlaev-Hans --- (In reply to David Edmundson from comment #2) > Something changed, and I believe this was fixed in master, but I can't know > for sure. > > Do you know what version xwaylandvideoridge has the Fedora repositories? Ah, seems to be a rather old version from May: xwaylandvideobridge-0:0~git20230504.3445aff-2.fc38.x86_64 A more recent Flatpak build from gitlab CI works fine. I guess Fedora just needs to update their package. -- You are receiving this mail because: You are watching all bug changes.
[XWaylandVideoBridge] [Bug 473599] XWaylandVideoBridge only shares white screen
https://bugs.kde.org/show_bug.cgi?id=473599 Firlaev-Hans changed: What|Removed |Added CC||firlaevhans.fiete@protonmai ||l.com Ever confirmed|0 |1 Status|REPORTED|CONFIRMED --- Comment #1 from Firlaev-Hans --- I'm having the same issue. I'm using xwaylandvideoridge from the Fedora Repositories, and before that I used a nightly Flatpak build. Neither of them work. -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 469989] Screen recording doesn't work
https://bugs.kde.org/show_bug.cgi?id=469989 Firlaev-Hans changed: What|Removed |Added CC||firlaevhans.fiete@protonmai ||l.com --- Comment #5 from Firlaev-Hans --- Cannot confirm anymore on current Neon Unstable on Wayland with Spectacle built against Qt 6.6. Fixed? -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 463533] Dolphin, file not getting sorted correctly
https://bugs.kde.org/show_bug.cgi?id=463533 Firlaev-Hans changed: What|Removed |Added CC||firlaevhans.fiete@protonmai ||l.com Status|NEEDSINFO |RESOLVED -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 474223] Changes to pinned apps are only saved at quit, so changes can be lost if there's a power outage or plasmashell crashes
https://bugs.kde.org/show_bug.cgi?id=474223 --- Comment #3 from Firlaev-Hans --- > However let's broaden the topic of this bug report a bit to request that > configs get saved > before quit so we can harden Plasmashell a bit against crashes, power loss, > etc. That's how it already worked in Plasma 5 (on 5.27.7 at least); any changes would be written to disk immediately. It was apparently changed in Plasma 6, either intentionally or not, but curiously *only for pinned task manager items and nothing else* as far as I can tell, which seems quite odd. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 474223] Pinned apps in a Wayland session are not remembered
https://bugs.kde.org/show_bug.cgi?id=474223 Firlaev-Hans changed: What|Removed |Added Status|REPORTED|CONFIRMED Ever confirmed|0 |1 CC||firlaevhans.fiete@protonmai ||l.com --- Comment #1 from Firlaev-Hans --- Looks like while changes like adding and removing widgets are immediately written to .config/plasma-org.kde.plasma.desktop-appletsrc, changes to the pinned launchers in the task manager are now only written when plasmashell exits, and does so "gracefully"? When I run plasmashell --replace, the changes are saved and kept, but if I not-so-gently kill either plasmashell or KWin, the changes are not saved. When shutting down / logging out, plasmashell behaves as if KWin died, according to the journal (this is the case on 5.27 too): plasmashell[3262]: The Wayland connection broke. Did the Wayland compositor die? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 442159] Adaptive transparency / floating reacts to windows on wrong screen after screen configuration changes
https://bugs.kde.org/show_bug.cgi?id=442159 Firlaev-Hans changed: What|Removed |Added Summary|Adaptive transparency works |Adaptive transparency / |with windows on wrong |floating reacts to windows |screen |on wrong screen after ||screen configuration ||changes --- Comment #3 from Firlaev-Hans --- Floating panels are affected in the same way as transparency: When plasmashell was started with only my internal display active and then I plug in the external monitor (which then becomes my primary monitor, thus my panel moves there), the panel defloats and becomes opaque when a window on my laptop display "touches" it even though it's located on the external display, and it stays floating and transparent when only a window on that display touches it. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 442159] Adaptive transparency works with windows on wrong screen
https://bugs.kde.org/show_bug.cgi?id=442159 Firlaev-Hans changed: What|Removed |Added Version|5.22.5 |5.27.7 -- You are receiving this mail because: You are watching all bug changes.
[kamoso] [Bug 469137] MKV is a dinosaur format from the 1990's.
https://bugs.kde.org/show_bug.cgi?id=469137
Firlaev-Hans changed:
What|Removed |Added
CC||firlaevhans.fiete@protonmai
||l.com
--- Comment #1 from Firlaev-Hans ---
Are you confusing mkv with something else? It is NOT some abandoned "dinosaur"
format from the 90s, it came out in 2002 more than a year AFTER mp4 and it had
its latest release last october, whereas mp4 hasn't had a new release in 3
years.
Mkv ("Matroska") is actually a very popular, very flexible container format
that supports almost any codec imaginable (including H264 and H265 video and
mp3 or AAC audio). It is a completely free and open standard (unlike mp4) and
doesn't have anything to do with Microsoft or proprietary formats.
It also holds a significant advantage over mp4 for recording scenarios like
this, which is that it can recover better from sudden interruptions during
recording (like crashes or power outages) as unlike mp4 it doesn't result in
broken files. It is the preferred container format in OBS Studio for a reason.
I also don't understand your complaint about editing and modifying mkv files.
FFMPEG and handbrake can work with them just fine, and so can most video
editors. I don't know which software you usually use to manipulate your MP4
files of course.
Now, the actual codecs used by kamoso are a different story. It records theora
video and vorbis audio, the latter is okay but theora *is* a dinosaur codec and
not very good. But again, that has nothing to do with mkv. Kamoso could easily
switch to H264 / H265 video and mp3 (or rather AAC which is much more popular
for videos) audio, while keeping the Matroska container format.
Although I'm not sure how that would work with the licensing of these codecs,
so it might be better to switch to VP8/VP9 video and Opus audio instead which
are good modern free formats and also widely supported (YouTube uses them).
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 470590] After logging in or unlocking the screen, external DP monitor connected to Thunderbolt Dock isn't automatically activated by KWin, but KScreen and Plasma act like it's there
https://bugs.kde.org/show_bug.cgi?id=470590 --- Comment #11 from Firlaev-Hans --- For the record: https://gitlab.freedesktop.org/drm/intel/-/issues/8402 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 470590] After logging in or unlocking the screen, external DP monitor connected to Thunderbolt Dock isn't automatically activated by KWin, but KScreen and Plasma act like it's there
https://bugs.kde.org/show_bug.cgi?id=470590 --- Comment #9 from Firlaev-Hans --- (In reply to Zamundaaa from comment #8) > I can't see any real differences either, it's just different IDs. As far as > KWin is concerned, the output is showing stuff... So this is likely a kernel > issue. > We can check at least one thing to maybe narrow it down though. Can you put > KWIN_DRM_PREFER_COLOR_DEPTH=24 > into /etc/environment, reboot and see if that makes a difference? Just experienced the issue again despite that variable in /etc/environment, so I guess we can rule that out... -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 470590] After logging in or unlocking the screen, external DP monitor connected to Thunderbolt Dock isn't automatically activated by KWin, but KScreen and Plasma act like it's there
https://bugs.kde.org/show_bug.cgi?id=470590 --- Comment #7 from Firlaev-Hans --- (In reply to Zamundaaa from comment #4) > Please attach the output of drm_info when the output isn't working correctly Sorry about the long delay, I had to send my only thunderbolt capable laptop in for repair and was without it for a few weeks. I experienced this issue again today and ran drm_info both in the broken state and in the good state after re-plugging the dock. At first glance, other than different connector numbers once again, I can't tell any significant difference. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 470590] After logging in or unlocking the screen, external DP monitor connected to Thunderbolt Dock isn't automatically activated by KWin, but KScreen and Plasma act like it's there
https://bugs.kde.org/show_bug.cgi?id=470590 --- Comment #6 from Firlaev-Hans --- Created attachment 160318 --> https://bugs.kde.org/attachment.cgi?id=160318=edit drm_info in broken state -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 470590] After logging in or unlocking the screen, external DP monitor connected to Thunderbolt Dock isn't automatically activated by KWin, but KScreen and Plasma act like it's there
https://bugs.kde.org/show_bug.cgi?id=470590 --- Comment #5 from Firlaev-Hans --- Created attachment 160317 --> https://bugs.kde.org/attachment.cgi?id=160317=edit drm_info in normal state -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 443155] kdeconnect breaks when openssh is upgraded to version 8.8p1-1
https://bugs.kde.org/show_bug.cgi?id=443155 Hans Deragon changed: What|Removed |Added CC||h...@deragon.biz -- You are receiving this mail because: You are watching all bug changes.
[kde-cli-tools] [Bug 429408] kde-open5 changes case of argument
https://bugs.kde.org/show_bug.cgi?id=429408 --- Comment #17 from Hans-Peter Jansen --- (In reply to Stefano Forli from comment #16) > (In reply to Hans-Peter Jansen from comment #14) > > Hi Nigel, > > > > you may want to try my slackfix hack - that provides a -v option, allowing > > you to prove, if it's Qt to blame here, or something else... > > Hi Hans, > any hints on how to use the script? I am tempted to replace the > /usr/bin/slack symlink but that doesn't seem to be the right way to do it. Just run slackfix instead of slack, I've provided a .desktop file for that reason. The script runs slack in a controlled way, and supplies the fix at the right moment. Consequently, make sure, slack isn't running beforehand. Feedback is appreciated. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 470590] After logging in or unlocking the screen, the external monitor sometimes doesn't come on though it is active in Plasma
https://bugs.kde.org/show_bug.cgi?id=470590 --- Comment #2 from Firlaev-Hans --- (In reply to Nate Graham from comment #1) > A couple of questions: > > 1. Is the affected screen plugged into the dock via an HDMI cable or > DisplayPort, or something else? > > 2. When this happens and the external screen is in this state, can you paste > the output of `kscreen-doctor -o` in a terminal window, Then, when you fix > it by unplugging and re-plugging the screen, can you paste the output of > that command a second time? 1. The screen is plugged into the thunderbolt dock via (Mini) Display Port 2.) Output of kscreen-doctor -o while in bad state: Output: 1 eDP-1 enabled connected priority 2 Panel Modes: 0:2240x1400@60*! 1:2240x1400@48 2:1600x1200@60 3:1280x1024@60 4:1024x768@60 5:1920x1200@60 6:1280x800@60 7:1920x1080@60 8:1600x900@60 9:1368x768@60 10:1280x720@60 Geometry: 122,1440 2240x1400 Scale: 1 Rotation: 1 Overscan: 0 Vrr: incapable RgbRange: Automatic Output: 2 DP-4 enabled connected priority 1 DisplayPort Modes: 0:2560x1440@60*! 1:1920x1440@60 2:2560x1080@60 3:2560x1080@60 4:2560x1080@50 5:1920x1080@60 6:1920x1080@60 7:1920x1080@60 8:1920x1080@50 9:1600x1200@60 10:1680x1050@60 11:1600x900@60 12:1280x1024@75 13:1280x1024@60 14:1280x800@60 15:1152x864@75 16:1280x720@60 17:1280x720@60 18:1280x720@60 19:1280x720@50 20:1024x768@75 21:1024x768@70 22:1024x768@60 23:832x624@75 24:800x600@75 25:800x600@72 26:800x600@60 27:800x600@56 28:720x576@50 29:720x480@60 30:720x480@60 31:720x480@60 32:720x480@60 33:720x480@60 34:640x480@75 35:640x480@73 36:640x480@67 37:640x480@60 38:640x480@60 39:640x480@60 40:720x400@70 Geometry: 0,0 2560x1440 Scale: 1 Rotation: 1 Overscan: 0 Vrr: incapable RgbRange: Automatic Output after reconnecting the monitor, returning to normal state: Output: 1 eDP-1 enabled connected priority 2 Panel Modes: 0:2240x1400@60*! 1:2240x1400@48 2:1600x1200@60 3:1280x1024@60 4:1024x768@60 5:1920x1200@60 6:1280x800@60 7:1920x1080@60 8:1600x900@60 9:1368x768@60 10:1280x720@60 Geometry: 122,1440 2240x1400 Scale: 1 Rotation: 1 Overscan: 0 Vrr: incapable RgbRange: Automatic Output: 2 DP-5 enabled connected priority 1 DisplayPort Modes: 0:2560x1440@60*! 1:1920x1440@60 2:2560x1080@60 3:2560x1080@60 4:2560x1080@50 5:1920x1080@60 6:1920x1080@60 7:1920x1080@60 8:1920x1080@50 9:1600x1200@60 10:1680x1050@60 11:1600x900@60 12:1280x1024@75 13:1280x1024@60 14:1280x800@60 15:1152x864@75 16:1280x720@60 17:1280x720@60 18:1280x720@60 19:1280x720@50 20:1024x768@75 21:1024x768@70 22:1024x768@60 23:832x624@75 24:800x600@75 25:800x600@72 26:800x600@60 27:800x600@56 28:720x576@50 29:720x480@60 30:720x480@60 31:720x480@60 32:720x480@60 33:720x480@60 34:640x480@75 35:640x480@73 36:640x480@67 37:640x480@60 38:640x480@60 39:640x480@60 40:720x400@70 Geometry: 0,0 2560x1440 Scale: 1 Rotation: 1 Overscan: 0 Vrr: incapable RgbRange: Automatic So for some reason the display gets a different number (DP4 vs DP5) when this error happens. I also noticed that most of the time then running kscreen-doctor, it aborts abnormally. I don't know if this is related at all. Unfortunately I couldn't generate a good backtrace for some reason, the kscreen debuginfo package it complains about *is* installed: malloc_consolidate(): unaligned fastbin chunk detected Thread 1 "kscreen-doctor" received signal SIGABRT, Aborted. __pthread_kill_implementation (threadid=, signo=signo@entry=6, no_tid=no_tid@entry=0) at pthread_kill.c:44 Downloading source file /usr/src/debug/glibc-2.37-4.fc38.x86_64/nptl/pthread_kill.c 44return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO (ret) : 0; Missing separate debuginfos, use: dnf debuginfo-install libkscreen-qt5-5.27.5-1.fc38.x86_64 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 470590] New: After logging in or unlocking the screen, the external monitor sometimes doesn't come on though it is active in Plasma
https://bugs.kde.org/show_bug.cgi?id=470590 Bug ID: 470590 Summary: After logging in or unlocking the screen, the external monitor sometimes doesn't come on though it is active in Plasma Classification: Plasma Product: kwin Version: 5.27.5 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: wayland-generic Assignee: kwin-bugs-n...@kde.org Reporter: firlaevhans.fi...@protonmail.com Target Milestone: --- SUMMARY I have a laptop with a thunderbolt dock with an external monitor, and I typically use both the internal and the external display at the same time. Sometimes when I log in, the external monitor is behaving normally in SDDM but once I'm in the Plasma Wayland session, it goes to sleep. However, as far as Plasma is concerned the screen is active, my panel and windows stay on that screen. I have to unplug and re-plug the thunderbolt dock to make it work again. The same thing occasionally happens when I wake the system from sleep and unlock the screen, only the internal display wakes up while the external one stays on stand-by. The following lines appear in the journal when this happens: >kwin_wayland_wrapper[16159]: warning: queue 0x56161e88c840 destroyed while >proxies still attached: >kwin_wayland_wrapper[16159]: wl_display@1 still attached STEPS TO REPRODUCE 1. (Not sure how to reproduce reliably, unfortunately) 2. Boot up your laptop to SDDM while an external display is attached (not sure if thunderbolt is important) 3. Log in to Plasma Wayland, which should be configured to use both the internal and external display OBSERVED RESULT The external screen may stay black / go to sleep, but Plasma will still treat it as an active screen. EXPECTED RESULT The external screen should just... work. SOFTWARE/OS VERSIONS Operating System: Fedora Linux 38 KDE Plasma Version: 5.27.5 KDE Frameworks Version: 5.106.0 Qt Version: 5.15.9 Kernel Version: 6.2.15-300.fc38.x86_64 (64-bit) Graphics Platform: Wayland Processors: 20 × 12th Gen Intel® Core™ i7-12700H Memory: 15.3 GiB of RAM Graphics Processor: Mesa Intel® Graphics Manufacturer: Dell Inc. Product Name: Inspiron 14 Plus 7420 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 442159] Adaptive transparency works with windows on wrong screen
https://bugs.kde.org/show_bug.cgi?id=442159 Firlaev-Hans changed: What|Removed |Added Ever confirmed|0 |1 CC||firlaevhans.fiete@protonmai ||l.com Status|REPORTED|CONFIRMED --- Comment #2 from Firlaev-Hans --- (In reply to Natalie Clarius from comment #1) > I can reproduce this, and it affects both adaptive transparency and > floating. As far as I can test, it occurs only when the display > configuration changes during the session, and `plasmashell --replace` fixes > it. So I suspect it's something to the effect that the panel code misses to > get a signal when the display config changes and is triggered to update its > screen map accordingly. I'm noticing the same issue as well sometimes when I attach or detach my external monitor on my laptop, especially if I'm doing it several times in one session. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 441533] Dolphin's terminal panel is partially transparent on Wayland even though it shouldn't be with Breeze
https://bugs.kde.org/show_bug.cgi?id=441533 --- Comment #3 from Firlaev-Hans --- (In reply to Nico Kümmel from comment #2) > Hi, > this bug seems to be still present. I face it on archlinux with the latest > updates on 3 different machines. > > SOFTWARE/OS VERSIONS > Operating System: Arch linux with latest updates > KDE Plasma Version: 5.27.5 > KDE Frameworks Version: 5.106.0 > Qt Version: 5.15.9 > Graphics Platform: Wayland > > I face it on 2 machines with AMD graphics as well as 1 machine with Intel > graphics. Yes, it seems to have returned. It was fixed for a while but now I can reproduce it again. -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 462313] Screen isn't locked automatically after the set time span of inactivity
https://bugs.kde.org/show_bug.cgi?id=462313 Firlaev-Hans changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED --- Comment #5 from Firlaev-Hans --- Marking this as fixed for now as I haven't been able to reproduce this issue recently. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 469699] New: SIGABRT in libldap
https://bugs.kde.org/show_bug.cgi?id=469699 Bug ID: 469699 Summary: SIGABRT in libldap Classification: Frameworks and Libraries Product: frameworks-baloo Version: 5.105.0 Platform: openSUSE OS: Linux Status: REPORTED Keywords: drkonqi Severity: crash Priority: NOR Component: Baloo File Daemon Assignee: baloo-bugs-n...@kde.org Reporter: h...@urpla.net Target Milestone: --- Application: baloo_file_extractor (5.105.0) Qt Version: 5.15.9 Frameworks Version: 5.105.0 Operating System: Linux 6.3.1-2-preempt x86_64 Windowing System: X11 Distribution: "openSUSE Tumbleweed" DrKonqi: 5.27.5 [KCrashBackend] -- Information about the crash: The SIGABRT was triggered during indexing. One specific difference to usual setups is indexing an nfs share. The reporter is unsure if this crash is reproducible. -- Backtrace: Application: Baloo-Dateiinfosammler (baloo_file_extractor), signal: Aborted [KCrash Handler] #4 0x7fdfc409490c in __pthread_kill_implementation () from /lib64/libc.so.6 #5 0x7fdfc4043196 in raise () from /lib64/libc.so.6 #6 0x7fdfc402b897 in abort () from /lib64/libc.so.6 #7 0x7fdfc448dd4d in mdb_assert_fail.constprop.0 (env=0x55cba060a920, expr_txt=, func=, line=, file=0x7fdfc449a9d0 "mdb.c") at /usr/src/debug/openldap-LMDB_0.9.30/libraries/liblmdb/mdb.c:1571 #8 0x7fdfc448c4bd in mdb_page_search_root (mc=0x7ffe661a3950, key=0x7ffe661a3d30, flags=0) at /usr/src/debug/openldap-LMDB_0.9.30/libraries/liblmdb/mdb.c:5563 #9 0x7fdfc4491b95 in mdb_cursor_set (mc=0x7ffe661a3950, key=0x7ffe661a3d30, data=0x7ffe661a3d20, op=MDB_SET, exactp=0x7ffe661a394c) at /usr/src/debug/openldap-LMDB_0.9.30/libraries/liblmdb/mdb.c:6175 #10 0x7fdfc4492a8f in mdb_get (txn=, dbi=, key=0x7ffe661a3d30, data=0x7ffe661a3d20) at /usr/src/debug/openldap-LMDB_0.9.30/libraries/liblmdb/mdb.c:5838 #11 0x7fdfc554d0f0 in Baloo::IdFilenameDB::get (this=this@entry=0x7ffe661a3dd0, docId=, docId@entry=4611769388037570618) at /usr/src/debug/baloo-5.105.0/src/engine/idfilenamedb.cpp:83 #12 0x7fdfc554d6df in Baloo::DocumentUrlDB::get (this=, docId=) at /usr/src/debug/baloo-5.105.0/src/engine/documenturldb.cpp:184 #13 0x7fdfc5559bf2 in Baloo::Transaction::documentUrl (this=, id=id@entry=2471620637941039162) at /usr/src/debug/baloo-5.105.0/src/engine/transaction.cpp:102 #14 0x55cb9f706ea3 in Baloo::App::processNextFile (this=0x7ffe661a4360) at /usr/src/debug/baloo-5.105.0/src/file/extractor/app.cpp:94 #15 0x7fdfc4918c50 in QObject::event (this=0x7ffe661a4360, e=0x7fdfb8010300) at kernel/qobject.cpp:1347 #16 0x7fdfc48ec978 in QCoreApplication::notifyInternal2 (receiver=0x7ffe661a4360, event=0x7fdfb8010300) at kernel/qcoreapplication.cpp:1064 #17 0x7fdfc48eff71 in QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, event_type=0, data=0x55cba04a3f50) at kernel/qcoreapplication.cpp:1821 #18 0x7fdfc4946713 in postEventSourceDispatch (s=0x55cba05e7920) at kernel/qeventdispatcher_glib.cpp:277 #19 0x7fdfc36698d8 in g_main_context_dispatch () from /lib64/libglib-2.0.so.0 #20 0x7fdfc3669ce8 in ?? () from /lib64/libglib-2.0.so.0 #21 0x7fdfc3669d7c in g_main_context_iteration () from /lib64/libglib-2.0.so.0 #22 0x7fdfc4945f26 in QEventDispatcherGlib::processEvents (this=0x55cba05e00d0, flags=...) at kernel/qeventdispatcher_glib.cpp:423 #23 0x7fdfc48eb40b in QEventLoop::exec (this=this@entry=0x7ffe661a4250, flags=..., flags@entry=...) at ../../include/QtCore/../../src/corelib/global/qflags.h:69 #24 0x7fdfc48f38a0 in QCoreApplication::exec () at ../../include/QtCore/../../src/corelib/global/qflags.h:121 #25 0x55cb9f6fce23 in main (argc=, argv=) at /usr/src/debug/baloo-5.105.0/src/file/extractor/main.cpp:43 [Inferior 1 (process 14811) detached] Reported using DrKonqi -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 455648] kf.coreaddons: "Could not load plugin from kcm_kscreen: The shared library was not found."
https://bugs.kde.org/show_bug.cgi?id=455648 --- Comment #4 from Hans Meine --- I will not say that it's not a distro packaging problem, yet I want to say that I am absolutely puzzled by this, and I personally cannot relate my findings to missing libraries yet. (First, it works with the nouveau driver, which means that the packaging did *something* correctly, second, even in the failing case, strace shows that kcm_screen.so is found, only *after* the error was reported.) -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 468709] After the opening picture appeares, I am prompted with "Canot find resources" and then pointing to bruhes
https://bugs.kde.org/show_bug.cgi?id=468709 --- Comment #1 from Hans J. Holm --- Oh . after the tenth attempt in a few days Krita started. I hope idoes further -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 468709] New: After the opening picture appeares, I am prompted with "Canot find resources" and then pointing to bruhes
https://bugs.kde.org/show_bug.cgi?id=468709 Bug ID: 468709 Summary: After the opening picture appeares, I am prompted with "Canot find resources" and then pointing to bruhes Classification: Applications Product: krita Version: 5.1.5 Platform: Microsoft Windows OS: Microsoft Windows Status: REPORTED Severity: grave Priority: NOR Component: * Unknown Assignee: krita-bugs-n...@kde.org Reporter: hjjah...@arcor.de 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. Freshly installed 2. Start 3. fails to continue OBSERVED RESULT EXPECTED RESULT SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kde-cli-tools] [Bug 429408] kde-open5 changes case of argument
https://bugs.kde.org/show_bug.cgi?id=429408 --- Comment #14 from Hans-Peter Jansen --- Hi Nigel, you may want to try my slackfix hack - that provides a -v option, allowing you to prove, if it's Qt to blame here, or something else... -- You are receiving this mail because: You are watching all bug changes.
[kaddressbook] [Bug 467148] ALTER DATABASE akonadi REFRESH COLLATION VERSION
https://bugs.kde.org/show_bug.cgi?id=467148 Hans-Peter Jansen changed: What|Removed |Added CC||h...@urpla.net --- Comment #1 from Hans-Peter Jansen --- Hi Axel, can confirm this issue for akonadi with postgres here! This fixed it for me: $ export $(grep Host $HOME/.config/akonadi/akonadiserverrc) $ psql -h $Host akonadi akonadi=# ALTER DATABASE akonadi REFRESH COLLATION VERSION; HINWEIS: Version wird von 2.36 in 2.37 geändert ALTER DATABASE akonadi=# \q -- You are receiving this mail because: You are watching all bug changes.
[kio-gdrive] [Bug 467451] Shared Drives names
https://bugs.kde.org/show_bug.cgi?id=467451 Hans changed: What|Removed |Added Summary|Shared Drive name |Shared Drives names -- You are receiving this mail because: You are watching all bug changes.
[kio-gdrive] [Bug 467451] New: Shared Drive name
https://bugs.kde.org/show_bug.cgi?id=467451 Bug ID: 467451 Summary: Shared Drive name Classification: Frameworks and Libraries Product: kio-gdrive Version: 22.12.3 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: elvis.angelac...@kde.org Reporter: hansco...@gmail.com Target Milestone: --- SUMMARY *** When listing Shared Drives in Krusader using kio-gdrive the drive IDs are shown and not the names. *** STEPS TO REPRODUCE 1. 2. 3. OBSERVED RESULT EXPECTED RESULT Show Shared Drive names instead of the GDrive ID SOFTWARE/OS VERSIONS Linux/KDE Plasma: (available in About System) KDE Plasma Version: 5.27.2-1 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 (built against 5.15.8) ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kde-cli-tools] [Bug 429408] kde-open5 changes case of argument
https://bugs.kde.org/show_bug.cgi?id=429408 Hans-Peter Jansen changed: What|Removed |Added CC||h...@urpla.net --- Comment #12 from Hans-Peter Jansen --- This is getting slightly off-topic now, but is still related! Newer slack versions (using 4.29 here) seem to suffer from this differently. On my Tumbleweed system (specs below), I've straced it, but the slack URI appeared lowercased already (electron?), and is not fed through kde-open5 anymore! For all, that come across this AND still want to use the app, here's an antidote: https://pypi.org/project/slackfix, as well as https://github.com/frispete/slackfix. Operating System: openSUSE Tumbleweed 20230313 KDE Plasma Version: 5.27.2 KDE Frameworks Version: 5.104.0 Qt Version: 5.15.8 Kernel Version: 6.2.6-3-preempt (64-bit) Graphics Platform: X11 Processors: 24 × AMD Ryzen 9 3900X 12-Core Processor Memory: 125.4 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 3060/PCIe/SSE2 Manufacturer: ASUS -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 453147] amdgpu: GPU reset crash loop
https://bugs.kde.org/show_bug.cgi?id=453147 --- Comment #10 from Firlaev-Hans --- I've recently been getting similar KWin hangs with an Intel iGPU whenever it resets (very frequently) kernel: i915 :00:02.0: [drm] GPU HANG: ecode 12:1:87b2bef9, in plasmashell [2627] kernel: i915 :00:02.0: [drm] Resetting chip for stopped heartbeat on rcs0 kernel: i915 :00:02.0: [drm] plasmashell[2627] context reset due to GPU hang kernel: i915 :00:02.0: [drm] GuC firmware i915/adlp_guc_70.bin version 70.5.1 kernel: i915 :00:02.0: [drm] HuC firmware i915/tgl_huc.bin version 7.9.3 kernel: i915 :00:02.0: [drm] HuC authenticated kernel: i915 :00:02.0: [drm] GuC submission enabled kernel: i915 :00:02.0: [drm] GuC SLPC enabled kwin_wayland[2443]: kwin_scene_opengl: A graphics reset not attributable to the current GL context occurred. kwin_wayland[2443]: OpenGL vendor string: Intel kwin_wayland[2443]: OpenGL renderer string: Mesa Intel(R) Graphics (ADL GT2) kwin_wayland[2443]: OpenGL version string: 4.6 (Core Profile) Mesa 22.3.6 kwin_wayland[2443]: OpenGL shading language version string: 4.60 kwin_wayland[2443]: Driver: Intel kwin_wayland[2443]: GPU class: Unknown kwin_wayland[2443]: OpenGL version: 4.6 kwin_wayland[2443]: GLSL version: 4.60 kwin_wayland[2443]: Mesa version: 22.3.6 kwin_wayland[2443]: X server version: 1.22.1 kwin_wayland[2443]: Linux kernel version: 6.1.15 kwin_wayland[2443]: Requires strict binding:no kwin_wayland[2443]: GLSL shaders: yes kwin_wayland[2443]: Texture NPOT support: yes kwin_wayland[2443]: Virtual Machine:no ... and then everything starting from the first "kwin_wayland" line is repeated infinitely. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 467008] New: background colors not available
https://bugs.kde.org/show_bug.cgi?id=467008 Bug ID: 467008 Summary: background colors not available Classification: Applications Product: kate Version: 21.12.3 Platform: Ubuntu OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kwrite-bugs-n...@kde.org Reporter: hhaussm...@arcor.de 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. Einstellungen 2. Kate einrichten 3. Farbschemata (color schemes) OBSERVED RESULT Nothing works EXPECTED RESULT I would like to have a green background for my texts. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: 5.24.7 KDE Frameworks Version: 5.92.0 Qt Version: 5.15.3 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 455648] kf.coreaddons: "Could not load plugin from kcm_kscreen: The shared library was not found."
https://bugs.kde.org/show_bug.cgi?id=455648
Hans Meine changed:
What|Removed |Added
CC||hans_me...@gmx.net
Resolution|DOWNSTREAM |---
Ever confirmed|0 |1
Status|RESOLVED|REOPENED
--- Comment #2 from Hans Meine ---
I have the same problem, and I only found out when debugging why Plasma does
not work properly since I upgraded Kubuntu to 22.04. (My original problem is
that I do not get a dock or desktop background; krunner works.)
The problem seems to be related to the proprietary NVidia driver (which I need
for work); if I switch to Nouveau, Plasma works.
Now I found some reports online that suggested this could be due to a broken
multi-monitor setup – I guess if Plasma believed there was more than one
screen, that could explain what I am seeing. Hence, I was trying to look into
the configuration and found a suspiciously uninteresting display configuration
control panel (that only allows to set a zoom scale).
When I try running `kcmshell5 kscreen`, I am getting
kf.coreaddons: "Could not load plugin from kcm_kscreen: The shared library
was not found."
kf.kirigami: Warning: Theme implementations should use
Kirigami.BasicThemeDefinition for its root item
kf.kirigami: Failed to find a Kirigami platform plugin
file:///usr/share/kpackage/kcms/kcm_kscreen/contents/ui/Screen.qml:39:
TypeError: Value is null and could not be converted to an object
qt.qpa.xcb: QXcbConnection: XCB error: 148 (Unknown), sequence: 190,
resource id: 0, major code: 140 (Unknown), minor code: 20
Just running `ldd` on kcm_kscreen.so, though, does not reveal any problems.
What's more, running strace on the above command shows that it does seem to
load the DLL *after* giving the error message?
statx(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/qt5/plugins/kcm_kscreen",
AT_STATX_SYNC_AS_STAT, STATX_ALL, 0x7ffcb3c5b4e0) = -1 ENOENT (No such file or
directory)
statx(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/qt5/plugins/kcm_kscreen.so",
AT_STATX_SYNC_AS_STAT, STATX_ALL, 0x7ffcb3c5b4e0) = -1 ENOENT (No such file or
directory)
statx(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/qt5/plugins/libkcm_kscreen",
AT_STATX_SYNC_AS_STAT, STATX_ALL, 0x7ffcb3c5b4e0) = -1 ENOENT (No such file or
directory)
statx(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/qt5/plugins/libkcm_kscreen.so",
AT_STATX_SYNC_AS_STAT, STATX_ALL, 0x7ffcb3c5b4e0) = -1 ENOENT (No such file or
directory)
statx(AT_FDCWD, "/usr/bin/kcm_kscreen", AT_STATX_SYNC_AS_STAT, STATX_ALL,
0x7ffcb3c5b4e0) = -1 ENOENT (No such file or directory)
statx(AT_FDCWD, "/usr/bin/kcm_kscreen.so", AT_STATX_SYNC_AS_STAT,
STATX_ALL, 0x7ffcb3c5b4e0) = -1 ENOENT (No such file or directory)
statx(AT_FDCWD, "/usr/bin/libkcm_kscreen", AT_STATX_SYNC_AS_STAT,
STATX_ALL, 0x7ffcb3c5b4e0) = -1 ENOENT (No such file or directory)
statx(AT_FDCWD, "/usr/bin/libkcm_kscreen.so", AT_STATX_SYNC_AS_STAT,
STATX_ALL, 0x7ffcb3c5b4e0) = -1 ENOENT (No such file or directory)
write(2, "kf.coreaddons: \"Could not load p"..., 91kf.coreaddons: "Could
not load plugin from kcm_kscreen: The shared library was not found."
) = 91
statx(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/qt5/plugins/kcms/kcm_kscreen",
AT_STATX_SYNC_AS_STAT, STATX_ALL, 0x7ffcb3c5b4d0) = -1 ENOENT (No such file or
directory)
statx(AT_FDCWD,
"/usr/lib/x86_64-linux-gnu/qt5/plugins/kcms/kcm_kscreen.so",
AT_STATX_SYNC_AS_STAT, STATX_ALL, {stx_mask=STATX_ALL|STATX_MNT_ID,
stx_attributes=0, stx_mode=S_IFREG|0644, stx_size=213464, ...}) = 0
openat(AT_FDCWD,
"/usr/lib/x86_64-linux-gnu/qt5/plugins/kcms/kcm_kscreen.so",
O_RDONLY|O_CLOEXEC) = 27
statx(27, "", AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH, STATX_ALL,
{stx_mask=STATX_ALL|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFREG|0644,
stx_size=213464, ...}) = 0
statx(27, "", AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH, STATX_ALL,
{stx_mask=STATX_ALL|STATX_MNT_ID, stx_attributes=0, stx_mode=S_IFREG|0644,
stx_size=213464, ...}) = 0
I admit that this might not be the right place to report this, but I decided to
reopen the issue in the hope that people can either help debugging this
directly here or point me (and others who might have the same problem) to a
better location.
--
You are receiving this mail because:
You are watching all bug changes.
[plasmashell] [Bug 465872] Plasma keeps crashing
https://bugs.kde.org/show_bug.cgi?id=465872 --- Comment #4 from Hans Brage --- It crashes shortly after login. I can see that background and desktop icons briefly appears and disappears. Then is the crash window displayed for some second and I looks like also that application crashes as the window disappears. Then it looks like it tries to restart itself as I can see objects on desktop occasionally flashing and also some crash windows flashing by. /var/log/messages also fills up with repeated entries. To be able to send the report I used the killall and a manual start of plasma. Den 17 februari 2023 09:30:05 skrev "David Redondo" : > https://bugs.kde.org/show_bug.cgi?id=465872 > > David Redondo changed: > > What|Removed |Added > > CC||k...@david-redondo.de > > --- Comment #3 from David Redondo --- > Does it crash right after it is started? Randomly during execution? Or when > you > do something specifc? > > -- > You are receiving this mail because: > You reported the bug. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 465872] Plasma keeps crashing
https://bugs.kde.org/show_bug.cgi?id=465872 --- Comment #2 from Hans Brage --- Tried to remove ~/.cache (renamed it) and then rebooted the system. Folder is recreated but plasma still crasches. Den 2023-02-17 kl. 02:02, skrev Fushan Wen: > https://bugs.kde.org/show_bug.cgi?id=465872 > > Fushan Wen changed: > > What|Removed |Added > > CC||qydwhotm...@gmail.com > > --- Comment #1 from Fushan Wen --- > Try to delete ~/.cache folder and test again > -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 465872] New: Plasma keeps crashing
https://bugs.kde.org/show_bug.cgi?id=465872 Bug ID: 465872 Summary: Plasma keeps crashing Classification: Plasma Product: plasmashell Version: 5.27.0 Platform: openSUSE OS: Linux Status: REPORTED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: h...@plattformen.se CC: k...@davidedmundson.co.uk Target Milestone: 1.0 Application: plasmashell (5.27.0) Qt Version: 5.15.8 Frameworks Version: 5.103.0 Operating System: Linux 6.1.10-1-pae i686 Windowing System: X11 Distribution: "openSUSE Tumbleweed" DrKonqi: 5.27.0 [KCrashBackend] -- Information about the crash: Applied regular updates to the system (zypper -dup) and since then plasma keeps crashing with segmentation faults. Restarts and crashes again. The crash can be reproduced every time. -- Backtrace: Application: Plasma (plasmashell), signal: Segmentation fault [KCrash Handler] #5 0xb705c376 in QQmlJavaScriptExpression::DeleteWatcher::wasDeleted() const (this=) at /usr/src/debug/qtdeclarative-everywhere-src-5.15.8+kde22/src/qml/qml/qqmljavascriptexpression_p.h:230 #6 QQmlPropertyCapture::captureProperty(QObject*, int, int, bool) (this=0x8dc35e5b, o=0x387a3d0, c=-1, n=0, doNotify=false) at /usr/src/debug/qtdeclarative-everywhere-src-5.15.8+kde22/src/qml/qml/qqmljavascriptexpression.cpp:281 #7 0xb442e75c in QV4::ModelObject::virtualGet(QV4::Managed const*, QV4::PropertyKey, QV4::Value const*, bool*) (m=0xa15c0820, id=..., receiver=0xa15c0820, hasProperty=0x0) at /usr/src/debug/qtdeclarative-everywhere-src-5.15.8+kde22/src/qmlmodels/qqmllistmodel.cpp:1639 #8 0xb6ef2681 in QV4::Object::get(QV4::StringOrSymbol*, bool*, QV4::Value const*) const (receiver=0xa15c0820, hasProperty=0x0, name=, this=0xa15c0820) at ../../include/QtQml/5.15.8/QtQml/private/../../../../../../src/qml/jsruntime/qv4object_p.h:308 #9 QV4::Lookup::getterFallback(QV4::Lookup*, QV4::ExecutionEngine*, QV4::Value const&) (l=0x3877f80, engine=0x18c0a60, object=...) at /usr/src/debug/qtdeclarative-everywhere-src-5.15.8+kde22/src/qml/jsruntime/qv4lookup.cpp:231 #10 0xb4429b39 in QV4::ModelObject::virtualResolveLookupGetter(QV4::Object const*, QV4::ExecutionEngine*, QV4::Lookup*) (object=0xa15c0788, engine=0x18c0a60, lookup=0x3877f80) at /usr/src/debug/qtdeclarative-everywhere-src-5.15.8+kde22/src/qmlmodels/qqmllistmodel.cpp:1650 #11 0xb6ef378e in QV4::Lookup::getterGeneric(QV4::Lookup*, QV4::ExecutionEngine*, QV4::Value const&) (l=0x3877f80, engine=0x18c0a60, object=...) at /usr/src/debug/qtdeclarative-everywhere-src-5.15.8+kde22/src/qml/jsruntime/qv4lookup.cpp:144 #12 0xb6f6520c in QV4::Moth::VME::interpret(QV4::CppStackFrame*, QV4::ExecutionEngine*, char const*) (frame=0x72023400, engine=0x18c0a60, code=0x920b4c46 ":n:o\030\a:pL\006\026\a:q\030\a\026\t>r\a\026\a:sL\005\026\tp\030\t\026\bx\030\bRH\304\016\002") at /usr/src/debug/qtdeclarative-everywhere-src-5.15.8+kde22/src/qml/jsruntime/qv4vme_moth.cpp:641 #13 0xb6f68e3c in QV4::Moth::VME::exec(QV4::CppStackFrame*, QV4::ExecutionEngine*) (engine=0x18c0a60, frame=0xbff5ce38) at /usr/src/debug/qtdeclarative-everywhere-src-5.15.8+kde22/src/qml/jsruntime/qv4vme_moth.cpp:466 #14 QV4::Moth::VME::exec(QV4::CppStackFrame*, QV4::ExecutionEngine*) (frame=0xbff5ce38, engine=0x18c0a60) at /usr/src/debug/qtdeclarative-everywhere-src-5.15.8+kde22/src/qml/jsruntime/qv4vme_moth.cpp:430 #15 0xb6f13cfe in QV4::ArrowFunction::virtualCall(QV4::FunctionObject const*, QV4::Value const*, QV4::Value const*, int) (fo=0xbff5ceb4, thisObject=0xa15c0770, argv=0xa15c0670, argc=0) at /usr/src/debug/qtdeclarative-everywhere-src-5.15.8+kde22/src/qml/jsruntime/qv4functionobject.cpp:528 #16 0xb6f7a3ea in QV4::FunctionObject::call(QV4::Value const*, QV4::Value const*, int) const (argc=0, argv=0xa15c0670, thisObject=0xa15c0770, this=0xbff5ceb4) at /usr/src/debug/qtdeclarative-everywhere-src-5.15.8+kde22/src/qml/jsruntime/qv4functionobject_p.h:202 #17 QV4::Runtime::CallQmlContextPropertyLookup::call(QV4::ExecutionEngine*, unsigned int, QV4::Value*, int) (engine=0x18c0a60, index=26, argv=0xa15c0670, argc=0) at /usr/src/debug/qtdeclarative-everywhere-src-5.15.8+kde22/src/qml/jsruntime/qv4runtime.cpp:1366 #18 0xb6f66e14 in QV4::Moth::VME::interpret(QV4::CppStackFrame*, QV4::ExecutionEngine*, char const*) (frame=0x72023400, engine=0x18c0a60, code=0x920b4531 "\320\016\002") at /usr/src/debug/qtdeclarative-everywhere-src-5.15.8+kde22/src/qml/jsruntime/qv4vme_moth.cpp:787 #19 0xb6f68e3c in QV4::Moth::VME::exec(QV4::CppStackFrame*, QV4::ExecutionEngine*) (engine=0x18c0a60, frame=0xbff5d058) at /usr/src/debug/qtdeclarative-everywhere-src-5.15.8+kde22/src/qml/jsruntime/qv4vme_moth.cpp:466 #20 QV4::Moth::VME::exec(QV4::CppStackFrame*, QV4::ExecutionEngine*) (frame=0xbff5d058, engine=0x18c0a60) at
[yakuake] [Bug 464977] New: Add option to start new session with specific profile in tab bar, plus keyboard shortcuts
https://bugs.kde.org/show_bug.cgi?id=464977 Bug ID: 464977 Summary: Add option to start new session with specific profile in tab bar, plus keyboard shortcuts Classification: Applications Product: yakuake Version: 22.12.1 Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: general Assignee: h...@kde.org Reporter: firlaevhans.fi...@protonmail.com Target Milestone: --- SUMMARY Currently, as far as I can tell, Yakuake does not have the ability to start a new session (new tab) with a specific profile, unless you were to go into the settings and set that profile as the default. You can change the profile of a session after the fact, though this does not execute the custom command. What I'd like to see is an option (perhaps when you right click on the tab bar) to start a new session with a submenu that lets you select the profile for the session (like Konsole has), as well as being able to set keyboard shortcuts for starting a session with a specific profile (which Konsole actually doesn't have either right now). My use case: Having an immutable system (Fedora Kinoite) with several containers of other distributions using distrobox or toolbox. I'd have several different Konsole profiles, the default one for the host system and then several profiles that each have "distrobox enter " set as their custom command. Then, whenever I need a terminal in a specific container I could just quickly open a new Yakuake tab with the corresponding profile. SOFTWARE/OS VERSIONS Operating System: Fedora Linux 37 KDE Plasma Version: 5.26.5 KDE Frameworks Version: 5.102.0 Qt Version: 5.15.8 Kernel Version: 6.1.7-200.fc37.x86_64 (64-bit) Graphics Platform: Wayland -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 377162] Window shading not supported for Wayland windows
https://bugs.kde.org/show_bug.cgi?id=377162 --- Comment #14 from Hans-Peter Jansen --- Especially, if you really want to convert the long term power users! A not too small share of them make use of this feature. If you get used to it, you will not want to do without it. -- You are receiving this mail because: You are watching all bug changes.
[ghostwriter] [Bug 460352] Do not save drafts and temporary files in the Documents directory
https://bugs.kde.org/show_bug.cgi?id=460352 Hans-Peter Jansen changed: What|Removed |Added CC||h...@urpla.net -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 462313] Screen isn't locked automatically after the set time span of inactivity
https://bugs.kde.org/show_bug.cgi?id=462313 Firlaev-Hans changed: What|Removed |Added Version|5.26.3 |5.26.4 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 462699] New: cannot change resolution of a picture
https://bugs.kde.org/show_bug.cgi?id=462699 Bug ID: 462699 Summary: cannot change resolution of a picture Classification: Applications Product: krita Version: 5.0.6 Platform: Compiled Sources OS: All Status: REPORTED Severity: normal Priority: NOR Component: * Unknown Assignee: krita-bugs-n...@kde.org Reporter: hjjah...@arcor.de Target Milestone: --- The problem is that I did not find a possibility to change the resolution of a figure, given as 72,00 under properties. For photoshop, it is described to be found under Image>Image "resolution". "If you’re using Adobe Photoshop to manipulate an image, you can find the DPI using Photoshop’s built-in options. To do this, open the image in Photoshop. From the menu bar, click Image > Image size to open the Image Size dialog box. Photoshop Image Size option menu The image resolution will be listed as pixels per inch in the options bo provided, under the Resolution section. Photoshop DPI settings If you want, you can change the resolution (and thus the DPI value) for your image using Photoshop from this menu. To do this, type a new value in the Resolution options box provided." -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 462313] Screen isn't locked automatically after the set time span of inactivity
https://bugs.kde.org/show_bug.cgi?id=462313 --- Comment #2 from Firlaev-Hans --- (In reply to Nate Graham from comment #1) > Can you paste the contents of the following files? > > ~/.config/kscreenlockerrc > > /etc/xdg/kscreenlockerrc The latter does not exist. The content of the local file in .config is: >[$Version] >update_info=kscreenlocker.upd:0.1-autolock > >[Daemon] >Timeout=1 Removing / regenerating this file made absolutely no difference. -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 462313] New: Screen isn't locked automatically after the set time span of inactivity
https://bugs.kde.org/show_bug.cgi?id=462313 Bug ID: 462313 Summary: Screen isn't locked automatically after the set time span of inactivity Classification: Plasma Product: kscreenlocker Version: 5.26.3 Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: firlaevhans.fi...@protonmail.com Target Milestone: --- SUMMARY This bug was introduced in 5.26, I believe. The screen locker can be activated manually with a shortcut, and it also comes on when waking the system from sleep. However, the screen is never locked automatically due to inactivity. On my system the timeout is set to 5 minutes (I have tried changing it, no difference), but even more than half an hour later I came back to my screen still being unlocked. After some time, the screen actually does turn off, but when I wiggle the mouse, it still comes back with no lock screen. The journal doesn't indicate any error. STEPS TO REPRODUCE 1. Make sure to set the screen locker to turn on automatically after some amount of time in "Workspace Behaviour > Lock screen" 2. Leave the computer for that amount of time without giving any input. OBSERVED RESULT The lock screen never appears EXPECTED RESULT The lock screen should appear SOFTWARE/OS VERSIONS Operating System: Fedora Linux 37 KDE Plasma Version: 5.26.3 KDE Frameworks Version: 5.100.0 Qt Version: 5.15.7 Kernel Version: 6.0.9-300.fc37.x86_64 (64-bit) Graphics Platform: Wayland System Version: Lenovo IdeaPad C340-14API -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 380886] Kmail2 - missing the little arrow right below
https://bugs.kde.org/show_bug.cgi?id=380886 --- Comment #3 from Hans-J. Ullrich --- Am Sonntag, 6. November 2022, 10:25:27 CET schrieben Sie: Hi Justin, thanks for the response. Yes I can. But what you named "recent" is the version in debian/stable. Others I could not test, as I do not have any debian system running higher versions as "stable". But maybe someone else in this list, who is running debian/testing or debian/unstable might test it for you. Hope this helps. Best regards Hans > https://bugs.kde.org/show_bug.cgi?id=380886 > > Justin Zobel changed: > >What|Removed |Added > > Status|REPORTED|NEEDSINFO > Resolution|--- |WAITINGFORINFO > > --- Comment #1 from Justin Zobel --- > Thank you for reporting this issue in KDE software. As it has been a while > since this issue was reported, can we please ask you to see if you can > reproduce the issue with a recent software version? > > If you can reproduce the issue, please change the status to "REPORTED" when > replying. Thank you! -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 380886] Kmail2 - missing the little arrow right below
https://bugs.kde.org/show_bug.cgi?id=380886 --- Comment #2 from Hans-J. Ullrich --- Am Sonntag, 6. November 2022, 10:25:27 CET schrieben Sie: Hi Justin, thanks for the response. Yes I can. But what you named "recent" is the version in debian/stable. Others I could not test, as I do not have any debian system running higher versions as "stable". But maybe someone else in this list, who is running debian/testing or debian/unstable might test it for you. Hope this helps. Best regards Hans > https://bugs.kde.org/show_bug.cgi?id=380886 > > Justin Zobel changed: > >What|Removed |Added > > Status|REPORTED|NEEDSINFO > Resolution|--- |WAITINGFORINFO > > --- Comment #1 from Justin Zobel --- > Thank you for reporting this issue in KDE software. As it has been a while > since this issue was reported, can we please ask you to see if you can > reproduce the issue with a recent software version? > > If you can reproduce the issue, please change the status to "REPORTED" when > replying. Thank you! -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 461032] With 150% scale, when maximising a window, kwin_x11 fails to redraw the window content
https://bugs.kde.org/show_bug.cgi?id=461032 Hans-Peter Jansen changed: What|Removed |Added CC||h...@urpla.net -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 457487] After fixing the shaded/shuttered window feature, restarting kwin_x11 --replace forgets the shaded window sizes
https://bugs.kde.org/show_bug.cgi?id=457487 --- Comment #3 from Hans-Peter Jansen --- (In reply to Luke-Jr from comment #2) > Is this going to get fixed? (Alternatively, is there a maintained fork of > KWin somewhere out there we can switch to?) Be careful with such expressions: kwin is maintained! It's the X11 part, that is problematic, and here, it's related to a feature, that doesn't even exist under wayland, yet! If you want this feature for wayland, please show your interest here: https://bugs.kde.org/show_bug.cgi?id=377162 FTR: I tried different approaches already to backport to an earlier state of the shaded window feature, aas well as backing out those changes, in order to get back to the state of the good ol' times, but the kwin codebase was shuffled around so heavily, that it would end up into something similar, what Vlad did already. Duuh. -- You are receiving this mail because: You are watching all bug changes.
[Discover] [Bug 460900] New: Discover crashed during installation of a flatpak
https://bugs.kde.org/show_bug.cgi?id=460900 Bug ID: 460900 Summary: Discover crashed during installation of a flatpak Classification: Applications Product: Discover Version: 5.26.0 Platform: Debian testing OS: Linux Status: REPORTED Keywords: drkonqi Severity: crash Priority: NOR Component: discover Assignee: plasma-b...@kde.org Reporter: eln...@pm.me CC: aleix...@kde.org Target Milestone: --- Application: plasma-discover (5.26.0) Qt Version: 5.15.4 Frameworks Version: 5.98.0 Operating System: Linux 5.19.0-2-amd64 x86_64 Windowing System: X11 Distribution: Debian GNU/Linux bookworm/sid DrKonqi: 5.26.0 [KCrashBackend] -- Information about the crash: Discover suddenly segfaulted during installation of a Yuzu Switch emulator flatpak. The reporter is unsure if this crash is reproducible. -- Backtrace: Application: Discover (plasma-discover), signal: Segmentation fault [KCrash Handler] #4 0x7f49e5923b98 in ?? () from /usr/lib/x86_64-linux-gnu/qt5/plugins/discover/flatpak-backend.so #5 0x7f4a05ce89af in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #6 0x7f4a07ec629e in Transaction::statusChanged(Transaction::Status) () from /usr/lib/x86_64-linux-gnu/plasma-discover/libDiscoverCommon.so #7 0x7f4a07ec66ec in Transaction::setStatus(Transaction::Status) () from /usr/lib/x86_64-linux-gnu/plasma-discover/libDiscoverCommon.so #8 0x7f4a05cdd2a0 in QObject::event(QEvent*) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #9 0x7f4a06f62f4e in QApplicationPrivate::notify_helper(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libQt5Widgets.so.5 #10 0x7f4a05cb1618 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #11 0x7f4a05cb45b1 in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #12 0x7f4a05d09ae3 in ?? () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #13 0x7f4a04522739 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #14 0x7f4a045229c8 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #15 0x7f4a04522a5c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #16 0x7f4a05d091c6 in QEventDispatcherGlib::processEvents(QFlags) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #17 0x7f4a05cb009b in QEventLoop::exec(QFlags) () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #18 0x7f4a05cb8206 in QCoreApplication::exec() () from /lib/x86_64-linux-gnu/libQt5Core.so.5 #19 0x5640163131db in ?? () #20 0x7f4a0522920a in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #21 0x7f4a052292bc in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6 #22 0x564016313751 in ?? () [Inferior 1 (process 3952) detached] Reported using DrKonqi -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 460248] plasmashell with high CPU usage in Wayland session
https://bugs.kde.org/show_bug.cgi?id=460248 Firlaev-Hans changed: What|Removed |Added CC||firlaevhans.fiete@protonmai ||l.com --- Comment #6 from Firlaev-Hans --- Could you test if the issue is gone after fully updating your Arch system now (specifically, kimageformats-5.99.0-2)? If so, it was probably the same as Bug 460085 and is now fixed. If the issue persists then Bug 460085 probably isn't related. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 460085] Plasmashell constantly uses ~20% of my CPU (and GPU?) and significantly tanks game performance
https://bugs.kde.org/show_bug.cgi?id=460085 --- Comment #6 from Firlaev-Hans --- Okay, I did some investigation, this is the weirdest thing ever. It is apparently wallpaper related. Since, in Bug 460248, Patrick Silva said they couldn't reproduce this on a fresh account, I tried removing stuff from plasmashellrc and the plasma*appletsrc until the problem went away. I determined that resetting the wallpaper for my second monitor "fixed" the issue. The issue would only occur if my *second* monitor's wallpaper was an AVIF image (which it previously was). Using PNG or JPG, CPU usage was normal. Oddly enough, setting the same AVIF wallpaper on my primary monitor did not cause the issue. Half an hour later the two displays seemingly "switched roles", now only the first monitor would cause the issue when using an AVIF wallpaper on it, and the second one didn't. I'm not sure what caused that. In any case, as long as I'm not using AVIF wallpapers at all, I guess I'm safe(?) -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 460085] Plasmashell constantly uses ~20% of my CPU (and GPU?) and significantly tanks game performance
https://bugs.kde.org/show_bug.cgi?id=460085 --- Comment #5 from Firlaev-Hans --- I just upgraded my Arch system to the stable 5.26 release and this issue still persists. -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 460263] Ekos focuser too small hardcoded max travel in UI
https://bugs.kde.org/show_bug.cgi?id=460263 --- Comment #4 from Hans Lambermont --- Fix confirmed. Thanks ! -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 460263] Ekos focuser too small hardcoded max travel in UI
https://bugs.kde.org/show_bug.cgi?id=460263 --- Comment #2 from Hans Lambermont --- Yes the driver is right, that is not the problem. Have a look at the PNG attachment to this bug ticket, that shows the problem is in the GUI. It has a hardcoded maximum of 10. In EKOS focus.ui , look at line 1629 : ``` focus.ui 1612 1613 1614 16150 16160 1617 1618 1619 1620 htmlhead/bodypMaximum travel in steps before the autofocus process aborts/p/body t;/html 1621 1622 1623 0 1624 1625 1626 10.000 1627 1628 1629 10.000 1630 ``` -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 460263] Ekos focuser too small hardcoded max travel in UI
https://bugs.kde.org/show_bug.cgi?id=460263 Hans Lambermont changed: What|Removed |Added Summary|Ekos focuser hardcoded max |Ekos focuser too small |travel in UI|hardcoded max travel in UI -- You are receiving this mail because: You are watching all bug changes.
[kstars] [Bug 460263] New: Ekos focuser hardcoded max travel in UI
https://bugs.kde.org/show_bug.cgi?id=460263 Bug ID: 460263 Summary: Ekos focuser hardcoded max travel in UI Classification: Applications Product: kstars Version: 3.6.1 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: mutla...@ikarustech.com Reporter: h...@lambermont.dyndns.org Target Milestone: --- Created attachment 152718 --> https://bugs.kde.org/attachment.cgi?id=152718=edit Note the greyed-out increase Max Travel arrow indicating that this is a UI thing. The focusMaxTravel has a hardcoded maximum set to 10 in focus.ui This breaks focusing on an Integra85 which has a max travel of 188500 STEPS TO REPRODUCE 1. Open EKOS focuser tab 2. In there open the Mechanics tab 3. Observe that Max Travel is limited to 10 OBSERVED RESULT Max Travel is limited to 10 EXPECTED RESULT Max Travel has a much higher limit. Maybe 30 ? ADDITIONAL INFORMATION This bug keeps coming back. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 460085] Plasmashell constantly uses ~20% of my CPU (and GPU?) and significantly tanks game performance
https://bugs.kde.org/show_bug.cgi?id=460085 --- Comment #3 from Firlaev-Hans --- Perhaps this is useful (this is the output without specifying the PID): >37.99% QSGRenderThread libc.so.6 >24.36% plasmashell libQt5Core.so.5.15.6 > 8.28% plasmashell libglib-2.0.so.0.7400.0 > 5.96% plasmashell libQt5Gui.so.5.15.6 > 5.58% plasmashell libc.so.6 > 5.50% plasmashell libQt5Quick.so.5.15.6 > 3.88% plasmashell [vdso] > 1.13% perf perf > 0.66% plasmashell ld-linux-x86-64.so.2 > 0.53% plasmashell libQt5Widgets.so.5.15.6 > 0.49% swapper [unknown] > 0.49% kwin_wayland radeonsi_dri.so > 0.45% plasmashell kimg_avif.so > 0.41% Isolated Web Co libxul.so > 0.29% plasmashell libstdc++.so.6.0.30 > 0.27% perf libc.so.6 > 0.24% plasmashell libwayland-client.so.0.21.0 > 0.22% plasmashell breeze.so > 0.22% plasmashell libQt5WaylandClient.so.5.15.6 > 0.18% plasmashell libKF5XmlGui.so.5.98.0 > 0.17% kwin_wayland libkwin.so.5.25.90 > 0.15% QSGRenderThread radeonsi_dri.so > 0.15% kwin_wayland libc.so.6 > 0.14% kwin_wayland [unknown] > 0.11% kwin_wayland libQt5Gui.so.5.15.6 > 0.10% plasmashell libQt5Qml.so.5.15.6 > 0.09% kwin_wayland libQt5Core.so.5.15.6 > 0.08% plasmashell libKirigamiPlugin.so > 0.07% plasmashell libpulse-mainloop-glib.so.0.0.6 > 0.06% plasmashell libKF5PlasmaQuick.so.5.98.0 > 0.06% QSGRenderThread libQt5Quick.so.5.15.6 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 460085] Plasmashell constantly uses ~20% of my CPU (and GPU?) and significantly tanks game performance
https://bugs.kde.org/show_bug.cgi?id=460085 --- Comment #2 from Firlaev-Hans --- (In reply to Fushan Wen from comment #1) > Could you run > > perf top -p $(pidof plasmashell) -K > > to see what's hogging the CPU? Unfortunately that command does not appear to work for me: >Error: >Failed to mmap with 22 (Invalid argument) -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 460085] New: Plasmashell constantly uses ~20% of my CPU (and GPU?) and significantly tanks game performance
https://bugs.kde.org/show_bug.cgi?id=460085 Bug ID: 460085 Summary: Plasmashell constantly uses ~20% of my CPU (and GPU?) and significantly tanks game performance Classification: Plasma Product: plasmashell Version: git-stable-Plasma/5.26 Platform: Archlinux OS: Linux Status: REPORTED Severity: major Priority: NOR Component: generic-performance Assignee: plasma-b...@kde.org Reporter: firlaevhans.fi...@protonmail.com Target Milestone: 1.0 SUMMARY This has been happening ever since I upgraded my Arch system to the 5.26 beta. I'm on Wayland. The plasmashell process constantly uses around 20-ish % of my CPU according to the system monitor (the more windows are visible, the higher the CPU usage), and all video games run like poo. When I kill plasmashell, I can literally hear my fans go quieter, and games run fine again. The only third party widget I use is "Window Title", removing it made no difference, and neither did removing the system monitor applets from my panel. STEPS TO REPRODUCE 1. Start plasma 5.26 on Wayland 2. Look at per-process CPU usage 3. minimize and maximize some windows and keep looking at CPU usage (4. Try playing a video game 5. Kill plasmashell 5. Keep playing the game) OBSERVED RESULT Plasmashell uses unusually many CPU resources. The more windows are visible, the higher the usage. Video games run at low framerates with lots of stuttering until plasmashell is killed. EXPECTED RESULT Plasmashell should barely use any CPU resources. Game performance should not be impacted by plasmashell running or not. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.25.90 KDE Frameworks Version: 5.98.0 Qt Version: 5.15.6 Kernel Version: 6.0.0-zen1-1-zen (64-bit) Graphics Platform: Wayland Processors: 8 × Intel® Core™ i7-7700 CPU @ 3.60GHz Memory: 15.5 GiB of RAM Graphics Processor: AMD Radeon RX 580 Series ADDITIONAL INFORMATION In case it may be relevant, I'm using two monitors. Also, running plasmashell with mesa-git or using zink instead of RadeonSI for OpenGL made no difference. It seems like the GPU usage is also higher (which would make sense for the game performance) but system monitor doesn't show any GPU info for me right now for some reason. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 459872] Session freezes entirely and doesn't recover after AMD GPU reset caused by VAAPI
https://bugs.kde.org/show_bug.cgi?id=459872 --- Comment #2 from Firlaev-Hans --- (In reply to Vlad Zahorodnii from comment #1) > It looks like kwin and plasmashell are stuck thinking that the OpenGL > context has been lost. Do you know how to reliably trigger a gpu reset? > Would reading /sys/kernel/debug/dri/0/amdgpu_gpu_reset work? or does vaapi > do something different? Running > sudo cat /sys/kernel/debug/dri/0/amdgpu_gpu_recover does in fact seem to cause the exact same symptoms. -- You are receiving this mail because: You are watching all bug changes.
[Elisa] [Bug 455497] After touchscreen-scrolling to the bottom of the playlist panel and overshooting, the playlist jitters indefinitely
https://bugs.kde.org/show_bug.cgi?id=455497 Firlaev-Hans changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Firlaev-Hans --- I am no longer able to reproduce this with Elisa 22.08 (from Fedora) and Frameworks 5.98. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 459872] New: Session freezes entirely and doesn't recover after AMD GPU reset caused by VAAPI
https://bugs.kde.org/show_bug.cgi?id=459872 Bug ID: 459872 Summary: Session freezes entirely and doesn't recover after AMD GPU reset caused by VAAPI Classification: Plasma Product: kwin Version: 5.25.5 Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: wayland-generic Assignee: kwin-bugs-n...@kde.org Reporter: firlaevhans.fi...@protonmail.com Target Milestone: --- Created attachment 152525 --> https://bugs.kde.org/attachment.cgi?id=152525=edit Excerpt from system journal SUMMARY Every now and then, VAAPI video decoding (in Firefox, in particular) triggers a GPU reset on my AMD iGPU. Whenever that happens, the screen goes black for a second and then comes back but is entirely frozen. Sometimes I'm still able to switch to a tty, sometimes not. But in any case, the Plasma session never recovers. STEPS TO REPRODUCE 1. Have a GPU reset trigger somehow OBSERVED RESULT KWin freezes entirely (but doesn't crash?) EXPECTED RESULT KWin should be able to recover from the crash. SOFTWARE/OS VERSIONS Operating System: Fedora Linux 36 KDE Plasma Version: 5.25.5 KDE Frameworks Version: 5.98.0 Qt Version: 5.15.5 Kernel Version: 5.19.11-200.fc36.x86_64 (64-bit) Graphics Platform: Wayland Processors: 4 × AMD Ryzen 3 3200U with Radeon Vega Mobile Gfx Memory: 6.7 GiB of RAM Graphics Processor: AMD Radeon Vega 3 Graphics ADDITIONAL INFORMATION I have attached an excerpt of the system journal from the time of the GPU reset. It never shows any indication that KWin crashed or whatever. The GPU resets successfully, and Plasmashell detects it and claims to restart its GPU process. KWin never explicitly says anything about the reset at all, but for some reason it continuously prints OpenGL information the the journal several times a second, for about a minute until I switch to a TTY and then it stops, but continues once I try to switch back. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 451681] Scan and refresh of album don't rotate HEIC files correctly.
https://bugs.kde.org/show_bug.cgi?id=451681 Hans changed: What|Removed |Added CC||kde-bugs.mail.postfach144@n ||everbox.com --- Comment #13 from Hans --- It seems to me this bug still exists. I'm using digiKam 7.8.0 on openSUSE Tumbleweed. HEIC files in portrait orientation are displayed in landscape orientation, no matter if as thumbnail, as preview or in the editor. They open correctly in Gwenview and GIMP. Reopen? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 454379] plasmashell starts lagging after any file is copied from dolphin and dolphin is closed
https://bugs.kde.org/show_bug.cgi?id=454379 --- Comment #17 from Firlaev-Hans --- (In reply to Nate Graham from comment #15) > I could reproduce this issue last month, but I can't anymore with the > current state of git master. Can anyone else? It might have been fixed > recently. Still reproducible latest Neon Unstable, so if it was in fact fixed it must have been VERY recently (i. e. ~ this week) if the fix hasn't even made it to Neon unstable yet. -- 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 #44 from Hans-Peter Jansen --- Here's a feature request for wayland: https://bugs.kde.org/show_bug.cgi?id=459034. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 459034] New: Implement shaded window feature
https://bugs.kde.org/show_bug.cgi?id=459034 Bug ID: 459034 Summary: Implement shaded window feature Product: kwin Version: master Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: wayland-generic Assignee: kwin-bugs-n...@kde.org Reporter: h...@urpla.net Target Milestone: --- In order to not disrupt long term users, and to create further momentum for switching to wayland, I kindly ask for implementation of the window shaded feature similar to what we have in X11. X11 does manage a boolean (toggle) flag called SHADED. If active, the window is drawn with the window content height set to zero. The window geometry isn't affected from this flag, and as such, such a window could be persisted in the session handling. After session restart, such a window is restored with its original size, but again, the screen representation is restored with height zero. The popularity of https://bugs.kde.org/show_bug.cgi?id=450582 demonstrates, that a lot of long term users rely on this feature and again, such an implementation would be required to allow them to switch over to wayland without friction. -- You are receiving this mail because: You are watching all bug changes.
[kscreenlocker] [Bug 458848] New: Lock screen timer ignores pen input / screen is locked after writing with stylus and giving no other input for 5 minutes.
https://bugs.kde.org/show_bug.cgi?id=458848 Bug ID: 458848 Summary: Lock screen timer ignores pen input / screen is locked after writing with stylus and giving no other input for 5 minutes. Product: kscreenlocker Version: 5.25.4 Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: firlaevhans.fi...@protonmail.com CC: bhus...@gmail.com Target Milestone: --- SUMMARY I was writing something in Xournal++ with my stylus on my 2in1 laptop. While using the stylus, touchscreen input is rightfully ignored (so my hand resting on the screen does not count as touch input). When I didn't pan around or anything using the touchscreen for a little while, thus giving no other input besides the stylus, the screen locker suddenly came on. The five-second-rule for unlocking without a password also only worked when I touched the screen and not when tapping it with the stylus. This has happened twice today and it's getting a bit annoying. STEPS TO REPRODUCE 1. Be on a 2in1 with a stylus (a wacom tablet may work too) 2. (Optional, but recommended for testing): Set the lock screen timeout to the lowest possible value (1 minute) 3. Just use the stylus for a minute without giving any other input (i. e. don't touch the screen (with fingers), keyboard or mouse) (4. When the lock screen appears, tap it with the stylus, then with your fingers, within five seconds) OBSERVED RESULT The lock screen appears despite actively using the computer with a stylus. Once it appears, using the stylus also won't unlock it within the short no-password-period. EXPECTED RESULT Stylus input should be considered input by kscreenlocker, just like keyboard, mouse and touchscreen. SOFTWARE/OS VERSIONS Operating System: Fedora Linux 36 KDE Plasma Version: 5.25.4 KDE Frameworks Version: 5.97.0 Qt Version: 5.15.5 Kernel Version: 5.19.6-200.fc36.x86_64 (64-bit) Graphics Platform: Wayland System Version: Lenovo IdeaPad C340-14API -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 458063] KDE Connect clipboard sharing syncs passwords copied from password managers
https://bugs.kde.org/show_bug.cgi?id=458063 --- Comment #4 from Firlaev-Hans --- (In reply to Nicolas Fella from comment #3) > I did implement that a while ago, but ironically people complained that they > *do* want to sync their passwords :) > > https://invent.kde.org/network/kdeconnect-kde/-/merge_requests/39 Could it be made into an option then? Looking at the MR it seems like that was were the discussion was leading but nothing happened after that. I can definitely see valid points for both sides of the argument, but personally I don't like it when my passwords are visible in plain text in some other device's clipboard history (the thing is that I often have not only my phone, but also my other Linux PC connected via KDE Connect) -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 458063] KDE Connect clipboard sharing syncs passwords copied from password managers
https://bugs.kde.org/show_bug.cgi?id=458063 --- Comment #2 from Firlaev-Hans --- (In reply to David Edmundson from comment #1) > klipper does have a mechanism supported by some password managers were we > filter out any selection which contains a mimetype key > application/x-kde-passwordManagerHint Is that something that KDE Connect already filters out, that just isn't supported on the KeePassXC side? Or does KDE Connect still need to implement the filtering? -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 458063] New: KDE Connect clipboard sharing syncs passwords copied from password managers
https://bugs.kde.org/show_bug.cgi?id=458063 Bug ID: 458063 Summary: KDE Connect clipboard sharing syncs passwords copied from password managers Product: kdeconnect Version: 22.04.3 Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: common Assignee: albertv...@gmail.com Reporter: firlaevhans.fi...@protonmail.com Target Milestone: --- SUMMARY Also see https://www.reddit.com/r/kde/comments/ws99fn/can_i_make_kde_connect_ignore_copied_passwords/ Basically, I want to keep using the clipboard sync feature of KDE Connect, but unfortunately it means that passwords copied from my password manager will also be synced to the connected devices and, unlike on the machine they were copied from, won't be automatically deleted from their clipboards after 10 seconds. This is a pretty big security issue for anyone using both a PM and a synced clipboard. If there's a way KDE Connect could know where a clipboard item came from, it would be great if one could blacklist specific sources (like my Password manager KeepassXC) from being synced to other devices. STEPS TO REPRODUCE 1. Have a connected device via KDE Connect, with clipboard sharing enabled 2. Let your password manager copy something to the clipboard 3. Check the clipboard on the connected device OBSERVED RESULT The copied content (password) is synced to all other devices. On the "host" machine, password managers like KeepassXC will usually automatically delete the copied password from the clipboard after a few seconds. Also, even within those few seconds, the password doesn't show up in the Klipper history. But on all devices that KDE Connect syncs the clipboard to, the password is permanently added to the clipboard. EXPECTED RESULT If possible, KDE Connect should be able to have a blacklist of applications whose clipboard items will not be synced. Otherwise, it might be possible to get away with only syncing the actual Klipper history and not copied items that aren't added to the history (because KeepassXC passwords aren't, but manually copied stuff would be) SOFTWARE/OS VERSIONS Operating System: Fedora Linux 36 KDE Plasma Version: 5.25.4 KDE Frameworks Version: 5.96.0 Qt Version: 5.15.5 Kernel Version: 5.18.17-200.fc36.x86_64 (64-bit) Graphics Platform: Wayland -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 451631] [Wayland] Plasmashell freezes briefly after focusing the desktop if it was started with a non-empty clipboard history
https://bugs.kde.org/show_bug.cgi?id=451631 --- Comment #10 from Firlaev-Hans --- But 454379 appears to be the same issue and has some more information (basically, it also happens when instead of restarting plasmashell you close dolphin after copying a file). Also, I have found the criteria for reproducing this bug is not only that you need to have non-text items like files in your clipboard, these items must also be the top most item in the clipboard history. i. e. if you have a file in your clipboard but also copied text after that, the issue doesn't happen / stops happening. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 454379] plasmashell starts lagging after any file is copied from dolphin and dolphin is closed
https://bugs.kde.org/show_bug.cgi?id=454379 Firlaev-Hans changed: What|Removed |Added Status|REPORTED|CONFIRMED CC||firlaevhans.fiete@protonmai ||l.com Ever confirmed|0 |1 --- Comment #5 from Firlaev-Hans --- Could this be a duplicate of Bug 451631 ? In that bug report I discovered that essentially the same thing happens not when closing dolphin but rather after restarting plasmashell (including by just rebooting or logging out and back in) when the top most item in the clipboard is a file. But I can confirm that closing dolphin instead of restarting Plasma produces the same results. Clearing the clipboard or copying text makes plasmashell responsive again in either case. Every time a slowdown happens, the following lines appear in the journal: >plasmashell[1756]: QWaylandDataOffer: timeout reading from pipe >plasmashell[1756]: QWaylandDataOffer: error reading data for mimeType >application/x-kde-cutselection But regarding what John described >For me, using Kubuntu 21.10 on a BTRFS+Zstd partition and latest KDE Plasma >from Kubuntu's backports PPA, >I've seen KDE Plasma many times becoming very slow and even unresponsive to >the point that everything freezes >with heavy IO operations like copying many folders and files or extracting >archives. I believe that is a different issue. I encountered that at some point as well when I copied hundreds of gigabytes to an external HDD, but I think that's some KIO issue that causes a total freeze, rather than this issue which seems to be the clipboards fault and only causes brief slowdowns. -- 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 #41 from Hans-Peter Jansen --- (In reply to David Edmundson from comment #40) > >Do I need to open a new one? > > Yeah. Done: https://bugs.kde.org/show_bug.cgi?id=457487 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 457487] New: After fixing the shaded/shuttered window feature, restarting kwin_x11 --replace forgets the shaded window sizes
https://bugs.kde.org/show_bug.cgi?id=457487 Bug ID: 457487 Summary: After fixing the shaded/shuttered window feature, restarting kwin_x11 --replace forgets the shaded window sizes Product: kwin Version: 5.24.3 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kwin-bugs-n...@kde.org Reporter: h...@urpla.net Target Milestone: --- Created attachment 15 --> https://bugs.kde.org/attachment.cgi?id=15=edit Tiny title bar objects after kwin restart After Vlad Zahorodnii fixed bko#450582 with https://invent.kde.org/plasma/kwin/-/commit/1c5215009865c20b18c0f3114b167080cd70a33a restarting kwin with `kwin_x11 --replace` forgets the shaded window sizes, defaulting to the minimum size of the original window, and just a tiny object in shaded state (see attached screenshot). Reproduce: Install a kwin_x11 version including the fix mentioned above. Change window behaviour: title bar double click action to "Shade", and change the window border size to Normal in window decorations. Double-click a window (memorize the original size): it will shade (only the title bar is visible now, with the original width). Restart kwin. The bar is reduced to a tiny object (depending on border size). Operating System: openSUSE Tumbleweed 20220719 KDE Plasma Version: 5.25.3 KDE Frameworks Version: 5.96.0 Qt Version: 5.15.5 Kernel Version: 5.18.12-2-preempt (64-bit) Graphics Platform: X11 Processors: 24 × AMD Ryzen 9 3900X 12-Core Processor Memory: 62.4 GiB of RAM Graphics Processor: NVIDIA GeForce RTX 3060/PCIe/SSE2 Manufacturer: ASUS kwin5-5.25.3git.20220718T142626~61b1eac5-189.1.x86_64 -- 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 #39 from Hans-Peter Jansen --- Why is it not possible to reopen bugs? Do I need to open a new one? -- 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 #38 from Hans-Peter Jansen --- Created attachment 150847 --> https://bugs.kde.org/attachment.cgi?id=150847=edit Shaded windows after a forceful kwin restart with kwin_x11 --replace. -- 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 #37 from Hans-Peter Jansen --- Hi Vlad, unfortunately I have to report, that your fix doesn't fully fix this issue. In order to reproduce, please shade some windows, and restart: kwin_x11 --replace. The result here is, that windows a reduced to the tiniest size I ever saw for a window (screenshot attached below). I'm not allowed to reopen this issue. -- 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 #35 from Hans-Peter Jansen --- @Duncan: nice sum up. Of course, we also need to take session management into account. The X11 protocol does provide the shaded flag for this task. I even hacked a related tool to handle my firefox setup. FF failed to handle the geometry and shaded state for some time: https://github.com/frispete/wm-win-tool -- 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 #33 from Hans-Peter Jansen --- @Audience: offensive language does not help anyone here. It only leads to worsening the situation as non-technical aspects come to the fore. Hi Vlad, > However, given how buggy window shading is and how difficult it is to make it > work right, I think that it's better to deprecate window > shading and remove it in some future release. Please, don't. Repeating here, what I wrote in the merge request already: There are a lot of users out there, that depend on it. Hard. Those, that I know of, used to work with KDE since the early 2000s. Well, personally, I'm using KDE as my main desktop since ~1999, doing all kinds of administration, development, and support work whole day long. So, during the last 23 years, I probably had less than 50 days not using a KDE desktop somehow (self-employed, you know..). And that legacy turned into strong habits, that most of us won't get rid of, because they use it for their own advantage. My workflows and desktop organization is so entangled with this feature, that I cannot *even* switch to Wayland unless Wayland will provide a similar feature on its own. It's also one of those features, that sets us apart. It might not be the nicest thing in the world implementationwise, but I'm immensely grateful, that you fixed it! As a reminder: as far as I know, the Wayland protocol has no such concept of shaded/shuttered windows. Therefore, preserving this feature in the longer term would, in my humble view, require that such an option be considered in the Wayland protocol itself. If anyone has more information on this topic, please let me know. Thank you! -- 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 #28 from Hans-Peter Jansen --- Hi Vlad, I hereby confirm, that your commit fixed the issue in the first tests (I built kwin as of 61b1eac5b against 5.25.3 here: https://build.opensuse.org/package/show/home:frispete:Tumbleweed:testing/kwin5) Thanks a lot! Much appreciated. Will update my primary system to this kwin version and give it some hard knocks! -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 456039] 5.25.1 "shading" a gtk window continues to display the window's contents
https://bugs.kde.org/show_bug.cgi?id=456039 --- Comment #11 from Hans-Peter Jansen --- FTR, my build is available here: https://build.opensuse.org/package/show/home:frispete:Tumbleweed/kwin5 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 456039] 5.25.1 "shading" a gtk window continues to display the window's contents
https://bugs.kde.org/show_bug.cgi?id=456039 --- Comment #10 from Hans-Peter Jansen --- (In reply to Rob from comment #9) > This appears resolved now in 5.25.2? If you agree @hpj I will close as > fixed. Thanks for the note, Rob. I've disabled my revert in the relevant build, but it takes a while to get this tested on my system zoo (because I and couple of others, that I infected with the Tumbleweed virus rely heavily on operational systems to do our day to day work). I restored a system backup on my primary workstation two times already related to this issue. -- You are receiving this mail because: You are watching all bug changes.
