[drkonqi] [Bug 484073] The items in list of "packages containing debug information for the following application and libraries are missing" cannot be copypasted due to extra newlines inserted into the
https://bugs.kde.org/show_bug.cgi?id=484073 Alain Knaff changed: What|Removed |Added Resolution|NOT A BUG |INTENTIONAL --- Comment #2 from Alain Knaff --- (In reply to Harald Sitter from comment #1) > You should look into debuginfod. too complicated. > Copy pasting around lines to construct > commands is not a feature we support. Well, where drkonqi sits, it could abuse the user's trust in a much worse fashion than by injecting malicious stuff into copy-pasted text. So I don't see the point in wanting to "teach the user a lesson" here. De-installed. -- You are receiving this mail because: You are watching all bug changes.
[drkonqi] [Bug 484073] New: The items in list of "packages containing debug information for the following application and libraries are missing" cannot be copypasted due to extra newlines inserted int
https://bugs.kde.org/show_bug.cgi?id=484073 Bug ID: 484073 Summary: The items in list of "packages containing debug information for the following application and libraries are missing" cannot be copypasted due to extra newlines inserted into the pasted text Classification: Applications Product: drkonqi Version: git-stable-Plasma/5.27 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: backtraceparsing Assignee: plasma-b...@kde.org Reporter: k...@kde.lka.org.lu 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. run an application that triggers a crash (but without having all its *-dev installed) 2. click through drkonqi until you read the "Fetching the Backtrace" screen 3. Click on "list of files" 4. triple click on one of the lines 5. type "dpkg -S " into a terminal 6. attempt to paste line into terminal OBSERVED RESULT instead of pasting just the line, a newline character is inserted before *and* after, thus submitting "dpkg -S" on its own, and then the package name on its own to the shell, where a single command was intended N.B. the preceding newline character is inserted even when selecting part of the line, such as skipping the leading slash, by dragging the mouse over it (at step 4) EXPECTED RESULT No extra newlines should be inserted, *especially* when only selecting part of a line. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 483678] Signing with Luxtrust's non-repudiation certificate just hangs
https://bugs.kde.org/show_bug.cgi?id=483678 --- Comment #8 from Alain Knaff --- (In reply to Albert Astals Cid from comment #7) > "Just called Luxtrust about this, they claimed that there was only one > certificate on the card." > > Well, NSS disagrees if firefox shows 2, not much we can do here really. Exactly, they _claimed_ ... :-) In the meantime, I got nss3 patched to get the signature working. It was a deadlock: the non-working certificate was a "non-repudiation" certificate which required 2 pin entries (same PIN, but needed to be re-entered again). While signing, NSS acquires a lock to the card slot, and then calls PK11_DoPassword to prompt for the "second" password. But unfortunately, PK11_DoPassword then tries to re-acquire the same lock a second time => which causes the block. However, even after fixing this, okular still doesn't work. Now, okular does pop up a password prompt for password re-entry, but this prompt returns control immediately to the code, even while the dialog box is still showing (as far as I can see, it returns an empty password). The password entered by the user is ignored, and the prompt keeps appearing. Commenting out the second call to PK11_DoPassword in NSS altogether allows signature to proceed. Of course, the card (or its pkcs11 module) notices that the second password was never entered, so now the pkcs11 module pops up its own password prompt via an X connection that it opened up itself. And that finally works. => I think this points to a threading issue within okular (or poppler?): SEC_SignData is not really supposed to be called from the thread handling the GUI. Indeed, this not only freezes the GUI while it does its calculation (or forever, in the case of a deadlock), but it also becomes iffy if it needs to call the GUI itself. There is no "clean" way for it to get back to the X client event loop to wait for password entry, and so has no other choice than return an empty password as soon as the box is up. Usually long operations, or operations that could potentially block, are supposed to be run from another thread than the thread handling the GUI. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 483678] Signing with Luxtrust's non-repudiation certificate just hangs
https://bugs.kde.org/show_bug.cgi?id=483678 --- Comment #6 from Alain Knaff --- (In reply to Albert Astals Cid from comment #5) > (In reply to Alain Knaff from comment #4) > > I now wanted to try whether it works better with gpg, but I couldn't find > > how to switch to gpg. > > > > In Settings->ConfigureBackends->PDF, it seems to assume NSS, and there is no > > switch to use GPG > > > > Or is this in an entirely different place in settings? If so, where? > > It's there, i see you're probably using a too old version of okular/poppler > for it to show up. I retried with okular 23.08.1 from Debian testing, and with a poppler that I compiled myself (24.03.0), and GPG still didn't show up :-( > > How many certificates do you get shown in Firefox->Own certificates > preferences page? I see 3 certificates: the 2 from the smartcard, and an old expired software CA cert that I happened to have lying around -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 483678] Signing with Luxtrust's non-repudiation certificate just hangs
https://bugs.kde.org/show_bug.cgi?id=483678 --- Comment #4 from Alain Knaff --- I now wanted to try whether it works better with gpg, but I couldn't find how to switch to gpg. In Settings->ConfigureBackends->PDF, it seems to assume NSS, and there is no switch to use GPG Or is this in an entirely different place in settings? If so, where? -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 483678] Signing with Luxtrust's non-repudiation certificate just hangs
https://bugs.kde.org/show_bug.cgi?id=483678 --- Comment #3 from Alain Knaff --- NSS -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 483678] Signing with Luxtrust's non-repudiation certificate just hangs
https://bugs.kde.org/show_bug.cgi?id=483678 Alain Knaff changed: What|Removed |Added Ever confirmed|0 |1 Status|REPORTED|CONFIRMED --- Comment #1 from Alain Knaff --- Just called Luxtrust about this, they claimed that there was only one certificate on the card. => so the problem seems to be that okular is listing certificates which should not be used. Remark about going into a hang, rather than popping up a clear message still stands. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 483678] New: Signing with Luxtrust's non-repudiation certificate just hangs
https://bugs.kde.org/show_bug.cgi?id=483678 Bug ID: 483678 Summary: Signing with Luxtrust's non-repudiation certificate just hangs Classification: Applications Product: okular Version: 22.12.2 Platform: Debian stable OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: PDF backend Assignee: okular-de...@kde.org Reporter: k...@kde.lka.org.lu 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. Connect Smart card reader with Luxtrust card to computer 2. View PDF form using okular 3. Click "show signatures panel" 4. In signatures panel, right click and chose sign 5. When asked, enter smart card's PIN 6. Chose LuxTrusV5: User Cert Sig (i.e. the certificate for "Non Repudiation" rather than "Digital Signature, Encrypt Keys" 7. Click Ok OBSERVED RESULT okular just freezes :-( okular's UI no longer refreshes, and okular needs to be killed with Control-C No diagnostic on stdout/stderr (except unrelated "evaluate() threw an exception" due to "This PDF file requires a newer version of Adobe Acrobat Reader DC." popup at document load) EXPECTED RESULT It should sign the document and allow me to save it. Or if not possible / allowed, plainly state why in a popup. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) menu item not present KDE Plasma Version: 142 KDE Frameworks Version: 5.103.0 Qt Version: 5.15.8 ADDITIONAL INFORMATION - Signing using the second certificate on the same smartcard works just fine - Signing using a PKCS12 certificate (file-based, rather than card) just works fine too -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 245478] "New Tab" menu opens a list with only one item
https://bugs.kde.org/show_bug.cgi?id=245478 Alain Knaff changed: What|Removed |Added Version|2.5 |22.12.3 -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 245478] "New Tab" menu opens a list with only one item
https://bugs.kde.org/show_bug.cgi?id=245478 Alain Knaff changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #13 from Alain Knaff --- Still (again) an issue in 22.12.3 Now File->NewTab opens a menu with a single item "Built-in" If Built-in is customized by user, it opens a menu with *2* items: the original "Built-in" and a second item with the users' customizations. Both cases are wrong. In the second case, the users' customizations should overwrite and completely hide the original Built-in, and still not cause that submenu to appear. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 472548] Konsole is very slow to perform a title bar / tab bar update
https://bugs.kde.org/show_bug.cgi?id=472548
--- Comment #1 from Alain Knaff ---
I started investigating this in more detail, and here is what I found:
1. Session::setSessionAttribute gets invoked as soon as the ANSI sequence is
received.
2. Session::setSessionAttribute copies the "caption" method parameter to the
_userTitle object attribute, and sets local variable modified to true (if title
did indeed change)
3. Near the end, it emits sessionAttributeChanged() if modified
4. SessionController::sessionAttributeChanged() indeed activates immediately
(good), and attempts to set the title using ViewProperties::setTitle
5. However, it gets the "wrong" title to set. In step #2, session._userTitle
was set, however, sessionAttributeChanged() gets session._displayName (via
session()->title(Session::DisplayedTitleRole);)
6. 2 seconds later, _userTitle gets copied over to _displayTitle by
Session::setTitle, and ViewProperties::setTitle gets invoked again, and this
time succeeds in setting the correct (i.e. new) title.
=> The immediate invocation of step #4 shows that there is indeed an intent to
perform the title update promptly. However, step #6 (or equivalent) should be
invoked before it as well.
The following patch is a stop-gap measure which fixes the issue:
--- konsole-orig/konsole-22.12.3/src/session/Session.cpp2023-02-27
05:02:33.0 +0100
+++ konsole-22.12.3/src/session/Session.cpp 2023-07-25 22:03:35.518283329
+0200
@@ -537,6 +537,7 @@
if ((what == IconNameAndWindowTitle) || (what == WindowTitle)) {
if (_userTitle != caption) {
_userTitle = caption;
+_displayTitle = caption;
modified = true;
}
}
--
You are receiving this mail because:
You are watching all bug changes.
[konsole] [Bug 472548] New: Konsole is very slow to perform a title bar / tab bar update
https://bugs.kde.org/show_bug.cgi?id=472548
Bug ID: 472548
Summary: Konsole is very slow to perform a title bar / tab bar
update
Classification: Applications
Product: konsole
Version: 22.12.3
Platform: Debian stable
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: konsole-de...@kde.org
Reporter: k...@kde.lka.org.lu
Target Milestone: ---
SUMMARY
Konsole waits almost 2 secods after receiving an ANSI sequence to change its
title until it actually pushes that change to the X server
STEPS TO REPRODUCE
1. echo -ne '\033]0;test\007'
OBSERVED RESULT
it takes almost 2 seconds before tab name and title bar is updated to "test"
EXPECTED RESULT
it should update the tab bar and title bar immediately
ADDITIONAL INFORMATION
Strace shows the following:
80262 22:02:28.488754 ioctl(24, FIONREAD, [9]) = 0
80262 22:02:28.488918 read(24, "\33]0;test\7", 9) = 9
80262 22:02:28.489073 recvmsg(11, {msg_namelen=0}, 0) = -1 EAGAIN (Resource
temporarily unavailable)
80262 22:02:28.489205 recvmsg(11, {msg_namelen=0}, 0) = -1 EAGAIN (Resource
temporarily unavailable)
80262 22:02:28.489291 poll([{fd=5, events=POLLIN}, {fd=10, events=POLLIN},
{fd=11, events=POLLIN}, {fd=15, events=POLLIN}, {fd=24, events=POLLIN}, {fd=34,
events=POLLIN}], 6, 10) = 0 (Timeout)
80262 22:02:28.499665 recvmsg(11, {msg_namelen=0}, 0) = -1 EAGAIN (Resource
temporarily unavailable)
80262 22:02:28.499815 recvmsg(11, {msg_namelen=0}, 0) = -1 EAGAIN (Resource
temporarily unavailable)
80262 22:02:28.499902 poll([{fd=5, events=POLLIN}, {fd=10, events=POLLIN},
{fd=11, events=POLLIN}, {fd=15, events=POLLIN}, {fd=24, events=POLLIN}, {fd=34,
events=POLLIN}], 6, 10) = 0 (Timeout)
80262 22:02:28.510193 recvmsg(11, {msg_namelen=0}, 0) = -1 EAGAIN (Resource
temporarily unavailable)
80262 22:02:28.510320 recvmsg(11, {msg_namelen=0}, 0) = -1 EAGAIN (Resource
temporarily unavailable)
80262 22:02:28.510764 poll([{fd=5, events=POLLIN}, {fd=10, events=POLLIN},
{fd=11, events=POLLIN}, {fd=15, events=POLLIN}, {fd=24, events=POLLIN}, {fd=34,
events=POLLIN}], 6, 1891) = 0 (Timeout)
80262 22:02:30.403850 ioctl(24, TIOCGPGRP, [80312]) = 0
80262 22:02:30.403957 ioctl(24, TIOCGPGRP, [80312]) = 0
80262 22:02:30.404046 readlink("/proc/80312/cwd", "/home/alain", 4096) = 11
80262 22:02:30.404196 poll([{fd=3, events=POLLIN|POLLOUT}], 1, -1) = 1 ([{fd=3,
revents=POLLOUT}])
80262 22:02:30.404290 writev(3,
[{iov_base="\22\0\n\0\r\0\0\6Y\1\0\0J\1\0\0\10\0\0\0\20\0\0\0test \342\200\224
Konsole", iov_len=40}], 1) = 40
So, basically, it sits on its handsfor two seconds, before finally pushing the
update to the X server...
--
You are receiving this mail because:
You are watching all bug changes.
[digikam] [Bug 457603] After saving a picture, keyboard becomes unresponsive until something is done with the mouse
https://bugs.kde.org/show_bug.cgi?id=457603 --- Comment #11 from Alain Knaff --- Problem still occurs with version 7.9.0 as included in Debian 12 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 457605] On large collections digikam often freezes for seconds with 100% CPU while paging through images
https://bugs.kde.org/show_bug.cgi?id=457605 Alain Knaff changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 457605] On large collections digikam often freezes for seconds with 100% CPU while paging through images
https://bugs.kde.org/show_bug.cgi?id=457605 --- Comment #23 from Alain Knaff --- Problems seems to no longer happen on 7.9.0 as included in Debian 12. Or at least not when just paging through the images, as happened before. Thanks -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 471163] Konsole has a mysterious extra scrollbar at left hand side which behaves erratically
https://bugs.kde.org/show_bug.cgi?id=471163 --- Comment #2 from Alain Knaff --- Thanks for your fast reply... but where exactly can I disable this extra scrollbar? -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 471163] New: Konsole has a mysterious extra scrollbar at left hand side which behaves erratically
https://bugs.kde.org/show_bug.cgi?id=471163 Bug ID: 471163 Summary: Konsole has a mysterious extra scrollbar at left hand side which behaves erratically Classification: Applications Product: konsole Version: 22.12.3 Platform: Debian stable OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: konsole-de...@kde.org Reporter: k...@kde.lka.org.lu Target Milestone: --- Since upgrading to Debian 12, konsole has an extra "scrollbar" at the left hand side. It's a thin purple line, it moves up when scrolling up, and down when scrolling down, but by a random amount. Which means it will be stuck near the top even long before reaching the top of the scrollback buffer. It doesn't seem to follow the "application style" setting either. The normal scrollbar at the right hand side is there too, behaves normally, and follows application style. Is this intentional, or is it a graphics artifact? -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 441803] Konsole does not allow to change default profile, but creates new profile instead, leading to cumbersome "New Tab" workflow
https://bugs.kde.org/show_bug.cgi?id=441803 Alain Knaff changed: What|Removed |Added Version|20.12.3 |22.12.3 -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 441803] Konsole does not allow to change default profile, but creates new profile instead, leading to cumbersome "New Tab" workflow
https://bugs.kde.org/show_bug.cgi?id=441803 --- Comment #5 from Alain Knaff --- The bug re-appeared in konsole 22.12.3 as shipped with Debian 12. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 465109] New: Gwenview freezes with strange dialog when attempting to view images in 2 same-named directories
https://bugs.kde.org/show_bug.cgi?id=465109 Bug ID: 465109 Summary: Gwenview freezes with strange dialog when attempting to view images in 2 same-named directories Classification: Applications Product: gwenview Version: 20.12.3 Platform: Debian stable OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: gwenview-bugs-n...@kde.org Reporter: k...@kde.lka.org.lu 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. Set up the following directory structure: mkdir -p circle/sub mkdir -p rect/sub 2. Put an image of a circle into circle/sub and an image of a rectange into rect/sub 3. Attempt to view both directories in gwenview: gwenview circle/sub rect/sub OBSERVED RESULT Gwenview pops up a weird dialogue "File already exists" showing the thumbnails of both files overlaid on a folder icon. Dialogue is not actually responsive, i.e. clicking anywhere on it does nothing. Even attempting to close it using the cross in titlebar does nothing KDE pops up 2 notifications "Gwenview Coying (Failed) Application closed unexpectedly." and "Gwenview Copying 2 files to /tmp/gwenview-JZONlr" with a progressbar oscillating left to right. At this point, gwenview and its dialogue can only be closed using Ctrl-C or kill. EXPECTED RESULT It should just show the images in both directories, just as if the 2 subdirectories had different names SOFTWARE/OS VERSIONS Linux/KDE Plasma: (available in About System) about System *where*? KDE Plasma Version: 4:5.20.5-4 KDE Frameworks Version: 5.78.0-3 Qt Version: 5.15.2-5 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 427278] Panel & desktop config of secondary monitor lost after ScreenConnectors renumbering
https://bugs.kde.org/show_bug.cgi?id=427278 --- Comment #23 from Alain Knaff --- It looks as if the problem happens much less often when checking the box "Save display's properties: For any display arrangement" in SystemSettings->Hardware->"Display and Monitor"->"Display Configuration" -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 457605] On large collections digikam often freezes for seconds with 100% CPU while paging through images
https://bugs.kde.org/show_bug.cgi?id=457605 --- Comment #20 from Alain Knaff --- (In reply to Maik Qualmann from comment #19) > When you run the ExifTool command, what error code do you get afterwards? > > exiftool -l -listr > echo $? > > Maik I get 0: > exiftool -l -listr ; echo $? ... XMP Extensible Metadata Platform ZIP ZIP archive 0 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 457605] On large collections digikam often freezes for seconds with 100% CPU while paging through images
https://bugs.kde.org/show_bug.cgi?id=457605 --- Comment #16 from Alain Knaff --- Created attachment 151178 --> https://bugs.kde.org/attachment.cgi?id=151178=edit Debug output with QT_LOGGING_RULES="digikam*=true" -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 457605] On large collections digikam often freezes for seconds with 100% CPU while paging through images
https://bugs.kde.org/show_bug.cgi?id=457605 --- Comment #14 from Alain Knaff --- (In reply to Maik Qualmann from comment #13) > Which output do you see with: > > exiftool -l -listr > > Maik > exiftool -l -listr Recognized file extensions: 360 GoPro 360 video 3FR Hasselblad RAW format 3G2 3rd Gen. Partnership Project 2 audio/video 3GP 3rd Gen. Partnership Project audio/video 3GP23rd Gen. Partnership Project 2 audio/video 3GPP3rd Gen. Partnership Project audio/video A Static library AA Audible Audiobook AAE Apple edit information AAX Audible Enhanced Audiobook ACFMAdobe Composite Font Metrics ACR American College of Radiology ACR-NEMA AFM Adobe Font Metrics AI Adobe Illustrator AIF Audio Interchange File Format AIFCAudio Interchange File Format Compressed AIFFAudio Interchange File Format AIT Adobe Illustrator ALIAS MacOS file alias AMFMAdobe Multiple Master Font Metrics APE Monkey's Audio format APNGAnimated Portable Network Graphics ARQ Sony Alpha Pixel-Shift RAW format ARW Sony Alpha RAW format ASF Microsoft Advanced Systems Format AVC Advanced Video Connection AVI Audio Video Interleaved AVIFAV1 Image File Format AZW Mobipocket electronic book AZW3Mobipocket electronic book BMP Windows Bitmap BPG Better Portable Graphics BTF Big Tagged Image File Format BZ2 BZIP2 archive CHM Microsoft Compiled HTML format CIFFCamera Image File Format COS Capture One Settings CR2 Canon RAW 2 format CR3 Canon RAW 3 format CRM Canon RAW Movie CRW Canon RAW format CS1 Sinar CaptureShop 1-Shot RAW CSV Comma-Separated Values CZI Zeiss Integrated Software RAW DC3 Digital Imaging and Communications in Medicine DCM Digital Imaging and Communications in Medicine DCP DNG Camera Profile DCR Kodak Digital Camera RAW DCX Multi-page PC Paintbrush DEX Dalvik Executable format DFONT Macintosh Data fork Font DIB Device Independent Bitmap DIC Digital Imaging and Communications in Medicine DICMDigital Imaging and Communications in Medicine DIVXDivX media format DJV DjVu image DJVUDjVu image DLL Windows Dynamic Link Library DNG Digital Negative DOC Microsoft Word Document DOCMOffice Open XML Document Macro-enabled DOCXOffice Open XML Document DOT Microsoft Word Template DOTMOffice Open XML Document Template Macro-enabled DOTXOffice Open XML Document Template DPX Digital Picture Exchange DR4 Canon VRD version 4 Recipe DS2 Digital Speech Standard 2 DSS Digital Speech Standard DV Digital Video DVB Digital Video Broadcasting DVR-MS Microsoft Digital Video recording DWF Autodesk drawing (Design Web Format) DWG AutoCAD Drawing DYLIB Mach-O Dynamic Link Library EIP Capture One Enhanced Image Package EPS Encapsulated PostScript Format EPS2Encapsulated PostScript Format EPS3Encapsulated PostScript Format EPSFEncapsulated PostScript Format EPUBElectronic Publication ERF Epson Raw Format EXE Windows executable file EXIFExchangable Image File Metadata EXR Open EXR EXV Exiv2 metadata F4A Adobe Flash Player 9+ Audio F4B Adobe Flash Player 9+ audio Book F4P Adobe Flash Player 9+ Protected F4V Adobe Flash Player 9+ Video FFF Hasselblad Flexible File Format FIT Flexible Image Transport System FITSFlexible Image Transport System FLA Macromedia/Adobe Flash project FLACFree Lossless Audio Codec FLIFFree Lossless Image Format FLIRFLIR File Format FLV Flash Video FPF FLIR Public image Format FPX FlashPix GIF Compuserve Graphics Interchange Format GPR GoPro RAW GZ GNU ZIP compressed archive GZIPGNU ZIP compressed archive HDP Windows HD Photo HDR Radiance RGBE High Dynamic Range HEICHigh Efficiency Image Format still image HEIFHigh Efficiency Image Format HIF High Efficiency Image Format HTM HyperText Markup Language HTMLHyperText Markup Language ICALiCalendar Schedule ICC International Color Consortium ICM International Color Consortium ICS iCalendar Schedule IDMLAdobe InDesign Markup Language IIQ
[digikam] [Bug 457605] On large collections digikam often freezes for seconds with 100% CPU while paging through images
https://bugs.kde.org/show_bug.cgi?id=457605 --- Comment #12 from Alain Knaff --- (In reply to Maik Qualmann from comment #11) > That was this Bug 454656, can you reproduce the locale error message with > ExifTool? > > Maik I'm not sure I understand what I'm supposed to do here. So I uninstalled libimage-exiftool-perl, and tried to start digikam again, but the segfault still happens as soon as I attempt to open configuration. Initially, I had my own locales set (crash happened), then I had removed all of them (crash still happened), and then I just set the following (crash still happens): LANG=en_US.UTF8 LC_ALL=en_US.UTF8 Then I tried: LANG=en_US LC_ALL=en_US but crash still happened -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 457603] After saving a picture, keyboard becomes unresponsive until something is done with the mouse
https://bugs.kde.org/show_bug.cgi?id=457603 --- Comment #9 from Alain Knaff --- I had a look at the save confirmation window using xprop, and I noticed that it had its WM_TRANSIENT_FOR property set pointing to digikam's *main* window, rather than to the ImageEditor window. Could that be what is confusing kwin? WM_TRANSIENT_FOR(WINDOW): window id # 0x4e0001f -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 457605] On large collections digikam often freezes for seconds with 100% CPU while paging through images
https://bugs.kde.org/show_bug.cgi?id=457605 --- Comment #9 from Alain Knaff --- (In reply to Maik Qualmann from comment #8) > No "--" > > Maik So now I've got a trace: :-) > ./digiKam-7.8.0-20220729T111547-x86-64-debug.appimage --debug -- digiKam Linux AppImage Bundle -- Use 'help' as CLI argument to know all available options for digiKam application. -- Notes: to integrate this bundle to your desktop, use AppImageLauncher. --to enable all debug messages on the console, use 'export QT_LOGGING_RULES="digikam*=true"'. -- Detected host Linux -64- -- AppImage mounted directory: /tmp/.mount_digiKapU7M9F Check library libudev.so.0 Check library libxcb-dri3.so.0 Check library libcrypto.so.1.1 Check library libssl.so.1.1 Check library libnss3.so Check library libnssutil3.so Check library libsmime3.so Check library libpango-1.0.so.0 Check library libpangocairo-1.0.so.0 Check library libgmodule-2.0.so.0 -- Preloading shared libs: :/tmp/.mount_digiKapU7M9F/usr/lib/libavif.so.13:/usr/lib/x86_64-linux-gnu/libxcb-dri3.so.0:/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1:/usr/lib/x86_64-linux-gnu/libssl.so.1.1:/usr/lib/x86_64-linux-gnu/libnss3.so:/usr/lib/x86_64-linux-gnu/libnssutil3.so:/usr/lib/x86_64-linux-gnu/libsmime3.so:/usr/lib/x86_64-linux-gnu/libpango-1.0.so.0:/usr/lib/x86_64-linux-gnu/libpangocairo-1.0.so.0:/usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0 digikam: Unknown option 'debug'. > ./digiKam-7.8.0-20220729T111547-x86-64-debug.appimage debug -- digiKam Linux AppImage Bundle -- Use 'help' as CLI argument to know all available options for digiKam application. -- Notes: to integrate this bundle to your desktop, use AppImageLauncher. --to enable all debug messages on the console, use 'export QT_LOGGING_RULES="digikam*=true"'. -- Detected host Linux -64- -- AppImage mounted directory: /tmp/.mount_digiKaZJSEGd Check library libudev.so.0 Check library libxcb-dri3.so.0 Check library libcrypto.so.1.1 Check library libssl.so.1.1 Check library libnss3.so Check library libnssutil3.so Check library libsmime3.so Check library libpango-1.0.so.0 Check library libpangocairo-1.0.so.0 Check library libgmodule-2.0.so.0 -- Preloading shared libs: :/tmp/.mount_digiKaZJSEGd/usr/lib/libavif.so.13:/usr/lib/x86_64-linux-gnu/libxcb-dri3.so.0:/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1:/usr/lib/x86_64-linux-gnu/libssl.so.1.1:/usr/lib/x86_64-linux-gnu/libnss3.so:/usr/lib/x86_64-linux-gnu/libnssutil3.so:/usr/lib/x86_64-linux-gnu/libsmime3.so:/usr/lib/x86_64-linux-gnu/libpango-1.0.so.0:/usr/lib/x86_64-linux-gnu/libpangocairo-1.0.so.0:/usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0 Starting digiKam into GDB... Use 'bt' command on debugger prompt to get a crash backtrace. Use 'q' command to quit debugger session. gdb: /tmp/.mount_digiKaZJSEGd/usr/lib/liblber-2.4.so.2: no version information available (required by /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4) gdb: /tmp/.mount_digiKaZJSEGd/usr/lib/liblber-2.4.so.2: no version information available (required by /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2) GNU gdb (Debian 10.1-1.7) 10.1.90.20210103-git Copyright (C) 2021 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from digikam... Starting program: /tmp/.mount_digiKaZJSEGd/usr/bin/digikam [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [New Thread 0x7fffe1a04700 (LWP 331893)] [New Thread 0x7fffe0fb1700 (LWP 331894)] [New Thread 0x7fffd42c1700 (LWP 331895)] [New Thread 0x7fffd3ac0700 (LWP 331896)] [New Thread 0x7fffd32bf700 (LWP 331897)] [New Thread 0x7fffd2abe700 (LWP 331898)] [New Thread 0x7fffd22bd700 (LWP 331899)] [New Thread 0x7fffd1abc700 (LWP 331900)] [New Thread 0x7fffd12bb700 (LWP 331901)] [New Thread 0x7fffd0aba700 (LWP 331902)] [New Thread 0x7fffabfff700 (LWP 331903)] [New Thread 0x7fffab7fe700 (LWP 331904)] [New Thread 0x7fffaaffd700 (LWP 331905)] [New Thread 0x7fffaa7fc700 (LWP 331906)] [New Thread 0x7fffa9ffb700 (LWP 331907)] [New Thread 0x7fffa97fa700 (LWP 331908)] [New Thread 0x7fffa8ff9700 (LWP 331909)] [New Thread 0x7fff8bfff700 (LWP 331910)] [New Thread 0x7fff83fff700 (LWP 331911)] [New Thread 0x7fff8b7fe700 (LWP 331912)] [New Thread 0x7fff8affd700 (
[digikam] [Bug 457605] On large collections digikam often freezes for seconds with 100% CPU while paging through images
https://bugs.kde.org/show_bug.cgi?id=457605 --- Comment #7 from Alain Knaff --- (In reply to Maik Qualmann from comment #6) > Debug AppImage has an internal GDB, run the AppImage with the "debug" option. > > Maik Unfortunately, it doesn't have any such option :-( : > ./digiKam-7.8.0-20220729T111547-x86-64-debug.appimage --debug -- digiKam Linux AppImage Bundle -- Use 'help' as CLI argument to know all available options for digiKam application. -- Notes: to integrate this bundle to your desktop, use AppImageLauncher. --to enable all debug messages on the console, use 'export QT_LOGGING_RULES="digikam*=true"'. -- Detected host Linux -64- -- AppImage mounted directory: /tmp/.mount_digiKapU7M9F Check library libudev.so.0 Check library libxcb-dri3.so.0 Check library libcrypto.so.1.1 Check library libssl.so.1.1 Check library libnss3.so Check library libnssutil3.so Check library libsmime3.so Check library libpango-1.0.so.0 Check library libpangocairo-1.0.so.0 Check library libgmodule-2.0.so.0 -- Preloading shared libs: :/tmp/.mount_digiKapU7M9F/usr/lib/libavif.so.13:/usr/lib/x86_64-linux-gnu/libxcb-dri3.so.0:/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1:/usr/lib/x86_64-linux-gnu/libssl.so.1.1:/usr/lib/x86_64-linux-gnu/libnss3.so:/usr/lib/x86_64-linux-gnu/libnssutil3.so:/usr/lib/x86_64-linux-gnu/libsmime3.so:/usr/lib/x86_64-linux-gnu/libpango-1.0.so.0:/usr/lib/x86_64-linux-gnu/libpangocairo-1.0.so.0:/usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0 digikam: Unknown option 'debug'. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 457605] On large collections digikam often freezes for seconds with 100% CPU while paging through images
https://bugs.kde.org/show_bug.cgi?id=457605 --- Comment #5 from Alain Knaff --- (In reply to Alain Knaff from comment #3) > (In reply to Maik Qualmann from comment #1) > > Please test it with a more recent version, e.g. with the AppImage from here: > > > > https://files.kde.org/digikam/ > > > > However, make a backup of the databases if you want to go back to your old > > version. > > > > Maik > > Unfortunately when adding my full collection of photos to the appimage > version of digikam, it segfaults during scan, and eventually completes, but > then segfaults each time I try to go into configuration. Unfortunately, even > the debug version of the app image contains no debug symbols, so I can't > post a stacktrace. Actually, I just noticed, that segfault when going into configure also happens on my much smaller collection. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 457605] On large collections digikam often freezes for seconds with 100% CPU while paging through images
https://bugs.kde.org/show_bug.cgi?id=457605 --- Comment #4 from Alain Knaff --- (In reply to Alain Knaff from comment #3) > (In reply to Maik Qualmann from comment #1) > > Please test it with a more recent version, e.g. with the AppImage from here: > > > > https://files.kde.org/digikam/ > > > > However, make a backup of the databases if you want to go back to your old > > version. > > > > Maik > > Unfortunately when adding my full collection of photos to the appimage > version of digikam, it segfaults during scan, and eventually completes, but > then segfaults each time I try to go into configuration. Unfortunately, even > the debug version of the app image contains no debug symbols, so I can't > post a stacktrace. Here is still stderr output, in case it's useful: > ./digiKam-7.8.0-20220729T111547-x86-64-debug.appimage -- digiKam Linux AppImage Bundle -- Use 'help' as CLI argument to know all available options for digiKam application. -- Notes: to integrate this bundle to your desktop, use AppImageLauncher. --to enable all debug messages on the console, use 'export QT_LOGGING_RULES="digikam*=true"'. -- Detected host Linux -64- -- AppImage mounted directory: /tmp/.mount_digiKaCk0neh Check library libudev.so.0 Check library libxcb-dri3.so.0 Check library libcrypto.so.1.1 Check library libssl.so.1.1 Check library libnss3.so Check library libnssutil3.so Check library libsmime3.so Check library libpango-1.0.so.0 Check library libpangocairo-1.0.so.0 Check library libgmodule-2.0.so.0 -- Preloading shared libs: :/tmp/.mount_digiKaCk0neh/usr/lib/libavif.so.13:/usr/lib/x86_64-linux-gnu/libxcb-dri3.so.0:/usr/lib/x86_64-linux-gnu/libcrypto.so.1.1:/usr/lib/x86_64-linux-gnu/libssl.so.1.1:/usr/lib/x86_64-linux-gnu/libnss3.so:/usr/lib/x86_64-linux-gnu/libnssutil3.so:/usr/lib/x86_64-linux-gnu/libsmime3.so:/usr/lib/x86_64-linux-gnu/libpango-1.0.so.0:/usr/lib/x86_64-linux-gnu/libpangocairo-1.0.so.0:/usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0 [0808/195504.061371:WARNING:resource_bundle_qt.cpp(119)] locale_file_path.empty() for locale [0808/195504.186441:WARNING:resource_bundle_qt.cpp(119)] locale_file_path.empty() for locale [0808/195504.186434:WARNING:resource_bundle_qt.cpp(119)] locale_file_path.empty() for locale QtAV 1.13.0(Jul 29 2022, 13:04:38) Multimedia framework base on Qt and FFmpeg. Distributed under the terms of LGPLv2.1 or later. Shanghai, China Copyright (C) 2012-2019 Wang Bin (aka. Lucas Wang) wbse...@gmail.com Donate: http://qtav.org/donate.html Source: https://github.com/wang-bin/QtAV Home page: http://qtav.org [0808/195506.367219:WARNING:resource_bundle_qt.cpp(119)] locale_file_path.empty() for locale unknown: Unhandled container to remove : Digikam::DigikamApp /tmp/.mount_digiKaCk0neh/AppRun: line 197: 329656 Segmentation fault digikam $@ -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 457605] On large collections digikam often freezes for seconds with 100% CPU while paging through images
https://bugs.kde.org/show_bug.cgi?id=457605 --- Comment #3 from Alain Knaff --- (In reply to Maik Qualmann from comment #1) > Please test it with a more recent version, e.g. with the AppImage from here: > > https://files.kde.org/digikam/ > > However, make a backup of the databases if you want to go back to your old > version. > > Maik Unfortunately when adding my full collection of photos to the appimage version of digikam, it segfaults during scan, and eventually completes, but then segfaults each time I try to go into configuration. Unfortunately, even the debug version of the app image contains no debug symbols, so I can't post a stacktrace. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 457603] After saving a picture, keyboard becomes unresponsive until something is done with the mouse
https://bugs.kde.org/show_bug.cgi?id=457603 --- Comment #8 from Alain Knaff --- (In reply to caulier.gilles from comment #7) > With Plasma desktop this problem can be also relevant of the OpenGL effect > turned on in the desktop settings. > > Try to disable the Plasma desktop effects and try again. > > Gilles Caulier I do not have "Desktop settings", but I do have settings for "Desktop effects". This lists numerous effects, but none of them is called plasma. Or do you mean to switch off *all* desktop effects, no matter their name? In "Compositor", I have "Rendering Backend", which can be set to "OpenGL 3.1", "OpenGL 2" or "XRender". It already was XRender. So, *exact* names / spellings of settings to change would definitely help me test this out. In any case, this still looks like a bug to be, other applications do pop up dialogs on occasion too, but this problem does not happen to them. So digikam must be doing something weird here, that no other application does, even if it does break by confusing kwin. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 457603] After saving a picture, keyboard becomes unresponsive until something is done with the mouse
https://bugs.kde.org/show_bug.cgi?id=457603 --- Comment #6 from Alain Knaff --- (In reply to Maik Qualmann from comment #5) > I can't reproduce the problem, maybe the focus is not returned to digiKam by > the window manager after the save dialog. Are you using Wayland or X11 and > which window manager? > > Maik I'm using X11, with KDE and its window manager kwin Why would the window manager screw up focus? It doesn't do this with other applications in similar circumstances. But if you suspect a bug in kwin, please explain why you think it might be a kwin issue, and I'm ready to report it there. I did notice though that just moving the mouse out of and back into the window seems to address the issue (but that workaround is still cumbersome, but might point us into the right direction) -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 457603] After saving a picture, keyboard becomes unresponsive until something is done with the mouse
https://bugs.kde.org/show_bug.cgi?id=457603 --- Comment #4 from Alain Knaff --- (In reply to Maik Qualmann from comment #2) > You are working with a 2 year old digiKam version. I'm working with the version that is included in the currently stable Debian version. > In the meantime, hundreds > of bugs have been fixed and improvements made. Good to know, but unfortunately this one is not among them :-( (see my previous comment) > > Maik Alain -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 457603] After saving a picture, keyboard becomes unresponsive until something is done with the mouse
https://bugs.kde.org/show_bug.cgi?id=457603 Alain Knaff changed: What|Removed |Added Status|REPORTED|CONFIRMED Ever confirmed|0 |1 --- Comment #3 from Alain Knaff --- (In reply to Maik Qualmann from comment #1) > Please test it with a more recent version, e.g. with the AppImage from here: > > https://files.kde.org/digikam/ > > However, make a backup of the databases if you want to go back to your old > version. > > Maik Unfortunately, the problem still occurs with the AppImage version :-( -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 457605] New: On large collections digikam often freezes for seconds with 100% CPU while paging through images
https://bugs.kde.org/show_bug.cgi?id=457605 Bug ID: 457605 Summary: On large collections digikam often freezes for seconds with 100% CPU while paging through images Product: digikam Version: 7.1.0 Platform: Debian stable OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: digikam-bugs-n...@kde.org Reporter: k...@kde.lka.org.lu Target Milestone: --- SUMMARY On large collections digikam often freezes for seconds with 100% CPU while paging through images STEPS TO REPRODUCE 1. Set up digikam to use a really large collection of photos (I've got 118029) 2. Work in digikam, moving often from photo to photo (doesn't depend on whether this is in Image Editor, or just scrolling through an album view. Doesn't need to be new photos, just switching between 2 photos in ImageEditor is enough to trigger this) OBSERVED RESULT Eventually, digikam hangs for a couple of seconds, with 100% CPU (as shown by top). When this happens in ImageEditor, a "Loading" progress bar is shown at bottom left of window, often stuck at 0%, but occasionally also at another percentage such as 73%. Doesn't happen on every new image, but only once in a while. EXPECTED RESULT Displaying a new image should always be snappy SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Debian 11 (available in About System) KDE Plasma Version: 5.20.5-1 KDE Frameworks Version: 5.78.0-2 Qt Version: 5.15.2 ADDITIONAL INFORMATION This happens on a box with a fast NVME SSD disk. Only happens on large collections. Indeed, after I included just the albums from my recent trip (1923 photos), everything seems fine. However, with the larger collection, neither disabling plugins of category "Export", nor unchecking "Monitor the albums for external changes" helps. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 457603] New: After saving a picture, keyboard becomes unresponsive until something is done with the mouse
https://bugs.kde.org/show_bug.cgi?id=457603 Bug ID: 457603 Summary: After saving a picture, keyboard becomes unresponsive until something is done with the mouse Product: digikam Version: 7.1.0 Platform: Debian stable OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: ImageEditor-Save Assignee: digikam-bugs-n...@kde.org Reporter: k...@kde.lka.org.lu Target Milestone: --- SUMMARY After saving a picture, keyboard becomes unresponsive until something is done with the mouse STEPS TO REPRODUCE 1. In digikam main window, in an album select several or all pictures (using Ctrl-A for instance) (3 or more) 2. Open the Image Editor with the Image Editor button 3. Do a trivial change on the image shown (for instance, rotate it right using Ctrl-Shift-Right) 4. Press cursor right key to move on to second image 5. Save dialog pops up, as it should. Confirm saving by pressing Space 6. Press cursor right key again to move on to third picture OBSERVED RESULT Nothing happens. Or rather, keyboard is just ignored in general until something is done with mouse (a click, or moving it out and back into window). EXPECTED RESULT The Image Editor should move on to third picture SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Debian 11 (available in About System) KDE Plasma Version: 5.20.5-1 KDE Frameworks Version: 5.78.0-2 Qt Version: 5.15.2 ADDITIONAL INFORMATION Bug is annoying when attempting to changes to lots of images with keyboard shortcuts -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 427278] Panel & desktop config of secondary monitor lost after ScreenConnectors renumbering
https://bugs.kde.org/show_bug.cgi?id=427278 --- Comment #11 from Alain Knaff --- (In reply to Kristian Rink from comment #10) > Wondering, though, whether there's a more reliable workaround for that. > Restarting plasma seems to work just sometimes, but sometimes the panel just > won't re-appear or apparently there's no way of making it show up again, > leaving adding a new panel (and reconfiguring everything inside) the only > option. That's pretty tedious if one has a customized panel. :( After reconfiguring everything as I need it, I store a backup copy of plasma-org.kde.plasma.desktop-appletsrc and plasmashellrc, and the restore those in my restart script: #!/bin/sh #kquitapp plasmashell killall plasmashell cp -a $HOME/.config/PlasmaBackup/* $HOME/.config/ nohup plasmashell >/dev/null 2>&1
[kdelibs] [Bug 240335] Konsole should update selection on QClipboard::selectionChanged(), like xterm does
https://bugs.kde.org/show_bug.cgi?id=240335 --- Comment #21 from Alain Knaff --- Bug still present, more than 11 years after reported, after spreading like a cancer to (almost) everywhere :-( xterm still safe, but I guess it'll only be a matter of time. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 427278] Panel & desktop config of secondary monitor lost after ScreenConnectors renumbering
https://bugs.kde.org/show_bug.cgi?id=427278 --- Comment #8 from Alain Knaff --- After a couple of months of tranquility, the issue suddenly reappeared a month ago, with a vengeance :-( And now it's stuff on *both* monitors that goes wonky. - Task managers set up to show only tasks from current screen suddenly show stuff from other screen, and only stuff from the other screen (i.e. the task manager on left hand screen shows tasks from right hand screen, and the task manager on right hand screen shows stuff from left hand screen) - Spacers disappear (i.e. systray and clock move flush left against whatever stuff is on the left hand side of the panel, rather than staying at the right border) - Occasionally panels disappear altogether (or move to hide under the equivalent panel on the other screen) - Clock widgets configured to show seconds suddenly no longer show seconds - Full screen applications move to the other screen Time to bring out that handy restartPlasmaShell script again, and add a shortcut to it to the panel: #!/bin/sh killall plasmashell nohup plasmashell >/dev/null 2>&1
[digikam] [Bug 446000] Digikam does not generate thumbnails for some images
https://bugs.kde.org/show_bug.cgi?id=446000 --- Comment #2 from Alain Knaff --- (In reply to Maik Qualmann from comment #1) > Well I am sure that if you send aimage it will work here. The Debian digiKam > package is out of date, in between there are hundreds of fixed bugs in the > last stable digiKam-7.3.0. Also, is the Debian package a snap image, like > Ubuntu's? Snap packages use a sandbox and are unusable. please test it with no snap here, sorry > our AppImage from www.digikam.org. I tried this, and indeed it worked. But now the surprising part: it still continued working after I then viewed the album with my normal Debian digikam, and even after I renamed my picture, and then moved it to another album. Weird. Unfortunately, this is the only image of this kind that I have around, so I've got no further opportunity to test :-( > > Maik Thanks, Alain -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 445998] Digikam editor always saves picture with version, never overwrites
https://bugs.kde.org/show_bug.cgi?id=445998 --- Comment #2 from Alain Knaff --- (In reply to Maik Qualmann from comment #1) > Exactly the current behavior is intended if the versioning feature is > activated in the Image Editor. The original should remain unchanged. If you > don't want that, deactivate the versioning in the digiKam settings under > Editor-> Versioning. Then you have normal "Save" and "Save As" available. > > Maik Thanks for info, this works. However, it was not obvious to find, as it became one day switched on on its own without my interaction. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 446000] New: Digikam does not generate thumbnails for some images
https://bugs.kde.org/show_bug.cgi?id=446000 Bug ID: 446000 Summary: Digikam does not generate thumbnails for some images Product: digikam Version: 7.1.0 Platform: Debian stable OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Database-Thumbs Assignee: digikam-bugs-n...@kde.org Reporter: k...@kde.lka.org.lu Target Milestone: --- SUMMARY I have this image here (see attachment), for which digikam does not generate a thumbnail. It is not a matter of size, as it *does* work if I convert it to an even bigger size using imagemagick. It also works with table view (I can click on the image's table entry and see the big one), just not with preview or thumbnail. STEPS TO REPRODUCE 1. Store this picture in an album watched by digikam (i.e. where other pictures are already visible) OBSERVED RESULT A thumbnail of this pix should appear EXPECTED RESULT Nothing happens SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: 5.78.0-3 (available in About System) KDE Plasma Version: 5.20.5-1 KDE Frameworks Version: 5.78.0-2 Qt Version: 5.15.2-5 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 445998] New: Digikam editor always saves picture with version, never overwrites
https://bugs.kde.org/show_bug.cgi?id=445998 Bug ID: 445998 Summary: Digikam editor always saves picture with version, never overwrites Product: digikam Version: 7.1.0 Platform: Debian stable OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: ImageEditor Assignee: digikam-bugs-n...@kde.org Reporter: k...@kde.lka.org.lu Target Milestone: --- SUMMARY When saving a modified image in digikam editor, there is no easy way to just overwrite the existing work copy, instead it creates a new version for me STEPS TO REPRODUCE 1. Edit picture (by Clicking on Image Editor) 2. Crop image (or do any other change) 3. Save changes OBSERVED RESULT No matter how you save changes (SaveChanges, SaveAsNewVersion->SaveInFormat) it always creates a versioned file, rather than overwriting existing file. Even explicitly chosing SaveAsNewVersion->SaveNewVersionAs first proposes a versioned file name. EXPECTED RESULT It should be possible to overwrite by default SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: plasma-framework 5.78.0-3 (available in About System) KDE Plasma Version: 5.20.5-1 KDE Frameworks Version: 5.78.0-2 Qt Version: 5.15.2-5 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 445463] New: Kwin grabs keyboard in doStartMoveResize() if it can't grab pointer, resulting in freeze of entire session
https://bugs.kde.org/show_bug.cgi?id=445463
Bug ID: 445463
Summary: Kwin grabs keyboard in doStartMoveResize() if it can't
grab pointer, resulting in freeze of entire session
Product: kwin
Version: 5.18.8
Platform: Debian stable
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: platform-x11-standalone
Assignee: kwin-bugs-n...@kde.org
Reporter: k...@kde.lka.org.lu
Target Milestone: ---
If some other application grabs the pointer when user wants to resize or move a
window, kwin can't get the pointer grab for itself, and "falls back" on
grabbing the keyboard instead. With the result that the entire X session
appears to freeze until user types ESCAPE key.
This race condition occurs roughly once every couple of days, and mostly
(only?) when attempting to move a firefox or Thunderbird window.
Currently, I'm running kwin 5.20.5, but the bug is much older than that, I
remember seeing this behavior since years already.
I've managed to get a stacktrace (using a preloaded object and the backtrace()
call, so please excuse the non-compliant formatting):
/usr/lib/x86_64-linux-gnu/libkwin.so.5(KWin::grabXKeyboard(unsigned
int)+0x143)[0x7f05fbd07793]
/usr/lib/x86_64-linux-gnu/libkwin.so.5(KWin::X11Client::doStartMoveResize()+0x3f2)[0x7f05fbd3aac2]
/usr/lib/x86_64-linux-gnu/libkwin.so.5(KWin::AbstractClient::startMoveResize()+0x155)[0x7f05fbbf0c35]
/usr/lib/x86_64-linux-gnu/libkwin.so.5(KWin::AbstractClient::performMouseCommand(KWin::Options::MouseCommand,
QPoint const&)+0x1c0)[0x7f05fbbf58b0]
/usr/lib/x86_64-linux-gnu/libkwin.so.5(KWin::X11Client::NETMoveResize(int, int,
NET::Direction)+0x166)[0x7f05fbc4ed76]
/usr/lib/x86_64-linux-gnu/libKF5WindowSystem.so.5(NETRootInfo::event(xcb_generic_event_t*,
QFlags*, QFlags*)+0x30d)[0x7f05fb8e4fcd]
/usr/lib/x86_64-linux-gnu/libkwin.so.5(+0x1b1344)[0x7f05fbca6344]
/usr/lib/x86_64-linux-gnu/libkwin.so.5(KWin::Workspace::workspaceEvent(xcb_generic_event_t*)+0x107)[0x7f05fbc51b07]
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5(QAbstractEventDispatcher::filterNativeEvent(QByteArray
const&, void*, long*)+0x87)[0x7f05fa8ba517]
/usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5(QXcbConnection::handleXcbEvent(xcb_generic_event_t*)+0x61)[0x7f05f3dda7c1]
/usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5(QXcbConnection::processXcbEvents(QFlags)+0x76)[0x7f05f3ddbcd6]
/usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5(+0x69b8c)[0x7f05f3dfeb8c]
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5(QEventLoop::exec(QFlags)+0x12b)[0x7f05fa8bb98b]
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5(QCoreApplication::exec()+0x90)[0x7f05fa8c3c00]
/usr/bin/kwin_x11.wrapped(+0x7f59)[0x5619162a7f59]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea)[0x7f05fa278d0a]
/usr/bin/kwin_x11.wrapped(_start+0x2a)[0x5619162a845a]
... and in X11Client::doStartMoveResize(), line 4730 of x11client.cpp, we do
indeed find the following code snippet, just after the attempt to grab the
pointer:
if (!pointerGrab.isNull() && pointerGrab->status ==
XCB_GRAB_STATUS_SUCCESS) {
has_grab = true;
}
This can't be helpful, as kwin needs a grab on the *pointer*, not on the
keyboard, in order to move the window. Even if it passes XCB_GRAB_MODE_SYNC
into pointer_mode, this just means that pointer events are "frozen" in the X
server, for later delivery to application, and not diverted to kwin (as would
happen with a true pointer grab).
IMHO, if pointer cannot be grabbed, it might be more appropriate to move on
directly to the next paragraph (line 4732), and just fail, rather than grab the
keyboard() which does not help:
if (!has_grab) { // at least one grab is necessary in order to be able to
finish move/resize
m_moveResizeGrabWindow.reset();
return false;
}
Or maybe a small delay followed with another pointer grab attempt. I suspect
what is happening here is that in response to a click in its title bar, firefox
or thunderbird grabs the pointer whatever strange reason but release it agan
almost immediately. If kwin "wins the race" (i.e. manages to grab the pointer
before firefox or thunderbird can) nothing bad happens, and window moves as
usual. If kwin "loses the race" by a wide margin, firefox or thunderbird will
already have released the pointer grab by the time kwin gets around to grabbing
it for itself, and nothing bad happens either. It's only when kwin "loses the
race" by a narrow margin that mayhem happens, and probably the reason why these
freezeups happen so rarely (but still often enough to be annoying)
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 445462] New: Kwin grabs keyboard in doStartMoveResize() if it can't grab pointer, resulting in freeze of entire session
https://bugs.kde.org/show_bug.cgi?id=445462
Bug ID: 445462
Summary: Kwin grabs keyboard in doStartMoveResize() if it can't
grab pointer, resulting in freeze of entire session
Product: kwin
Version: 5.18.8
Platform: Debian stable
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: platform-x11-standalone
Assignee: kwin-bugs-n...@kde.org
Reporter: k...@kde.lka.org.lu
Target Milestone: ---
If some other application grabs the pointer when user wants to resize or move a
window, kwin can't get the pointer grab for itself, and "falls back" on
grabbing the keyboard instead. With the result that the entire X session
appears to freeze until user types ESCAPE key.
This race condition occurs roughly once every couple of days, and mostly
(only?) when attempting to move a firefox or Thunderbird window.
Currently, I'm running kwin 5.20.5, but the bug is much older than that, I
remember seeing this behavior since years already.
I've managed to get a stacktrace (using a preloaded object and the backtrace()
call, so please excuse the non-compliant formatting):
/usr/lib/x86_64-linux-gnu/libkwin.so.5(KWin::grabXKeyboard(unsigned
int)+0x143)[0x7f05fbd07793]
/usr/lib/x86_64-linux-gnu/libkwin.so.5(KWin::X11Client::doStartMoveResize()+0x3f2)[0x7f05fbd3aac2]
/usr/lib/x86_64-linux-gnu/libkwin.so.5(KWin::AbstractClient::startMoveResize()+0x155)[0x7f05fbbf0c35]
/usr/lib/x86_64-linux-gnu/libkwin.so.5(KWin::AbstractClient::performMouseCommand(KWin::Options::MouseCommand,
QPoint const&)+0x1c0)[0x7f05fbbf58b0]
/usr/lib/x86_64-linux-gnu/libkwin.so.5(KWin::X11Client::NETMoveResize(int, int,
NET::Direction)+0x166)[0x7f05fbc4ed76]
/usr/lib/x86_64-linux-gnu/libKF5WindowSystem.so.5(NETRootInfo::event(xcb_generic_event_t*,
QFlags*, QFlags*)+0x30d)[0x7f05fb8e4fcd]
/usr/lib/x86_64-linux-gnu/libkwin.so.5(+0x1b1344)[0x7f05fbca6344]
/usr/lib/x86_64-linux-gnu/libkwin.so.5(KWin::Workspace::workspaceEvent(xcb_generic_event_t*)+0x107)[0x7f05fbc51b07]
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5(QAbstractEventDispatcher::filterNativeEvent(QByteArray
const&, void*, long*)+0x87)[0x7f05fa8ba517]
/usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5(QXcbConnection::handleXcbEvent(xcb_generic_event_t*)+0x61)[0x7f05f3dda7c1]
/usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5(QXcbConnection::processXcbEvents(QFlags)+0x76)[0x7f05f3ddbcd6]
/usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5(+0x69b8c)[0x7f05f3dfeb8c]
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5(QEventLoop::exec(QFlags)+0x12b)[0x7f05fa8bb98b]
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5(QCoreApplication::exec()+0x90)[0x7f05fa8c3c00]
/usr/bin/kwin_x11.wrapped(+0x7f59)[0x5619162a7f59]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xea)[0x7f05fa278d0a]
/usr/bin/kwin_x11.wrapped(_start+0x2a)[0x5619162a845a]
... and in X11Client::doStartMoveResize(), line 4730 of x11client.cpp, we do
indeed find the following code snippet, just after the attempt to grab the
pointer:
if (!pointerGrab.isNull() && pointerGrab->status ==
XCB_GRAB_STATUS_SUCCESS) {
has_grab = true;
}
This can't be helpful, as kwin needs a grab on the *pointer*, not on the
keyboard, in order to move the window. Even if it passes XCB_GRAB_MODE_SYNC
into pointer_mode, this just means that pointer events are "frozen" in the X
server, for later delivery to application, and not diverted to kwin (as would
happen with a true pointer grab).
IMHO, if pointer cannot be grabbed, it might be more appropriate to move on
directly to the next paragraph (line 4732), and just fail, rather than grab the
keyboard() which does not help:
if (!has_grab) { // at least one grab is necessary in order to be able to
finish move/resize
m_moveResizeGrabWindow.reset();
return false;
}
Or maybe a small delay followed with another pointer grab attempt. I suspect
what is happening here is that in response to a click in its title bar, firefox
or thunderbird grabs the pointer whatever strange reason but release it agan
almost immediately. If kwin "wins the race" (i.e. manages to grab the pointer
before firefox or thunderbird can) nothing bad happens, and window moves as
usual. If kwin "loses the race" by a wide margin, firefox or thunderbird will
already have released the pointer grab by the time kwin gets around to grabbing
it for itself, and nothing bad happens either. It's only when kwin "loses the
race" by a narrow margin that mayhem happens, and probably the reason why these
freezeups happen so rarely (but still often enough to be annoying)
--
You are receiving this mail because:
You are watching all bug changes.
[konsole] [Bug 441803] Konsole does not allow to change default profile, but creates new profile instead, leading to cumbersome "New Tab" workflow
https://bugs.kde.org/show_bug.cgi?id=441803 Alain Knaff changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #3 from Alain Knaff --- (In reply to Ahmad Samir from comment #2) > And there is an open MR to rename the "Default" (aka Fallback, aka Built-in) > profile to "Built-in" everywhere, to finally disambiguate the name of the > internal immutable profile. > > (A "set profile as default" button sounds like a good idea, currently the > only way to set a profile as default is using the profile manager (settings > -> configure konsole)). This wouldn't still fix the issue about the extra click needed in "New Tab", as long as that original "Built-in" profile stays visible. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 441806] Kwin moves maximized applications from second screen to first screen after long sleep
https://bugs.kde.org/show_bug.cgi?id=441806 --- Comment #2 from Alain Knaff --- (In reply to Nate Graham from comment #1) > If the left-most screen marked as the primary screen? As said, this happens independently of which screen is marked as primary. Originally, the left-most screen was marked as primary. Then I changed it (so that the rightmost screen was now marked as primary), and it still happened. It only stopped happening once I physically swapped both screen's connectors. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 441806] New: Kwin moves maximized applications from second screen to first screen after long sleep
https://bugs.kde.org/show_bug.cgi?id=441806 Bug ID: 441806 Summary: Kwin moves maximized applications from second screen to first screen after long sleep Product: kwin Version: 5.20.5 Platform: Debian stable OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: multi-screen Assignee: kwin-bugs-n...@kde.org Reporter: k...@kde.lka.org.lu Target Milestone: --- SUMMARY When system wakes up after a long sleep, maximized applications that were originally on second screen are now moved to first screen. STEPS TO REPRODUCE 1. Start thunderbird 2. Move thunderbird to second screen (monitor) 3. Maximize it 4. Wait for screen saver to kick it 5. Wait another half hour (or possibly more) 6. Shake mouse to wake up system OBSERVED RESULT Thunderbird is now on first screen EXPECTED RESULT The application should stay put where it was left before sleep (i.e. second screen) SOFTWARE/OS VERSIONS Linux/KDE Plasma: (available in About System) KDE Plasma Version: 5.20.5 KDE Frameworks Version: 5.78.0 Qt Version: 5.12.2 ADDITIONAL INFORMATION It's the "natural" order of screens that is important here, not the "primary screen" checkbox from SystemSettings->DisplayAndMonitor i.e. to get thunderbird staying on my rightmost screen (rather than moving to the one I had on left), I had to physically swap DisplayPort connectors of the 2 screens. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 441803] New: Konsole does not allow to change default profile, but creates new profile instead, leading to cumbersome "New Tab" workflow
https://bugs.kde.org/show_bug.cgi?id=441803 Bug ID: 441803 Summary: Konsole does not allow to change default profile, but creates new profile instead, leading to cumbersome "New Tab" workflow Product: konsole Version: 20.12.3 Platform: Debian stable OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: konsole-de...@kde.org Reporter: k...@kde.lka.org.lu Target Milestone: --- SUMMARY I'd like to customize the default profile of konsole, but have no need of having multiple parallel profiles in parallel as this leads to an excessive (non-optimal) amount of clicks to open a new tab STEPS TO REPRODUCE 1. Settings->Edit Current Profile->Appearance 2. Change the color scheme to something else (or any other change) 3. Apply OBSERVED RESULT "Each profile must have a name before it can be saved into disk." Why would it need another name when changing an *existing* profile? Entering a name causes a new profile to be created with the changed setting As there are now 2 profiles (the original unchangeable default profile and then this new profile), opening new tabs becomes more cumbersome, as now the menu forces to chose among these 2 profiles EXPECTED RESULT It should be possible to change the default profile without needing to create a new profile to do so. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Linux 5.10.0-8 (available in About System) KDE Plasma Version: 5.20.5 KDE Frameworks Version: 5.78.0 Qt Version: 5.15.2 (btw, why are these version numbers, in SystemSettings->SystemInformation, not copy-pastable?) ADDITIONAL INFORMATION N.B. It is indeed possible to set a "Default" flag on such newly created profile, but this still keeps the original default in place, which cannot be removed -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 387231] Calendar widget closes itself as soon as mouse leaves
https://bugs.kde.org/show_bug.cgi?id=387231 Alain Knaff changed: What|Removed |Added Status|NEEDSINFO |CONFIRMED Ever confirmed|0 |1 Resolution|WAITINGFORINFO |--- --- Comment #7 from Alain Knaff --- . -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 387231] Calendar widget closes itself as soon as mouse leaves
https://bugs.kde.org/show_bug.cgi?id=387231 --- Comment #6 from Alain Knaff --- The issue is still occurring (calendar collapses as soon as mouse enters another window). However Christophe Feck's workaround does work, thanks. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 416739] Panel disappears from time to time and after a while re-appears
https://bugs.kde.org/show_bug.cgi?id=416739 --- Comment #43 from Alain Knaff --- *** Bug 425897 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 425897] Panel on second screen is corrupted after waking up from screensaver
https://bugs.kde.org/show_bug.cgi?id=425897 Alain Knaff changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Alain Knaff --- *** This bug has been marked as a duplicate of bug 416739 *** -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 425897] Panel on second screen is corrupted after waking up from screensaver
https://bugs.kde.org/show_bug.cgi?id=425897 --- Comment #2 from Alain Knaff --- More comments about this on bug 416739. Unfortunately I was mistaken in my comment from 2020-09-13 : the problem only went away for a while, but now occurs again. Copying the config files from a backup from when it was working did not help this time :-( -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 416739] Panel disappears from time to time and after a while re-appears
https://bugs.kde.org/show_bug.cgi?id=416739 --- Comment #42 from Alain Knaff --- (In reply to Alain Knaff from comment #40) [...] > I've got the impression that the problem mostly occurs when the work > computer is connected, and has the screens. After some time passed, the pattern of failure apparently has changed for a mysterious reason. Now, the problem happens with the screens going just to sleep. No matter of restoring the config files from backups from various dates cured the problem... Unless there are config files elsewhere than in in ~/.config that need restoring? Btw, what is the purpose of this mysterious :0.0 entry being added to the ScreenConnectors? Why is it being added *in*the*middle* rather than at the end? And if the purpose of this entry is irrelevant for most use cases anyways, can't we have a config option to just disable this behavior? Could an actual developer please chime in here? Indeed, I'd rather have a couple of clicks to perform once and for all after buying a new screen, rather than having to do that each time the screens wake up. No, write protecting the plasmashellrc file unfortunately didn't help. And nor did write protecting plasma-org.kde.plasma.desktop-appletsrc -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 416739] Panel disappears from time to time and after a while re-appears
https://bugs.kde.org/show_bug.cgi?id=416739 Alain Knaff changed: What|Removed |Added CC||k...@kde.lka.org.lu --- Comment #40 from Alain Knaff --- I am experiencing the same problem. Debian Version: 10 Kernel: 4.19.0-10-amd64 Plasma Version: 5.14.5-1 Desktop: Terra Monitors: 2 Terra 2463W monitors, connected via Display Port These are monitors that have 2 inputs each, Display Port and HDMI. On Mondays and Fridays, I work from home, and connect my work laptop to the HDMI inputs. The home computer is still connected to the display port inputs, but the monitors are switched to HDMI input. I've got the impression that the problem mostly occurs when the work computer is connected, and has the screens. When that happens, the ~/.config/plasmashellrc gets an extra :0.0 entry for the screen connector: Before: [ScreenConnectors] 0=DP-1 1=DP-2 After: [ScreenConnectors] 0=DP-1 1=:0.0 2=DP-2 => i.e. the bogus sneaked right into the middle of the real entries, causing DP-2 to get renumbered from 1 to 2. However, the lastScreen settings in .config/plasma-org.kde.plasma.desktop-appletsrc would not get updated, i.e. all panels on DP-2 would still keep lastScreen=1, causing them to disappear (as plasma tried to display them on the non-existant :0.0 screen) N.B. monitors just going to sleep don't cause the problem by itself (unless ~/.config/plasmashellrc is already corrupted), it actually needs monitor's input to be switched to another computer to make .plasmashellrc to become corrupted. But once plasmashellrc *is* corrupted, then shenanigans happen whenever monitors go to sleep. I've now write-protected the plasmashellrc file, let's see whether this stops the problem from happening next Friday :-) -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 425897] Panel on second screen is corrupted after waking up from screensaver
https://bugs.kde.org/show_bug.cgi?id=425897 --- Comment #1 from Alain Knaff --- Some addition: Before the bug first appeared, I had replaced my screens. The new ones are both connected via DisplayPort, whereas the old ones used to be connected one via HDMI and one via DisplayPort. This left the following situation in my ~/.config/plasmashellrc [ScreenConnectors] 0=DP-2 1=eDP-1 2=HDMI-3 3=DP-1 4=HDMI-2 5=:0.0 I now cleaned this out from a text console while not being logged in KDE, to leave this: [ScreenConnectors] 0=DP-2 1=DP-1 2=:0.0 ... an now the problem no longer occurs (touching wood...) -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 425897] New: Panel on second screen is corrupted after waking up from screensaver
https://bugs.kde.org/show_bug.cgi?id=425897 Bug ID: 425897 Summary: Panel on second screen is corrupted after waking up from screensaver Product: plasmashell Version: 5.14.1 Platform: Debian stable OS: Linux Status: REPORTED Severity: grave Priority: NOR Component: Panel Assignee: plasma-b...@kde.org Reporter: k...@kde.lka.org.lu Target Milestone: 1.0 SUMMARY After waking up from screen saver, panels on second screen go all wonky. Either disappear, or an included task manager shows up tasks from the wrong screen. Restarting plasmashell then "fixes" it STEPS TO REPRODUCE 1. On second screen, set up a panel with a task manager with "Show only tasks from the current screen" is ticked. 2. At first, it does indeed only show tasks from the second screen, as it should 3. Wait 10 minutes for the screen saver to kick in 4. Move the mouse to wake it from screen. 5. Now, the task manager in the panel on the second screen shows tasks from the *first* screen. Sometimes, that panel is also gone altogether (i.e. not displayed at all) 6. Execute kquitapp plasmashell ; nohup plasmashell >/dev/null 2>&1
[kwin] [Bug 421068] Kwin sends out undated WM_TAKE_FOCUS messages that goad firefox into stealing focus
https://bugs.kde.org/show_bug.cgi?id=421068 --- Comment #8 from Alain Knaff --- Created attachment 128685 --> https://bugs.kde.org/attachment.cgi?id=128685=edit Pass valid time to sendClientMessage Just attaching the patch here, easier than getting kdesrc-build going... -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 421068] Kwin sends out undated WM_TAKE_FOCUS messages that goad firefox into stealing focus
https://bugs.kde.org/show_bug.cgi?id=421068 --- Comment #7 from Alain Knaff --- (In reply to David Edmundson from comment #6) > I assume the patch is basically just passing xTime() as the last argument of > sendClientMessage in Client::takeFocus() > > ? Yes indeed. And calling updateXTime(); just before. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 421068] Kwin sends out undated WM_TAKE_FOCUS messages that goad firefox into stealing focus
https://bugs.kde.org/show_bug.cgi?id=421068 --- Comment #5 from Alain Knaff --- (In reply to David Edmundson from comment #4) > >Any comments on this? > > Firstly, thanks for the research. It's very appreciated. Thanks for your sign of life :-) It's reassuring to see that this doesn't fall on deaf ears.:-) > > I'm normally quite reluctant on anything replacing one bug for another, this > is the first report on this and the GTK code hasn't changed in a long time. > The other report this was fixing has several. Well, the thing is this behavior has been around for quite a while, but it was hard to pinpoint it on a specific component. KDE, Firefox and GTK were throwing the ball to each other... Focus management bugs have been reported to the KDE bugtracker since at least 2004 (not the same bug, but same category), and most often only with lukewarm success, unfortunately. Thus, "recent bug report" does not necessarily mean "recent problem". It could have been lurking quite a while, and only have become more frequent / more annoying due to timing and performance changes elsewhere. It's a race condition bug after all. But, if push comes to shove, and indeed more than just Java applications will be broken by this, maybe we could make the behavior configurable by application by using the "Special Window Settings" and "Special Application Settings" dialogs? > > On the other hand being spec compliant is important. Indeed... > > Just wanted to say, we have read this, we'll get back to you. Thanks for the reassuring words. I do have a patch by now (literally a 3 liner...), is it useful to attach it here, or must I get through the whole dance of setting up a complete kdesrc-build environment and submit a merge request? :-) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 421068] Kwin sends out undated WM_TAKE_FOCUS messages that goad firefox into stealing focus
https://bugs.kde.org/show_bug.cgi?id=421068 --- Comment #3 from Alain Knaff --- Another thing. If there really are still a sizable number of users around who use Java on the desktop, and who depend on the current "take focus at any time" behavior, maybe this could be made configurable on a per-application basis by using the "Special Applications Settings" window, i.e. the one where you also configure Focus Stealing Prevention per Application. Interestingly enough, this configuration window only contains a setting "Accept Focus", but no "Uses NET::TakeFocusProtocol". The latter would be very useful for the Firefox/Thunderbird case, because these 2 applications work alright even if they don't get these wm_take_focus messages. Indeed, the Client::takeFocus method already *gives* the application focus (via m_client.focus()) before allowing it to grab focus for itself. Thus the second step here is redundant in most cases (... and, as far as I understood, only useful for applications that do indeed want to hand focus to one specific subwindow of theirs) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 421068] Kwin sends out undated WM_TAKE_FOCUS messages that goad firefox into stealing focus
https://bugs.kde.org/show_bug.cgi?id=421068 --- Comment #2 from Alain Knaff --- Ok, now I located the commit which (probably) broke this: https://github.com/KDE/kwin/commit/e73e331f35b9da4bbb99c80c5c1eedd2ae99422b So, until 2016, kwin *used* to send a valid timestamp, but this got deliberately broken to appease some Java Applications which were "extremely picky" and would refuse focus. But after that change, we now have GTK applications which dutifully take kwin's word for it, and actually do claim focus "at any time", i.e. at a moment where doing so is no longer appropriate, and where they disrupt the application that the user is actually working with. Well, nowadays Java on the Desktop is pretty much dead, whereas GTK is alive and kicking (even if tied to KDE's competitor Gnome). And GTK is used by some very widely used applications such as Firefox and Thunderbird. So we should really go back to respecting section 4.1.7 of the ICCCM "client to Window Manager Communication" communication rules, and include a meaningful timestamp. Indeed the ICCCM document clearly says: Windows with the atom WM_TAKE_FOCUS in their WM_PROTOCOLS property may receive a ClientMessage event from the window manager (as described in section 4.2.8) with WM_TAKE_FOCUS in its data[0] field and a valid timestamp (i.e. not CurrentTime ) in its data[1] field. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 421068] Kwin sends out undated WM_TAKE_FOCUS messages that goad firefox into stealing focus
https://bugs.kde.org/show_bug.cgi?id=421068 Alain Knaff changed: What|Removed |Added Ever confirmed|0 |1 Status|REPORTED|CONFIRMED --- Comment #1 from Alain Knaff --- Any comments on this? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 421068] New: Kwin sends out undated WM_TAKE_FOCUS messages that goad firefox into stealing focus
https://bugs.kde.org/show_bug.cgi?id=421068 Bug ID: 421068 Summary: Kwin sends out undated WM_TAKE_FOCUS messages that goad firefox into stealing focus Product: kwin Version: 5.14.5 Platform: Debian stable OS: Linux Status: REPORTED Severity: grave Priority: NOR Component: core Assignee: kwin-bugs-n...@kde.org Reporter: k...@kde.lka.org.lu Target Milestone: --- SUMMARY Kwin sends out undated WM_TAKE_FOCUS client messages. Gtk based applications such as Firefox react to these by handing focus to one of their subwindows using XSetInputFocus(), and pass on the null time field that they received in the client message to XSetInputFocus(). If for whatever reason the application (firefox) is slow to process the event, it might issue that XSetInputFocus() message at a time when it has already lost focus to the next application. This results in Firefox stealing back the focus from the next application. Normally, such an occurrence would not happen, as the server could tell by the time field that the message is stale. STEPS TO REPRODUCE 1. Open Firefox 2. Open Web Console Window (by using Inspect element) 3. Open another window (for example, a konsole), and place it such that it covers the top of the firefox web console 4. Open another window (another konsole) and place it such that it covers the bottom of the firexfox web console, leaving a narrow gap between both where web console is visible behind them. 5. Move mouse back and forth between the top and the bottom konsole, crossing the web console each time. 6. Whenever you are in a konsole with the mouse, observe the cursor shape. 7. Pretty quickly you see that your konsole does not have focus (hollow cursor) even the mouse is in the window. 8. Press cursor keys: you see that it's the Firefox web console who has focus! OBSERVED RESULT Firefox web console has focus EXPECTED RESULT Konsole should have focus SOFTWARE/OS VERSIONS Linux/KDE Plasma: Debian 10, 5.14.5.1-1 (available in About System) KDE Plasma Version: 5.14.5.1-1 KDE Frameworks Version: Qt Version: 4.8.7+dfsg-18 ADDITIONAL INFORMATION Bug initially reported to gtk under https://gitlab.gnome.org/GNOME/gtk/-/issues/2699 xtruss line showing the bad message WM_TAKE_FOCUS message: --- SendEvent-generated ClientMessage(window=w#0403, type=a#306, format=32, data=0133::::) -- You are receiving this mail because: You are watching all bug changes.
[kdeplasma-addons] [Bug 420307] New: Window list plasmoid cannot select window that is on another virtual desktop
https://bugs.kde.org/show_bug.cgi?id=420307 Bug ID: 420307 Summary: Window list plasmoid cannot select window that is on another virtual desktop Product: kdeplasma-addons Version: 5.14.5 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: General Assignee: plasma-b...@kde.org Reporter: k...@kde.lka.org.lu Target Milestone: --- SUMMARY STEPS TO REPRODUCE 1. Click on window list plasmoid 2. In Window click on an application that is running on another desktop than the current one OBSERVED RESULT 1. The screen flickers briefly, but then comes back to desktop where it was before 2. The target window (on other desktop) is indeed uniconified (when it was iconified before). EXPECTED RESULT 1. The desktop should switch to the desktop where the chosen Window is. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: 5.14.5 (available in About System) KDE Plasma Version: 5.14.5 KDE Frameworks Version: 5.14.5 Qt Version: 5.11.3 ADDITIONAL INFORMATION Debian 10 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 409686] New: Digikam hits database deadlock on start with gelocation query
https://bugs.kde.org/show_bug.cgi?id=409686 Bug ID: 409686 Summary: Digikam hits database deadlock on start with gelocation query Product: digikam Version: 5.9.0 Platform: Other OS: Linux Status: REPORTED Severity: major Priority: NOR Component: ImageEditor Assignee: digikam-bugs-n...@kde.org Reporter: k...@kde.lka.org.lu Target Milestone: --- SUMMARY When digikam is started, it freezes for 10 seconds, and then says that it could not execute a database query about geolocation STEPS TO REPRODUCE 1. Start digikam OBSERVED RESULT The following is printed to STDERR, all the while the UI is unresponsive for 10 seconds: digikam.geoiface: digikam.general: Cancel Main Thread digikam.general: Cancel Main Thread digikam.geoiface: "setting backend marble" QFSFileEngine::open: No file name specified digikam.geoiface: "ROADMAP" digikam.geoiface: "setting backend marble" digikam.facesengine: Face database ready for use digikam.general: Face PipeLine: add database writer digikam.general: Face PipeLine: add faces trainer digikam.facesengine: Face database ready for use digikam.general: Face PipeLine: add database writer digikam.general: Face PipeLine: add faces trainer digikam.geoiface: "setting backend marble" QFSFileEngine::open: No file name specified digikam.geoiface: "ROADMAP" digikam.geoiface: "ROADMAP" digikam.general: scan mode: ScanDeferredFiles digikam.general: total scan value : 373261 digikam.dbengine: Database is locked. Waited 0 digikam.dbengine: Database is locked. Waited 250 digikam.dbengine: Database is locked. Waited 500 digikam.dbengine: Database is locked. Waited 750 digikam.dbengine: Database is locked. Waited 1000 digikam.dbengine: Database is locked. Waited 1250 digikam.dbengine: Database is locked. Waited 1500 digikam.dbengine: Database is locked. Waited 1750 digikam.dbengine: Database is locked. Waited 2000 digikam.dbengine: Database is locked. Waited 2250 digikam.dbengine: Database is locked. Waited 2500 digikam.dbengine: Database is locked. Waited 2750 digikam.dbengine: Database is locked. Waited 3000 digikam.dbengine: Database is locked. Waited 3250 digikam.dbengine: Database is locked. Waited 3500 digikam.dbengine: Database is locked. Waited 3750 digikam.dbengine: Database is locked. Waited 4000 digikam.dbengine: Database is locked. Waited 4250 digikam.dbengine: Database is locked. Waited 4500 digikam.dbengine: Database is locked. Waited 4750 digikam.dbengine: Database is locked. Waited 5000 digikam.dbengine: Database is locked. Waited 5250 digikam.dbengine: Database is locked. Waited 5500 digikam.dbengine: Database is locked. Waited 5750 digikam.dbengine: Database is locked. Waited 6000 digikam.dbengine: Database is locked. Waited 6250 digikam.dbengine: Database is locked. Waited 6500 digikam.dbengine: Database is locked. Waited 6750 digikam.dbengine: Database is locked. Waited 7000 digikam.dbengine: Database is locked. Waited 7250 digikam.dbengine: Database is locked. Waited 7500 digikam.dbengine: Database is locked. Waited 7750 digikam.dbengine: Database is locked. Waited 8000 digikam.dbengine: Database is locked. Waited 8250 digikam.dbengine: Database is locked. Waited 8500 digikam.dbengine: Database is locked. Waited 8750 digikam.dbengine: Database is locked. Waited 9000 digikam.dbengine: Database is locked. Waited 9250 digikam.dbengine: Database is locked. Waited 9500 digikam.dbengine: Database is locked. Waited 9750 digikam.dbengine: Database is locked. Waited 1 digikam.dbengine: Detected locked database file. There is an active transaction. Waited but giving up now. digikam.dbengine: Failure executing query: "SELECT latitude, latitudeNumber, longitude, longitudeNumber, altitude, orientation, tilt, roll, accuracy, description FROM ImagePositions WHERE imageid=:a;" Error messages: "Unable to fetch row" "database table is locked: ImagePositions" 6 1 Bound values: (QVariant(qlonglong, 275510)) EXPECTED RESULT Digikam should not freeze. A database query should not take that long, especially for a feature which is only of interest to a minority of users. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: (available in About System) KDE Plasma Version: KDE Frameworks Version: Qt Version: ADDITIONAL INFORMATION I do not have any need for geolocation. How can I switch it off easily? -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 409685] ImageEditor can only be invoked once
https://bugs.kde.org/show_bug.cgi?id=409685 --- Comment #1 from Alain Knaff --- I just noticed: the problem only occurs when closing the Image Editor window using the "cross" icon on its title bar (top-right corner). It doesn't occur when using the "Close Editor" from the Image Editor's own "Main toolbar" -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 409685] New: ImageEditor can only be invoked once
https://bugs.kde.org/show_bug.cgi?id=409685 Bug ID: 409685 Summary: ImageEditor can only be invoked once Product: digikam Version: 5.9.0 Platform: Other OS: Linux Status: REPORTED Severity: major Priority: NOR Component: ImageEditor Assignee: digikam-bugs-n...@kde.org Reporter: k...@kde.lka.org.lu Target Milestone: --- SUMMARY Image editor can only be invoked once from digikam's main window STEPS TO REPRODUCE 1. In an album, select a picture 2. Click Image Editor button 3. Image editor opens (albeit, without its menu) 4. Close image editor 5. In main window, click Image Editor button again OBSERVED RESULT After Step 5, an image editor window with a white background (and nothing else) appears. At the same time, the following message is printed to STDERR: digikam.geoiface: qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 48058, resource id: 96469350, major code: 19 (DeleteProperty), minor code: 0 ... and after closing the useless image editor: digikam.geoiface: EXPECTED RESULT Image editor should appear normally (i.e. with selected photo), even when opening it the second time. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: Linux 4.19.0-5-amd64, Debian 10, KDE 5.54.0-1 (available in About System) KDE Plasma Version: 4:5.14.5.1-1 KDE Frameworks Version: Qt Version: 5.11.3 ADDITIONAL INFORMATION -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 405897] New: There is a gap between the bottom task bar and the K-menu, making menu unusable if a window is behind it
https://bugs.kde.org/show_bug.cgi?id=405897 Bug ID: 405897 Summary: There is a gap between the bottom task bar and the K-menu, making menu unusable if a window is behind it Product: plasmashell Version: 5.12.7 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Panel Assignee: plasma-b...@kde.org Reporter: k...@kde.lka.org.lu Target Milestone: 1.0 SUMMARY There is a gap between the bottom panel and the K-menu, making the menu unusable if a window is behind that gap. Indeed, in that case, after opening the menu by klicking on the K (or the "3 dots and arrow" icon), the menu closes when attempting to move the mouse into it, because the mouse has to cross that gap, and by doing so, it touches the window behind it. Problem does not happen when moving mouse very quickly (but sometimes you need to move it *really* quick, so this is not an option...) STEPS TO REPRODUCE 1. Open a window (for example a konsole), and position it at the bottom left corner of the screen, partially behind the bottom task bar 2. Click on the "K" icon 3. Slowly move the mouse into the newly opened "K" menu. OBSERVED RESULT The K menu closes, because of the small gap between the bottom panel and the K menu. The mouse has to cross that gap to go into the K menu, and by doing so, it will touch the window behind it, closing the K menu before it can be used. EXPECTED RESULT K menu should be displayed with its lower border flush with the K icon's upper border, so that it is possible to move the mouse from the icon to the menu without crossing any other window. SOFTWARE/OS VERSIONS Windows: macOS: Linux/KDE Plasma: 4.15.0 / 5.12.7 (available in About System) KDE Plasma Version: 5.12.7 KDE Frameworks Version: 5.12.7 Qt Version: 5.9.5 ADDITIONAL INFORMATION Gaps stays even after making the bottom panel taller or lower using the "Height" control. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 367480] Crash inside Baloo::PostingCodec::decode
https://bugs.kde.org/show_bug.cgi?id=367480 Alain Knaff changed: What|Removed |Added CC|k...@kde.lka.org.lu | -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 387231] Calendar widget closes itself as soon as mouse leaves
https://bugs.kde.org/show_bug.cgi?id=387231 Alain Knaff <k...@kde.lka.org.lu> changed: What|Removed |Added Status|NEEDSINFO |UNCONFIRMED Resolution|WAITINGFORINFO |--- --- Comment #3 from Alain Knaff <k...@kde.lka.org.lu> --- > Do you have 'Focus Follows Mouse' enabled? I have "Focus Follows Mouse - Mouse Precedence" (why can't I copy-paste this?) But it seems to happen on other settings as well (tried also "Focus Under Mouse", and "Focus Strictly Under Mouse") -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 387637] New: Baloo crashes randomly, disrupts work via messing with keyboard
https://bugs.kde.org/show_bug.cgi?id=387637 Bug ID: 387637 Summary: Baloo crashes randomly, disrupts work via messing with keyboard Product: kde Version: unspecified Platform: unspecified OS: Linux Status: UNCONFIRMED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: unassigned-b...@kde.org Reporter: k...@kde.lka.org.lu Target Milestone: --- Application: baloo_file (5.18.0) Qt Version: 5.5.1 Operating System: Linux 4.4.0-101-generic x86_64 Distribution: Ubuntu 16.04.3 LTS -- Information about the crash: - What I was doing when the application crashed: Just editing some Java source code in Emacs Suddenly baloo crashed (what's this?, what's it for?, and why is it compulsory to have it?) and from then one keyboard froze until I attented to the crash reporting assistant The crash can be reproduced sometimes. -- Backtrace: Application: Baloo File Indexing Daemon (baloo_file), signal: Segmentation fault Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". [Current thread is 1 (Thread 0x7fba4244f900 (LWP 4462))] Thread 2 (Thread 0x7fb8f6ad3700 (LWP 4468)): #0 0x7fba4055124d in read () at ../sysdeps/unix/syscall-template.S:84 #1 0x7fba39563073 in ?? () from /usr/lib/nvidia-384/tls/libnvidia-tls.so.384.90 #2 0x7fba3d7666f0 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #3 0x7fba3d722e74 in g_main_context_check () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #4 0x7fba3d723330 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #5 0x7fba3d72349c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #6 0x7fba4118b7eb in QEventDispatcherGlib::processEvents(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #7 0x7fba41132b4a in QEventLoop::exec(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #8 0x00420cd8 in Baloo::FileContentIndexer::run() () #9 0x7fba40f512d3 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #10 0x7fba40f547be in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #11 0x7fba3fbb76ba in start_thread (arg=0x7fb8f6ad3700) at pthread_create.c:333 #12 0x7fba405613dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 Thread 1 (Thread 0x7fba4244f900 (LWP 4462)): [KCrash Handler] #6 __memcpy_avx_unaligned () at ../sysdeps/x86_64/multiarch/memcpy-avx-unaligned.S:238 #7 0x7fba4163e8da in Baloo::PostingCodec::decode(QByteArray const&) () from /usr/lib/x86_64-linux-gnu/libKF5BalooEngine.so.5 #8 0x7fba4162a814 in Baloo::PostingDB::get(QByteArray const&) () from /usr/lib/x86_64-linux-gnu/libKF5BalooEngine.so.5 #9 0x7fba4163b3c6 in Baloo::WriteTransaction::commit() () from /usr/lib/x86_64-linux-gnu/libKF5BalooEngine.so.5 #10 0x7fba41633032 in Baloo::Transaction::commit() () from /usr/lib/x86_64-linux-gnu/libKF5BalooEngine.so.5 #11 0x004296d5 in Baloo::MetadataMover::removeFileMetadata(QString const&) () #12 0x7fba41163baf in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #13 0x00432f05 in Baloo::PendingFileQueue::removeFileIndex(QString const&) () #14 0x00427856 in Baloo::PendingFileQueue::processCache() () #15 0x7fba41163baf in QMetaObject::activate(QObject*, int, int, void**) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #16 0x7fba411705c8 in QTimer::timerEvent(QTimerEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #17 0x7fba41164bb3 in QObject::event(QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #18 0x7fba4113536c in QCoreApplication::notifyInternal(QObject*, QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #19 0x7fba4118a5ed in QTimerInfoList::activateTimers() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #20 0x7fba4118ab29 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #21 0x7fba3d723197 in g_main_context_dispatch () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #22 0x7fba3d7233f0 in ?? () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #23 0x7fba3d72349c in g_main_context_iteration () from /lib/x86_64-linux-gnu/libglib-2.0.so.0 #24 0x7fba4118b7cf in QEventDispatcherGlib::processEvents(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #25 0x7fba41132b4a in QEventLoop::exec(QFlags) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #26 0x7fba4113abec in QCoreApplication::exec() () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5 #27 0x0041698c in main () Reported using DrKonqi -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 387231] New: Calendar widget closes itself as soon as mouse leaves
https://bugs.kde.org/show_bug.cgi?id=387231 Bug ID: 387231 Summary: Calendar widget closes itself as soon as mouse leaves Product: plasmashell Version: master Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Calendar Assignee: plasma-b...@kde.org Reporter: k...@kde.lka.org.lu Target Milestone: 1.0 The calendar popup widget from the taskbar closes as soon as the mouse leaves the taskbar and the widget. This makes it unusable when trying to keep it up for a while (because needing to look it up while planning a meeting or event in another application). I vaguely remember that this already used to be an issue a while ago, but then was repaired. Recently it broke again. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 383052] KDE allows applications to freeze whole GUI
https://bugs.kde.org/show_bug.cgi?id=383052 --- Comment #8 from Alain Knaff <k...@kde.lka.org.lu> --- >> I'm just wondering why such disruptive functions still exist in the X API :-( > > Because you cannot break it. But *why* can't you remove it? Even screensavers don't depend on this nowadays (just tried it. Start sesson with xgrab.so workaround. Lock Screen. Press Alt-F2. Nope, this *doesn't* bring up a command prompt, screen stays safely locked.) > In fact currently there are proposals to add exactly this to Wayland to allow > backward compatibility. One more reason not to move over to Wayland... But seriously, what kind of *useful* functionality is this supposed to bring? I mean, useful to the user, not to advertisers, marketers, spammers and scammers... -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 383052] KDE allows applications to freeze whole GUI
https://bugs.kde.org/show_bug.cgi?id=383052 --- Comment #6 from Alain Knaff <k...@kde.lka.org.lu> --- Indeed, it seems to be XGrabKeyboard that they are doing, thanks for the pointer. The workaround at https://bugs.freedesktop.org/show_bug.cgi?id=21652#c4 succeeds in addressing the issue, without any negative side-effects. I'm just wondering why such disruptive functions still exist in the X API :-( -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 383052] KDE allows applications to freeze whole GUI
https://bugs.kde.org/show_bug.cgi?id=383052 Alain Knaff <k...@kde.lka.org.lu> changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #5 from Alain Knaff <k...@kde.lka.org.lu> --- > The X11 protocol allows applications to grab keyboard input However, it's not just the keyboard, but the mouse too. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 383052] KDE allows applications to freeze whole GUI
https://bugs.kde.org/show_bug.cgi?id=383052 --- Comment #3 from Alain Knaff <k...@kde.lka.org.lu> --- 52.2.0 (64-bit) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 383052] New: KDE allows applications to freeze whole GUI
https://bugs.kde.org/show_bug.cgi?id=383052 Bug ID: 383052 Summary: KDE allows applications to freeze whole GUI Product: kwin Version: unspecified Platform: Debian stable OS: Linux Status: UNCONFIRMED Severity: critical Priority: NOR Component: libinput Assignee: kwin-bugs-n...@kde.org Reporter: k...@kde.lka.org.lu Target Milestone: --- Currently, Firefox is able to freeze the entire GUI. Not sure how they're doing it, but KDE should not allow such shenanigans. The Window system should protect the applications against each other, whether they are just clumsy or malicious. The below link points to the report on Mozilla's bugzilla about this issue. https://bugzilla.mozilla.org/show_bug.cgi?id=1386699 -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 365921] New: Occasionally, konsole silently transforms trailing spaces into carriage returns when copy-pasting => dataloss due to prematurely executing incomplete commands!
https://bugs.kde.org/show_bug.cgi?id=365921 Bug ID: 365921 Summary: Occasionally, konsole silently transforms trailing spaces into carriage returns when copy-pasting => dataloss due to prematurely executing incomplete commands! Product: konsole Version: 2.13 Platform: Ubuntu Packages OS: Linux Status: UNCONFIRMED Severity: critical Priority: NOR Component: copy-paste Assignee: konsole-de...@kde.org Reporter: k...@kde.lka.org.lu When copy-pasting from konsole, trailing spaces are occasionally transformed into carriage returns. This may lead to data loss if copy-pasting to another konsole in the process of building a command. Example: when intending to do "cp file1 file2 directory", and copy-pasting "file1 file2" from one konsole to another after typing cp, you just lost file2 => such bugs are just inacceptable! It is due to this potential of data loss that I marked the bug as critical. I'm aware that konsole has had trouble with trailing spaces for ages, and had a bad tendency of "fixing" issues by "compensating" them (i.e. replacing a pattern resulting from one bug with the expected pattern, thereby causing a new bug in situations where such patterns were indeed intended) => it is never a good idea to "compensate" like that, and in fixing bugs, care must be taken to actually locate and fix the *cause* rather than patch the symptoms. (In my case, I managed to regenerate the file, but others may not be so lucky...) -- You are receiving this mail because: You are watching all bug changes.
