[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.
[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
--- Comment #4 from Luke Horwell ---
Created attachment 168947
--> https://bugs.kde.org/attachment.cgi?id=168947=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.
[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.
[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.
[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=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.
[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.
[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.
[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 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.
[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.
[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=edit Buggy behaviour (kwrite 23.08.2) -- 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=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.
[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.
[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=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.
[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=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.
[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.
[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.
[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.
[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=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.
[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.
[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=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] 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.
[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.
[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.
[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=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.
[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.
[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.
[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=edit Reverts commit 0c76e685e022e8a9648805f8ddc5a2857c9e37bb -- 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.
[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.
[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=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.
[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] 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.
[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=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.
[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.
[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=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.
