[i18n] [Bug 484993] Settings energy-saving mode mixed
https://bugs.kde.org/show_bug.cgi?id=484993 Frank Steinmetzger changed: What|Removed |Added Status|REOPENED|ASSIGNED -- You are receiving this mail because: You are watching all bug changes.
[i18n] [Bug 474572] Plasma5-pk-updates with mixed languages
https://bugs.kde.org/show_bug.cgi?id=474572 Frank Steinmetzger changed: What|Removed |Added CC||dev-...@felsenfleischer.de --- Comment #7 from Frank Steinmetzger --- (In reply to Frank Kruger from comment #5) > The issue is solved, if ":" is omitted in the translation for "Check for > Updates" in plasma_applet_org.kde.plasma.pkupdates.po, i.e., "Auf > Aktualisierungen prüfen" I fixed that one now, so it should trickle down into packages over time. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 486646] New: Wrong tooltip text in kcms/desktoppaths/ui/main.qml
https://bugs.kde.org/show_bug.cgi?id=486646 Bug ID: 486646 Summary: Wrong tooltip text in kcms/desktoppaths/ui/main.qml Classification: Plasma Product: plasmashell Version: 6.0.4 Platform: Arch Linux OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: dev-...@felsenfleischer.de CC: k...@davidedmundson.co.uk Target Milestone: 1.0 I noticed while translating that there is a wrong help text in the KCM for desktop paths. The text for public shares is the same as for movies. Apparently this happened in e864dd3b, where the correct text was refactored away. Sorry for not fixing it myself, I used to fix such little stuff with the web IDE in the past. But I can't find it now and don't have the time to learn the MR workflow for a single line of text. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.0.4 KDE Frameworks Version: 6.1.0 Qt Version: 6.7.0 Kernel Version: 6.8.9-arch1-1 (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 486219] Dolphin crashes when dragging an item into the breadcrumb address bar
https://bugs.kde.org/show_bug.cgi?id=486219 --- Comment #1 from Frank Steinmetzger --- Created attachment 168957 --> https://bugs.kde.org/attachment.cgi?id=168957=edit New crash information added by DrKonqi DrKonqi auto-attaching complete backtrace. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 486219] New: Dolphin crashes when dragging an item into the breadcrumb address bar
https://bugs.kde.org/show_bug.cgi?id=486219 Bug ID: 486219 Summary: Dolphin crashes when dragging an item into the breadcrumb address bar Classification: Applications Product: dolphin Version: 24.02.2 Platform: Arch Linux OS: Linux Status: REPORTED Keywords: drkonqi Severity: crash Priority: NOR Component: general Assignee: dolphin-bugs-n...@kde.org Reporter: dev-...@felsenfleischer.de CC: kfm-de...@kde.org Target Milestone: --- Application: dolphin (24.02.2) Qt Version: 6.7.0 Frameworks Version: 6.1.0 Operating System: Linux 6.8.7-arch1-2 x86_64 Windowing System: X11 Distribution: "Arch Linux" DrKonqi: 6.0.4 [CoredumpBackend] -- Information about the crash: When I want to move a file from one Dolphin tab to another, Dolphin crashes every time. After some more experimenting, I narrowed it down to the breadcrumb bar, and so I noticed that Gwenview has the same problem. The crash can be reproduced every time. -- Backtrace (Reduced): #5 QScopedPointer >::get (this=0x8, this=) at /usr/src/debug/qt6-base/qtbase/src/corelib/tools/qscopedpointer.h:110 [...] #8 QObject::deleteLater (this=0x0) at /usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qobject.cpp:2456 #9 0x7247c45d1cce in KDEPrivate::KUrlNavigatorButton::dragMoveEvent (this=0x5ab772bff1b0, event=) at /usr/src/debug/kio/kio-6.1.0/src/filewidgets/kurlnavigatorbutton.cpp:323 #10 0x7247c2f47073 in QWidget::event (this=0x5ab772bff1b0, event=0x7ffc21cf20e0) at /usr/src/debug/qt6-base/qtbase/src/widgets/kernel/qwidget.cpp:9237 #11 0x7247c2efbfcb in QApplicationPrivate::notify_helper (this=this@entry=0x5ab7722be290, receiver=0x5ab772bff1b0, e=e@entry=0x7ffc21cf20e0) at /usr/src/debug/qt6-base/qtbase/src/widgets/kernel/qapplication.cpp:3287 Reported using DrKonqi -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 485430] New: Rename file with F2: initial keyboard focus should be in the filename text field
https://bugs.kde.org/show_bug.cgi?id=485430 Bug ID: 485430 Summary: Rename file with F2: initial keyboard focus should be in the filename text field Classification: Applications Product: gwenview Version: 24.02.1 Platform: Arch Linux OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: general Assignee: gwenview-bugs-n...@kde.org Reporter: dev-...@felsenfleischer.de Target Milestone: --- When I rename an image with F2, a little dialog opens in which I can enter the new filename. Currently, the initial keyboard focus sits on one of the buttons, so I need to press Tab first. It would be more efficient if the focus were in the input field in which to enter the new filename. Bonus point: highlight only the basename part of the filename, i.e. without the file extension (if one exists) and its dot, like Dolphin does. Regards SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.0.3 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.3 Kernel Version: 6.8.2-arch2-1 (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[i18n] [Bug 484993] Settings energy-saving mode mixed
https://bugs.kde.org/show_bug.cgi?id=484993 Frank Steinmetzger changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED -- You are receiving this mail because: You are watching all bug changes.
[i18n] [Bug 484993] Settings energy-saving mode mixed
https://bugs.kde.org/show_bug.cgi?id=484993 Frank Steinmetzger changed: What|Removed |Added Ever confirmed|0 |1 CC||dev-...@felsenfleischer.de Status|REPORTED|ASSIGNED --- Comment #1 from Frank Steinmetzger --- There are indeed lots of still missing strings in that dialog. I’ll update it as much as I can. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 484890] URL hint numbering has offset
https://bugs.kde.org/show_bug.cgi?id=484890 --- Comment #1 from Frank Steinmetzger --- Addendum with a different observation. I just viewed a message in mutt and wanted to open an address from the message. This time the numbering started at 1, but the offset was 2. In detail: The mutt sidebar showed two local paths at the left edge (like /var/spool/mail), which got the hints 1 and 2. And then there is one URL in the displayed mail, labelled 3. But I need to press Ctrl+1 to open it. At first I thought this happens because the URL appears a few lines above the two paths. So I mocked it in an editor and moved the URL around, and I still had to press Ctrl+1 when the URL was below the paths. Are local paths perhaps skipped? -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 484890] New: URL hint numbering has offset
https://bugs.kde.org/show_bug.cgi?id=484890 Bug ID: 484890 Summary: URL hint numbering has offset Classification: Applications Product: konsole Version: 24.02.1 Platform: Arch Linux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: konsole-de...@kde.org Reporter: dev-...@felsenfleischer.de Target Milestone: --- SUMMARY When I press Ctrl to get keyboard hints of URLs, there is an offset of 1. Numbering starts at 2, and when I press 2, for example, then the URL labelled with 3 is opened. STEPS TO REPRODUCE Have konsole display a few URLs, like in mutt, or an editor. Trigger URL hints. OBSERVED RESULT The numbering labels show their value + 1. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 6.0.3 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.3 Kernel Version: 6.8.2-arch2-1 (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[i18n] [Bug 462458] Default window size ever so slightly too small to display tall/desktop view with German language
https://bugs.kde.org/show_bug.cgi?id=462458 Frank Steinmetzger changed: What|Removed |Added CC||dev-...@felsenfleischer.de --- Comment #5 from Frank Steinmetzger --- This would however require support by the layout, because in English the [set] is at the front of the sentence, whereas in German the [einstellen] is at the end. You would need a prefix and a suffix string around the button, and you are still left with a long text. Can't we lose the “more” from “more settings” and just say “Appearance settings”. Because the button’s destination is the actual settings anyways. It doesn’t mention “Appearance” on the start page either, so the user may not even know that it belongs to the Appearance section. -- You are receiving this mail because: You are watching all bug changes.
[Telly Skout] [Bug 481783] New: Move the main view with mouse dragging
https://bugs.kde.org/show_bug.cgi?id=481783 Bug ID: 481783 Summary: Move the main view with mouse dragging Classification: Applications Product: Telly Skout Version: 23.08.5 Platform: Arch Linux OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: General Assignee: unassigned-b...@kde.org Reporter: dev-...@felsenfleischer.de CC: plata.h...@kdemail.net Target Milestone: --- SUMMARY I have a tablet with a touch screen and on it Telly can be used very intuitively. On the laptop, the touchpad also works well. But on a normal PC (or when you use a normal mouse on a laptop), it’s a different story. There is no way of moving the view sideways save for with the scrollbars. In other electronic TV guides I’ve been using in the past, it was always possible to click+drag the view around arbitrarily. So I would like to ask for the feature to move the view by “grabbing” it with the mouse. I also just noticed there is a glitch in the scrollbars: when the mouse pointer leaves or enters the widget, it blinks out for a tiny moment. -- You are receiving this mail because: You are watching all bug changes.
[kinfocenter] [Bug 480805] New: Battery charge graph shows no data when charge reaches 100 %
https://bugs.kde.org/show_bug.cgi?id=480805 Bug ID: 480805 Summary: Battery charge graph shows no data when charge reaches 100 % Classification: Applications Product: kinfocenter Version: 5.27.10 Platform: Arch Linux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: dev-...@felsenfleischer.de CC: sit...@kde.org Target Milestone: --- Created attachment 165510 --> https://bugs.kde.org/attachment.cgi?id=165510=edit Screenshot of the two battery graphs at the same time SUMMARY During a seldomly done full charge of the battery I noticed that the charge graph stops collecting data when the battery reached around 99 %. The battery actually kept on charging for a good while longer because it is miscalibrated. This can also be observed in the power graph. STEPS TO REPRODUCE Charge the battery to the top. OBSERVED RESULT The graph has a gap when it reaches around 99 %. EXPECTED RESULT The graph should be continuous. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.27.10 KDE Frameworks Version: 5.114.0 Qt Version: 5.15.12 Kernel Version: 6.7.3-arch1-1 (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[kinfocenter] [Bug 480804] New: Battery charge graph: layout flicker
https://bugs.kde.org/show_bug.cgi?id=480804 Bug ID: 480804 Summary: Battery charge graph: layout flicker Classification: Applications Product: kinfocenter Version: 5.27.10 Platform: Arch Linux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: dev-...@felsenfleischer.de CC: sit...@kde.org Target Milestone: --- Created attachment 165509 --> https://bugs.kde.org/attachment.cgi?id=165509=edit screencast showing the issue SUMMARY I was in the process of recalibrating my internal battery and had the charge graph open. All of a sudden I noticed the fan spinning up sharply. It turned out it was kinfocenter, whose GUI layout was fluctuating between two states when the windows is maximised. See the attached screencast. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.27.10 KDE Frameworks Version: 5.114.0 Qt Version: 5.15.12 Kernel Version: 6.7.3-arch1-1 (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 438074] baloo reindexing files on every start
https://bugs.kde.org/show_bug.cgi?id=438074 --- Comment #19 from Frank Steinmetzger --- (In reply to tagwerk19 from comment #18) > Watch out for indexing email files, particularly those encoded or with > attachments. For .eml files see Bug 460882; .mbox files can be absolutely > massive. It’s all maildir, but with over 100k files. ^^ I’ve had enough at one point and figured there must be something wrong with my database. So I moved it away and reindexed everything. Seeing that it indexed a lot more files, I think that the database has been in a very old state for quite some time and baloo tried to update it ever since. There is one problem though: the write volume is very bad. The final database file is maybe around 16 GB (the defunct database was 18 GB), but the write volume during indexing was a multiple of that during indexing, at least 100 GB. So I symlinked ~/.local/share/baloo to a ramdisk. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 438074] baloo reindexing files on every start
https://bugs.kde.org/show_bug.cgi?id=438074 Frank Steinmetzger changed: What|Removed |Added CC||dev-...@felsenfleischer.de --- Comment #17 from Frank Steinmetzger --- I’ve also been observing this problem for quite some time now. Thankfully, it does not slow down my PC, even though it is 9½ years old. But I see it in the system monitor applets in my panel that there is constant read I/O of 150 MB/s for at least half an hour after login. I ran balooshow -x on a file before and after the last two reboots and the output was identical. I don’t run btrfs. My system uses ext4 on LVM on LUKS. The output of lsblk also remained unchanged across boots. I’m not sure what else to check. I’ve issued balooctl suspend a few minutes ago, but the indexer still chucks along. Eventually I killed the extractor with killall. ``` ~ LC_ALL=C time balooctl status Baloo File Indexer is running Indexer state: Suspended Total files indexed: 176,898 Files waiting for content indexing: 74,305 Files failed to index: 0 Current size of index is 18.22 GiB real0m49,878s user0m0,013s sys 0m0,004s ``` Addendum: Reading this thread, I found out about `balooctl monitor` and started it, then resumed the indexing. The monitor first printed some email files and there was minor system load. Then a few seconds nothing and then the I/O load started again, but the monitor has not shown any new filenames since. Operating System: Arch Linux KDE Plasma Version: 5.27.10 KDE Frameworks Version: 5.113.0 Qt Version: 5.15.11 Kernel Version: 6.6.9-arch1-1 (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Core™ i5-4590 CPU @ 3.30GHz Memory: 30.8 GiB of RAM -- You are receiving this mail because: You are watching all bug changes.
[frameworks-purpose] [Bug 478653] New: Pastebin sharing should not paste without confirmation
https://bugs.kde.org/show_bug.cgi?id=478653 Bug ID: 478653 Summary: Pastebin sharing should not paste without confirmation Classification: Frameworks and Libraries Product: frameworks-purpose Version: 5.113.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: aleix...@kde.org Reporter: dev-...@felsenfleischer.de Target Milestone: --- SUMMARY I just read a post in a tech forum where someone set up a KDE environment on a non-techie’s laptop. And he asked how to disable the pastebin item from the Dolphin context menu, because it is a security risk for the user-to-be. The function itself is not really dangerous of course, but the fact that there is no warning for the uninitiated and no way of confirmation or cancellation is indeed a problem. Also, the “…” in the context menu item suggest that it will open a dialog window. But the window simply posts and then closes immediately. OBSERVED RESULT The file is uploaded immediately. EXPECTED RESULT There should be a request for confirmation with an appropriate warning that whatever is being shared will be publicly visible for the entire internet and that there is no way to remove the content—which probably only applies to guests without an account. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.27.10 KDE Frameworks Version: 5.113.0 Qt Version: 5.15.11 -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 476636] New: "Welcome" popup message after opening a document
https://bugs.kde.org/show_bug.cgi?id=476636 Bug ID: 476636 Summary: "Welcome" popup message after opening a document Classification: Applications Product: okular Version: 23.08.1 Platform: Archlinux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: okular-de...@kde.org Reporter: dev-...@felsenfleischer.de Target Milestone: --- SUMMARY When I open a document with Okular, I see a popup in the top left with the text “Welcome”. No other document viewer I know does this. We all aim to be polite as people and a society, but I find this—frankly—rather useless, even distracting. Also: when I open a document from the welcome screen, this message does not show “Welcome”, but instead “Loaded a xyz-paged document.” But only then: when I open another document from the File menu, it says “Welcome” again. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.27.9 KDE Frameworks Version: 5.111.0 Qt Version: 5.15.11 Kernel Version: 6.5.9-arch2-1 (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 476635] New: After opening a document, Okular moves the view down by a few pixels/mm
https://bugs.kde.org/show_bug.cgi?id=476635 Bug ID: 476635 Summary: After opening a document, Okular moves the view down by a few pixels/mm Classification: Applications Product: okular Version: 23.08.1 Platform: Archlinux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: okular-de...@kde.org Reporter: dev-...@felsenfleischer.de Target Milestone: --- Created attachment 162908 --> https://bugs.kde.org/attachment.cgi?id=162908=edit screen recording of repeated opening of the same document SUMMARY Okular never shows a new document from the very top, but always a few pixels down. This triggers my eye for details. :) I’ve had this „problem“ for many years now and I’ve come to terms with it (using muscle memory: as soon as the window appears, I hit page up). But now for the first time, I noticed that this movement is animated, which induced me to file a report. I can’t imagine this hasn’t been reported before. I tried searching with "okular open scroll" or "opening from top" and stuff like this, but didn’t see something of this sort. STEPS TO REPRODUCE 1. Open a (PDF?) document in Okular. OBSERVED RESULT 1. When opened for the first time, the document is not viewed from the very top, but a few pixels down. 2. When not opened for the first time, the document view is moved down another increment (I guess due to the remembered viewing position). EXPECTED RESULT This movement should not happen. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.27.9 KDE Frameworks Version: 5.111.0 Qt Version: 5.15.11 Kernel Version: 6.5.9-arch2-1 (64-bit) Graphics Platform: X11 ADDITIONAL INFORMATION I attach a screen recording of repeatedly opening a document with a description. Notice the animated scrolling down with each subsequent opening. In the middle of the recording I switch to one-column view. The scrolling goes down to a very small amount, but it is still there, as can be seen by the distance of the mouse cursor to the line of text. -- You are receiving this mail because: You are watching all bug changes.
[Merkuro] [Bug 453068] Pane for event details should always be visible, so the layout stays constant
https://bugs.kde.org/show_bug.cgi?id=453068 Frank Steinmetzger changed: What|Removed |Added Resolution|WAITINGFORINFO |FIXED Status|NEEDSINFO |RESOLVED --- Comment #2 from Frank Steinmetzger --- While the popup is not perfect yet, it fixes the issue that was raised in this ticket. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 474532] New: Git sidebar: error message after cancelling Open Commit
https://bugs.kde.org/show_bug.cgi?id=474532 Bug ID: 474532 Summary: Git sidebar: error message after cancelling Open Commit Classification: Applications Product: kate Version: 23.08.0 Platform: Archlinux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: application Assignee: kwrite-bugs-n...@kde.org Reporter: dev-...@felsenfleischer.de Target Milestone: --- STEPS TO REPRODUCE 1. Open a git-managed file in Kate 2. Open the Git sidebar 3. From the Tools button, select “Open Commit…” 4. Click on “Cancel” OBSERVED RESULT The log view shows a new Git error with “invalid hash” So apparently even though I pressed cancel, Git is still called. When I input a valid commit ID and press Cancel, I still get the error message. EXPECTED RESULT Cancel means “do nothing”, so there should be no error message. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.27.7 KDE Frameworks Version: 5.109.0 -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 471326] New: Gwenview displays EXIF metadata twice/in duplicate
https://bugs.kde.org/show_bug.cgi?id=471326 Bug ID: 471326 Summary: Gwenview displays EXIF metadata twice/in duplicate Classification: Applications Product: gwenview Version: 23.04.2 Platform: Archlinux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: gwenview-bugs-n...@kde.org Reporter: dev-...@felsenfleischer.de Target Milestone: --- Created attachment 159831 --> https://bugs.kde.org/attachment.cgi?id=159831=edit Screenshot of the sidebar and the selection dialog SUMMARY I just started noticing this problem. An hour ago I upgraded from Plasma 5.27.5 to 5.27.6 (and a week ago from applications 23.04.1 to 23.04.2, but I’m not sure which is the cause, because I haven’t used Gwenview extensively in the last week). OBSERVED RESULT Gwenview now shows most of the items in the metadata pane twice. There are exceptions, such as the filename, user comment and date of modification. I assume because they come from different data sources. EXPECTED RESULT Each item should only be shown once. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.27.6 KDE Frameworks Version: 5.107.0 Qt Version: 5.15.10 Kernel Version: 6.3.8-arch1-1 (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[i18n] [Bug 471302] Wrong translation in german for open media file button
https://bugs.kde.org/show_bug.cgi?id=471302 Frank Steinmetzger changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED CC||dev-...@felsenfleischer.de --- Comment #2 from Frank Steinmetzger --- I fixed the string and while I was at it, found another typo and little issues in the file. -- You are receiving this mail because: You are watching all bug changes.
[krunner] [Bug 470471] New: Search input field animation when opening krunner seems out of place
https://bugs.kde.org/show_bug.cgi?id=470471 Bug ID: 470471 Summary: Search input field animation when opening krunner seems out of place Classification: Plasma Product: krunner Version: 5.27.5 Platform: Archlinux OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: dev-...@felsenfleischer.de CC: alexander.loh...@gmx.de, natalie_clar...@yahoo.de Target Milestone: --- SUMMARY When krunner is opened and slides in from the top, at the same time the input cursor and the “Search ...“ text in the input field slide from right to left. After investigation I now know this comes from the default behaviour of a search input widget, which does this when it receives input focus, because it then hides its looking-glass icon. But to me (I set global animation speed rather high, which also means it is not always butter-smooth) it looks like the GUI is still being constructed while the panel slides in. Partly this is because the icon starts vanishing as soon as krunner moves in, which makes the icon—and thus the reason for the animation in the first place—practically imperceptible. What’s your opinion on avoiding this particular animation? Perhaps the focus can be pre-set, or the icon is set only after creating the widget (I don’t know the particulars on how the GUI is constructed). I think it would give an impression of a seemingly faster responding GUI. Cheers. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.27.5 KDE Frameworks Version: 5.106.0 Qt Version: 5.15.9 -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 470468] New: Saving a second second screenshot from a Spectacle window keeps being titled as unsaved
https://bugs.kde.org/show_bug.cgi?id=470468 Bug ID: 470468 Summary: Saving a second second screenshot from a Spectacle window keeps being titled as unsaved Classification: Applications Product: Spectacle Version: 23.04.1 Platform: Archlinux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: General Assignee: noaha...@gmail.com Reporter: dev-...@felsenfleischer.de CC: k...@david-redondo.de Target Milestone: --- STEPS TO REPRODUCE 1. Press PrintScreen to make a screenshot in Spectacle 2. Press the Save button 3. The titlebar text changes to the filename of the new file 4. Press PrintScreen to capture another screenshot 5. Press the Save button OBSERVED RESULT The image is saved, but the titlebar keeps showing “*Unsaved“ EXPECTED RESULT The titlebar should be updated again. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.27.5 KDE Frameworks Version: 5.106.0 Qt Version: 5.15.9 Kernel Version: 6.3.3-arch1-1-surface (64-bit) Graphics Platform: offscreen Processors: 4 × Intel® Pentium® CPU 4415Y @ 1.60GHz Memory: 7.7 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 615 -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 462088] Don't show Gwenview in its own "Open With" menu
https://bugs.kde.org/show_bug.cgi?id=462088 Frank Steinmetzger changed: What|Removed |Added CC||dev-...@felsenfleischer.de --- Comment #9 from Frank Steinmetzger --- (In reply to phd from comment #5) > Actually I use that quite often to duplicate the current window. > How do I do it now? Just as a quick idea (I write it here, b/c I couldn’t find a request for it yet): Ctrl+N could be a solution. Just like in a browser or Dolphin, it would open a new window which shows or pre-selects the file that is active in the current window. -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 470126] New: "Open with" menu has off-by one error
https://bugs.kde.org/show_bug.cgi?id=470126 Bug ID: 470126 Summary: "Open with" menu has off-by one error Classification: Applications Product: gwenview Version: 23.04.1 Platform: Archlinux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: gwenview-bugs-n...@kde.org Reporter: dev-...@felsenfleischer.de Target Milestone: --- STEPS TO REPRODUCE 1. View an image in Gwenview 2. Open the “Open with” menu, it doesn’t matter whether from the main or the context menu 3. Select an item from the menu. OBSERVED RESULT The program from the menu item above the selected one is launched. For the first item, Gwenview is launched. In my case, the menu contains (in that order) Krita, Showfoto, Okular, Gimp. And the items launch Gwenview, Krita, Showfoto and Okular, respectively. The very last menu item which opens the dialog to start a different application works as expected. EXPECTED RESULT The correct program should be started. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.27.5 KDE Frameworks Version: 5.106.0 Qt Version: 5.15.9 Kernel Version: 6.3.2-arch1-1-surface (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 427225] Showfoto GUI becomes unresponsive when used with the keyboard
https://bugs.kde.org/show_bug.cgi?id=427225 --- Comment #5 from Frank Steinmetzger --- I haven’t done much editing lately, but I will report back if I encounter the problem again. -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 467818] Rightmost column's width cannot be changed
https://bugs.kde.org/show_bug.cgi?id=467818 Frank Steinmetzger changed: What|Removed |Added CC||dev-...@felsenfleischer.de --- Comment #1 from Frank Steinmetzger --- Created attachment 157644 --> https://bugs.kde.org/attachment.cgi?id=157644=edit Resize cursor at right edge of rightmost column If you are talking about the Detailed view, then you can change the column width. Its right edge is just not visible. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 464966] Pressing Escape in Trash clears the view
https://bugs.kde.org/show_bug.cgi?id=464966 --- Comment #1 from Frank Steinmetzger --- Addendum: after some more clicking around I come to the conclusion that I actually found two separate bugs. One is that pressing Escape empties the Trash view. The other one is about the scrollbar: when I open an empty album, the vertical scrollbar retains its status from the last viewed non-empty album. Meaning: 1. I go to an album with so many images, that there would be a scrollbar grip of—for example—50 % height (meaning: two pages worth of scrolling). 2. I go to an empty album. The scrollbar remains visible with 50 % height. 3. I go to the empty trash, all the action buttons at the bottom are disabled (as they should, because Trash is empty and nothing is selected) and the scrollbar disappears. 4. I go back to the empty album, the scrollbar reappears with 50 % height. 5. As soon as the view is resized, either by moving a separator or by hiding/showing a sidebar, the scrollbar also disappears. So when I press Escape in the Trash view which empties the view, this emptying triggers the same behaviour as in Step 4. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 464966] New: Pressing Escape in Trash clears the view
https://bugs.kde.org/show_bug.cgi?id=464966 Bug ID: 464966 Summary: Pressing Escape in Trash clears the view Classification: Applications Product: digikam Version: 7.9.0 Platform: Archlinux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Albums-Trash Assignee: digikam-bugs-n...@kde.org Reporter: dev-...@felsenfleischer.de Target Milestone: --- STEPS TO REPRODUCE 1. I have an image in the trash view. 2. I wanted to clear the selection of the image, so I pressed the Escape key. OBSERVED RESULT The view is completely emptied, but there now appears a vertical scrollbar as if there were many items. When I open another album and then go back to Trash, the image is shown again. EXPECTED RESULT Nothing like this should happen when simply pressing Escape. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.26.5 KDE Frameworks Version: 5.102.0 Qt Version: 5.15.8 -- You are receiving this mail because: You are watching all bug changes.
[k3b] [Bug 249055] Wrong message strings during burning
https://bugs.kde.org/show_bug.cgi?id=249055 --- Comment #4 from Frank Steinmetzger --- (In reply to Justin Zobel from comment #3) > Thank you for reporting this issue in KDE software. As it has been a while > since this issue was reported, can we please ask you to see if you can > reproduce the issue with a recent software version? > > If you can reproduce the issue, please change the status to "REPORTED" when > replying. Thank you! I currently don’t have any media to test. But the code lines in question haven’t been changed since early 2010. So unless cdrdao changed its output since, the bug probably is still present. -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 144968] Attachments order is not preserved during Drag and Drop
https://bugs.kde.org/show_bug.cgi?id=144968 Frank Steinmetzger changed: What|Removed |Added CC||dev-...@felsenfleischer.de --- Comment #6 from Frank Steinmetzger --- (In reply to Thomas McGuire from comment #1) > Where did you drag the files from? In my case I used the file picker dialog. > Why does the order matter to you? The other day I was sending some pictures and wrote a descriptive text about them. The image filenames were in chronological order (they started with the date in ISO format) and my text described the details of the images (“first I attached … Then you see …“). In the composer’s attachment list they were shown in the right order. But once sent (or even just saved as draft), they were mixed up. Interestingly, after I renamed them from starting with the date to “1.”, “2.” in front of the date, the mixup was still in the same order. -- You are receiving this mail because: You are watching all bug changes.
[kopete] [Bug 240664] Kopete mixes up window sizes of contact list and chat windows
https://bugs.kde.org/show_bug.cgi?id=240664 Frank Steinmetzger changed: What|Removed |Added Status|NEEDSINFO |RESOLVED Resolution|WAITINGFORINFO |FIXED --- Comment #7 from Frank Steinmetzger --- The chat window keeps its size now. But the main window always starts with some pre-defined size. It does not remember where it was when last quit and how big it was. So as to the original problem in this bug, this is fixed (kinda-sorta). However I’m sad to say that—while trying to narrow down the behavior—I encountered many problems that make Kopete unusable in its current state. - it reliably crashed when I pressed Ctrl+Q in the main window while a chat window was open - when trying to look whether I had an option enabled or disabled, I opened the settings window and Kopete freezes up right away in a memory leak loop -- You are receiving this mail because: You are watching all bug changes.
[QMLKonsole] [Bug 463387] Tab button text cut off on tablet
https://bugs.kde.org/show_bug.cgi?id=463387 Frank Steinmetzger changed: What|Removed |Added CC||dev-...@felsenfleischer.de --- Comment #8 from Frank Steinmetzger --- I checked: the translation indeed says „Tabulator“. We’ll change it then. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 462971] New: Profile configuration: set page scroll to half screen height does not work
https://bugs.kde.org/show_bug.cgi?id=462971 Bug ID: 462971 Summary: Profile configuration: set page scroll to half screen height does not work Classification: Applications Product: konsole Version: 22.12.0 Platform: Archlinux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: konsole-de...@kde.org Reporter: dev-...@felsenfleischer.de Target Milestone: --- I was in the process of syncing Konsole profiles across my devices. Playing around with profile settings, I discovered that I could set the page scroll height (setting ScrollFullPage in the profile file) to full, but not to half. Selecting full in the GUI writes ScrollFullPage=1 into the profile file (in legacy files, it was =True). But selecting half does not change the setting anymore. STEPS TO REPRODUCE 1. Configure a profile 2. Go to the scrollbar page 3. Under “Scroll Page Up/Down:” select “Full screen height”, klick OK → The profile file now contains the line ScrollFullPage=1 and scrolling happens by full pages 4. Now select “Half screen height” OBSERVED RESULT The setting remains unchanged. When I reopen the profile configuration, the selection is displayed back at Full height. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.26.4 KDE Frameworks Version: 5.101.0 Qt Version: 5.15.7 Kernel Version: 6.0.12-arch1-1 (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 407086] Scam detection is too sensitive for URLs that trivially differ and are not a scam
https://bugs.kde.org/show_bug.cgi?id=407086 Frank Steinmetzger changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #3 from Frank Steinmetzger --- (In reply to Frank Steinmetzger from comment #2) > I was just reading a plain-text mail which contains a list of URLs of Gentoo > package repositories. For some reason, KMail re-interprets one (and only > one) of those links by removing its trailing slash. Sorry, forgot to mention: Operating System: Arch Linux KDE Plasma Version: 5.26.3 KDE Frameworks Version: 5.100.0 Qt Version: 5.15.7 Kernel Version: 6.0.9-arch1-1 (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 407086] Scam detection is too sensitive for URLs that trivially differ and are not a scam
https://bugs.kde.org/show_bug.cgi?id=407086 Frank Steinmetzger changed: What|Removed |Added CC||dev-...@felsenfleischer.de --- Comment #2 from Frank Steinmetzger --- Created attachment 154169 --> https://bugs.kde.org/attachment.cgi?id=154169=edit Screenshot Unfortunately, the trailing slash issue has not been resolved. I was about to file a new bug, but the list of possible duplicates showed me this one. I was just reading a plain-text mail which contains a list of URLs of Gentoo package repositories. For some reason, KMail re-interprets one (and only one) of those links by removing its trailing slash. -- You are receiving this mail because: You are watching all bug changes.
[i18n] [Bug 387519] Dolphin context menu "Paste" text is confusing to first time users
https://bugs.kde.org/show_bug.cgi?id=387519 Frank Steinmetzger changed: What|Removed |Added CC||dev-...@felsenfleischer.de Status|NEEDSINFO |REPORTED Resolution|WAITINGFORINFO |--- --- Comment #7 from Frank Steinmetzger --- Ich kannte das Ticket bisher nicht, aber muss sagen, dass mich das auch regelmäßig etwas nervt. Dadurch, dass ich das Kontextmenü ziemlich selten nutze, muss ich praktisch jedes Mal nach dem Menüeintrag suchen. Ich fände daher ein „Einfügen (x Dateien/Zwischenablage)“ tatsächlich auch schöner. Erstens bleibt dann vermutlich der Accelerator konstant (E für einfügen) und zweitens hat man den visuellen Anker am linken Rand. Dass es dann kein grammatikalisch vollwertiger Satz mehr ist, stört mich persönlich nicht. -- You are receiving this mail because: You are watching all bug changes.
[i18n] [Bug 462082] NeoChat appdata: "[...] als auch auf dem Arbeitsfläche"
https://bugs.kde.org/show_bug.cgi?id=462082 Frank Steinmetzger changed: What|Removed |Added Status|CONFIRMED |ASSIGNED -- You are receiving this mail because: You are watching all bug changes.
[i18n] [Bug 462082] NeoChat appdata: "[...] als auch auf dem Arbeitsfläche"
https://bugs.kde.org/show_bug.cgi?id=462082 Frank Steinmetzger changed: What|Removed |Added Status|REPORTED|CONFIRMED CC||dev-...@felsenfleischer.de Ever confirmed|0 |1 --- Comment #1 from Frank Steinmetzger --- Ja, ich finde „Arbeitsfläche“ in diesem Fall auch unglücklich gewählt. Neochat hat aktuell allgemein viel Unübersetztes, das wird dann wohl mein nächster Abendzeitvertreib. :) -- You are receiving this mail because: You are watching all bug changes.
[Spectacle] [Bug 462092] New: Confirming crop tool with Enter crops twice
https://bugs.kde.org/show_bug.cgi?id=462092 Bug ID: 462092 Summary: Confirming crop tool with Enter crops twice Classification: Applications Product: Spectacle Version: 22.08.3 Platform: Archlinux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: General Assignee: m...@baloneygeek.com Reporter: dev-...@felsenfleischer.de CC: k...@david-redondo.de Target Milestone: --- SUMMARY When I confirm the selected crop region with Enter, the wrong area is apparently cropped. STEPS TO REPRODUCE 1. Take a screenshot 2. Go to Annotations 3. Select Crop and pick a region 4. Press Enter to crop OBSERVED RESULT A much smaller region than what I selected is cropped. Now I press Ctrl+Z to undo, and the image appears with the proper crop. It seems to me that cropping is executed twice. This does not happen if I accept the crop by clicking the Apply button. I tried a different region of the image, and the cropped region was OK, but still cropped twice (I had to press Ctrl+Z two times to get back to the original image). EXPECTED RESULT The proper region shall be cropped. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.26.3 KDE Frameworks Version: 5.100.0 Qt Version: 5.15.7 Kernel Version: 6.0.9-arch1-1 (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[lokalize] [Bug 424024] Main window doesn't repaint correctly on Wayland
https://bugs.kde.org/show_bug.cgi?id=424024 Frank Steinmetzger changed: What|Removed |Added CC||dev-...@felsenfleischer.de -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 461018] Cannot copy link and address URLs from a mail via link’s context menu
https://bugs.kde.org/show_bug.cgi?id=461018 --- Comment #2 from Frank Steinmetzger --- I never had the problem before, either. So I followed a hunch and was able to confirm: it only happens under Wayland. I logged into an X11 session and the bug was gone. Logged back into Wayland and it reappeared. -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 461018] New: Cannot copy link and address URLs from a mail via link’s context menu
https://bugs.kde.org/show_bug.cgi?id=461018 Bug ID: 461018 Summary: Cannot copy link and address URLs from a mail via link’s context menu Classification: Applications Product: kmail2 Version: 5.15.3 Platform: Archlinux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: UI Assignee: kdepim-b...@kde.org Reporter: dev-...@felsenfleischer.de Target Milestone: --- STEPS TO REPRODUCE 1. View an e-mail 2a. Right-click on the clickable sender or recipient address, select “Copy email address” 2b. Right click a link in the email body, select “Copy link address” OBSERVED RESULT Nothing new is copied to the clipboard. The clipboard content remains unchanged. ADDITIONAL INFORMATION Selecting some text from the message and selecting “Copy” from the context menu works as expected. Operating System: Arch Linux KDE Plasma Version: 5.26.1 KDE Frameworks Version: 5.99.0 Qt Version: 5.15.6 Kernel Version: 6.0.1-arch2-1-surface (64-bit) Graphics Platform: Wayland Processors: 4 × Intel® Pentium® CPU 4415Y @ 1.60GHz Memory: 7.7 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 615 Manufacturer: Microsoft Corporation Product Name: Surface Go System Version: 1 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 460700] New: Add action to go to previous and next sibling folder
https://bugs.kde.org/show_bug.cgi?id=460700 Bug ID: 460700 Summary: Add action to go to previous and next sibling folder Classification: Frameworks and Libraries Product: frameworks-kio Version: 5.99.0 Platform: Archlinux OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: URL navigator Assignee: kio-bugs-n...@kde.org Reporter: dev-...@felsenfleischer.de CC: kdelibs-b...@kde.org Target Milestone: --- SUMMARY Time and again I browse through a hierarchy of folders, most often to view photo albums. That means I either have to click through a tree view in a sidebar with the mouse, or when I only use the keyboard, go one folder level up, select the next one and press enter (in Gwenview) or – in Dolphin’s detailed view – press left to select the folder, left again to close it, go down to the next folder and right to open it. Due to https://bugs.kde.org/show_bug.cgi?id=426716, being on a Touchpad is not very practical and on a touch screen the user cannot scroll on a breadcrumb item at all. We already have a “Go up” action. So I propose two new related actions: go to previous sibling folder and go to next sibling folder. The Icon could be double-arrow left/right (i.e. the skip symbols from a media player), and the default keyboard shortcut something like Ctrl+Alt+Left/Right (unfortunately, Alt+Left/Right, which would better fit together with Alt+Up for “Go to parent”, is already taken). I got this idea yesterday when I was using Ranger, the vim-like terminal file manager, which provides [ and ] to do what I just described. -- You are receiving this mail because: You are watching all bug changes.
[kopete] [Bug 407147] Kopete crashes when trying to associate an address book entry to a new contact
https://bugs.kde.org/show_bug.cgi?id=407147 Frank Steinmetzger changed: What|Removed |Added Ever confirmed|0 |1 Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |CONFIRMED --- Comment #4 from Frank Steinmetzger --- Kopete still crashes when clicking on the „Change“ button. Kopete 1.13.0 Operating System: Arch Linux KDE Plasma Version: 5.25.5 KDE Frameworks Version: 5.98.0 Qt Version: 5.15.6 Kernel Version: 5.19.13-arch1-1 (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 459272] Unable to navigate submenus with cursor keys
https://bugs.kde.org/show_bug.cgi?id=459272 --- Comment #1 from Frank Steinmetzger --- (In reply to Frank Steinmetzger from comment #0) > Observed under both X11 and Wayland. Correction: I’m back in X11 and I can’t reproduce it there. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 459272] New: Unable to navigate submenus with cursor keys
https://bugs.kde.org/show_bug.cgi?id=459272 Bug ID: 459272 Summary: Unable to navigate submenus with cursor keys Classification: Unclassified Product: plasmashell Version: 5.25.5 Platform: Archlinux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Application Menu (Kicker) Assignee: plasma-b...@kde.org Reporter: dev-...@felsenfleischer.de Target Milestone: 1.0 SUMMARY I just noticed that I can’t navigate to submenus in the cascading menu anymore. I can only go up and down on the main menu level and open a submenu with cursor right, but while the visible selection mark enters the menu, the actual focus does not. Instead, pressing up/down still changes the top-level menu selection. STEPS TO REPRODUCE 1. Press to open the menu. 2. Use cursor up/down to select a menu. 3. Press cursor right to open a submenu. The first item of the submenu is highlighted. OBSERVED RESULT Selection focus stays in the top level. Pressing up/down when the submenu item is highlighted still selects a new menu here instead. If the highlighted submenu item is a menu item itself, pressing cursor right again does not enter its subsubmenu. Observed under both X11 and Wayland. EXPECTED RESULT Cursor navigation should be restored to the original and intuitive behavior. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.25.5 KDE Frameworks Version: 5.98.0 Qt Version: 5.15.6 Kernel Version: 5.19.9-arch1-1 (64-bit) Graphics Platform: Wayland -- You are receiving this mail because: You are watching all bug changes.
[kalendar] [Bug 459245] New: Menu cannot be used with cursor left/right keys
https://bugs.kde.org/show_bug.cgi?id=459245 Bug ID: 459245 Summary: Menu cannot be used with cursor left/right keys Classification: Unclassified Product: kalendar Version: 22.08.1 Platform: Archlinux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: claudio.cam...@gmail.com Reporter: dev-...@felsenfleischer.de CC: c...@carlschwan.eu Target Milestone: --- SUMMARY Normally, when a window menu is open, the user can navigate it with cursor up/down for a menu’s item and cursor left/right to go to the prievious or next menu. In Kalendar, the left/right keys are eaten by the main view while a menu is open. STEPS TO REPRODUCE 1. Open a menu, e.g. File (with Alt+F) 2. Press cursor right OBSERVED RESULT The calendar view goes to the next month. EXPECTED RESULT The menu right of File should open. Operating System: Arch Linux KDE Plasma Version: 5.25.5 KDE Frameworks Version: 5.98.0 Qt Version: 5.15.6 Kernel Version: 5.19.7-arch1-1 (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 458615] Window frame is shown as inactive after input of shortcut
https://bugs.kde.org/show_bug.cgi?id=458615 --- Comment #5 from Frank Steinmetzger --- (In reply to Nate Graham from comment #4) > Cannot reproduce on Wayland. I’m on X11. ;-) One of my devices runs on Wayland, because it has a touch screen. I can’t reproduce it there, either. > Does this happens in other windows that use the same shortcut picker, such > as the config dialogs for Plasma widgets? I tried it in three places: system settings, menu editor (through right click on the „start menu“) and in Dolphin→Configure shortcuts. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kglobalaccel] [Bug 458615] Window frame is shown as inactive after input of shortcut
https://bugs.kde.org/show_bug.cgi?id=458615 --- Comment #1 from Frank Steinmetzger --- Created attachment 151773 --> https://bugs.kde.org/attachment.cgi?id=151773=edit Screen capture of the issue Oops, forgot to select a file to attach in the OP. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kglobalaccel] [Bug 458615] New: Window frame is shown as inactive after input of shortcut
https://bugs.kde.org/show_bug.cgi?id=458615 Bug ID: 458615 Summary: Window frame is shown as inactive after input of shortcut Product: frameworks-kglobalaccel Version: 5.97.0 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: general Assignee: kdelibs-b...@kde.org Reporter: dev-...@felsenfleischer.de Target Milestone: --- SUMMARY Whenever I configure a custom shortcut in KDE, be it in system settings, the menu editor or an application’s own shortcuts, afterwards the window which contains the shortcut settings is drawn as if it were inactive. I need to switch focus away from it and back for the frame to be drawn as active again. It could be a kwin bug, but I suspect something in the shortcut assignment logic creates an invisible window to catch input and then does not return the original window to its original state. STEPS TO REPRODUCE 1. Open any shortcut setting dialog 2. Enter a new custom keyboard shortcut OBSERVED RESULT The window frame colour changes to inactive. EXPECTED RESULT The colour should not change. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.25.4 KDE Frameworks Version: 5.97.0 Qt Version: 5.15.5 Kernel Version: 5.19.3-arch1-1 (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Core™ i5-4590 CPU @ 3.30GHz Memory: 30.8 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 4600 Manufacturer: MSI -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kglobalaccel] [Bug 458213] Cannot launch certain applications with global shortcut
https://bugs.kde.org/show_bug.cgi?id=458213 --- Comment #7 from Frank Steinmetzger --- (In reply to Nate Graham from comment #6) > Ah this is Bug 440507 which is already fixed in 5.98. I hope you’re right. I was aware of that bug, but since gwenview’s Exec line also contained arguments, I thought I was experiencing a different problem. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kglobalaccel] [Bug 458213] Cannot launch certain applications with global shortcut
https://bugs.kde.org/show_bug.cgi?id=458213 --- Comment #5 from Frank Steinmetzger --- (In reply to Nate Graham from comment #4) > On the affected machine, is the kglobalaccel daemon not running? Yes: $ pgrep kglobalaccel 1093 16940 This is also backed by the fact that other shortcuts work, it’s only Kate and Libreoffice Start Center that I can’t get to launch. And I just discovered a new interesting tidbit: I wanted to assign Meta+O (usually for libreoffice) to another Program. I opened the menu editor, selected Okular, clicked on the assignment button and pressed Meta+O. I get asked whether I want to reassign. I click yes. but the shortcut button now says “None”. The reassignment only works if I remove the shortcut from its current assignment manually. The same goes for Meta+W, but *not* for example for Meta+G, which is one of the still working shortcuts. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kglobalaccel] [Bug 458213] Cannot launch certain applications with global shortcut
https://bugs.kde.org/show_bug.cgi?id=458213 --- Comment #3 from Frank Steinmetzger --- (In reply to Nate Graham from comment #2) > For the affected apps, can you attach their .desktop files in > ~/.local/share/applications? I think I might know what's going on, but I > need to see the .desktop files to be sure. Unfortunately, I don’t have any desktop files at that location for those two applications. One more factoid: I have three machines, all running the (almost) identical KDE-based Arch linux setup. Yesterday I noticed that the shortcuts work on my laptop. Muscle memory dies slowly when trying to launch a text editor. Well now I am totally unsure whether they didn’t work there before or when they started working again. Per-maybe-haps it was fixed with the recent upgrade to 5.97? Anyways. Now, only one machine remains affected. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 453890] Umount icon unnecessarily shown for internal drives
https://bugs.kde.org/show_bug.cgi?id=453890 --- Comment #23 from Frank Steinmetzger --- (In reply to Kai Uwe Broulik from comment #22) > Can you check in solid-hardware5 list for those drives and then post the > output of solid-hardware5 details for each one of these. I used to have most of my internal SATA-drives set to hotpluggable in the BIOS, mostly because I have a dual hotswap bay installed. It is currently not in use, though. Nowadays, all the partitions shown on my screenshot reside on an NVMe drive, which by definition is not hot-pluggable, AFAIK. Before I post the whole wall of text from solid-hardware5, here is a summary, I hope the formatting is retained: > Device Name Mount pointRemove button shown > > nvme 1 boot /boot entry not shown in Dolphin > nvme 3 windows /mnt/windows no > nvme 4 (LVM base partition) no > dm-1 arch / no > dm-2 home /home no > dm-3 gentoo/mnt/gentooyes > dm-4 data /mnt/data yes Looking at your list of criteria again, I think I may see the problem: my affected partitions all reside on LVM and not on NVMe directly (like the unaffected windows partition). So maybe solid knows that the NVMe drive is not hot-pluggable, but does not know this about LVM. Or maybe it even assumes that LVM *is* hot-pluggable (except for / and $HOME). The boot partition (not shown in Dolphin, possibly due to StorageVolume.ignored?): solid-hardware5 details '/org/freedesktop/UDisks2/block_devices/nvme0n1p1' udi = '/org/freedesktop/UDisks2/block_devices/nvme0n1p1' parent = '/org/freedesktop/UDisks2/drives/Samsung_SSD_970_EVO_Plus_2TB_xxx' (string) vendor = '' (string) product = 'Samsung SSD 970 EVO Plus 2TB' (string) description = 'EFI system partition' (string) icon = 'drive-harddisk' (string) Block.major = 259 (0x103) (int) Block.minor = 1 (0x1) (int) Block.device = '/dev/nvme0n1p1' (string) StorageAccess.accessible = true (bool) StorageAccess.filePath = '/boot' (string) StorageAccess.ignored = true (bool) StorageAccess.encrypted = false (bool) StorageVolume.ignored = true (bool) StorageVolume.usage = 'FileSystem' (0x2) (enum) StorageVolume.fsType = 'vfat' (string) StorageVolume.label = 'EFI system partition' (string) StorageVolume.uuid = 'e875-7c1b' (string) StorageVolume.size = 104857600 (0x640) (qulonglong) The windows partition at /mnt/windows (shown without remove button): solid-hardware5 details '/org/freedesktop/UDisks2/block_devices/nvme0n1p3' udi = '/org/freedesktop/UDisks2/block_devices/nvme0n1p3' parent = '/org/freedesktop/UDisks2/drives/Samsung_SSD_970_EVO_Plus_2TB_xxx' (string) vendor = '' (string) product = 'Samsung SSD 970 EVO Plus 2TB' (string) description = 'Windows' (string) icon = 'drive-harddisk' (string) Block.major = 259 (0x103) (int) Block.minor = 3 (0x3) (int) Block.device = '/dev/nvme0n1p3' (string) StorageAccess.accessible = true (bool) StorageAccess.filePath = '/mnt/windows' (string) StorageAccess.ignored = true (bool) StorageAccess.encrypted = false (bool) StorageVolume.ignored = false (bool) StorageVolume.usage = 'FileSystem' (0x2) (enum) StorageVolume.fsType = 'ntfs' (string) StorageVolume.label = 'Windows' (string) StorageVolume.uuid = '3c0ec7340ec6e64c' (string) StorageVolume.size = 20971520 (0x30d400) (qulonglong) My system’s root partition (LVM-lv "arch"): solid-hardware5 details '/org/freedesktop/UDisks2/block_devices/dm_2d1' udi = '/org/freedesktop/UDisks2/block_devices/dm_2d1' parent = '/' (string) vendor = '' (string) product = '' (string) description = 'arch' (string) icon = 'drive-harddisk-root' (string) Block.major = 254 (0xfe) (int) Block.minor = 1 (0x1) (int) Block.device = '/dev/dm-1' (string) StorageAccess.accessible = true (bool) StorageAccess.filePath = '/' (string) StorageAccess.ignored = true (bool) StorageAccess.encrypted = false (bool) StorageVolume.ignored = false (bool) StorageVolume.usage = 'FileSystem' (0x2) (enum) StorageVolume.fsType = 'ext4' (string) StorageVolume.label = 'arch' (string) StorageVolume.uuid = '59056c42-c6f3-4975-a56f-d86e64c003bb' (string) StorageVolume.size = 47244640256 (0xb) (qulonglong) The home partition (LVM-lv "home"): solid-hardware5 details '/org/freedesktop/UDisks2/block_devices/dm_2d2' udi = '/org/freedesktop/UDisks2/block_devices/dm_2d2' parent = '/' (string) vendor = '' (string) product = '' (string) description = 'home' (string) icon = 'drive-harddisk' (string) Block.major = 254 (0xfe) (int) Block.minor = 2 (0x2) (int) Block.device = '/dev/dm-2' (string) StorageAccess.accessible = true (bool) StorageAccess.filePath = '/home' (string) StorageAccess.ignored
[frameworks-kio] [Bug 453890] Umount icon unnecessarily shown for internal drives
https://bugs.kde.org/show_bug.cgi?id=453890 Frank Steinmetzger changed: What|Removed |Added CC||dev-...@felsenfleischer.de --- Comment #21 from Frank Steinmetzger --- Created attachment 151529 --> https://bugs.kde.org/attachment.cgi?id=151529=edit Screenshot Having just upgraded to 22.08, I came to this bug from Nate Graham’s blog, where he links to here and states that ‘The “Eject” button next to mounted disks in Dolphin’s Places panel no longer appears for internal disks and those manually added to your /etc/fstab file’. Sadly, I must disagree to his statement. I have several partitions on my internal NVMe drive, all of which have an auto-mount entry in fstab, and two of them have a remove button. Interestingly, they are both mounted under /mnt (data and gentoo). But that in itself is not the cause, because there is a third, /mnt/windows, and it has no remove button. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kirigami] [Bug 458219] New: Setting from widget style whether to show keyboard accelerators is ignored
https://bugs.kde.org/show_bug.cgi?id=458219 Bug ID: 458219 Summary: Setting from widget style whether to show keyboard accelerators is ignored Product: frameworks-kirigami Version: 5.97.0 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kdelibs-b...@kde.org Reporter: dev-...@felsenfleischer.de CC: notm...@gmail.com Target Milestone: Not decided SUMMARY I was investigating other bugs when I noticed that Elisa’s settings dialog always hides the accelerators and only shows them when Alt is pressed. But when I switch the application widget style while the dialog is left open (and accelerators are set to always show in the style), the underlines are shown permanently in the dialog *until* I press Alt again. At first I thought it was an Elisa issue, but the settings dialog for the digital clock has the same problem. So I figured this is a Plasma issue. Hence I filed this under kirigami, I hope that is correct. STEPS TO REPRODUCE 1. Set up an application widget style that is set to always show keyboard accelerator underlines. In my case, I tried Breeze and QtCurve. 2. Confirm the setting for example by opening Kate’s configuration dialog which has lots of shortcuts. 3. Open Elisa’s settings or the Plasma digital clock’s configuration. OBSERVED RESULT The dialogs opened in step 3 always show the accelerators only when the user presses Alt, irrespective of the widget style setting. EXPECTED RESULT The setting shall be obeyed. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.25.4 KDE Frameworks Version: 5.97.0 Qt Version: 5.15.5 Kernel Version: 5.19.3-arch1-1 (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Core™ i5-4590 CPU @ 3.30GHz Memory: 30.8 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 4600 Manufacturer: MSI Product Name: MS-7924 System Version: 1.0 -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 458217] New: Application style settings: comboboxes have unnecessary padding to the right, causing truncated text
https://bugs.kde.org/show_bug.cgi?id=458217 Bug ID: 458217 Summary: Application style settings: comboboxes have unnecessary padding to the right, causing truncated text Product: Breeze Version: 5.25.4 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: dev-...@felsenfleischer.de CC: uhh...@gmail.com Target Milestone: --- Created attachment 151528 --> https://bugs.kde.org/attachment.cgi?id=151528=edit Screenshot STEPS TO REPRODUCE 1. Go to system settings → Appearance → Application style 2. Click on the configure button for Breeze OBSERVED RESULT The two comboboxes on the first tab are too narrow. Or rather, they are narrower than is possible, because there is whitespace to the right. EXPECTED RESULT Use all available space that is there, just as the controls on the other tabs of the dialog. -- You are receiving this mail because: You are watching all bug changes.
[Elisa] [Bug 458215] New: Elisa settings: indexing method combobox is too narrow
https://bugs.kde.org/show_bug.cgi?id=458215 Bug ID: 458215 Summary: Elisa settings: indexing method combobox is too narrow Product: Elisa Version: 22.08.0 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: matthieu_gall...@yahoo.fr Reporter: dev-...@felsenfleischer.de Target Milestone: --- Created attachment 151527 --> https://bugs.kde.org/attachment.cgi?id=151527=edit Screenshot See the attached screenshot. Maybe it is wide enough for the English texts, but not for the German ones. The image shows the QtCurve style, but the problem also exists with Breeze. Operating System: Arch Linux KDE Plasma Version: 5.25.4 KDE Frameworks Version: 5.97.0 Qt Version: 5.15.5 Kernel Version: 5.19.3-arch1-1 (64-bit) Graphics Platform: X11 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kglobalaccel] [Bug 458213] Cannot launch certain applications with global shortcut
https://bugs.kde.org/show_bug.cgi?id=458213 --- Comment #1 from Frank Steinmetzger --- Additional Info: The problem is definitely not the shortcut itself. I just assigned Meta+W (my usual kate shortcut) to kcachegrind and it worked right away. On the other hand, assigning a different one to kate (like Meta+G, which is my usual Gwenview shortcut) had no effect. Another evidence that the shortcut itself is working, but not the launch part: if Meta+letter is not assigned to a shortcut and I press it, the letter appears in whatever input widget is currently focused. Once assigned to kate, the letter does not appear anymore, but obviously Kate does not open. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kglobalaccel] [Bug 458213] New: Cannot launch certain applications with global shortcut
https://bugs.kde.org/show_bug.cgi?id=458213 Bug ID: 458213 Summary: Cannot launch certain applications with global shortcut Product: frameworks-kglobalaccel Version: 5.97.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kdelibs-b...@kde.org Reporter: dev-...@felsenfleischer.de Target Milestone: --- SUMMARY For many years I’ve been using Meta+letter shortcuts to launch various applications. Among them: Meta+G = Gwenview, Meta+I = Gimp, Meta+K = Konsole and so on. For a longer while now, two of them stopped working (there may be more applications affected, I just haven’t assigned them). They are kate and Libreoffice, which were assigned to Meta+W and Meta+O, respectively. Over the last weeks and months I repeatedly tried removing and reassigning the shortcut both in the menu editor and in system settings’ shortcut module. I tried removing ~/.config/kglobalshortcutsrc and I even tested it with a brand new user account, in order to rule out config cruft in my existing account. Nothing helped. STEPS TO REPRODUCE Method one: Menu editor 1. Right-click launcher widget in the panel, select Edit menu items 2. Filter for Kate, select it and go to the Advanced tab and set a keyboard shortcut 3. Save the setting (Ctrl+S) 4. Press the shortcut Method two: system settings 1. Open system settings 2. Go to shortcuts 3. Add application (button at the bottom left) 4. Select kate 5. Add a custom shortcut on the right 6. Apply 7. Press the shortcut OBSERVED RESULT Nothing happens, Kate is not launched. EXPECTED RESULT Kate should start. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.25.4 KDE Frameworks Version: 5.97.0 Qt Version: 5.15.5 Kernel Version: 5.19.3-arch1-1 (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Core™ i5-4590 CPU @ 3.30GHz Memory: 30.8 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 4600 -- You are receiving this mail because: You are watching all bug changes.
[kmymoney] [Bug 453857] malloc() aborts during save
https://bugs.kde.org/show_bug.cgi?id=453857 Frank Steinmetzger changed: What|Removed |Added CC||dev-...@felsenfleischer.de -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 453383] New: Reply mails are shown in wrong thread after being moved to a different folder (in Kontact)
https://bugs.kde.org/show_bug.cgi?id=453383 Bug ID: 453383 Summary: Reply mails are shown in wrong thread after being moved to a different folder (in Kontact) Product: kmail2 Version: 5.20.0 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: folders Assignee: kdepim-b...@kde.org Reporter: dev-...@felsenfleischer.de Target Milestone: --- Created attachment 148558 --> https://bugs.kde.org/attachment.cgi?id=148558=edit Comparison of inbox view between Kontact and Kmail I’ve been observing this issue now for a very long time now. I thought something this obvious must be noticed easily. But it seems I hit a niche and it just happened again, so I finally decided to report it. STEPS TO REPRODUCE I just sent replies to two different mail threads in an IMAP account. KMail stored the replies in the Sent folder, as usual. I went to the folder, selected both mails and moved them to the Inbox folder, so they may be shown within their respective threads. OBSERVED RESULT The mails were shown in the wrong thread: replay to thread A is shown in thread B and vice versa. EXPECTED RESULT The mails should appear as reply to the correct mail. Operating System: Arch Linux KDE Plasma Version: 5.24.5 KDE Frameworks Version: 5.93.0 Qt Version: 5.15.3 Kernel Version: 5.17.5-arch1-1 (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Core™ i5-5200U CPU @ 2.20GHz Memory: 15.5 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 5500 ADDITIONAL INFORMATION One very interesting bit of info that I found out just now: the issue only appears in Kontakt. I closed Kontact and opened KMail as standalone application, and in there the threads were correct. Then I closed KMail and reopened Kontact, and the mails were mixed up again. I did this twice, both times with the same result. So perhaps this is a Kontact thing, or an Akonadi bug? I haven’t tested yet what happens if I move mail in standalone-KMail, so whether the (akonadi?) data is garbled during the move or during display. I also looked at the mail source to make sure the In-Reply-To header was correct. But I already knew it was so, because when I sync the account with offlineimap and view it in mutt, the thread is also correct. I have akonadiconsole installed, so I am happy to provide deeper info if required. While preparing the screenshots, I also noticed that the structure of the lower thread is different between the two programs (see circles in the image). Apparently there has been a similar hickup in the thread before. -- You are receiving this mail because: You are watching all bug changes.
[i18n] [Bug 453334] [Kasts] German Translation in the Network settings include two typos
https://bugs.kde.org/show_bug.cgi?id=453334 Frank Steinmetzger changed: What|Removed |Added Assignee|kde-i18n...@kde.org |dev-...@felsenfleischer.de Status|REPORTED|ASSIGNED Ever confirmed|0 |1 CC||dev-...@felsenfleischer.de -- You are receiving this mail because: You are watching all bug changes.
[kmail2] [Bug 453194] New: Manual linebreaks in tooltip strings
https://bugs.kde.org/show_bug.cgi?id=453194 Bug ID: 453194 Summary: Manual linebreaks in tooltip strings Product: kmail2 Version: 5.20.0 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: UI Assignee: kdepim-b...@kde.org Reporter: dev-...@felsenfleischer.de Target Milestone: --- Created attachment 148458 --> https://bugs.kde.org/attachment.cgi?id=148458=edit Screenshot giving an example in the Composer configuration dialog Hello devs, I am currently reviewing the German translation of kmail and came across a lot of tooltip strings that use manual linebreaks (\n). Looking at my running instance, those linebreaks cause what was called "combing" in the newsgroup days: in addition to the manual breaks, lines were also auto-wrapped by the tooltip frame, which causes alternating long and short lines of text. So my question is: are those breaks intentional, are they an oversight, or is this “historical ballast” dating from a time when tooltips did not auto-wrapp at all? I propose disposing of those breaks and let the system choose. Operating System: Arch Linux KDE Plasma Version: 5.24.4 KDE Frameworks Version: 5.93.0 Qt Version: 5.15.3 Kernel Version: 5.17.4-arch1-1 (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Celeron® N5100 @ 1.10GHz Memory: 15.4 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics -- You are receiving this mail because: You are watching all bug changes.
[kalendar] [Bug 453068] New: Pane for event details should always be visible, so the layout stays constant
https://bugs.kde.org/show_bug.cgi?id=453068 Bug ID: 453068 Summary: Pane for event details should always be visible, so the layout stays constant Product: kalendar Version: 22.04.0 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: general Assignee: claudio.cam...@gmail.com Reporter: dev-...@felsenfleischer.de CC: c...@carlschwan.eu Target Milestone: --- I just discovered Kalendar due to a recommendation under a current bug in Korganizer. ;-) So I had a quick look through everything, using my two radicale calendars and contact birthdays. Right in the first few moments I noticed an example of -- in my very humble opinion -- bad UI design: the details pane which wooshes in and out of the view. My reasoning is that it constantly rearranges the layout of the whole window, which is very distracting to the eye and confuses the user's orientation. EXAMPLE Consider the month view, and in it a day that has two events. I want to view the details of both of them. So I click on the first and while my eyes go off to read the details, my hand already moves the mouse to the next event automatically and blindly. OBSERVED RESULT The details pane, by moving into view, now squeezes the month view, which causes that next event to move away from the anticipated location. EXPECTED RESULT The main view layout should remain constant. When no event is selected, the pane may be left entirely empty, or get an empty-label, sort of like Dolphin does in empty directories. Something along the lines of "Select an event to show details here". Thanks for your work and consideration. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.24.4 KDE Frameworks Version: 5.93.0 Qt Version: 5.15.3 Kernel Version: 5.17.4-arch1-1 (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Celeron® N5100 @ 1.10GHz Memory: 15.4 GiB of RAM Graphics Processor: Mesa Intel® UHD Graphics -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 451184] Action buttons do not appear when an item moves to under the mouse, in particular after deleting an item
https://bugs.kde.org/show_bug.cgi?id=451184 --- Comment #2 from Frank Steinmetzger --- Created attachment 147711 --> https://bugs.kde.org/attachment.cgi?id=147711=edit Screencapture as requested First I delete item “a”, then click on where the delete button would be for item “b”. But instead of deleting, I select it. Then I open the panel again (note that “b” is the topmost one item) and delete it and item “c”, including moving the mouse afterwards, so the delete button reappears. Then I delete item “d” and don’t move the mouse, which prevents the delete button from appearing. Thus I select item “e” with the next click. -- You are receiving this mail because: You are watching all bug changes.
[i18n] [Bug 451560] Missing German localization in Plasma Taskbar
https://bugs.kde.org/show_bug.cgi?id=451560 Frank Steinmetzger changed: What|Removed |Added Status|CONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Frank Steinmetzger --- Danke für den Hinweis. Des String und einiger weiterer in den Einstellungen fehlenden wurde sich angenommen. -- You are receiving this mail because: You are watching all bug changes.
[i18n] [Bug 451560] Missing German localization in Plasma Taskbar
https://bugs.kde.org/show_bug.cgi?id=451560 Frank Steinmetzger changed: What|Removed |Added CC||dev-...@felsenfleischer.de Ever confirmed|0 |1 Status|REPORTED|CONFIRMED -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 446295] The accept dialog after changing screen resolution is not modal and is not properly set up for operation with the keyboard
https://bugs.kde.org/show_bug.cgi?id=446295 --- Comment #3 from Frank Steinmetzger --- Probably thanks to Méven's change, pressing enter works now (just tested on 5.24.3), but only if a button is focused. Well, that's correct of course, but getting there is another story: - None of the buttons is focused by default - focus leaves the dialog after a few presses on Tab In essence, it's something that is made to look like a dialog, while technically it is not, bringing with it the baggage to have to reimplement expected default behaviours. The tab order also is a bit weird when going back and forth with Tab/Shift+Tab: - press Tab a few times initially to reach the Accept button - press Tab again, the Accept button is still focused - press Tab once more, and now the Revert button is focused - in the other direction (with Shift+Tab) the focus stays on the Accept button for only one cycle. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 446295] The accept dialog after changing screen resolution is not modal and is not properly set up for operation with the keyboard
https://bugs.kde.org/show_bug.cgi?id=446295 Frank Steinmetzger changed: What|Removed |Added CC||k...@privat.broulik.de --- Comment #2 from Frank Steinmetzger --- *** Bug 451274 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 451274] Cannot accept prompt on screen configuration change with Return
https://bugs.kde.org/show_bug.cgi?id=451274 Frank Steinmetzger changed: What|Removed |Added Status|REPORTED|RESOLVED CC||dev-...@felsenfleischer.de Resolution|--- |DUPLICATE --- Comment #1 from Frank Steinmetzger --- *** This bug has been marked as a duplicate of bug 446295 *** -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 451488] New: When changing default paths, ask whether to move the physical directory
https://bugs.kde.org/show_bug.cgi?id=451488 Bug ID: 451488 Summary: When changing default paths, ask whether to move the physical directory Product: systemsettings Version: 5.24.3 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: kcm_desktoppath Assignee: plasma-b...@kde.org Reporter: dev-...@felsenfleischer.de Target Milestone: --- SUMMARY When I change the location of a default path in System settings→Applications→Locations, I usually do this because I want to rename the actual directory. Another use case is the default paths having been created with English names before I could switch the workspace to my local language. So if the old location exists, then a dialog would be nice: „Shall the existing directory be moved to the new location?“ And if the new location already exists, just confirm whether to move the contents into it, especially if the destination is not empty. Maybe even use the same dialog for that as when moving something in Dolphin, so we get a nice progress indicator for longer operations. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.24.3 KDE Frameworks Version: 5.91.0 Qt Version: 5.15.3 Kernel Version: 5.16.11-arch1-1-surface (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Pentium® CPU 4415Y @ 1.60GHz Memory: 7.7 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 615 -- You are receiving this mail because: You are watching all bug changes.
[lokalize] [Bug 451461] New: Rescan of translation memory never finishes in the GUI
https://bugs.kde.org/show_bug.cgi?id=451461 Bug ID: 451461 Summary: Rescan of translation memory never finishes in the GUI Product: lokalize Version: 21.12.3 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: translation memory Assignee: sdepi...@gmail.com Reporter: dev-...@felsenfleischer.de CC: sha...@ukr.net Target Milestone: --- STEPS TO REPRODUCE 1. Load a project 2. Start a full project rescan 3. The scan starts, its progress is shown both in the task bar item and in a plasma notification OBSERVED RESULT After a files have been processed, the progress never changes to the finished state, i.e. the “progress bar” in the task bar remains at 100 % and the notification shows a Stop button. EXPECTED RESULT The notification should change its text to a “Finished reading %1 files“ message, hide the Stop button and ultimately go away by itself. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.24.3 KDE Frameworks Version: 5.91.0 Qt Version: 5.15.3 Kernel Version: 5.16.13-arch1-1 (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Core™ i5-4590 CPU @ 3.30GHz Memory: 31.0 GiB of RAM Graphics Processor: Mesa DRI Intel® HD Graphics 4600 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 451256] An empty album displays a notification message that the database query returned no result
https://bugs.kde.org/show_bug.cgi?id=451256 --- Comment #2 from Frank Steinmetzger --- Hehe, I see. OK, then let’s see if we can accommodate everyone. The easiest way would be to display the text inside the main view, as I mentioned with my Dolphin reference. Perhaps not show it in the centre of the screen, but on the topleft, so it can easily be found with the eyes, because photo management screens tend to be large. This would even allow for a progress message like “Searching …” — but only in case the query takes longer. Otherwise we would risk constantly flickering text when browsing through albums. So as a step-by-step: 10 user selects album 20 wait for result, but one second maximum (arbitrary value, the actual best-fitting duration should be determined in experiments. It should prevent annoying distraction of the eye when clicking through albums) 30 search result available? → display result or message “This album is empty.” or “The search returned no results.”. End. 40 no result yet? → Display “Searching ...” message and wait for result indefinitely. 50 Result is available, goto 30 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 451256] New: An empty album displays a notification message that the database query returned no result
https://bugs.kde.org/show_bug.cgi?id=451256 Bug ID: 451256 Summary: An empty album displays a notification message that the database query returned no result Product: digikam Version: 7.5.0 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Albums-MainView Assignee: digikam-bugs-n...@kde.org Reporter: dev-...@felsenfleischer.de Target Milestone: --- SUMMARY When the user selects an album from the album tree which has no images, a notification appears at the top of the main view, starting with “The current query from the database returned no results.“ This is bad UI design. It is perfectly normal that an album may be empty, e.g. if it is just the parent for subalbums. A notification is used to get the user’s attention. But an empty album is nothing to be alarmed about. Another problem this creates is that when I select a non-empty album next, the image list is display and then the notification goes away. This causes the images to shift up on the screen. OBSERVED RESULT Empty albums show a notification that they are empty. The notification goes away after a few seconds. EXPECTED RESULT There should be no notification. If the user has to be told that this album is in fact empty, then the better way would be to use the mainview for that (see Dolphin for an example). SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.24.2 KDE Frameworks Version: 5.91.0 Qt Version: 5.15.3 Kernel Version: 5.16.12-arch1-1 (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Core™ i5-4590 CPU @ 3.30GHz Memory: 31.0 GiB of RAM Graphics Processor: Mesa DRI Intel® HD Graphics 4600 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 451184] New: Action buttons should appear when an item moves to under the mouse, in particular after deleting an item
https://bugs.kde.org/show_bug.cgi?id=451184 Bug ID: 451184 Summary: Action buttons should appear when an item moves to under the mouse, in particular after deleting an item Product: plasmashell Version: 5.24.2 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Clipboard Assignee: plasma-b...@kde.org Reporter: dev-...@felsenfleischer.de Target Milestone: 1.0 SUMMARY When I want to delete several clipboard items in succession, it is not possible to just repeatedly click at the place of the delete button and let the items move up under the mouse cursor, because the button of the next item does not appear, even though it would be right under the mouse cursor. If I now click, the item is instead selected and the popup closes. In case my description is not good enough, I’m happy to provide a video capture. STEPS TO REPRODUCE 1. Have several items in the clipboard. 2. Move mouse over the delete button of an item and click it. 3. The item is deleted and the items around it move up to fill the space. 4. Click again where the delete button was to delete the next item. OBSERVED RESULT The delete button of the item that moved up does not appear unless the mouse is moved again. As a result, the click does not trigger a delete action, but instead selects the item and the clipboard popup closes. EXPECTED RESULT I would like for the buttons to appear, because they are right under the mouse cursor in that moment. This is quite the same behaviour as when I delete items from the notification list (where the dismiss button is not hover-activated) or from the (vertical) tab bar in a browser. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.24.2 KDE Frameworks Version: 5.91.0 Qt Version: 5.15.2 Kernel Version: 5.16.12-arch1-1 (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Core™ i5-4590 CPU @ 3.30GHz Memory: 31.0 GiB of RAM Graphics Processor: Mesa DRI Intel® HD Graphics 4600 -- You are receiving this mail because: You are watching all bug changes.
[kaddressbook] [Bug 451177] New: Kaddressbook asks to cancel contact editing even if nothing was changed
https://bugs.kde.org/show_bug.cgi?id=451177 Bug ID: 451177 Summary: Kaddressbook asks to cancel contact editing even if nothing was changed Product: kaddressbook Version: 5.19.3 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: general Assignee: kdepim-b...@kde.org Reporter: dev-...@felsenfleischer.de CC: to...@kde.org Target Milestone: --- STEPS TO REPRODUCE 1. Open a contact by double-clicking it. 2. Click on cancel. OBSERVED RESULT The user is asked whether to really cancel or not. EXPECTED RESULT If nothing was changed, there is no harm in closing immediately. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.24.2 KDE Frameworks Version: 5.91.0 Qt Version: 5.15.2 Kernel Version: 5.16.12-arch1-1 (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Core™ i5-4590 CPU @ 3.30GHz Memory: 31.0 GiB of RAM Graphics Processor: Mesa DRI Intel® HD Graphics 4600 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 450699] bad margins in notification layout
https://bugs.kde.org/show_bug.cgi?id=450699 --- Comment #1 from Frank Steinmetzger --- Created attachment 147045 --> https://bugs.kde.org/attachment.cgi?id=147045=edit Screenshot of a notificcation with scrollable message text Oops, forgot the screenshot -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 450699] New: bad margins in notification layout
https://bugs.kde.org/show_bug.cgi?id=450699 Bug ID: 450699 Summary: bad margins in notification layout Product: plasmashell Version: 5.23.4 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Notifications Assignee: plasma-b...@kde.org Reporter: dev-...@felsenfleischer.de CC: k...@privat.broulik.de Target Milestone: 1.0 SUMMARY I noticed that, for small message texts, the bold text sits too close to the dividing line towards the heading, giving it an asymmetric appearance. This irks me. :) Examining it more as a preparation for this ticket, I noticed the clunky margins around the scrollbar in case the message text becomes longer. Apparently the scrollbar itself has a four-sided margin, so it keeps its distance from the vertical 1-pixel-line that separates it from the text. Why is this line there in the first place? An optical separation between scrollbar and the content it scrolls is illogical. Also, the margin around the scrollbar should only exist between the scrollbar and the text. Because – like all other client content – the scrollbar should have a „normal“ distance to the notification edge. This would also give more room to the scrollbar without enlarging the notification, which in turn improves scrollbar accuracy. ADDITIONAL INFORMATION Screenshot taken on a tablet with 216 ppi screen, font DPI is thus set at 192. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.24.0 KDE Frameworks Version: 5.90.0 Qt Version: 5.15.2 Kernel Version: 5.16.9-arch1-1-surface (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Pentium® CPU 4415Y @ 1.60GHz Memory: 7.7 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 615 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 450589] New: "Save as": Cancelling the filename dialog does not cancel "Save as"
https://bugs.kde.org/show_bug.cgi?id=450589 Bug ID: 450589 Summary: "Save as": Cancelling the filename dialog does not cancel "Save as" Product: digikam Version: 7.5.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Showfoto-Save Assignee: digikam-bugs-n...@kde.org Reporter: war...@gmx.de Target Milestone: --- STEPS TO REPRODUCE 1. Edit an image 2. Execute "Save as" 3. Change your mind and press Escape to cancel the filename dialog OBSERVED RESULT The jpeg compression dialog comes up. EXPECTED RESULT The dialog should not appear. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.24.1 KDE Frameworks Version: 5.91.0 Qt Version: 5.15.2 Kernel Version: 5.16.9-arch1-1 (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Core™ i5-4590 CPU @ 3.30GHz Memory: 31.0 GiB of RAM Graphics Processor: Mesa DRI Intel® HD Graphics 4600 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 450588] New: "Save" does not work if image was removed outside of Showfoto
https://bugs.kde.org/show_bug.cgi?id=450588 Bug ID: 450588 Summary: "Save" does not work if image was removed outside of Showfoto Product: digikam Version: 7.5.0 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Showfoto-Save Assignee: digikam-bugs-n...@kde.org Reporter: war...@gmx.de Target Milestone: --- STEPS TO REPRODUCE 1. Edit an image. 2. Save it. 3. Do some more editing. 4. Move away the image, for example in Dolphin. My goal in that moment was to have two versions of the image with different edits so that I can compare the effects. 5. Execute "Save" again (I didn’t use "Save as" because I wanted to avoid its more complex process). OBSERVED RESULT Showfoto produces an error message “Failed to save file”. EXPECTED RESULT Saving should work like in any other application in such a situation. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.24.1 KDE Frameworks Version: 5.91.0 Qt Version: 5.15.2 Kernel Version: 5.16.9-arch1-1 (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Core™ i5-4590 CPU @ 3.30GHz Memory: 31.0 GiB of RAM Graphics Processor: Mesa DRI Intel® HD Graphics 4600 -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 450587] New: Inconsistent disabled state of Save action after Undo/Redo
https://bugs.kde.org/show_bug.cgi?id=450587 Bug ID: 450587 Summary: Inconsistent disabled state of Save action after Undo/Redo Product: digikam Version: 7.5.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Showfoto-Save Assignee: digikam-bugs-n...@kde.org Reporter: war...@gmx.de Target Milestone: --- SUMMARY The Save action is not re-enabled after using Undo/Redo. STEPS TO REPRODUCE 1. Make some changes to an image. 2. Save it. The Save action becomes disabled (correct). 4. Undo last change. Save becomes enabled (correct). 4. Save it again. Save becomes disabled (correct). 5. Redo the change. OBSERVED RESULT Save remains disabled. EXPECTED RESULT Save should be enabled again. SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.24.1 KDE Frameworks Version: 5.91.0 Qt Version: 5.15.2 Kernel Version: 5.16.9-arch1-1 (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Core™ i5-4590 CPU @ 3.30GHz Memory: 31.0 GiB of RAM Graphics Processor: Mesa DRI Intel® HD Graphics 4600 -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 373897] Gwenview rolls image slightly when rotating JPEG image (some leftmost pixels are moved rightmost)
https://bugs.kde.org/show_bug.cgi?id=373897 Frank Steinmetzger changed: What|Removed |Added CC||war...@gmx.de --- Comment #8 from Frank Steinmetzger --- I discovered this issue in current Gwenview a while ago. I use this feature a lot when editing screenshots from my android phone. It happens often, but not for every single image I edit and I haven’t found out yet why that is. Looking at a binary diff of an image and its rotated version, I noticed that the content is completely different. Is Gwenview actually recompressing the whole image‽ I’ve always assumed that it would only change the appropriate orientation tag, because recompression is a bad idea for jpeg in any case. :( Operating System: Arch Linux KDE Plasma Version: 5.23.5 KDE Frameworks Version: 5.90.0 Qt Version: 5.15.2 Kernel Version: 5.16.5-arch1-1 (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Core™ i5-4590 CPU @ 3.30GHz Memory: 31.0 GiB of RAM Graphics Processor: Mesa DRI Intel® HD Graphics 4600 -- You are receiving this mail because: You are watching all bug changes.
[plasma-systemmonitor] [Bug 448494] disk read/write sensors sometimes report huuuuge values
https://bugs.kde.org/show_bug.cgi?id=448494 --- Comment #2 from Frank Steinmetzger --- Created attachment 145818 --> https://bugs.kde.org/attachment.cgi?id=145818=edit Screen capture of the applet while inserting a USB stick Update: the reason why I never noticed it on my other machine was that it didn’t have a plasmoid with the disk sensors there. So I set one up. Then I plugged in an external disk and as soon as I mounted it, the issue appears—in 100 % of cases. In some instances I didn’t even have to mount it. In the attached screencap, I opened the plasmoid popup to watch it, then plugged in the stick and a fraction of a second later the scales changed without any mounting involved. One interesting detail here is that the sensor values don’t stay at the high level, but return to 0—in contrast to my first screenshot. Only when watching my recording did I notice that I recorded at reduced picture size. So I reset it to 100 % and began another recording, but from then on I was unable to reproduce the issue as I did in the first capture. At first I though that was because recording at FullHD now put a lot more load on the system which may slow down other stuff (thinking of a timing issue). But even after I stopped recording and just replayed my steps about a dozen times, I could not recreate the glitch right at media insertion. -- You are receiving this mail because: You are watching all bug changes.
[plasma-systemmonitor] [Bug 448494] disk read/write sensors sometimes report huuuuge values
https://bugs.kde.org/show_bug.cgi?id=448494 --- Comment #1 from Frank Steinmetzger --- Little update: I just noticed that it’s doing it again. But this time there is no prior suspend. However, earlier I did some juggling with removable storage devices, including ones that are LUKS-encrypted and opened via Dolphin. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 448910] GUI remains disabled after search for similarities returns an empty result
https://bugs.kde.org/show_bug.cgi?id=448910 --- Comment #2 from Frank Steinmetzger --- I use sqlite. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 448910] New: GUI remains disabled after search for similarities returns an empty result
https://bugs.kde.org/show_bug.cgi?id=448910 Bug ID: 448910 Summary: GUI remains disabled after search for similarities returns an empty result Product: digikam Version: 7.5.0 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Searches-Similarity Assignee: digikam-bugs-n...@kde.org Reporter: war...@gmx.de Target Milestone: --- I tried to look for duplicates in a subtree of my collection. STEPS TO REPRODUCE 1. Select an album in the UI, which has subalbums, but no images. Having no previous experience with the UI, I assumed it would search all subalbums, which is not the case. 2. Run search. 3. Now the result list is emptied, the search UI is completely disabled, the search starts and finishes immediately. OBSERVED RESULT The search UI is not enabled again. When I switch to another tab on the left sidebar, and back to the search tab, the result of the *previous* search is shown and *only* the start search button is re-enabled. While research reproducibility, I found another glitch: right after the search finishes and if it returns a non-empty result, the [Remove duplicates] button is enabled right away. When I now switch to another tab and back to the search tab, the button (and only this one) is disabled. EXPECTED RESULT The UI should be fully enabled again. The Enabled state of UI elements should always be comprehensible to the user, depending on the current state of other UI parts. Operating System: Arch Linux KDE Plasma Version: 5.23.5 KDE Frameworks Version: 5.90.0 Qt Version: 5.15.2 Kernel Version: 5.16.1-arch1-1 (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Core™ i5-4590 CPU @ 3.30GHz Memory: 31.0 GiB of RAM Graphics Processor: Mesa DRI Intel® HD Graphics 4600 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 433138] Since update to 5.21, system tray icons on a very thin panel are smaller
https://bugs.kde.org/show_bug.cgi?id=433138 --- Comment #31 from Frank Steinmetzger --- Created attachment 145651 --> https://bugs.kde.org/attachment.cgi?id=145651=edit Whoopsie, forgot the screenshot. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 433138] Since update to 5.21, system tray icons on a very thin panel are smaller
https://bugs.kde.org/show_bug.cgi?id=433138 --- Comment #30 from Frank Steinmetzger --- (In reply to veggero from comment #17) > […] > Frank: The blurryness should have been fixed in 5.21.2 thanks to the above > patch. Please report to me whether everything is fine whet it comes out. (In reply to Frank Steinmetzger from comment #23) > veggero: I just installed 5.21.2 on the two affected systems and another > unaffected one. The icon bluriness has gone away now, both in the taskbar > and also in the tray area. I’m sorry, but I must rescind my previous answer. I’ve been having blurry icons again on my laptop (the one with 176 DPI setting) for quite some time now. I narrowed it down by setting a new DPI and restarting plasmasession. Please look at the screenshot. The panel is always the same size (in pixels). As you can see from the clock’s font, the margin is increasing in pixel count (as is expected to compensate for the higher pixel density, so it always looks the same physically). But for the icons the margins actually shrink. Could this be a sign error? :-) The clipboard icon for 142 DPI is clearly 16×16. But the one for 144 DPI is only 18 px high instead of the next common icon size (22 I believe). So I think it would be nice if plasma knew which sizes it may draw (16, 22, 48, 64 and so in) and which not in order to avoid this. -- You are receiving this mail because: You are watching all bug changes.
[plasma-systemmonitor] [Bug 448494] disk read/write sensors sometimes report huuuuge values
https://bugs.kde.org/show_bug.cgi?id=448494 Frank Steinmetzger changed: What|Removed |Added Summary|disk applet sometimes shows |disk read/write sensors |hge values |sometimes report hge ||values -- You are receiving this mail because: You are watching all bug changes.
[plasma-systemmonitor] [Bug 448494] New: disk applet sometimes shows huuuuge values
https://bugs.kde.org/show_bug.cgi?id=448494 Bug ID: 448494 Summary: disk applet sometimes shows hge values Product: plasma-systemmonitor Version: 5.23.5 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: ksysguard-b...@kde.org Reporter: war...@gmx.de CC: ahiems...@heimr.nl, plasma-b...@kde.org Target Milestone: --- Created attachment 145472 --> https://bugs.kde.org/attachment.cgi?id=145472=edit Screenshot of the issue I usually suspend my PC in the evening. Weeks may go by without reboot or logoff from KDE, meaning a desktop session can live over dozens of suspends. Sometimes, the disk applet doesn’t take kindly to that and has some kind of run-off. I have been observing this problem for quite some time now, but can’t remember for how long precisely. It is rather sporadic. I have no proof that it’s the suspend/resume that causes this, but I can hardly imagine anything else. However, I never saw this on my laptop, which I also suspend almost daily. The PC in question has two SATA drives: a system SSD and a hard disk and several ramdisk. There is also a davfs and an nfs configured in fstab, but they are currently not mounted. The applet uses two sensors: total disk write (“Schreiben“ on the screenshot) and total disk read (“Lesen”). OBSERVED RESULT The legend goes up to around 2^65 and the graph shows permanent full load. EXPECTED RESULT It shouldn’t do that. :) SOFTWARE/OS VERSIONS Operating System: Arch Linux KDE Plasma Version: 5.23.5 KDE Frameworks Version: 5.90.0 Qt Version: 5.15.2 Kernel Version: 5.15.13-arch1-1 (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Core™ i5-4590 CPU @ 3.30GHz Memory: 31.0 GiB of RAM Graphics Processor: AMD PITCAIRN -- You are receiving this mail because: You are watching all bug changes.
[kdeconnect] [Bug 427790] Lack of exit button
https://bugs.kde.org/show_bug.cgi?id=427790 Frank Steinmetzger changed: What|Removed |Added CC||war...@gmx.de --- Comment #15 from Frank Steinmetzger --- (In reply to Daniel Tang from comment #13) > > I just want to close the app I have the same problem as the OP. I use kdeconnect very sporadically, usually to transfer one or a few files, nothing more (although I appreciate all the other possibilities it provides). But because of the notification issue, I usually go to Total Commander instead and do it The Old Way via sftp, even though that requires me to input a password. It’s just too much hassle to afterwards go into settings, wait for the app list to load, scroll down, find the app and kill it. I, too, like the way Syncthing implemented it with its “Exit” menu item. In contrast, its “competitor” Nextcloud Sync Client has the same issue as kdeconnect: there is no exit function and it has a permanent notification. Which is why I usually avoid it, because usually I just need one file from my nextcoud—not a permanent sync. > How about a further "Disconnect from all devices" button on the settings > screen that does the 3 things, causing the app and service to exit? That doesn’t sound so bad. But did you mean the screen behind the cogwheel, or the menu that can be slided in from the left? I think a “Disconnect all” would suffice and as soon as there is no active connection, the notification can go away. Of course this would mean it no longer listens to incoming connection requests. Hm... I understand your desire to not make it too complicated for non-techie users, so a toggle “Listen for incoming connections” is maybe too overengineered. I’m afraid I’m a bit old-school for the modern Android-approach on UI things. :) Please don’t get me wrong. I think a service that auto-discovers and -connects is a reasonable and useful feature. But only if you want it. If not, then it’s in your way. Another aspect to consider for an always-running service: it consumes power for CPU and network, possibly needlessly. Also, when I am in a different network, I might not want to broadcast search requests for other kdeconnect instances as soon as I load the app. I just had a look at kdeconnect on my phone and connected it to my KDE machine. And I currently cannot see any disconnect option there, neither on the Android end nor on the KDE desktop. The only “option” I had was to shut down the WiFi on a participant. But this left the app UI in a strange state. I might write another ticket about that. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 427225] Showfoto GUI becomes unresponsive when used with the keyboard
https://bugs.kde.org/show_bug.cgi?id=427225 --- Comment #3 from Frank Steinmetzger --- Hi, I did try to do some recordings last year. I actually installed OBS Studio for that. But following Murphy’s law, it did rarely occur during recordings. I experienced the issue less frequently in the recent past. But I think it happened once not too long ago, but I can’t be sure whether that was already with 7.4. I will keep my eyes open. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 447031] Emoji selector icon in “big icons” task switcher changes to preferences-desktop when unselected
https://bugs.kde.org/show_bug.cgi?id=447031 --- Comment #2 from Frank Steinmetzger --- I updated my machines to 5.89 this week. Now I see the preferences-desktop icon for both states (highlighted and non-hightlighted) in the task switcher instead of the big smiley. It is also used as window icon now. I suspect that the icon is not part of oxygen and I can accept that. But why did I see it in the first place, as can be glimpsed on my screenshot of the window? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 447031] New: Emoji selector icon in “big icons” task switcher changes to preferences-desktop when unselected
https://bugs.kde.org/show_bug.cgi?id=447031 Bug ID: 447031 Summary: Emoji selector icon in “big icons” task switcher changes to preferences-desktop when unselected Product: plasmashell Version: 5.23.4 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Emoji Selector Assignee: plasma-b...@kde.org Reporter: war...@gmx.de Target Milestone: 1.0 Created attachment 144576 --> https://bugs.kde.org/attachment.cgi?id=144576=edit Screenshots of the two mentioned issues STEPS TO REPRODUCE 1. Open some windows in addition to the emoji selector 2. Launch the big icons task switcher 3. Keep the switcher open and select another window in it ACTUAL RESULT When the emoji selector is highlighted in the task switcher, its icon is the big yellow smiley. But when the highlight switches to another window, the icon is replaced with preferences-desktop. EXPECTED RESULT The icon should stay the same. There is a similar issue with the “most recently used” tab. When selected, it shows a clock symbol. But when not selected, I see a silhouette of, may be, document-close. ADDITIONAL INFORMATION I’m using the oxygen theme as main icon style. While this *could* be a fallback issue, because oxygen icons is missing newer stuff, it is only half the problem, because in 50 % of cases I see the proper icon. Operating System: Arch Linux KDE Plasma Version: 5.23.4 KDE Frameworks Version: 5.88.0 Qt Version: 5.15.2 Kernel Version: 5.15.6-arch2-1-surface (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Pentium® CPU 4415Y @ 1.60GHz Memory: 7.7 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 615 -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 446422] Opening System Settings with a KCM doesn't always select it in the sidebar
https://bugs.kde.org/show_bug.cgi?id=446422 --- Comment #2 from Frank Steinmetzger --- Created attachment 144221 --> https://bugs.kde.org/attachment.cgi?id=144221=edit Screenshot of the issue It worked when I started it using the command you provided. Then I clicked around frantically to “influence” the list of Frequently Used items. This offered me “Rechtschreibprüfung” (Spell Checking), which is not the topmost submenu item under Regional settings, in the taskbar Actions list. I clicked it, and then I got at what you see in this screenshot. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 446422] New: Task bar context menu: Action does not open proper menu item on the left
https://bugs.kde.org/show_bug.cgi?id=446422 Bug ID: 446422 Summary: Task bar context menu: Action does not open proper menu item on the left Product: systemsettings Version: 5.23.4 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: war...@gmx.de Target Milestone: --- SUMMARY I just discovered that the task bar item of Systemsettings contains two or three custom “Action” items. Namely some (seemingly?) random items from the settings hierarchy. First a general question: how is decided which actions are shown here? I could not see any pattern. Is this a “take me anywhere” feature? When I first experimented with them, the one I selected changed after I used it. But after a while, they did not change anymore and are always the same three: Energy saving mode, Login screen and Global design. Now to the actual issue: when I select one of these actions, systemsettings switches the view to that kcm. But the menu on the left is not fully updated. The leftmost column changes, but not the next one. For example: one time I had “Touchpad” as an item. I selected it, the systemsettings window came to the foreground, the touchpad kcm was shown and the left-most column switched to “Input devices”. But the submenu in the second column had the first item “Keyboard” highlighted, not the “Touchpad” one, which was the fourth in the list. In one instance of those trials, the systemsettings window opened and was filled with one solid dark grey colour in the area where the menu columns would be. Only the kcm content was visible. Hoping I could reproduce it first, I did not screenshot it right away, but then was not able to reproduce. Operating System: Arch Linux KDE Plasma Version: 5.23.4 KDE Frameworks Version: 5.88.0 Qt Version: 5.15.2 Kernel Version: 5.15.5-arch1-1-surface (64-bit) Graphics Platform: X11 Processors: 4 × Intel® Pentium® CPU 4415Y @ 1.60GHz Memory: 7.7 GiB of RAM Graphics Processor: Mesa Intel® HD Graphics 615 -- You are receiving this mail because: You are watching all bug changes.
