[plasmashell] [Bug 442877] Submenus of KStatusNotifierItem open to the wrong side
https://bugs.kde.org/show_bug.cgi?id=442877 Luke Horwell changed: What|Removed |Added CC||c...@horwell.me --- Comment #1 from Luke Horwell --- Created attachment 158279 --> https://bugs.kde.org/attachment.cgi?id=158279&action=edit Test case: Simple AppIndicator3 in Python Can confirm AppIndicator3 (GTK) and Ayatana Indicator tray icons are affected too. Both in single monitor and multiple monitor setups. Attached is a simple test case to replicate this with a simple Python application. If necessary, replace "AppIndicator3" with "AyatanaAppIndicator3" depending on the Python implementation available for your distro (both APIs are compatible). I was writing this for a new bug report until I found this one, originally suspecting it was a GTK integration bug. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 448169] Contrast for Breeze Dark's Places icons with light foreground clashes
https://bugs.kde.org/show_bug.cgi?id=448169 --- Comment #4 from Luke Horwell --- My latest crude workaround is throwing together a mix-and-match of 5.87 and 6.0.x icon theme. Taking the latest icon developments from 6.0.x but the static icons from 5.87 with some search & replace hacks. This works better for the Breeze Dark theme. https://github.com/lah7/breeze-dark-icons-static-mix It also "fixed" BUG 482648 too, where symbolic icons were not working below ~32 pixels, but it's not the solution of course. --- While investigating, some of the earlier comments are outdated. - The previously suggested CSS class removal no longer works after 6.3.0, for some reason. - KIconThemes is doing the recolouring [src/kiconcolors.cpp] - CSS "ColorScheme-Text" maps to "highlightedText" I guess, that's the problem - it currently assumes text colour is OK if the accent colour is used as a background. To reproduce, use "Breeze Dark" window theme with a white accent colour, you'd expect a darker inner icon for places folders. Likewise, try a black accent colour under "Breeze Light". In both cases, the places icons are indistinguishable. In terms of fixing this, I'd suggest: - A new CSS variable applies a colour tint based on the accent colour. This can be used for the 'inner icon' inside places icons. The hex code can be checked to determine this. E.g. For a bright accent colour, go darker. If it's a dark accent colour, go lighter. For Breeze' default blue, it would go darker (#366681). -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 483012] New: Changing line spacing for a Konsole profile causes misalignment until application restart
https://bugs.kde.org/show_bug.cgi?id=483012 Bug ID: 483012 Summary: Changing line spacing for a Konsole profile causes misalignment until application restart Classification: Applications Product: konsole Version: 24.02.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: font Assignee: konsole-de...@kde.org Reporter: c...@horwell.me Target Milestone: --- Created attachment 166812 --> https://bugs.kde.org/attachment.cgi?id=166812&action=edit Screenshot after changing line spacing to 16px SUMMARY In Konsole 24.02.0, changing the line spacing for a profile causes the terminal to be misaligned (in some cases unreadable) until the application is restarted. This is also problematic if the user switches to a profile using different line spacing settings, unless it is the default profile. STEPS TO REPRODUCE 1. Settings → Create/Edit a profile (use CTRL+ALT+M to show menu bars if hidden) 2. Appearance → Miscellaneous 3. Set the line spacing to 8px. 4. Run an application like "nano" to observe text. OBSERVED RESULT The line spacing is broken, causing unreadable text, depending on the line spacing. This is a regression since Konsole 23.08.5 (Qt 5). EXPECTED RESULT Changing line spacing (via settings or switching profiles) render correctly without needing to restart Konsole. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux KDE Plasma Version: 6.0.1 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 ADDITIONAL INFORMATION Tested under X11. Observation for other users -- opening a new Konsole window (24.02.0, Qt 6) did seem smaller to its 23.08.5 (Qt 5) version after upgrading, then I found out line spacing wasn't applying properly and also needs a 1 pixel bump. I had it set to 1px up to now, but 2px makes it familiar again to how it was prior to upgrading (after restarting Konsole, of course!) Appreciate the line spacing option, a nice feature for dyslexa users! -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 476800] KWrite and "minimal overlapping" window placement regressed since 22.08.3
https://bugs.kde.org/show_bug.cgi?id=476800 --- Comment #4 from Luke Horwell --- KWrite 24.05.1 still has an unusual way of arranging windows. I discovered a new workaround: Set up a Window Rule (KWin) to tell KWrite to "Ignore requested geometry" (Force) and set a size. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kiconthemes] [Bug 482648] With Breeze Dark and >100% display scaling, Symbolic icons are not shown.
https://bugs.kde.org/show_bug.cgi?id=482648 Luke Horwell changed: What|Removed |Added Ever confirmed|0 |1 CC||c...@horwell.me Status|REPORTED|CONFIRMED --- Comment #2 from Luke Horwell --- Can confirm the bug happens on X11 too. I observe that symbolic icons do render correctly at 200% monitor scale in Dolphin's sidebar and home folder list view if the regular "Breeze" icon theme is used (requires re-opening Dolphin). Although it's not a great workaround since using "Breeze" icons under a "Breeze Dark" style would result in dark icons for GTK applications. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kiconthemes] [Bug 482648] With Breeze Dark and >100% display scaling, Symbolic icons are not shown.
https://bugs.kde.org/show_bug.cgi?id=482648
--- Comment #4 from Luke Horwell ---
Created attachment 168947
--> https://bugs.kde.org/attachment.cgi?id=168947&action=edit
Video demo of switching light/dark themes. Display is at 200% scale (Wayland)
It's still happening in the current release versions (on Arch Linux, rolling).
Can reproduce in a new user account too.
KDE Plasma 6.0.4
KDE Frameworks 6.2.0
Qt 6.7.0
Wayland and X11
In addition to dolphin, other apps include:
- Gwenview's Places sidebar (e.g. when icons set to 16x16)
- Open/Save file dialog chooser
I did come across something strange. At first, I thought where the theme is
changed made a difference:
(1) System Settings (Home) → "Breeze Dark"
(2) System Settings → Colors & Themes → Global Theme / Icons → "Breeze Dark"
Turns out if switching themes, the icons may look correct, but hovering over
the program reloads into the wrong (colour) icons. Sometimes it'll be right,
but broken thereafter by restarting the program (like with "Details" view in
Dolphin). Attached is a screen capture of some of the weirdness.
It seems to be the icon theme itself ("Breeze Dark") that has the issue - but
only when display scaling is set above 100% (regardless of screen resolution).
If I get time, I'll see if I can Neon running in a container (distrobox) to
check the current git versions.
--
You are receiving this mail because:
You are watching all bug changes.
[ark] [Bug 469762] Give us a way to configure if the destination opens or not after creating an archive via "Compress to..." option from the context menus
https://bugs.kde.org/show_bug.cgi?id=469762
--- Comment #3 from Luke Horwell ---
With the latest Plasma 6 and Ark/Dolphin 24.02.1, here's what happens when
starting a long-running compression via context menu:
* Dolphin process that started the compression is closed: No dolphin window
opens on completion. [Good]
* Dolphin process that started the compression stays open: That window steals
focus back on completion. [Bad]
* Dolphin process that started the compression navigated to a different folder:
New window opens on completion, stealing focus. [Bad]
Under X11 at least, I haven't checked if this is the same behaviour under
Wayland. I have "Keep a single Dolphin window, opening new folders in tabs"
unchecked in Dolphin's settings if that's related.
For now, until a configuration option is present, I'll rebuild the ark package
locally but revert changes in:
https://invent.kde.org/utilities/ark/-/commit/2c847f76778a797964e189bb17ce774e56005f57
In particular, by removing this line in app/compressfileitemaction.cpp:
KIO::highlightInFileManager({QUrl::fromLocalFile(addToArchiveJob->fileName())});
--
You are receiving this mail because:
You are watching all bug changes.
[ark] [Bug 469762] Give us a way to configure if the destination opens or not after creating an archive via "Compress to..." option from the context menus
https://bugs.kde.org/show_bug.cgi?id=469762 Luke Horwell changed: What|Removed |Added CC||c...@horwell.me --- Comment #2 from Luke Horwell --- This "bug" still bites (23.08.4). Sometimes I use the compress menu to create archives, but don't expect Dolphin to steal focus(!) after the archive finished being created minutes later. The notification is good on its own since it allows to open the containing folder if desired. Having Dolphin honour Ark's "Open destination folder after extraction" will greatly help. Another way to reproduce (on X11) is to compress a large file and switch to another application. - Expected: Only the notification is shown when compression finished. - Observed: Dolphin pops up (even if it was on another virtual desktop) and steals focus of the active app. Hopefully the DELETE key isn't being pressed at the time :) -- You are receiving this mail because: You are watching all bug changes.
[ark] [Bug 440663] Ark opens a new instance of Dolphin after compression/extraction via Dolphin
https://bugs.kde.org/show_bug.cgi?id=440663 Luke Horwell changed: What|Removed |Added CC||c...@horwell.me --- Comment #31 from Luke Horwell --- For context, I'm gathering that this regression came to be because of this behaviour change: > What we want to happen is Dolphin to focus the window we have with the file > selected. > -- https://invent.kde.org/frameworks/kio/-/merge_requests/554 In my opinion, we should go back to the previous KDE 5.22.4 behaviour which is to compress/extract in the background. I'm not sure if this "we want to focus the window" idea is intended to interrupt the user, since even fixing the new tab/window regression sounds like a new problem would be introduced: I could be in another program doing other things and Dolphin jumps to the top (like it already gets in the way now). Even flashing in the 'taskbar' might not be suitable, because I may have changed folder/tabs after a long compression/extraction has completed. At the very least, an option to turn off any focus/attention grabbing feature would be appreciated. If the idea is to help the user return to the folder, instead of trying to bring the window into focus, the notification that reads "Compressing a file (Finished)" & "Extracting Files (Finished)" might be a better outlet. There's already a button for "Open Containing Folder" for the extraction, but there isn't one for the compression notification. Currently in 5.23.3 / Frameworks 5.88, there are similar instance-related bugs, and possibly causing confusion and/or may be related to this change: - When compressing a file, and the window is closed, Dolphin crashes and the compression doesn't complete. - When extracting a file, and is cancelled via notification, Dolphin continues to extract in the background. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 440663] New Dolphin window or tab opened after compression/extraction when certain default options are disabled, or when the job is canceled, or when the Dolphin window that initiated i
https://bugs.kde.org/show_bug.cgi?id=440663 --- Comment #40 from Luke Horwell --- > Hmm, these seem broken too. :/ What a mess. I'm wondering if it might make > more sense to revert the original change that caused this. Does anyone happen > to know what it was? I don't know the exact commit, but a known good version was around 01 Jun 2021, (according to my snapshot Arch VM), running: - Plasma 5.21.5 - Frameworks 5.82.0 - Gear 20.04.1 (It could be between 01 Jun 2021 - 12 Aug 2021, I haven't kept snapshots between those dates. This VM uses X11) The "close window aborts extraction crash" bug started when KDE Gear 21.08.0 was released around 13 Aug 2021. I observe the compression happens inside the 'dolphin' process, which was a separate 'ark' process before this update. The "cancel notification continues extracting" bug is actually even older. It happens in Plasma 5.21.5. I can see that the ark process keeps doing its thing despite the notification being cancelled, so I think that's an ark bug, not dolphin. The process happens inside 'dolphin' now, so that can be a bit confusing. Finally, the "new window/tab after extraction/compression" (this original bug report) started around Plasma 5.22, Frameworks 5.84.0, Gear 21.08.0. I also confirm that in earlier versions, leaving "Open new folders in tabs" checked didn't open anything -- so an earlier variant of the regression -- but it currently open tabs too, I believe. Just now, I checked "Open new folders in tabs", extracted a zip and it focused a completely irrelevant instance of dolphin without opening a new tab. I have this unchecked normally. This might be an incentive to ditch the "steal the focus" behaviour as mentioned in comment 31 if a clean revert is not possible. I tried a git bisect on dolphin's repo too the other day, with no luck... only now I just realized the problem is not exclusive to dolphin's code. It may involve ark and kio too. Hope this helps. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 446627] New: Pager does not show correct size when PLASMA_USE_QT_SCALING=1 is set on X11
https://bugs.kde.org/show_bug.cgi?id=446627 Bug ID: 446627 Summary: Pager does not show correct size when PLASMA_USE_QT_SCALING=1 is set on X11 Product: plasmashell Version: 5.23.4 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Pager Assignee: h...@kde.org Reporter: c...@horwell.me CC: plasma-b...@kde.org Target Milestone: 1.0 Created attachment 144305 --> https://bugs.kde.org/attachment.cgi?id=144305&action=edit X11 desktop at 100%, 200% and with variable set SUMMARY On X11 desktops, when the environment variable `PLASMA_USE_QT_SCALING=1` is set, the Pager widget only shows the first quarter of the desktop (in the case of 200% scaling). When the variable is not present, the pager works correctly when Plasma's global scale set to 100% and 200%. Wayland is not affected and works as expected, even with the variable set. Perhaps there needs to be a condition to divide the global scale (e.g. 200% = 2) when X11 is in use and the environment variable is present? STEPS TO REPRODUCE A HiDPI display is useful, but not required. 1. Set the global scale to 200%. 2. echo "PLASMA_USE_QT_SCALING=1" >> .bash_profile 3. Log out and back in 4. Observe the Pager widget on the panel and open some windows in the top-left and bottom-right regions. OBSERVED RESULT On X11 desktops, the window outlines on the widget are not accurately shown when PLASMA_USE_QT_SCALING is set. EXPECTED RESULT The pager shows the correct position/size of windows for a virtual desktop. SOFTWARE/OS VERSIONS OS: Arch Linux KDE Plasma Version: 5.23.4 KDE Frameworks Version: 5.88.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION See attachments for screenshots. -- You are receiving this mail because: You are watching all bug changes.
[ksysguard] [Bug 442546] New: Regression: KSysGuard application icon and window title missing
https://bugs.kde.org/show_bug.cgi?id=442546 Bug ID: 442546 Summary: Regression: KSysGuard application icon and window title missing Product: ksysguard Version: 5.22.0 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: ksysguard Assignee: ksysguard-b...@kde.org Reporter: c...@horwell.me CC: plasma-b...@kde.org Target Milestone: --- Created attachment 141606 --> https://bugs.kde.org/attachment.cgi?id=141606&action=edit Screenshot of KSysGuard on 5.21.5 (left) and 5.22.5 (right, bug) Since the release of KDE 5.22.0, the processes listed in KSysGuard are missing both the window icon and window title. This issue is not present in KDE 5.21.5. This bug happens in both the stand alone KSysGuard application and System Activity (CTRL+ESC) pop up. STEPS TO REPRODUCE 1. Open KSysGuard 2. Open "Process Table" tab 3. Observe running windowed applications, such as Dolphin, Konsole. OBSERVED RESULT - There is no window icon in the "Name" column. - There is no text in the "Window Title" column. EXPECTED RESULT - The window icon and title is displayed. SOFTWARE/OS VERSIONS Linux Distribution: Arch Linux KDE Plasma Version: 5.22.5, 5.22.90 KDE Frameworks Version: 5.86.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION The alternate, newer "System Monitor" application isn't affected. Not sure if they share the same underlying library? -- You are receiving this mail because: You are watching all bug changes.
[kdevplatform] [Bug 443118] New: KDevelop's Problems tool view to list FIXME/TODO comments
https://bugs.kde.org/show_bug.cgi?id=443118 Bug ID: 443118 Summary: KDevelop's Problems tool view to list FIXME/TODO comments Product: kdevplatform Version: unspecified Platform: Other OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: problemreporter Assignee: kdevelop-bugs-n...@kde.org Reporter: c...@horwell.me Target Milestone: --- SUMMARY In KDevelop, a productive addition to the Problems view would be to list actionable comments, like FIXME, TODO and HACK. This could appear under a separate "Comments" (or "Tasks") tab adjacent to the existing "Parser" tab. This feature should work for comments across multiple languages - starting with // or # - as well as different scopes, like "Current Project" and "Current Document". There is a "TODO marker words" field in Configure → Language Support, which could be used as the user-configurable list of keywords to determine the lines for listing. ADDITIONAL INFORMATION According to the mailing list archive, this was a feature in KDevelop 4.6.0: https://mail.kde.org/pipermail/kdevelop/2014-February/018244.html If this feature is already implemented, but is broken, consider this a bug. A quick look in the source code suggests the logic may be there already (todoextractor.cpp), but not hooked up to a tab for display. -- You are receiving this mail because: You are watching all bug changes.
[kdevplatform] [Bug 443118] KDevelop's Problems tool view to list FIXME/TODO comments
https://bugs.kde.org/show_bug.cgi?id=443118
Luke Horwell changed:
What|Removed |Added
Ever confirmed|0 |1
Resolution|WORKSFORME |---
Status|NEEDSINFO |CONFIRMED
--- Comment #3 from Luke Horwell ---
Thanks for the feedback. Looks like it's specific languages. I'm using Python
with a generic project ("KDevGenericManager" according to .kdev4).
I just tried a blank session with some simple hello world files. C and C++ are
OK, but other languages/markup like these do not show:
- Python
- JavaScript
- CSS
- HTML
The syntax highlighter - although not directly related - highlights the word
HACK in a scary red, so I was under the impression the Problems tab would show
these for consistency. Would be a plus to see HACK listed too!
I do observe with a test C file that the Problems tool view doesn't list them
after the initial save of a new file, or by changing a new document's highlight
to C. They do show and start monitoring the document after switching file tabs.
SOFTWARE/OS VERSIONS
kdevelop: 5.6.2-5
kdevelop-python: 5.6.2-1
Distro: Arch Linux
KDE Plasma Version: 5.22.5
KDE Frameworks Version: 5.86.0
Qt Version: 5.15.2
--
You are receiving this mail because:
You are watching all bug changes.
[kdevplatform] [Bug 443118] KDevelop's Problems tool view to list FIXME/TODO comments
https://bugs.kde.org/show_bug.cgi?id=443118 --- Comment #4 from Luke Horwell --- Created attachment 142027 --> https://bugs.kde.org/attachment.cgi?id=142027&action=edit Test files for checking TODO functionality If it helps, here's some basic files with comments for testing. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-ktexteditor] [Bug 451471] New: Toggle comment for Python code no longer works if leading whitespace is present
https://bugs.kde.org/show_bug.cgi?id=451471 Bug ID: 451471 Summary: Toggle comment for Python code no longer works if leading whitespace is present Product: frameworks-ktexteditor Version: 5.91.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kwrite-bugs-n...@kde.org Reporter: c...@horwell.me Target Milestone: --- Created attachment 147481 --> https://bugs.kde.org/attachment.cgi?id=147481&action=edit ZIP containing two GIFs demonstrating the issue (5.90 vs 5.91) SUMMARY Since the release of ktexteditor 5.91.0, the "toggle comment" feature no longer works on Python code where whitespace is present at the start of the selection. For example, when an empty new line is included above the block, or selecting multiple lines which are indented. Affects KWrite, Kate and KDevelop. Downgrading to 5.90.0 restores the expected behaviour. STEPS TO REPRODUCE 1. In a Python document, select multiple lines which are indented (an example of leading whitespace on a line) 2. Press CTRL+/ to toggle the comment. OBSERVED RESULT Toggling comments only ever comments, and does not uncomment. Please observe the attached zip of GIFs demonstrating this. EXPECTED RESULT The line would be commented and uncommented. ADDITIONAL INFORMATION According to a git bisect, the problematic commit starts at: 690e16d5e06477d5f504d1ab89c760cb0cdcf4ff "Fix comment toggling when all lines in selection aren't commented" https://invent.kde.org/frameworks/ktexteditor/-/commit/690e16d5e06477d5f504d1ab89c760cb0cdcf4ff SOFTWARE/OS VERSIONS OS: Arch Linux KDE Plasma Version: 5.91.0 KDE Frameworks Version: 5.91.0 Qt Version: 5.15.3 -- You are receiving this mail because: You are watching all bug changes.
[kdevplatform] [Bug 443118] KDevelop's Problems tool view to list FIXME/TODO comments
https://bugs.kde.org/show_bug.cgi?id=443118 --- Comment #6 from Luke Horwell --- Looking at the source code again, the file "plugins/clang/duchain/todoextractor.cpp" suggests that Clang is used to extract TODO markers, which would confirm by design it's limited to the C family of languages. A solution could be to add logic to the problem reporter's model that parses commented lines (for any known language) against the list of TODO markers. Maybe there's something in KTextEditor/KPart/duchain (whichever handles the syntax highlighting) that can help filter a document's lines to comments only. My C++ is extremely limited, otherwise I'd give it a stab. A workaround for now could be to add an "external script" that executes: "egrep -n 'FIXME|TODO' %f" -- You are receiving this mail because: You are watching all bug changes.
[ksysguard] [Bug 442546] Regression: KSysGuard application icon and window title missing
https://bugs.kde.org/show_bug.cgi?id=442546 Luke Horwell changed: What|Removed |Added Component|ksysguard |libksysguard --- Comment #2 from Luke Horwell --- I did a git bisect and found the problem started at this commit on the libksysguard repository: 0c76e685e022e8a9648805f8ddc5a2857c9e37bb https://invent.kde.org/plasma/libksysguard/-/commit/0c76e685e022e8a9648805f8ddc5a2857c9e37bb I was able to get it working by reverting that commit (despite fixing something deprecated), resolving the conflict and rebuilding my package locally (in the case of Arch, the PKGBUILD file). Attached is a copy of the diff. -- You are receiving this mail because: You are watching all bug changes.
[ksysguard] [Bug 442546] Regression: KSysGuard application icon and window title missing
https://bugs.kde.org/show_bug.cgi?id=442546 --- Comment #3 from Luke Horwell --- Created attachment 143553 --> https://bugs.kde.org/attachment.cgi?id=143553&action=edit Reverts commit 0c76e685e022e8a9648805f8ddc5a2857c9e37bb -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 476800] New: KWrite and "minimal overlapping" window placement regressed since 22.08.3
https://bugs.kde.org/show_bug.cgi?id=476800 Bug ID: 476800 Summary: KWrite and "minimal overlapping" window placement regressed since 22.08.3 Classification: Applications Product: kate Version: 23.08.3 Platform: Archlinux OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: kwrite Assignee: kwrite-bugs-n...@kde.org Reporter: c...@horwell.me Target Milestone: --- Created attachment 163018 --> https://bugs.kde.org/attachment.cgi?id=163018&action=edit Expected behaviour (kate 22.08.3) SUMMARY Around the release of Kate 22.12.0, opening KWrite windows with KDE's minimal overlapping option regressed since 22.08.3. The bug is still present at time of writing (23.08.2). However, the main Kate application open its windows as expected, so it seems specific to KWrite. KDE -> System Settings -> Window Behaviour: - Window placement: "Minimal Overlapping" - Uncheck: "Allow apps to remember the positions of their own windows, if they support it." Workaround: Downgrade kate to 22.08.3, since KWrite is part of Kate. STEPS TO REPRODUCE 1. Start with an empty desktop. 2. Set the KDE setting above (minimal overlapping, don't remember positions) 3. Open multiple KWrite instances. OBSERVED RESULT Newly opened KWrite windows overlaps in a way that is inconsistent with other applications or 22.08.3. EXPECTED RESULT New KWrite instances open without overlapping other windows, similar to 22.08.3 and versions prior. SOFTWARE/OS VERSIONS OS: Arch Linux KDE Plasma Version: 5.27.9 KDE Frameworks Version: 5.111.0 Qt Version: 5.15.11 ADDITIONAL INFORMATION Please observe the attached videos demoing the before/after. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 476800] KWrite and "minimal overlapping" window placement regressed since 22.08.3
https://bugs.kde.org/show_bug.cgi?id=476800 --- Comment #1 from Luke Horwell --- Created attachment 163019 --> https://bugs.kde.org/attachment.cgi?id=163019&action=edit Buggy behaviour (kwrite 23.08.2) -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 476800] KWrite and "minimal overlapping" window placement regressed since 22.08.3
https://bugs.kde.org/show_bug.cgi?id=476800 --- Comment #2 from Luke Horwell --- If it helps, I did a git bisect and found that 353bccf6c5fe0fa284c8cb51def259313e7c9e45 is the commit when the minimal overlapping breaks. https://invent.kde.org/utilities/kate/-/commit/353bccf6c5fe0fa284c8cb51def259313e7c9e45 https://invent.kde.org/utilities/kate/-/network/master?extended_sha1=353bccf6c5fe0fa284c8cb51def259313e7c9e45 Thanks in advance! -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 476808] New: Symbolic links on desktop cannot open original location under "Desktop folder" setting
https://bugs.kde.org/show_bug.cgi?id=476808 Bug ID: 476808 Summary: Symbolic links on desktop cannot open original location under "Desktop folder" setting Classification: Plasma Product: plasmashell Version: 5.27.9 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Desktop Containment Assignee: plasma-b...@kde.org Reporter: c...@horwell.me CC: notm...@gmail.com Target Milestone: 1.0 SUMMARY For symbolic links stored on the desktop, the [>.] button to open the original location (via the Properties window) does not work as expected. The error message reads "The file or folder [path] does not exist" where [path] erroneously prefixes "/home/luke/Desktop" at the start. The symbolic link itself is valid, and the path inside the "Points to" text box is correct. This only happens when configured with the default setting: Configure Desktop and Wallpaper → Location → "Desktop folder" The [>.] button works when this setting is set to "Places panel item" or "Custom location", as well as within Dolphin. Workaround: Set "/home/" as the custom location. STEPS TO REPRODUCE 1. Configure your Desktop Folder Settings to "Desktop folder". 2. Create a symbolic link on desktop (i.e. CTRL+SHIFT+drag a file) 3. Right click the file and open Properties. 4. Click the [>.] button to open the original location. OBSERVED RESULT An error appears stating that the path does not exist. The path in the error message prefixes /home//Desktop. EXPECTED RESULT Dolphin opens to show the original location for the symbolic link. SOFTWARE/OS VERSIONS OS: Arch Linux KDE Plasma Version: 5.27.9 KDE Frameworks Version: 5.111.0 Qt Version: 5.15.11 ADDITIONAL INFORMATION Would love to cross-check with Plasma 6 Alpha, but the unstable Neon ISO and Arch kde-unstable packages result in a black screen under a VirtualBox VM at this time. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 476808] Symbolic links on desktop cannot open original location under "Desktop folder" setting
https://bugs.kde.org/show_bug.cgi?id=476808 --- Comment #1 from Luke Horwell --- Can confirm the bug happens on Plasma 5.27.80 (Plasma 6 Alpha) too. Plus, the "link" icon at the bottom-right of the icon was missing, but the icon's label was italic. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 477201] New: Wayland: Right click and dragging does not activate context menu item
https://bugs.kde.org/show_bug.cgi?id=477201 Bug ID: 477201 Summary: Wayland: Right click and dragging does not activate context menu item Classification: Plasma Product: plasmashell Version: 5.27.80 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: c...@horwell.me CC: k...@davidedmundson.co.uk Target Milestone: 1.0 SUMMARY Activating items from a context menu is possible while holding the right click and releasing it while hovering over the item. Under Wayland, this doesn't happen for the Plasma shell (possibly if it uses Qt 6 Quick), but works in Qt Widgets applications like Dolphin (v24.01.75), GTK 3 applications and under the Plasma X11 session. Areas affected: - On a panel, launchers or applets. - On the desktop or its icons. STEPS TO REPRODUCE 1. Right click (but keep hold) on a panel. 2. Hover over "Enter Edit Mode" then release the right click. OBSERVED RESULT Under Wayland, the item did not hover nor activate. The user must release the right mouse button and left click the item. Under X11, this works as expected. EXPECTED RESULT The menu item highlights and activates upon release of the right click. SOFTWARE/OS VERSIONS OS: Arch Linux KDE Plasma Version: 5.27.80 KDE Frameworks Version: 5.245.0 Qt Version: 6.6.0 -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 3212] Option to hide backup files as well as dotfiles?
https://bugs.kde.org/show_bug.cgi?id=3212 Luke Horwell changed: What|Removed |Added CC||c...@horwell.me --- Comment #81 from Luke Horwell --- Just wanted to note: To unhide any of the file extensions affected by this change / Dolphin 23.08, use "File Associations" in System Settings to create a new file type for them. To the contrary, removing *.old and *.bak from the "application/x-trash" association still kept them hidden (which makes sense since the file types probably fell back to the system association, which is still "application/x-trash") Might be stating the obvious, but I think this tip might help someone stumbling into this in future. I was one of the users purposefully renaming files to end in *.bak or *.old and naturally would like to keep them visible. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 448122] New: [Regression] Unchecking "Draw a circle around close button" does not set it to false in breezerc
https://bugs.kde.org/show_bug.cgi?id=448122 Bug ID: 448122 Summary: [Regression] Unchecking "Draw a circle around close button" does not set it to false in breezerc Product: Breeze Version: 5.23.3 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: c...@horwell.me Target Milestone: --- SUMMARY In System Settings, under Window Decorations, there is a check box to turn on/off the circle drawn around the close button. By default, this is checked. Unchecking this does not write "OutlineCloseButton=false" in breezerc, causing the circle to be drawn for close tab buttons, with only the circle outline disappearing on the window decoration's close button, causing this inconsistency. >From a VM snapshot, 5.22.5 is a last known good version. 5.23.3 inhibits the bad behaviour, but it may have regressed as early as 5.23.0. STEPS TO REPRODUCE 1. Check "Draw a circle around close button" for Breeze's window decoration and apply. 2. "OutlineCloseButton=true" appears in ~/.config/breezerc 3. Open tabs in Dolphin: both the tab close button and window close button draw a circle as expected. 4. Uncheck "Draw a circle around close button" and apply. 5. "OutlineCloseButton=true" disappears from ~/.config/breezerc 6. Dolphin's close tab button shows the outline, but does disappear on the window's close button. 7. Manually add "OutlineCloseButton=false" to ~/.config/breezerc 8. Relaunch Dolphin. Both the close tab buttons and window decorations no longer draw a circle. OBSERVED RESULT Unchecking the option causes the close button shape to be inconsistent across Breeze. Very confusing as the user tries looking in other areas (like Breeze's "Application Style") in case there were separate settings for widgets and window decorations, which is currently not the case. EXPECTED RESULT Unchecking the option turns off the circle outline for both widgets (e.g. close tab) and window decoration's close button. The feature is functional by manually setting 'false' in ~/.config/breezerc: ``` [Common] OutlineCloseButton=false ``` It seems like the code may be deleting the line under the assumption that unchecked values = delete/blank the key, but this doesn't work in this context as no key = true, so the tab close button will always be drawn unless the user was aware of the config file or this bug. SOFTWARE/OS VERSIONS OS: Arch Linux KDE Plasma Version: 5.23.3 KDE Frameworks Version: 5.87.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION Bug 419474 is related in that this an unexpected link between a window decoration setting and one that affects the application style too. An idea could be to add "Draw a circle around close button" to the application style's settings instead. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 448169] New: Contrast for Breeze Dark's Places icons with light foreground clashes
https://bugs.kde.org/show_bug.cgi?id=448169 Bug ID: 448169 Summary: Contrast for Breeze Dark's Places icons with light foreground clashes Product: Breeze Version: 5.23.5 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Icons Assignee: visual-des...@kde.org Reporter: c...@horwell.me CC: kain...@gmail.com Target Milestone: --- Created attachment 145273 --> https://bugs.kde.org/attachment.cgi?id=145273&action=edit Comparing 5.87 and 5.90 with Breeze themes SUMMARY Since breeze-icons 5.88, the places icons have a white foreground for "Breeze Dark". The contrast clashes with the folder background. The icons display as expected under the "Breeze" and "Breeze Light" theme. #b0ddf5 (foreground) on #3daee9 (background) for the default KDE blue does not meet accessibility contrast standards: https://contrastchecker.com/ making it harder for visually impaired users. The icons at /usr/share/icons/breeze-dark/places/48/ represent the correct colour. They appear to be the same for "breeze" too. It's confusing because: - The user doesn't know where this foreground colour is coming from. - Not clear if this foreground colour can be changed. - If the foreground contrast is supposed to be handled automatically or if this was intentional for Breeze Dark. A temporary workaround is to downgrade breeze-icons to 5.87. STEPS TO REPRODUCE 1. Create a new user profile, with default theme/icon settings (Breeze Light) 2. Open Dolphin, observe correct icon colour. 3. Change theme to "Breeze Dark" and observe icons again. OBSERVED RESULT The foreground for the icon within the icon (e.g. Documents, Downloads, Music) is insufficient (#b0ddf5). The Icon chooser (such as when changing a folder's icon) shows the darker, original contrast (#366681), which is inconsistent with what actually gets displayed in Dolphin. EXPECTED RESULT The foreground is the same as Breeze Light (#2e5d77), and previous <=5.87 versions. SOFTWARE/OS VERSIONS OS: Arch Linux KDE Plasma Version: 5.23.5 KDE Frameworks Version: 5.89.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION - Colour hex codes in this report were provided as a rough indicator. - Local cache was cleared (~/.cache) when testing. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 448122] [Regression] Unchecking "Draw a circle around close button" does not set it to false in breezerc
https://bugs.kde.org/show_bug.cgi?id=448122 Luke Horwell changed: What|Removed |Added Status|NEEDSINFO |CONFIRMED Ever confirmed|0 |1 Resolution|WAITINGFORINFO |--- --- Comment #2 from Luke Horwell --- > If you click on the "Defaults" button in the dialog window that contains this > checkbox, what happens? It's unchecked, my bad. Sorry! I think my confusion came from seeing this in the code: https://invent.kde.org/plasma/breeze/-/blob/d3490373c2988c4c062351874dae4a2bf3981174/kstyle/breeze.kcfg#L34-37 I checked on KDE Neon, the problem happens there too. Thanks for clarifying how defaults should work in configuration files, that makes sense. I've created a merge request to fix this: https://invent.kde.org/plasma/breeze/-/merge_requests/167 Glad it's a simple negation and nothing complex. Can confirm recompiling Breeze with this correction fixes the issue. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 448596] New: [Regression] Custom SVG folder icons no longer visible
https://bugs.kde.org/show_bug.cgi?id=448596 Bug ID: 448596 Summary: [Regression] Custom SVG folder icons no longer visible Product: frameworks-kio Version: 5.90.0 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Open/save dialogs Assignee: kio-bugs-n...@kde.org Reporter: c...@horwell.me CC: kdelibs-b...@kde.org Target Milestone: --- Created attachment 145540 --> https://bugs.kde.org/attachment.cgi?id=145540&action=edit Comparison between 5.89 and 5.90 file picker SUMMARY Since upgrading to KDE Frameworks 5.90 (from 5.89), folders that use a custom SVG icon now appear as an empty file in the load/save dialog. STEPS TO REPRODUCE 1. Create a folder and set the folder icon's to a custom SVG. 2. Open a Qt app's file picker (such as KWrite) 3. Navigate to the parent folder containing the custom folder icon. OBSERVED RESULT The folder icon is a generic file. EXPECTED RESULT The folder icon displays the custom SVG, as seen in Dolphin and <=5.89. SOFTWARE/OS VERSIONS KDE Plasma Version: 5.24.5, 5.23.90 KDE Frameworks Version: 5.90.0 Qt Version: 5.15.2+kde+r291-1 ADDITIONAL INFORMATION Folders with custom PNG files are not affected. -- You are receiving this mail because: You are watching all bug changes.
[kdev-python] [Bug 438206] Fails to build against Python 3.10
https://bugs.kde.org/show_bug.cgi?id=438206 Luke Horwell changed: What|Removed |Added CC||c...@horwell.me --- Comment #2 from Luke Horwell --- A heads up that Arch Linux is now affected with their recent rebuild to Python 3.10.1. The package was removed from their repositories: https://pkgbuild.com/~foutrelis/failed-py310-builds/kdevelop-python.log https://github.com/archlinux/svntogit-packages/commits/packages/kdevelop-python https://archlinux.org/todo/remaining-rebuilds-for-python-310/ -- You are receiving this mail because: You are watching all bug changes.
[kdev-python] [Bug 438206] Fails to build against Python 3.10
https://bugs.kde.org/show_bug.cgi?id=438206 --- Comment #4 from Luke Horwell --- (In reply to Øystein S. Haaland from comment #3) > I use kdevelop for python development in my day-to-day job. It seem now that > kdev-python has stopped working on arch, which I am currently using. I use KDevelop on Arch nearly every day too. A workaround I found is to install Python 3.9 (`python39` in AUR) and install `kdevelop-python` (now in AUR). Syntax highlighting and parsing works again as before, and so far, it is processing modules installed in /usr/lib/python3.10 for auto-completion, etc. I imagine Python 3.10-specific syntax won't work (I haven't checked) but at least things can continue to work for Python <= 3.9 projects. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 448169] Contrast for Breeze Dark's Places icons with light foreground clashes
https://bugs.kde.org/show_bug.cgi?id=448169
--- Comment #1 from Luke Horwell ---
I tried looking into this, but I'm stumped. A git bisect between v5.87.0 and
v5.88.0 reveals that 1b92cfc450f6ab6b72ed9ef69c052e4624e5a040 ("Remove exact
duplicate icons from dark theme") was the first commit to introduce the issue,
but it seems like something else is involved.
If the change was intended to deduplicate icons from the source and so dark
coloured themes use lighter monochrome icon colours (like toolbars, menus), it
kind of makes sense - this bug would be about the wrong monochrome colour being
used/forced inside a folder icon when dark colour scheme like Breeze Dark is
set.
Some questions to help understand the situation:
- Where's the code that changes the behaviour when a dark colour scheme is
selected?
- Why would icon previews in the icon picker (32px) show the original icons,
but Dolphin renders modified icons?
- Why would places icons (32, 48, 64, 96) in
/usr/share/icons/{breeze,breeze-dark} be exactly the same?
- Can this be disabled (at build, env variable, hidden config file)?
Possible guesstimate solutions:
- Skip processing places icons over 32px?
- Add a checkbox in System Settings' Icons or Colours tab to set icon
foreground to dark/light?
--
You are receiving this mail because:
You are watching all bug changes.
[Breeze] [Bug 448169] Contrast for Breeze Dark's Places icons with light foreground clashes
https://bugs.kde.org/show_bug.cgi?id=448169
--- Comment #2 from Luke Horwell ---
There is a workaround, thanks to clues in BUG 353819.
> Why would places icons (32, 48, 64, 96) in
> /usr/share/icons/{breeze,breeze-dark} be exactly the same?
There's CSS in the icons that look for "current-color-scheme" and recolours
them accordingly. Still not sure which component (KIO, KIconThemes?) actually
does the processing. Removing this ID from the SVG prevents them from being
recoloured.
Potentially, further optimisation could deduplicate these further if they are
byte-for-byte the same, so Breeze-Dark can fallback to Breeze.
> Can this be disabled (at build, env variable, hidden config file)?
Not that I could see with toggles, but this can be patched out when building
the package:
find . -name "*.svg" -exec sed -i 's/current\-color\-scheme//g' {} +
Unrelated: I'm also patching out the 96 icons locally, as they've become a tad
bit thinner since 5.87 that I'm struggling to see some of these icons (e.g.
downloads, templates) at a distance. (4K display, X11 user here)
find . -type d -name 96 -exec rm -vr {} +
--
You are receiving this mail because:
You are watching all bug changes.
[ksysguard] [Bug 442546] Regression: KSysGuard application icon and window title missing
https://bugs.kde.org/show_bug.cgi?id=442546 Luke Horwell changed: What|Removed |Added Status|REPORTED|RESOLVED Resolution|--- |FIXED Keywords||regression --- Comment #4 from Luke Horwell --- This commit fixes the issue: https://invent.kde.org/plasma/libksysguard/-/commit/52b475fbaff2a9d96cdcdde064a9e56b921d1699 https://invent.kde.org/plasma/libksysguard/-/merge_requests/215 A revert of the commit won't be necessary, but it did help find the cause: https://invent.kde.org/plasma/libksysguard/-/merge_requests/200 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kiconthemes] [Bug 434451] SVG icons in custom Qt application stopped rendering
https://bugs.kde.org/show_bug.cgi?id=434451 Luke Horwell changed: What|Removed |Added CC||c...@horwell.me --- Comment #10 from Luke Horwell --- Created attachment 136852 --> https://bugs.kde.org/attachment.cgi?id=136852&action=edit Test case for QIcon selected state in PyQt5 app I tested the patch/branch and still found some issues, at least with PyQt5 apps. I used git-cola for testing. While the icons have reappeared, the functionality to switch between dark/light themes from within the app does not work. The icons appear to be stuck in one theme. This works as expected under 5.79 or by checking out kiconthemes commit 6bada57e705190c20fd72c9e7b1ef1a25d6d44a3. The other issue is that QIcon states don't seem to be working. I've attached a test case demonstrating the problem using PyQt5 which loads an SVG file for 2 buttons directly from /usr/share/icons/breeze/ (just as an example). The focused button should be a different icon. An application in practice using QIcon states on buttons and menus is polychromatic[-git] - a screenshot can be seen here: https://forum.endeavouros.com/t/12788 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kiconthemes] [Bug 434451] SVG icons in custom Qt application stopped rendering
https://bugs.kde.org/show_bug.cgi?id=434451 --- Comment #13 from Luke Horwell --- Thanks, I rebuilt the branch again and apps are back to normal. Regarding git-cola, I have no code hints. After setting "Icon Theme" via the preferences window, the program just needs to be restarted to see the new icon scheme. > See > https://kate-editor.org/post/2021/2021-03-07-cross-platform-light-dark-themes-and-icons/ > for the reason. IMO, the "kiconthemes" package shouldn't risk inconsistencies or create unintended bugs for non-KDE Qt-based apps. I think it would be a better practice for QIconEngine not to be overridden by KIconEngine when this package is installed. If it can specifically be confined to KDE applications or be overridden by some other condition, like an environment variable, that would be better. -- You are receiving this mail because: You are watching all bug changes.
[ktorrent] [Bug 490894] New: KTorrent persistently writing 2 bytes to a "magnets" file while torrents are active
https://bugs.kde.org/show_bug.cgi?id=490894 Bug ID: 490894 Summary: KTorrent persistently writing 2 bytes to a "magnets" file while torrents are active Classification: Applications Product: ktorrent Version: 24.05.2 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: joris.guis...@gmail.com Reporter: c...@horwell.me Target Milestone: --- SUMMARY When a torrent is active, i.e. downloading or seeding, a file named "magnets" in ~/.local/share/ktorrent is persistently being written to in a loop. This causes the HDD activity indicator to be constantly flickering on/off. The content of that file is just 2 bytes: "le". Happens even under a fresh configuration. No magnets are active. STEPS TO REPRODUCE 1. Start a torrent, such as KDE Neon ISO. STEPS TO DIAGNOSE 1. Install "inotifywait" package for the distro 2. Run "inotifywait -m -r /home/$USER/.local/share/ktorrent/" WORKAROUND Create a symbolic link for "magnets" to "/dev/null". SOFTWARE/OS VERSIONS OS: Arch Linux KDE Plasma Version: 6.1.3 KDE Frameworks Version: 6.4.0 Qt Version: 6.7.2 ADDITIONAL INFORMATION - Still happens even if all plugins are disabled. - Deleting the file immediately recreates it. -- You are receiving this mail because: You are watching all bug changes.
[ktorrent] [Bug 490894] KTorrent persistently writing 2 bytes to a "magnets" file while torrents are active
https://bugs.kde.org/show_bug.cgi?id=490894 --- Comment #1 from Luke Horwell --- Forgot to add the output of inotifywait, if it helps: ``` /home/luke/.local/share/ktorrent/ OPEN magnets /home/luke/.local/share/ktorrent/ MODIFY magnets /home/luke/.local/share/ktorrent/ CLOSE_WRITE,CLOSE magnets ``` (repeated multiple times every second) -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 476800] KWrite and "minimal overlapping" window placement regressed since 22.08.3
https://bugs.kde.org/show_bug.cgi?id=476800 Luke Horwell changed: What|Removed |Added Ever confirmed|0 |1 Status|RESOLVED|REOPENED Resolution|WORKSFORME |--- --- Comment #6 from Luke Horwell --- I should've mentioned it only happens under X11, sorry, missing detail. Just had a quick test under Wayland, and it's OK there. I'm using a 4K screen. Still happens under 24.08.2 in KWrite mode only. No issue under Kate mode. However, I have more info: There is a "Restore Window Configuration" key (in katerc) that can be set in Kate (under Settings → Session → Include window configuration), but there is no way to set this in KWrite's GUI settings. If "Restore Window Configuration=true" ends up in kwriterc, or the key is not there, this bug is triggered. Presumably that means it's true by default? Adding "Restore Window Configuration=false" to kwriterc no longer remembers the height/width of the window, but it does fix the improper minimal overlapping behaviour. In practice, I would still need a window rule, since KWrite no longer behaves like Dolphin would, whereby the height/width is remembered, but the window placement is handled by the window manager. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 494521] Behaviour change with timezones in Qt 6.8
https://bugs.kde.org/show_bug.cgi?id=494521 Luke Horwell changed: What|Removed |Added CC||c...@horwell.me --- Comment #2 from Luke Horwell --- I noticed this too, with "BST" becoming "British Summer Time" - very verbose! Couldn't find a specific bug upstream, but there were a number of bug reports related to time zone parsing around versions 6.7 - 6.8, so I would guess it is on Qt's radar. https://bugreports.qt.io/browse/QTBUG-130278 <-- affects macOS but seems closest to this problem https://bugreports.qt.io/browse/QTBUG-129696 <-- KDE contributor reported a crash with Spectacle (screenshot app) -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 492449] Can't disable edit mode
https://bugs.kde.org/show_bug.cgi?id=492449 Luke Horwell changed: What|Removed |Added CC||c...@horwell.me --- Comment #4 from Luke Horwell --- +1. I use the F2 shortcut to rename files, but quite often accidentally trigger edit mode and then always needing to hit ESC or click 'Exit'. I'd love to see an option to disable it. Space bar also triggers it. I believe this feature is more useful for touch screens and Plasma Mobile, it was recently mentioned here: https://blogs.kde.org/2024/10/20/this-week-in-kde-apps/ -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 494887] Clipboard pop up window too tall, lacks border and first item obscured by buttons
https://bugs.kde.org/show_bug.cgi?id=494887 --- Comment #2 from Luke Horwell --- Created attachment 174921 --> https://bugs.kde.org/attachment.cgi?id=174921&action=edit Clipboard pop up in 6.1.5 vs 6.2.1 Attached is a screenshot comparison that didn't upload earlier for some reason. Thanks for the tips! Resizing with meta + right click helps a lot. I already patch some other KDE packages, so I may embark on my own on that. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 494887] Clipboard pop up window too tall, lacks border and first item obscured by buttons
https://bugs.kde.org/show_bug.cgi?id=494887
--- Comment #3 from Luke Horwell ---
Created attachment 174922
--> https://bugs.kde.org/attachment.cgi?id=174922&action=edit
Border and resizing workaround using window rules
As you've pointed out it's a dialog, this makes sense. The shadow is tiny, but
this might be misexpectations since my Breeze Window Decoration setting is set
to "Large" for shadows, although this is also the case for any plasma thing
that pops up. (possible bug?)
It is possible to workaround by adding a window rule ("Clipboard Popup" title)
with "No titlebar and frame" = "No", and then set a window-specific override in
the window decorations to add a tiny border and hide the title bar.
--
You are receiving this mail because:
You are watching all bug changes.
[plasmashell] [Bug 494887] New: Clipboard pop up window too tall, lacks border and first item obscured by buttons
https://bugs.kde.org/show_bug.cgi?id=494887 Bug ID: 494887 Summary: Clipboard pop up window too tall, lacks border and first item obscured by buttons Classification: Plasma Product: plasmashell Version: 6.2.1 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Clipboard Assignee: plasma-b...@kde.org Reporter: c...@horwell.me Target Milestone: 1.0 SUMMARY Since Plasma 6.2.0, it feels uncomfortable to use the clipboard pop up (Klipper) due to the large excessive height it takes when opened using a global shortcut (CTRL+V). This is more apparent when the cursor is near the bottom and there are only a few items. It also lacks a border/shadow, so the background can clash with similar colours underneath - at least under a dark theme. The first item is highlighted (as with previous versions), but now there are now 4 buttons obscuring the text. STEPS TO REPRODUCE 1. Have multiple items copied to the clipboard. 2. Open a KWrite window near the bottom of the screen and open the clipboard pop up (CTRL+V) on a 1080p/2160p screen. OBSERVED RESULT The list is positioned much higher from where the cursor is due to the excessive height, taking up under half the screen in some cases. The lack of border/shadow on the pop up causes it to blend into the application toolbar. Items also had large padding which seems out of place for a contextual menu/pop up. The text for the first item was obscured by 4 buttons. EXPECTED RESULT The pop up fits the contents of the list; items didn't have too much padding and the pop up has a shadow/border to enforce it's floating above the window. The text for the first highlighted item isn't obscured by buttons. SOFTWARE/OS VERSIONS Arch Linux KDE Plasma Version: 6.2.1 KDE Frameworks Version: 6.7.0 Qt Version: 6.8.0 ADDITIONAL INFORMATION The older context menu style was greatly preferred as it was simple, smaller and more productive. As a user, I used the pop up clipboard menu for switching between text, but not to switch images or manage the clipboard itself. More control was possible via the "Clipboard" applet when needed. If the change intentional for 6.2.0, this bug could be a suggestion to consider a context menu when non-text selection is disabled, or if the focused input is a text box (which sounds impossible). Otherwise, I would be interested to patch it back locally, or perhaps there's an API to read Klipper so a custom script can handle the shortcut? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 495134] Plasmashell (and Dolphin) crash after ejecting a disc from an optical drive
https://bugs.kde.org/show_bug.cgi?id=495134 Luke Horwell changed: What|Removed |Added CC||c...@horwell.me --- Comment #4 from Luke Horwell --- According to a weekly blog update, this is fixed for KDE Frameworks 6.8: > Fixed a case where Plasma and other KDE apps could crash when ejecting a CD > (Nicolas Fella, Frameworks 6.8) > https://invent.kde.org/frameworks/solid/-/merge_requests/172 > > — > https://pointieststick.com/2024/10/26/this-week-in-plasma-all-screens-all-the-time/ -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 496179] New: Kickoff: Recent folders appear as "unknown" icon under Places -> History
https://bugs.kde.org/show_bug.cgi?id=496179 Bug ID: 496179 Summary: Kickoff: Recent folders appear as "unknown" icon under Places -> History Classification: Plasma Product: plasmashell Version: 6.2.3 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Application Launcher (Kickoff) Assignee: plasma-b...@kde.org Reporter: c...@horwell.me CC: mikel5...@gmail.com, noaha...@gmail.com Target Milestone: 1.0 Created attachment 175759 --> https://bugs.kde.org/attachment.cgi?id=175759&action=edit Screenshot of Kicker Places Recent menu showing the unknown icon SUMMARY After navigating through files and folders in Dolphin, these appear as entries in the Kickoff "Places" menu under "History". However, regular folders are shown with an "unknown" question mark icon. STEPS TO REPRODUCE 1. Trigger history of a folder in Dolphin. E.g. create a folder called "My Folder" and create a file "My File.txt" inside. 2. Open Kickoff, then Places -> History. OBSERVED RESULT Folders show a question mark icon. EXPECTED RESULT Folders use the default directory icon. SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Neon Testing Edition (neon-testing-20241112-0034.iso) KDE Plasma Version: 6.2.4 KDE Frameworks Version: 6.8.0 Qt Version: 6.8.0 ADDITIONAL INFORMATION Same happens on Arch Linux. It seems to have been broken for months, but I hadn't opened a report sooner as I (wrongly) assumed I messed something up with my custom mime types (these are fine). There is an older, similar bug 2 years ago (401579) that affected the older Kicker menu. Folders with a custom icon seem to show as expected if it's an absolute path and not an icon name (e.g. "folder-git") in the accompanying .directory file. -- You are receiving this mail because: You are watching all bug changes.
[xdg-desktop-portal-kde] [Bug 493698] New: Unable to choose a 'custom' application for "Open With" via Dolphin
https://bugs.kde.org/show_bug.cgi?id=493698 Bug ID: 493698 Summary: Unable to choose a 'custom' application for "Open With" via Dolphin Classification: Plasma Product: xdg-desktop-portal-kde Version: 6.1.90 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: c...@horwell.me CC: aleix...@kde.org Target Milestone: --- Created attachment 174113 --> https://bugs.kde.org/attachment.cgi?id=174113&action=edit Screenshot of the user stuck choosing a custom path SUMMARY In Dolphin, "Open With" → "Choose Application..." appears to be using this portal. However, it regresses functionality since it is impossible to use a custom program path. For example, qt6-tools no longer ships with *.desktop launchers, so a *.ui file needs to be opened with "/usr/lib/qt6/bin/designer" to use the Qt 6 version of Qt Designer. Thankfully, the old chooser still works by right clicking the file → Properties and adding the program to the file association there instead. STEPS TO REPRODUCE 1. Create an empty *.ui file in Dolphin. 2. Right click the file and choose "Open With" → "Other Application..." 3. Type "/usr/lib/qt6/bin/designer" or try selecting the path. 4. Run the program OBSERVED RESULT The user is stuck. There is no way to start a program with a 'custom' path or command line. - Clicking "Choose Other..." button only updates the text field. - Pressing ENTER does nothing. - There is no OK button. EXPECTED RESULT The portal allows a custom path to be used, or Dolphin reverts to the previous file association "list selector". SOFTWARE/OS VERSIONS Linux/KDE Plasma: KDE Neon KDE Plasma Version: 6.1.90 KDE Frameworks Version: 6.7.0 Qt Version: 6.7.2 ADDITIONAL INFORMATION As feedback, I completely missed the "Always open" checkbox at the top. I felt disorientated thinking the dialog was broken since "Cancel" and "OK" dialog buttons were missing at the bottom. The dialog does jarring a bit when it first opens. I much prefer the old file association "list", is there a way to disable this portal on desktop? (Or any hints on which commits to revert?) -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 491815] Menu rolling in plasmashell context menus does not work on wayland
https://bugs.kde.org/show_bug.cgi?id=491815 Luke Horwell changed: What|Removed |Added CC||c...@horwell.me --- Comment #4 from Luke Horwell --- *** Bug 477201 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 477201] Wayland: Right click and dragging does not activate context menu item (no menu rolling)
https://bugs.kde.org/show_bug.cgi?id=477201 Luke Horwell changed: What|Removed |Added Resolution|--- |DUPLICATE Status|CONFIRMED |RESOLVED --- Comment #2 from Luke Horwell --- *** This bug has been marked as a duplicate of bug 491815 *** -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 491815] Menu rolling in plasmashell context menus does not work on wayland
https://bugs.kde.org/show_bug.cgi?id=491815 --- Comment #5 from Luke Horwell --- Just to note, this regressed under X11 too when Qt 6.7.3 was released. The problematic commit was found and reverting fixes it again for X11. Even though the bug found isn't the same as our menu rolling issue, it was related to how Qt handles input. https://gitlab.archlinux.org/archlinux/packaging/packages/qt6-base/-/issues/6 https://bugreports.qt.io/browse/QTBUG-129509 https://code.qt.io/cgit/qt/qtbase.git/commit/?id=9c1f39b93e6fd5261da4324d17a5ecd40db5f05b Still non-functional under Wayland with the current stable releases, for now! -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 496179] Kickoff: Recent folders appear as "unknown" icon under Places -> History
https://bugs.kde.org/show_bug.cgi?id=496179
--- Comment #3 from Luke Horwell ---
Created attachment 175819
--> https://bugs.kde.org/attachment.cgi?id=175819&action=edit
Comparing Dolphin Recent Files and Kicker's History lists
Tried testing again, a possible new discovery:
- For the folders in Kicker → Places → History that currently show a "?" icon,
they definitely don't appear in Dolphin's "Recent Locations" view
[recentlyused:/locations/]. The ones that are in Dolphin's recent locations are
more likely to have a folder icon in Kicker → Places → History. Attached is a
screenshot to show this.
- The folder icon appears if added as a bookmark ("Add to Places"), but is lost
again after removing ("Remove from Places").
I had another test on some VMs/distros, and I can replicate the "?" icon each
time:
- EndeavourOS (Arch)
- KDE Neon (neon-user-20241110-0746.iso)
- Fedora 41 KDE live session (Fedora-KDE-Live-x86_64-41-1.4.iso) [Older:
Plasma 6.2.1, Frameworks 6.7.0, Qt 6.7.2]
It's pretty erratic. At some point under EndeavourOS, all recent directories
had a folder icon. After right clicking → "Forget All" and going through the
folder tree & opening the same files, the folders are remembered with a "?"
icon (except one folder). At some point, all recent directories showing "?"
icons suddenly had their folder icons back. This didn't last long, since
clearing the history and trying to replicate the state led to "?" folder icons
again!
The bug doesn't trigger if "New Folder" is on the desktop. However, any
subfolders in there will appear in Kicker's recent list with a "?" icon. The
attachment also shows this.
That's odd that you both can't reproduce the "?" icons. Have you tried clearing
the history first and/or afterwards? Did you try different areas of the file
system?
Also, try right clicking a recent folder from your Kicker → Places → History /
Files, and select "Properties". Do you see a folder icon in the properties
dialog? Over here, there is an "?" icon both for the buggy item icons ("?") and
items with working icons (e.g. "Home", "Documents", a places bookmark). It
comes up with "No registered file type" even though it does open with Dolphin.
--
You are receiving this mail because:
You are watching all bug changes.
[plasmashell] [Bug 496179] Kickoff: Recent folders appear as "unknown" icon under Places -> History
https://bugs.kde.org/show_bug.cgi?id=496179 --- Comment #4 from Luke Horwell --- Created attachment 175820 --> https://bugs.kde.org/attachment.cgi?id=175820&action=edit Screenshot negating comment 3 I might be wrong in my last comment about it being related to Dolphin's Recent Locations. In this screenshot, we can see it appear in both Dolphin and Kicker, but Kicker is still showing the "?" icon. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 493638] Impossible removing a single file from recent files list
https://bugs.kde.org/show_bug.cgi?id=493638 Luke Horwell changed: What|Removed |Added CC||c...@horwell.me Status|REOPENED|CONFIRMED --- Comment #13 from Luke Horwell --- I can confirm "Forget File" menu item isn't behaving as expected in the "Application Menu" (Kicker). The bug was filed under the wrong component (Kickoff: "Application Launcher") Reproduced under: Arch Linux, Plasma 6.2.3, Frameworks 6.8.0, Qt 6.8.0. Steps to reproduce: 1. Replace menu: "Show Alternates" → "Application Menu" on the Plasma panel. 2. Create some text files on the desktop and open them. 3. Open the menu → Recent Files → "Forget File" for one of them. 4. Nothing appears to happen. However, if I log out and back in, the file I asked to forget disappears from the menu, so it is functionally working. Hopefully it's just a simple 'need to refresh the list' kind of bug. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 493638] Impossible removing a single file from recent files list
https://bugs.kde.org/show_bug.cgi?id=493638 Luke Horwell changed: What|Removed |Added Component|Application Launcher|Application Menu (Kicker) |(Kickoff) | -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 497375] New: "Dimensions" field incorrectly adds a comma
https://bugs.kde.org/show_bug.cgi?id=497375 Bug ID: 497375 Summary: "Dimensions" field incorrectly adds a comma Classification: Frameworks and Libraries Product: frameworks-kio Version: 6.8.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Properties dialog Assignee: kio-bugs-n...@kde.org Reporter: c...@horwell.me CC: kdelibs-b...@kde.org Target Milestone: --- SUMMARY When looking at the "Details" tab for a media file in Dolphin, the "Dimensions" numbers is erroneously displayed with a comma, which is quite unusual for media files. For example, "1,920 × 1,080" is displayed instead of "1920 x 1080". See also: BUG 488639. Gwenview's title bar is also affected and was identified to be due to i18n changes. Perhaps the function is prettifying integers but is undesired in this scenario? STEPS TO REPRODUCE 1. Right click a media file → Properties. 2. Go to "Details" tab. 3. Read the value of the "Dimensions" field. OBSERVED RESULT The dimensions are displayed with a comma, like "1,920 × 1,080" EXPECTED RESULT The dimensions are displayed as "1920 × 1080" SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux KDE Plasma Version: 6.2.4 KDE Frameworks Version: 6.8.0 Qt Version: 6.8.1 -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 488639] Gwenview puts commas in image dimensions in window title bar
https://bugs.kde.org/show_bug.cgi?id=488639 Luke Horwell changed: What|Removed |Added CC||c...@horwell.me --- Comment #1 from Luke Horwell --- Created attachment 176556 --> https://bugs.kde.org/attachment.cgi?id=176556&action=edit Comparing image dimensions with other apps/OS It also affects the "Details" tab in Dolphin when right clicking an image file. Not sure if it's Qt 6 or a KDE library causing this. Attached is an image showing the bug, and comparing other apps and OSes. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 497372] New: 24.12.0: Overlay/emblem icons at 64px view inconsistently larger
https://bugs.kde.org/show_bug.cgi?id=497372 Bug ID: 497372 Summary: 24.12.0: Overlay/emblem icons at 64px view inconsistently larger Classification: Applications Product: dolphin Version: 24.12.0 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: dolphin-bugs-n...@kde.org Reporter: c...@horwell.me CC: kfm-de...@kde.org Target Milestone: --- Created attachment 176558 --> https://bugs.kde.org/attachment.cgi?id=176558&action=edit Changing view scale in Dolphin 24.12 (left) and Dolphin 24.08.3 (right) SUMMARY After updating to Dolphin 24.12.0, overlay icons (such as symlinks and read-only) are proportionately larger at the default 64 pixels zoom compared to Dolphin 24.08.3. They no longer scale proportionately when increasing/decreasing zoom level. These overlay icons seem to using the 22px version of the icon (e.g. "22/emblem-symbolic-link.svg"), even though the icon scheme provides a 24px size, which goes unused. I believe it's a bug rather than an intentional design change. Attached is a video to demonstrate. STEPS TO REPRODUCE 1. Open a folder containing files/folders which trigger an overlay icon (e.g. a symlink file) 2. Change the zoom of the view (mouse+scroll wheel) OBSERVED RESULT Overlay icons are larger. EXPECTED RESULT Overlay icons were a little smaller. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Arch Linux KDE Plasma Version: 6.2.4 KDE Frameworks Version: 6.8.0 Qt Version: 6.8.1 ADDITIONAL INFORMATION >From the 24.12.0 release notes, the closest thing could be: "Port from KIconLoader::drawOverlays to KIconUtils::addOverlays." http://commits.kde.org/dolphin/cebcf8dbb3ff310aa0761ad452e4ca79278d7831 — https://kde.org/announcements/changelogs/gear/24.12.0/ -- You are receiving this mail because: You are watching all bug changes.
[gwenview] [Bug 488639] Gwenview puts commas in image dimensions in window title bar
https://bugs.kde.org/show_bug.cgi?id=488639 Luke Horwell changed: What|Removed |Added Ever confirmed|0 |1 Status|REPORTED|CONFIRMED --- Comment #2 from Luke Horwell --- I was able to track down the problematic commit/MR: https://invent.kde.org/graphics/gwenview/-/commit/3663c774ca0b766583ee92d9b2776d67cf5d5c2a https://invent.kde.org/graphics/gwenview/-/merge_requests/220 Reverting that commit fixes the title bar for Gwenview. Although, it was to fix a localisation issue: * https://bugs.kde.org/show_bug.cgi?id=473638 * https://bugs.kde.org/show_bug.cgi?id=473636 Not sure if it's the i18nc() function that causes the integers (e.g. 1024) to end up formatted with commas according to locale (e.g. 1,024). Makes sense for something like "15,200 files" but not "1024x1024 pixels". -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 494887] Clipboard pop up window too tall, lacks border and first item obscured by buttons
https://bugs.kde.org/show_bug.cgi?id=494887 --- Comment #5 from Luke Horwell --- No problem. In the end, I wrote my own "open at mouse cursor" replacement to complement Klipper: https://github.com/lah7/clipqture -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 497372] 24.12.0: Overlay/emblem icons at 64px view inconsistently larger
https://bugs.kde.org/show_bug.cgi?id=497372 --- Comment #1 from Luke Horwell --- Just to note, it seems to only affect the right overlay icon (e.g. emblem-symbolic-link, emblem-readonly). The left overlay icon scales as expected like the previous version (e.g. version control status: vcs-normal, vcs-locally-modified-unstaged, etc). -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 497372] 24.12.0: Overlay/emblem icons at 64px view inconsistently larger
https://bugs.kde.org/show_bug.cgi?id=497372 --- Comment #2 from Luke Horwell --- Created attachment 176786 --> https://bugs.kde.org/attachment.cgi?id=176786&action=edit Screenshot showing inconsistency on hidden files with Git plugin Looks like the left icon is indeed affected. I was going to open a new report, but it seems too similar to this one. Overlay icons added by the Git plugin are inconsistently sized between hidden and non-hidden files and folders in Dolphin 24.12. STEPS TO REPRODUCE 1. Create a directory and run "git init" inside. 2. Create files and folders, with some hidden by prefixing a dot in the name. 3. Commit the changes, e.g. "git add ." and "git commit -m Test". 4. Show hidden files in the folder. 5. Observe the overlay VCS icon size. Hidden files/folders have a smaller VCS icon then non-hidden files/folders. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 497372] [24.12.0 Regression] Overlay icons have inconsistent sizes
https://bugs.kde.org/show_bug.cgi?id=497372 Luke Horwell changed: What|Removed |Added Summary|24.12.0: Overlay/emblem |[24.12.0 Regression] |icons at 64px view |Overlay icons have |inconsistently larger |inconsistent sizes -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 476800] KWrite and "minimal overlapping" window placement regressed since 22.08.3
https://bugs.kde.org/show_bug.cgi?id=476800 --- Comment #8 from Luke Horwell --- Tried your patch on Arch Linux by rebuilding kate 24.12.1 + 1697.patch. I don't see much difference with the patch for this particular bug, under X11. Wayland is fine. All I noticed is the menu bar did disappear once "Restore Window Configuration=false" was added in kwriterc, and it remembers my preference (menu bar visible) on next launch. A quick recap of this bug: - Only affects X11 session. Wayland works fine. - Only affects KWrite. Kate works fine. - With minimal overlapping set in Plasma, KWrite opens in buggy 'minimal' positions (overlapping a window, opening in same spot, etc). - On X11, manually adding "Restore Window Configuration=false" under [General] in ~/.config/kwriterc fixes the buggy overlapping, but the height/width is no longer remembered. [see workaround] - On Wayland, don't add "Restore Window Configuration=false". This is the default. - This GUI option to change this setting is missing in KWrite. Workaround (for X11): - Add line to ~/.config/kwriterc [see above]. - Add a window rule to set a height/width (and possibly force "Ignore geometry" for good measure). Now on par with how a Dolphin window behaves. Since it seems to be only me with this issue, and with X11 being deprecated long-term, the status quo with the above workaround works for me. I don't mind if this is closed as a WONTFIX. However, a possible solution for this bug could be to add the missing "Include window configuration" checkbox (in the "Session Elements" group) for KWrite too. -- You are receiving this mail because: You are watching all bug changes.
[Smb4k] [Bug 442187] Smb4K 3.1.0 still has frustrating, old usability glitches and bugs (explained in description). Kills usability.
https://bugs.kde.org/show_bug.cgi?id=442187 Bug 442187 depends on bug 442877, which changed state. Bug 442877 Summary: Submenus of KStatusNotifierItem open to the wrong side https://bugs.kde.org/show_bug.cgi?id=442877 What|Removed |Added Status|NEEDSINFO |CONFIRMED Resolution|FIXED |--- -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 442877] Submenus of KStatusNotifierItem open to the wrong side
https://bugs.kde.org/show_bug.cgi?id=442877 Luke Horwell changed: What|Removed |Added Status|NEEDSINFO |CONFIRMED Resolution|FIXED |--- --- Comment #5 from Luke Horwell --- The bug is still present in Plasma 6.2.5. Using the Python test case (attachment), I can still reproduce the issue as described (menus open _initially_ to the wrong side). Tested under: Arch Linux KDE Plasma 6.2.5 KDE Frameworks 6.9.0 Qt Version 6.8.1 X11 Does the test case work for you? If the issue was indeed fixed, please could you share details of your environment and the app? Additionally, if there were specific commits or changes that addressed this bug, I’d appreciate a reference to help verify - I couldn't see any specific commits. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 442877] Submenus of KStatusNotifierItem open to the wrong side
https://bugs.kde.org/show_bug.cgi?id=442877 --- Comment #6 from Luke Horwell --- Created attachment 177256 --> https://bugs.kde.org/attachment.cgi?id=177256&action=edit Test case: QSystemTrayIcon in Python (PyQt6) Here's another test case to demonstrate, using QSystemTrayIcon (Qt) via PyQt6. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 500103] New: Window title wraps search query with '%27'
https://bugs.kde.org/show_bug.cgi?id=500103 Bug ID: 500103 Summary: Window title wraps search query with '%27' Classification: Applications Product: dolphin Version: 24.12.2 Platform: Other OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: search Assignee: dolphin-bugs-n...@kde.org Reporter: c...@horwell.me CC: kfm-de...@kde.org Target Milestone: --- Created attachment 178390 --> https://bugs.kde.org/attachment.cgi?id=178390&action=edit Screenshot of the window title with character escaping issue SUMMARY In Dolphin 24.12.2, perform a search in most (or all) locations will show %27 in the window title. STEPS TO REPRODUCE 1. Click the search icon and type "test". 2. Observe the window title. OBSERVED WINDOW TITLE Query Results from %27test%27 — Dolphin EXPECTED WINDOW TITLE Query Results from test — Dolphin SOFTWARE/OS VERSIONS Arch Linux KDE Plasma: 6.1.0 KDE Frameworks Version: 6.10.0 Qt Version: 6.8.2 ADDITIONAL INFORMATION Dolphin 24.08.3 does not have this bug. However, the window title in that version simply says "Search for test — Dolphin" - which I think was better at conveying the same meaning in less words (especially with the "icons and text task manager" on the panel) -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 500101] New: Dolphin crashes when middle clicking back button when a search page was last in history
https://bugs.kde.org/show_bug.cgi?id=500101
Bug ID: 500101
Summary: Dolphin crashes when middle clicking back button when
a search page was last in history
Classification: Applications
Product: dolphin
Version: 24.12.2
Platform: Arch Linux
OS: Linux
Status: REPORTED
Keywords: drkonqi
Severity: crash
Priority: NOR
Component: general
Assignee: dolphin-bugs-n...@kde.org
Reporter: c...@horwell.me
CC: kfm-de...@kde.org
Target Milestone: ---
Application: dolphin (24.12.2)
ApplicationNotResponding [ANR]: false
Qt Version: 6.8.2
Frameworks Version: 6.10.0
Operating System: Linux 6.13.2-arch1-1 x86_64
Windowing System: Wayland
Distribution: EndeavourOS
DrKonqi: 6.3.0 [CoredumpBackend]
-- Information about the crash:
When searching for files in Dolphin, then searching again with different terms
and middle clicking the back arrow to open a tab for the last search page will
cause Dolphin to crash each time.
STEPS TO REPRODUCE
1. Open /home in Dolphin.
2. Perform a search, e.g. "apple".
3. Perform another search by changing the search terms, e.g. "banana"
4. Middle click the back arrow.
5. Crash!
OBSERVED RESULT
Dolphin crashes when creating a new tab where the last item in history was a
search page.
EXPECTED RESULT
A new tab for the last search (e.g. "apple") is created.
ADDITIONAL INFORMATION
The problem is also present in Dolphin 24.08.3.
The crash can be reproduced every time.
-- Backtrace:
Application: Dolphin (dolphin), signal: Segmentation fault
Content of s_kcrashErrorMessage: std::unique_ptr = {get() = }
warning: Can't open file /memfd:lp_dma_buf (deleted) during file-backed mapping
note processing
warning: Can't open file /memfd:wayland-shm (deleted) during file-backed
mapping note processing
[New LWP 1001]
[New LWP 1013]
[New LWP 1018]
[New LWP 1016]
[New LWP 1006]
[New LWP 1007]
[New LWP 1002]
[New LWP 1005]
[New LWP 1003]
[New LWP 1004]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
Core was generated by `/usr/bin/dolphin'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 __pthread_kill_implementation (threadid=,
signo=signo@entry=11, no_tid=no_tid@entry=0) at pthread_kill.c:44
44return INTERNAL_SYSCALL_ERROR_P (ret) ? INTERNAL_SYSCALL_ERRNO
(ret) : 0;
[Current thread is 1 (Thread 0x7a6927b35a00 (LWP 1001))]
Cannot QML trace cores :(
/usr/share/drkonqi/gdb/python/gdb_preamble/preamble.py:531: DeprecationWarning:
datetime.datetime.utcfromtimestamp() is deprecated and scheduled for removal in
a future version. Use timezone-aware objects to represent datetimes in UTC:
datetime.datetime.fromtimestamp(timestamp, datetime.UTC).
boot_time =
datetime.utcfromtimestamp(psutil.boot_time()).strftime('%Y-%m-%dT%H:%M:%S')
Downloading 1.41 K source file
/usr/src/debug/glibc/glibc/io/../sysdeps/unix/sysv/linux/poll.c...
Downloading 10.05 K source file
/usr/src/debug/qt6-base/qtbase/src/dbus/qdbusconnectionmanager.cpp...
Downloading 11.71 K source file
/usr/src/debug/qt6-base/qtbase/src/corelib/global/qflags.h...
Downloading 13.15 K source file
/usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qeventloop.cpp...
Downloading 17.52 K source file
/usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qeventdispatcher_glib.cpp...
Downloading 184.85 K source file
/usr/src/debug/glib2/build/../glib/glib/gmain.c...
Downloading 2.27 K source file
/usr/src/debug/glibc/glibc/io/../sysdeps/unix/sysv/linux/ppoll.c...
Downloading 1.22 K source file
/usr/src/debug/kio/kio-6.10.0/src/core/workerthread.cpp...
Downloading 44.92 K source file
/usr/src/debug/kio/kio-6.10.0/src/core/slavebase.cpp...
Downloading 6.30 K source file
/usr/src/debug/kio/kio-6.10.0/src/core/connection.cpp...
Downloading 9.13 K source file
/usr/src/debug/kio/kio-6.10.0/src/core/connectionbackend.cpp...
Downloading 100.00 K source file
/usr/src/debug/qt6-base/qtbase/src/network/socket/qabstractsocket.cpp...
Downloading 48.00 K source file
/usr/src/debug/qt6-base/qtbase/src/network/socket/qnativesocketengine.cpp...
Downloading 49.15 K source file
/usr/src/debug/qt6-base/qtbase/src/network/socket/qnativesocketengine_unix.cpp...
Downloading 4.13 K source file
/usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qcore_unix.cpp...
Downloading 26.05 K source file
/usr/src/debug/qt6-base/qtbase/src/corelib/thread/qthreadpool.cpp...
Downloading 38.27 K source file
/usr/src/debug/qt6-base/qtbase/src/corelib/thread/qthread.cpp...
Downloading 11.70 K source file
/usr/src/debug/dolphin/dolphin-24.12.2/src/main.cpp...
Downloading 145.00 K source file
/usr/src/debug/qt6-base/qtbase/src/widgets/kernel/qapplication.cpp...
Downloading 14.22 K source file
/usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qtimerinfo_unix.cpp...
Downloading 114.44 K source file
/usr/src/debug/qt6-base/qtbase/src/corelib/kernel/qco
[plasmashell] [Bug 499989] Ability to disable inline divider on digital clock
https://bugs.kde.org/show_bug.cgi?id=499989
Luke Horwell changed:
What|Removed |Added
CC||c...@horwell.me
--- Comment #2 from Luke Horwell ---
Same here. Modifying DigitalClock.qml to remove the hardcoded "|" separator
caused the spacing between date and time to be too wide and equally as
unconfigurable. My panel separates date/time with a comma (",") which is easily
achieved by setting the "Date format" custom field.
For now, I've copied the old file from plasma-workspace-6.2.5-1 package:
/usr/share/plasma/plasmoids/org.kde.plasma.digitalclock/contents/ui/DigitalClock.qml
--
You are receiving this mail because:
You are watching all bug changes.
[plasmashell] [Bug 499997] New: Virtual desktops no longer reset to Desktop 1 at logon
https://bugs.kde.org/show_bug.cgi?id=47 Bug ID: 47 Summary: Virtual desktops no longer reset to Desktop 1 at logon Classification: Plasma Product: plasmashell Version: 6.3.0 Platform: Arch Linux OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: Pager widget Assignee: plasma-b...@kde.org Reporter: c...@horwell.me CC: h...@kde.org Target Milestone: 1.0 SUMMARY Since upgrading to Plasma 6.3, the last virtual desktop position is restored, which is undesired, especially as the desktop session settings are set to "Start with an empty session" (System Settings → Desktop Session). STEPS TO REPRODUCE 1. Add a few virtual desktops. 2. Use the pager to switch to desktop 3. 3. Log out. 4. Log back in. 5. Observe the current virtual desktop position. OBSERVED RESULT If you log out on desktop 3, you return to desktop 3. EXPECTED RESULT If you log out on desktop 3, you return to desktop 1. SOFTWARE/OS VERSIONS Arch Linux KDE Plasma Version: 6.3.0 KDE Frameworks Version: 6.10.0 Qt Version: 6.8.2 Both X11 and Wayland affected. ADDITIONAL INFORMATION This behaviour is inconsistent with other panel environments like MATE, which by default, start from 1. Unsurprisingly, this is because an old bug was fixed (BUG 390295): https://invent.kde.org/plasma/kwin/-/commit/4599483dba615546dd7e6c4cc73f3275ad9c3979 Suggestions: (a) When an empty session is set, don't restore the virtual desktop last position. (b) Add an option "Remember virtual desktop position between sessions". -- You are receiving this mail because: You are watching all bug changes.
[plasma-integration] [Bug 499179] "Open Folder" dialog visually breaks after resizing places panel splitter to the right with a narrow window width
https://bugs.kde.org/show_bug.cgi?id=499179 Luke Horwell changed: What|Removed |Added CC||c...@horwell.me --- Comment #8 from Luke Horwell --- The width of the sidebar also doesn't happen to be saved under the directory picker, but does under the file picker. Reported that as BUG 500435. If the kdialog package is installed, another way to get to this dialog is run: > kdialog --getexistingdirectory -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 421247] Cannot decrease the size of the Places panel of the folder selector
https://bugs.kde.org/show_bug.cgi?id=421247 Luke Horwell changed: What|Removed |Added Status|REPORTED|CONFIRMED CC||c...@horwell.me Ever confirmed|0 |1 --- Comment #7 from Luke Horwell --- The relevant class is KDirSelectDialog (from src/kdirselectdialog.cpp) from plasma-integration. I believe it may have been filed under the wrong product/component so I've corrected it. There's a Qt splitter and a minimum size being enforced. Some related bugs: - BUG 499179 - The weird window behaviour at small sizes. - BUG 500435 - The width of the sidebar isn't being saved at all. -- You are receiving this mail because: You are watching all bug changes.
[plasma-integration] [Bug 421247] Cannot decrease the size of the Places panel of the folder selector
https://bugs.kde.org/show_bug.cgi?id=421247 Luke Horwell changed: What|Removed |Added Product|frameworks-kio |plasma-integration Assignee|kio-bugs-n...@kde.org |plasma-b...@kde.org Component|Open/save dialogs |general Version|5.102.0 |5.18.5 -- You are receiving this mail because: You are watching all bug changes.
[plasma-integration] [Bug 500435] New: "Open Folder" (directory picker) does not save the sidebar width
https://bugs.kde.org/show_bug.cgi?id=500435 Bug ID: 500435 Summary: "Open Folder" (directory picker) does not save the sidebar width Classification: Plasma Product: plasma-integration Version: 6.3.1 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: c...@horwell.me Target Milestone: --- Created attachment 178614 --> https://bugs.kde.org/attachment.cgi?id=178614&action=edit Reference of what the directory selector looks like SUMMARY The directory picker does not remember its width and is reset each time. This makes it inconsistent with others like the file picker and Dolphin sidebar, which do. STEPS TO REPRODUCE 1. Perform a task that opens a directory picker, or run "kdialog --getexistingdirectory" 2. Resize the sidebar 3. Close the directory picker and open it again 4. Observe the size of the sidebar OBSERVED RESULT The size of the sidebar is not retained. EXPECTED RESULT The size of the sidebar is retained, with similar behaviour to the file picker. SOFTWARE/OS VERSIONS Arch Linux KDE Plasma Version: 6.3.1 KDE Frameworks Version: 6.11.0 Qt Version: 6.8.2 ADDITIONAL INFORMATION The relevant class is KDirSelectDialog from src/kdirselectdialog.cpp. It should be noted that icon size setting is remembered. At this time, there is also BUG 499179 which is preventing the sidebar from being resized any smaller. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 500103] Window title wraps search query with '%27'
https://bugs.kde.org/show_bug.cgi?id=500103 --- Comment #3 from Luke Horwell --- (In reply to TraceyC from comment #2) > Curiously, I'm not able to reproduce this with Dolphin 24.12.2 or built from > git-master It depends where the search takes place. In my testing, the title was correct when searching the home folder, but the window title goes bad when searching from the root filesystem folder (/). It looks like it has something to do with file indexing. In my VM, the window title was OK when searching the home folder, but disabling the file index and starting a new search, '%27' is seen in the window title thereafter. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 500103] Window title wraps search query with '%27' in non-indexed locations
https://bugs.kde.org/show_bug.cgi?id=500103 Luke Horwell changed: What|Removed |Added Summary|Window title wraps search |Window title wraps search |query with '%27'|query with '%27' in ||non-indexed locations -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 500428] Unusual placement of overlay icons
https://bugs.kde.org/show_bug.cgi?id=500428 Luke Horwell changed: What|Removed |Added Version|24.12.2 |git-master --- Comment #1 from Luke Horwell --- Affects git-master only, not 24.12.2, my mistake. Might have been mentioned here: https://invent.kde.org/system/dolphin/-/merge_requests/912 > One think master could improve is the position of the overlay icon with small > sizes, I think we can do something. -- You are receiving this mail because: You are watching all bug changes.
[bugs.kde.org] [Bug 500476] Bug Janitor Suggestion: Add comment if merge request description is edited with a new "BUG:" keyword
https://bugs.kde.org/show_bug.cgi?id=500476 Luke Horwell changed: What|Removed |Added Resolution|--- |NOT A BUG Status|REPORTED|RESOLVED --- Comment #4 from Luke Horwell --- Thank you for the feedback and information. On reflection, it seems like it's not worth it. The current "static" approach (once, on open, on close) will be more reliable then risking a "dynamic" aspect. I was thinking it would enumerate the Bugzilla comments (authored by bot) before commenting, but I hadn't dug deeper into these APIs. There's always the risk of breakage if the string changed in future, as well as increased maintenance if/when an API or library changes. Completely missed that area of the wiki, my bad. My searches and entry points yesterday kept me within the "Get Involved" areas. Didn't spot any links towards the "Policies" area. The previews when searching the wiki wasn't as obvious: - https://community.kde.org/index.php?search=%22BUG%3A%22&title=Special%3ASearch&profile=default&fulltext=1 [Yesterday] - https://community.kde.org/index.php?search=%22BUG%3A%22+keywords&title=Special%3ASearch&profile=default&fulltext=1 [Today] I see now it is also mentioned in: https://community.kde.org/Infrastructure/GitLab#Write_a_good_commit_message and https://community.kde.org/Infrastructure/Git/Hooks#Keywords too. Thanks again for considering the suggestion! -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 500624] When zooming, 1 of the zoom change make linked files (soft link) with generated thumbnail have less zoomed thumbnails (and overlay emblem)
https://bugs.kde.org/show_bug.cgi?id=500624 Luke Horwell changed: What|Removed |Added CC||c...@horwell.me --- Comment #1 from Luke Horwell --- Created attachment 178774 --> https://bugs.kde.org/attachment.cgi?id=178774&action=edit Zooming in dolphin master@59e3f59b + MR 917 It might be worth testing the master branch of Dolphin to see if this particular case has been resolved. Attached is a video running the latest master plus https://invent.kde.org/system/dolphin/-/merge_requests/917 that I was keen to test. I'm observing that thumbnail sizes are consistent now (no longer suddenly smaller/larger at certain zoom points), but the animation and thumbnail refresh still isn't as smooth as it was in 24.08.3. -- You are receiving this mail because: You are watching all bug changes.
[kdevplatform] [Bug 443118] KDevelop's "Problems" panel should list FIXME/TODO comments for other programming languages
https://bugs.kde.org/show_bug.cgi?id=443118 Luke Horwell changed: What|Removed |Added Summary|KDevelop's Problems tool|KDevelop's "Problems" panel |view to list FIXME/TODO |should list FIXME/TODO |comments|comments for other ||programming languages -- You are receiving this mail because: You are watching all bug changes.
[plasma-integration] [Bug 500435] "Open Folder" (directory picker) does not save the sidebar width
https://bugs.kde.org/show_bug.cgi?id=500435 Luke Horwell changed: What|Removed |Added Status|REPORTED|CONFIRMED Ever confirmed|0 |1 --- Comment #1 from Luke Horwell --- I've created a merge request to fix this (and 2 other bugs): https://invent.kde.org/plasma/plasma-integration/-/merge_requests/168 -- You are receiving this mail because: You are watching all bug changes.
[plasma-integration] [Bug 421247] Cannot decrease the size of the Places panel of the folder selector
https://bugs.kde.org/show_bug.cgi?id=421247 --- Comment #8 from Luke Horwell --- I've created a merge request that fixes this (and 2 other bugs): https://invent.kde.org/plasma/plasma-integration/-/merge_requests/168 -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 500476] New: Bug Janitor Suggestion: Add comment if merge request description is edited with a new "BUG:" keyword
https://bugs.kde.org/show_bug.cgi?id=500476
Bug ID: 500476
Summary: Bug Janitor Suggestion: Add comment if merge request
description is edited with a new "BUG:" keyword
Classification: I don't know
Product: kde
Version: unspecified
Platform: Other
OS: Linux
Status: REPORTED
Severity: wishlist
Priority: NOR
Component: general
Assignee: unassigned-b...@kde.org
Reporter: c...@horwell.me
Target Milestone: ---
SUMMARY
The bug janitor adds a comment "A possibly relevant merge request was started @
" when a merge request is opened with the "BUG:" keyword on a line. However, I
typically can't remember what is valid syntax for this to work ("BUG 123" or
"BUG: 123"? Does "Bug 123" work too?). In particular, by editing the MR
description, nothing happens.
I struggled to find any documentation or code
(https://invent.kde.org/sysadmin/bugzilla-bot) that directly uses this string,
so I'm not sure where/how it works. I'd guess it's some kind of webhook in
GitLab.
As a suggestion, please could:
* The documentation/wiki describe the optional keywords like "BUG:" or "CCBUG:"
when a creating a merge request that directly fixes a bug. Perhaps include
whether the janitor runs on a timer (e.g. every hour) or only at time of the MR
being opened.
* Add a mechanism/hook into GitLab so:
- When a merge request description is edited, summon bot.
- Bot reads Bugzilla comments. If "A possibly relevant..." comment was
found for bug, skip. Otherwise, add comment.
STEPS TO REPRODUCE
1. Open a merge request that fixes a bug, but don't add "BUG: XXX"
2. Edit the description in the merge request and add "BUG: " (XXX = bug
report number)
OBSERVED RESULT
Bug janitor doesn't inform the bug report. Developer unsure if janitor will
ever come back.
EXPECTED RESULT
Bug janitor posts "A possibly relevant merge request was started" if the
description is updated with new bug references.
--
You are receiving this mail because:
You are watching all bug changes.
[plasma-integration] [Bug 499179] "Open Folder" dialog visually breaks after resizing places panel splitter to the right with a narrow window width
https://bugs.kde.org/show_bug.cgi?id=499179 --- Comment #9 from Luke Horwell --- I've created a merge request that fixes this (and 2 other bugs): https://invent.kde.org/plasma/plasma-integration/-/merge_requests/168 (Bug janitor might not stop by since I didn't reference the bug in the description originally - suggestion at BUG 500476) -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 500428] New: Unusual placement of overlay icons
https://bugs.kde.org/show_bug.cgi?id=500428 Bug ID: 500428 Summary: Unusual placement of overlay icons Classification: Applications Product: dolphin Version: 24.12.2 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: dolphin-bugs-n...@kde.org Reporter: c...@horwell.me CC: kfm-de...@kde.org Target Milestone: --- Created attachment 178604 --> https://bugs.kde.org/attachment.cgi?id=178604&action=edit Screenshot of Dolphin 25.03.70 (git) with offset icons SUMMARY Since the overlay icons were refactored (previously causing regressions like BUG 497372 and BUG 498211). Visually, there is still a regression with the placement of overlay icons being positioned away from the icon instead of actually being overlaid. This looks unusual coming from other file managers / OS and presents a jarring feeling scanning a folder with icon states (e.g. read only, symlinks, VCS status) STEPS TO REPRODUCE 1. Browse to a folder containing overlay icons (symlinks, or root filesystem) 2. Observe icons under an Icon view mode. OBSERVED RESULT Overlay icons are offset to the side. EXPECTED RESULT Overlay icons actually overlaid on top of an icon. SOFTWARE/OS VERSIONS Arch Linux KDE Plasma: 6.3.1 KDE Frameworks Version: 6.11.0 Qt Version: 6.8.2 ADDITIONAL INFORMATION The change was introduced in https://invent.kde.org/system/dolphin/-/merge_requests/889, which had passed one approval of this change. I appreciate the fact it might have been a challenge to get it right with varying icon sizes. As a workaround, stick with Dolphin 24.08.3 before the overlays started changing. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 500737] Notifications sent a 0 msec timeout no longer displayed indefinitely & may clip the next notification
https://bugs.kde.org/show_bug.cgi?id=500737 --- Comment #2 from Luke Horwell --- Thank you for triaging! Can confirm under Plasma 6.2 that upgrading libnotify to 0.8.4-1 is the cause. Just a coincidence since Plasma updated around the same time! The clipping/cut off notifications may still be a bug on Plasma's side, were you able to reproduce that issue too? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 500737] New: Notifications sent a 0 msec timeout no longer displayed indefinitely & may clip the next notification
https://bugs.kde.org/show_bug.cgi?id=500737
Bug ID: 500737
Summary: Notifications sent a 0 msec timeout no longer
displayed indefinitely & may clip the next
notification
Classification: Plasma
Product: plasmashell
Version: 6.3.1
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: Notifications
Assignee: plasma-b...@kde.org
Reporter: c...@horwell.me
CC: k...@privat.broulik.de
Target Milestone: 1.0
Created attachment 178872
--> https://bugs.kde.org/attachment.cgi?id=178872&action=edit
Video demonstrating the clipped notification after a 0 msec notification
SUMMARY
Since Plasma 6.3.0, I realised one my shell scripts was causing buggy
notification behaviour. In particular, the script sends a transient ("don't
show in history") notification with a timeout of 0 to indicate a long-running
action. In Plasma 6.2.x, the 0 msec timeout allowed normal priority
notifications to appear indefinitely until dismissed, or if the script replaces
it by ID:
> NOTIFY_ID=$(notify-send -p -e -a Example -t 0 -i clock "Performing action...")
>
> notify-send -r ${NOTIFY_ID} -a Example -i emblem-success "Action completed"
Currently, notifications in Plasma 6.3.1 now quickly fades in/out a
notification sent with a 0 msec timeout. Sometimes, this also causes the next
notification to appear clipped. I also observed the other day that one was
incorrectly positioned in the top-left corner of the screen (BUG 499970 ?), but
I was unable to reproduce that, so not sure if related.
STEPS TO REPRODUCE
1. Execute "notify-send -a Test -i clock "This is a test" -t 0"
2. Observe how long the notification stays open.
3. Try executing again. The subsequent notification risks appearing clipped
(regardless of timeout)
OBSERVED RESULT
(a) Notification quickly faded in and out. Can't read, too fast!
(b) The next notification may appear clipped (only a few pixels visible) if the
last one didn't fade/appear properly.
EXPECTED RESULT
(a) Notification with a 0 msec timeout are displayed indefinitely (OR fallback
to a default timeout)
(b) Notifications don't appear clipped.
SOFTWARE/OS VERSIONS
Arch Linux
KDE Plasma: 6.3.1
KDE Frameworks Version: 6.11.0
Qt Version: 6.8.2
X11
ADDITIONAL INFORMATION
It might be a user bug for sending a 0 msec timeout 'normal' notification, but
on the other hand, it could be considered a Plasma 6.3 regression since 0 msec
previously displayed such notification indefinitely. For now, the script can
fix the problem by sending an "urgent" notification type, or set a very high
timeout.
Originally the bug report was for the clipping issue, but I'd guess it's due to
the 0 timeout behaviour. Fixing the timeout might fix the clipping/position
issues too.
The video recording got lucky, since the first time the command ran, no
notification was seen (no fade at all), then the next one was clipped. As later
shown, it isn't always 100% reproducible.
--
You are receiving this mail because:
You are watching all bug changes.
[dolphin] [Bug 500103] Window title wraps search query with '%27'
https://bugs.kde.org/show_bug.cgi?id=500103 --- Comment #1 from Luke Horwell --- >From looking at the code (dolphinsearchbox.cpp, queryTitle): * At first glance, involves this commit: https://invent.kde.org/system/dolphin/-/commit/2059ce2986e2d2cf6e22041b2ffe28e50b913c7f * Later fixed by: https://invent.kde.org/system/dolphin/-/merge_requests/806 * Then fixed in KIO here: https://invent.kde.org/frameworks/kio/-/merge_requests/1678 However, from a git bisect, the problem starts with this commit: https://invent.kde.org/system/dolphin/-/commit/80d2ea0bcc37737348b1df1691e21763272d0157 Reverting the commit fixes the issue and also restores the desired "Search for [...]" text in the window title. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 501265] Add ability to drag-and-drop custom icons in properties dialog
https://bugs.kde.org/show_bug.cgi?id=501265 Luke Horwell changed: What|Removed |Added Summary|Add ability to |Add ability to |drag-and-drop icons in |drag-and-drop custom icons |properties dialog |in properties dialog -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 494521] Behaviour change with timezones in Qt 6.8
https://bugs.kde.org/show_bug.cgi?id=494521
Luke Horwell changed:
What|Removed |Added
Status|REOPENED|CONFIRMED
--- Comment #7 from Luke Horwell ---
(In reply to popov895 from comment #5)
>
> So it looks like this is an intentional change in Qt 6.8. Therefore, it
> seems reasonable to me that KIO should use its own "long" format to display
> the date/time. Actually, I don't see any point in displaying the timezones
> here at all, because the creating/modification time should be converted to
> the user's local timezone.
I agree. This makes sense. The code for this is at
src/widgets/kpropertiesdialogbuiltin_p.cpp in the "kio" repository. It directly
uses a QLocale which only has 3 format types: LongFormat, ShortFormat,
NarrowFormat, confirming Qt 6.8's QLocale changed the behaviour.
I didn't see a way with Qt alone to exclude the time zone when formatting, so
having KIO handle a "long format without time zone" seems like a good idea.
Perhaps it could be as simple as taking the time zone string (e.g. "British
Summer Time") and subtracting that from the original 'long' output? (I'm just a
user however, not a KDE developer)
As a local hack, one could patch their own copy by forcing their desired date
format:
> -d->m_ui->modifiedTimeLabel->setText(locale.toString(dt,
> QLocale::LongFormat));
> +d->m_ui->modifiedTimeLabel->setText(dt.toString(QStringLiteral(" d
> , hh:mm:ss")));
--
You are receiving this mail because:
You are watching all bug changes.
[frameworks-kio] [Bug 501265] New: Add ability to drag-and-drop icons in properties dialog
https://bugs.kde.org/show_bug.cgi?id=501265
Bug ID: 501265
Summary: Add ability to drag-and-drop icons in properties
dialog
Classification: Frameworks and Libraries
Product: frameworks-kio
Version: 6.8.0
Platform: Other
OS: Linux
Status: REPORTED
Severity: wishlist
Priority: NOR
Component: Properties dialog
Assignee: kio-bugs-n...@kde.org
Reporter: c...@horwell.me
CC: kdelibs-b...@kde.org
Target Milestone: ---
Created attachment 179248
--> https://bugs.kde.org/attachment.cgi?id=179248&action=edit
Example of dropping a custom icon on button
SUMMARY
As a user who customises a lot of folder icons, it would enhance productivity
if the file properties dialog (as used in apps like Dolphin) could support
drag-and-drop to set a custom icon, as opposed to many steps to achieve the
same thing with the file picker.
STEPS TO REPRODUCE
1. Right click a folder → Properties.
2. Drag-and-drop an image file (PNG or SVG) to the icon button.
OBSERVED RESULT
Cursor shows a clashed circle, not possible. Must perform many clicks:
1. The icon button ("iconButton")
2. Click "Browse..."
3. Drag and drop the desired icon.
4. Accept the file picker.
5. Accept the icon chooser.
EXPECTED RESULT
Icon button implements the drop event for valid image files.
SOFTWARE/OS VERSIONS
KDE Plasma Version: 6.3.2
KDE Frameworks Version: 6.11.0
Qt Version: 6.8.2
--
You are receiving this mail because:
You are watching all bug changes.
[plasma-integration] [Bug 499179] "Open Folder" dialog visually breaks after resizing places panel splitter to the right with a narrow window width
https://bugs.kde.org/show_bug.cgi?id=499179 --- Comment #13 from Luke Horwell --- Thanks for the merge! I couldn't with good coincidence declare this bug as "fixed" after using my patched fix for weeks. Of the many times I use the directory picker in programs, the bug struck at me once (so, very rare). My sidebar looked smaller then my usual, and dragging it out to the right as described in this report caused a broken layout glitch. The quick fix is to dismiss the directory picker; open the file ~/.config/kdeglobals and delete the keys under the group [DirSelect Dialog]. It won't glitch again or be reproducible afterwards. Can't quite put my finger on why this happens, or how to replicate, but still an improvement then always glitching out! Since it's been cherry picked, the improvement should be available starting with 6.3.3 to re-test. -- You are receiving this mail because: You are watching all bug changes.
[plasma-integration] [Bug 499179] "Open Folder" dialog visually breaks after resizing places panel splitter to the right with a narrow window width
https://bugs.kde.org/show_bug.cgi?id=499179 --- Comment #14 from Luke Horwell --- * Correction to previous comment: It was cherry picked into the Plasma 6.3.3 branch, but missed the 6.3.3 release: https://invent.kde.org/plasma/plasma-integration/-/commits/2885b098a2275ddce9021248b6bf788b4879f42e -- You are receiving this mail because: You are watching all bug changes.
[plasma-integration] [Bug 400054] DirSelect Dialog saves history in kdeglobals
https://bugs.kde.org/show_bug.cgi?id=400054 Luke Horwell changed: What|Removed |Added Ever confirmed|0 |1 CC||c...@horwell.me Status|REPORTED|CONFIRMED --- Comment #3 from Luke Horwell --- Can confirm KDirSelectDialog is saving history into ~/.config/kdeglobals. With today's Plasma 6.3, saving history when selecting directories seems redundant. None of the programs I tried (KDE and non-KDE) actually read this history nor have a recents menu because the program will set the initial folder. ($HOME in most cases) -- You are receiving this mail because: You are watching all bug changes.
[plasma-integration] [Bug 400054] DirSelect Dialog saves history in kdeglobals
https://bugs.kde.org/show_bug.cgi?id=400054 --- Comment #4 from Luke Horwell --- Regarding my last comment, I made a mistake. Turns out history is used for the combo box (drop down), but obviously will be the same across all applications (globally). Ideally would be stored per-app in the *rc files if it is to be consistent with KFileDialog. A quick way to test this dialog is with kdialog: > kdialog --getexistingdirectory [initial path] -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 496179] Kickoff: Recent folders appear as "unknown" icon under Places -> History
https://bugs.kde.org/show_bug.cgi?id=496179 Luke Horwell changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #14 from Luke Horwell --- Can confirm Plasma 6.3.3 shows the unknown icon here too. Thanks for spotting, I haven't used the history menu in a while. I also observe the grouping, "Files", "Folders", "Files", "Folders" multiple times, that I don't recall seeing before. The only items that appear under "Folders" are any items that happen to be on my Places sidebar. There's BUG 501903 for that one. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 501903] Two "Files" sections under "History"
https://bugs.kde.org/show_bug.cgi?id=501903
Luke Horwell changed:
What|Removed |Added
Ever confirmed|0 |1
CC||c...@horwell.me
Status|REPORTED|CONFIRMED
--- Comment #2 from Luke Horwell ---
Can confirm. It looks like it lists items in chronological order, but each
file/folder type causes a new group to start. Grouping by relative time
("Today", "Yesterday") would make more sense to me. Or, I'd be happier with no
grouping at all, assuming it's sorting in chronological order, newest at top.
It's similiar for the "Frequently Used" list too - perhaps "Most frequent",
"Occasionally" could be groups. Or likewise, grouping doesn't seem a necessity
for that list either.
--
You are receiving this mail because:
You are watching all bug changes.
[kwin] [Bug 501393] Window focus is lost after activity switch when using multiple activities and screens (Plasma 6.3.2, Frameworks 6.1.1, Qt 6.8.2)
https://bugs.kde.org/show_bug.cgi?id=501393 Luke Horwell changed: What|Removed |Added CC||c...@horwell.me Status|REPORTED|CONFIRMED Ever confirmed|0 |1 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 501397] [X11] Activity switch issue when virtual desktop switch is involved
https://bugs.kde.org/show_bug.cgi?id=501397 Luke Horwell changed: What|Removed |Added Resolution|--- |DUPLICATE CC||c...@horwell.me Status|REPORTED|RESOLVED --- Comment #2 from Luke Horwell --- I ran into the same issue too (after not using activities in a long while). Looks to be the same as BUG 501393. *** This bug has been marked as a duplicate of bug 501393 *** -- You are receiving this mail because: You are watching all bug changes.
