[systemsettings] [Bug 456574] New: System Settings - Desktop Effects - Missing scrollbar
https://bugs.kde.org/show_bug.cgi?id=456574 Bug ID: 456574 Summary: System Settings - Desktop Effects - Missing scrollbar Product: systemsettings Version: 5.25.2 Platform: openSUSE RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: kcm_kwin_effects Assignee: kwin-bugs-n...@kde.org Reporter: polarathene-sig...@hotmail.com CC: plasma-b...@kde.org Target Milestone: --- SUMMARY Without one it is a bit tedious to navigate, especially when you want to toggle an effect or modify settings at the bottom of the list. This issue seems similar to a previous one, however the package qqc2-desktop-style is installed, something else has changed since: https://bugs.kde.org/show_bug.cgi?id=406182 STEPS TO REPRODUCE 1. Open System Settings, navigate to Desktop Effects. OBSERVED RESULT No scroll bar available. EXPECTED RESULT A scroll bar should be present. SOFTWARE/OS VERSIONS Tested via VMware and QEMU-KVM VM guests with 3D accel enabled: Operating System: openSUSE Tumbleweed 20220708 (Krypton, daily build of KDE git) KDE Plasma Version: 5.25.80 KDE Frameworks Version: 5.97.0 Qt Version: 5.15.5 Kernel Version: 5.18.9 Graphics Platform: X11 + Wayland Extra: xorg: 21.1.3, xwayland 22.1.2, mesa 22.1.3 SVGA3D => vmwgfx 2.20.0 (VMware guest) virgl => virtio_gpu (QEMU-KVM guest) Operating System: EndeavourOS (ArchLinux based, fresh and updated install) KDE Plasma Version: 5.25.2 KDE Frameworks Version: 5.95.0 Qt Version: 5.15.5 Kernel Version: 5.18.10 Graphics Platform: X11 + Wayland Extra: xorg: 21.1.3, xwayland 22.1.2, mesa 22.1.3 SVGA3D => vmwgfx 2.20.0 (VMware guest) virgl => virtio_gpu (QEMU-KVM guest) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 456572] New: KWin effects Overview and Present Windows poor contrast with underlay
https://bugs.kde.org/show_bug.cgi?id=456572 Bug ID: 456572 Summary: KWin effects Overview and Present Windows poor contrast with underlay Product: kwin Version: 5.25.2 Platform: openSUSE RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: effects-overview Assignee: kwin-bugs-n...@kde.org Reporter: polarathene-sig...@hotmail.com Target Milestone: --- SUMMARY This may be dependent upon the theme, but looked unpleasant in both default Breeze and a third-party dark theme. For the dark theme, the underlay almost blended in with the window colours. STEPS TO REPRODUCE 1. Enable and toggle each of the effects. 2. "Overview" and "Present Windows" should have underlays that can look washed out, and the latter cannot remove or adjust blur (blur effect settings don't seem to have any effect to it). OBSERVED RESULT Washed out underlay provides poor contrast to windows shown, even with a dark background. Especially with a dark theme. EXPECTED RESULT No underlay, or control over colour/opacity or contrast so that windows shown stand out better. SOFTWARE/OS VERSIONS Tested via VMware and QEMU-KVM VM guests with 3D accel enabled: Operating System: openSUSE Tumbleweed 20220708 (Krypton, daily build of KDE git) KDE Plasma Version: 5.25.80 KDE Frameworks Version: 5.97.0 Qt Version: 5.15.5 Kernel Version: 5.18.9 Graphics Platform: X11 + Wayland Extra: xorg: 21.1.3, xwayland 22.1.2, mesa 22.1.3 SVGA3D => vmwgfx 2.20.0 (VMware guest) virgl => virtio_gpu (QEMU-KVM guest) Operating System: EndeavourOS (ArchLinux based, fresh and updated install) KDE Plasma Version: 5.25.2 KDE Frameworks Version: 5.95.0 Qt Version: 5.15.5 Kernel Version: 5.18.10 Graphics Platform: X11 + Wayland Extra: xorg: 21.1.3, xwayland 22.1.2, mesa 22.1.3 SVGA3D => vmwgfx 2.20.0 (VMware guest) virgl => virtio_gpu (QEMU-KVM guest) ADDITIONAL INFORMATION Only "Overview" effect provides an option to disable blur (which does not affect "Present Windows" that lacks this option). I mention that so that both effects settings can be resolved. The related effect "Desktop Grid" behaves a bit differently (if only 1 virtual desktop), by omitting any underlay. There's a bit of disparity between UI elements (virtual desktop add/remove, search) between the effects. In earlier releases, I remember "Present Windows" having a dark contrasting underlay. Now I am given the impression it is tied to the theme/color scheme, but not obvious as to a user what to change / look for to adjust (or if that will affect other parts of UI visuals negatively in doing so). I'd be happy with no underlay at all vs the current experience that gets in the way with a washed out look, even when the background/wallpaper is quite dark and contrasting, the underlay is far brighter. -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 451698] Actually applied accent color is not the exact color you chose in the UI
https://bugs.kde.org/show_bug.cgi?id=451698 Brennan Kinney changed: What|Removed |Added CC||polarathene-signup@hotmail. ||com --- Comment #10 from Brennan Kinney --- Chiming in as I think this is what I've just noticed when testing latest daily build of openSUSE Krypton. "Use accent color" results in different appearance between "From current color scheme" and "Custom", despite providing the same colour value. I am not familiar with the color scheme or accent feature. Playing around with editing a color scheme, it seemed the "Selection Color" was mapped to the accent used by the scheme, and the contrast slider in the options tab made no difference. I liked the brighter accent from the scheme, but when text was involved (white text in a dark theme), the text was not readable. I was hoping the contrast slider would have helped with that. When using "Custom" for accent source instead, the dimmed accent was much better for readability (file selected in Dolphin). --- I also noticed in the systray "Audio Volume" applet that the tabs used the color scheme "Hover Decoration". That colour change would not be visible until I changed back to "Custom" accent, applied, and back to "From current color scheme", or by changing the "Selection" colour in the scheme also would update the colour used in the applet tab.. I guess it relied on the accent colour being adjusted as other settings did not seem to make a difference at updating the visual. When "Custom" is used for the accent, it would override the "Hover Decoration" from the colour scheme, it seems to be the colour value assigned to "Custom" without any alterations, while the applets sliders beneath the "Devices" tab have the dulled accent (testing with a bright red). I guess "Custom" accent overrides multiple colors from the scheme this way? Or the other way around, and the "From current color scheme" replaces the accent with a variety of sources? As a user who's not strayed from the defaults before, it's unclear to me what is overriding the other, and what values in a color scheme map to the accents "Custom" affects. --- While the accent adjustments for contrast with "Custom" seem to be otherwise good for readability, I get the impression there is a consistency issue. Not only is the "Selection" colour used from the scheme as an accent, with "Custom" adjusting the value, "Custom" is also applying the accent chosen on other colours from the scheme that were a different colour. It's a very different experience between the two for me. My expectation was that "Use accent color" selects a source for the accent, not to modify it or override other colours from the scheme too. That sounds like a different setting that provides dynamic contrast (nice), and overrides (vague, possibly some visual/contextual hierarchy?) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 456499] KWin Magic Lamp effect causing black screen (X11 + Wayland)
https://bugs.kde.org/show_bug.cgi?id=456499 --- Comment #2 from Brennan Kinney --- I have created a 3D accel VM guest with a different hypervisor (QEMU-KVM), and cannot reproduce the Magic Lamp effect bug described here. It appears to be specific to the VMware GPU driver SVGA3D/vmwgfx. Mesa has a related issue about the Magic Lamp effect bug with SVGA3D originally reported in 2017 here: https://gitlab.freedesktop.org/mesa/mesa/-/issues/889 I'll leave this bug report open, if a developer wants to assess if there is a bug in the Magic Lamp effect, or close it as a driver bug. --- If at all useful, the output of `glxinfo | grep -i opengl` reports: For virgl: - OpenGL core profile version string: 4.3 (same as reported by `inxi -G`) - OpenGL version string: 3.1 (which kwin uses) - OpenGL ES: 3.2 For SVGA3D: - OpenGL core profile version string: 4.1 - OpenGL version string: 4.1 (notes that it's a Compatibility profile) - OpenGL ES: 3.0 For SVGA3D (with ENV `SVGA_VGPU10=0` which avoids the bug): - Not Present => OpenGL core profile version string - OpenGL version string: 2.1 - OpenGL ES: 2.0 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 456499] KWin Magic Lamp effect causing black screen (X11 + Wayland)
https://bugs.kde.org/show_bug.cgi?id=456499 --- Comment #1 from Brennan Kinney --- I forgot to add that I did test with the official Breeze theme. --- This bug may only affect VMware guests. There is a related bug report from 2017 that describes this bug more briefly, and later discovers a workaround via an ENV that drops OpenGL in the guest down to 2.1: https://bugs.kde.org/show_bug.cgi?id=376115#c4 > `export SVGA_VGPU10=0` anywhere so it would be applied to all 3D apps. [Referencing Mesa SVGA3D driver docs](https://docs.mesa3d.org/drivers/svga3d.html) (which seems a bit outdated in content) > OpenGL 3.3 support can be disabled by setting the environment variable > SVGA_VGPU10=0. You will then have OpenGL 2.1 support. This may be useful to > work around application bugs (such as incorrect use of the OpenGL 3.x core > profile). --- Setting the ENV into the bash profile and restarting, the graphical failure is no longer reproducible: $ echo "export SVGA_VGPU10=0" >> ~/.bashrc Fedora 36 logs (journalctl -b0) after toggling the compositor on: Jul 09 18:48:17 fedora kwin_x11[1304]: OpenGL vendor string: VMware, Inc. Jul 09 18:48:17 fedora kwin_x11[1304]: OpenGL renderer string: SVGA3D; build: RELEASE; LLVM; Jul 09 18:48:17 fedora kwin_x11[1304]: OpenGL version string: 2.1 Mesa 22.1.3 Jul 09 18:48:17 fedora kwin_x11[1304]: OpenGL shading language version string: 1.20 Jul 09 18:48:17 fedora kwin_x11[1304]: Driver: VMware (SVGA3D) Jul 09 18:48:17 fedora kwin_x11[1304]: GPU class: Unknown Jul 09 18:48:17 fedora kwin_x11[1304]: OpenGL version: 2.1 Jul 09 18:48:17 fedora kwin_x11[1304]: GLSL version: 1.20 Jul 09 18:48:17 fedora kwin_x11[1304]: Mesa version: 22.1.3 Jul 09 18:48:17 fedora kwin_x11[1304]: X server version: 1.20.14 Jul 09 18:48:17 fedora kwin_x11[1304]: Linux kernel version: 5.18.9 Jul 09 18:48:17 fedora kwin_x11[1304]: Requires strict binding: yes Jul 09 18:48:17 fedora kwin_x11[1304]: GLSL shaders: yes Jul 09 18:48:17 fedora kwin_x11[1304]: Texture NPOT support: yes Jul 09 18:48:17 fedora kwin_x11[1304]: Virtual Machine: yes Jul 09 18:48:18 fedora kwin_x11[1304]: QObject::connect(KWin::InputMethod, KWin::EffectsHandlerImpl): invalid nullptr parameter --- It may still be considered a possible bug in the effect. But I am also aware of Chrome based web browsers all having rendering issues unless switching to their Vulkan experimental rendering backend (in chrome://flags), that workaround is not required when OpenGL drivers are reset to 2.1. The fix worked for both openSUSE Tumbleweed and Fedora 36, but NOT for EndeavourOS. It is unclear why, but it may be a timing issue? `inxi -G` and `glxinfo | grep -i opengl` both report OpenGL 2.1, but kwin (X11 and Wayland) is started with OpenGL 4.1, requiring manual `kwin_x11 --replace &` to be run to restart kwin when it will then also use OpenGL 2.1. I have run without systemd startup for EndeavourOS: kwriteconfig5 --file startkderc --group General --key systemdBoot false qdbus org.kde.KWin /KWin supportInformation | grep -i opengl This did not help and still required manually restarting kwin to switch OpenGL used from 4.1 to 2.1. The ENV set in bashrc is perhaps applied too late for this distro with kwin initializing earlier? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 456499] KWin Magic Lamp effect causing black screen (X11 + Wayland)
https://bugs.kde.org/show_bug.cgi?id=456499 Brennan Kinney changed: What|Removed |Added CC||polarathene-signup@hotmail. ||com -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 456499] New: KWin Magic Lamp effect causing black screen (X11 + Wayland)
https://bugs.kde.org/show_bug.cgi?id=456499 Bug ID: 456499 Summary: KWin Magic Lamp effect causing black screen (X11 + Wayland) Product: kwin Version: 5.25.2 Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: effects-various Assignee: kwin-bugs-n...@kde.org Reporter: polarathene-sig...@hotmail.com Target Milestone: --- Using the Magic Lamp effect with windows of a certain area size causes the display to be flooded with a black fill. Recovery on Wayland may not be possible. On X11 it is possible to recovery by disabling the compositor with alt+shift+f12 in the guest. This would repaint the screen. --- ### Additional Details Without recovering by toggling the compositor, the desktop remains interactive. I was able to click the bottom-left of the display where the application launcher button should be, and a white rectangle is drawn at the expected size of the applet. In some cases other colours bleed through, but the screen is mostly painted black. The window may need to be large. I was able to consistently reproduce with Konsole at "width x height" values of 1673x395, 1670x432, 912x822, 595x1230 or larger. Slightly smaller height or width dimension than those example dimensions worked correctly. At 1360x768 guest resolution, a maximized system-settings window would reproduce the bug too. These sizes were consistent at reproducing regardless of the set display resolution (1080p and 1360x768 tested, as well as maximized VM guest display on host 1440p monitor). I tried with all other effects disabled, no change in behaviour. The problem does not occur when the Magic Lamp effect is disabled. Adjusting the animation duration from Default, did not seem to make a difference. Nor does it seem to matter what toolkit is used for the window (GTK or Qt). At one point, when using the effect on windows that did not trigger the issue, the effect was degraded to what looked like maybe 6 sided geometry? The smooth curved distortion of the effect was replaced with a single point bend, but I am not sure how to reproduce that. --- This was reproduced on Fedora 36, EndeavourOS, and openSUSE Tumbleweed. All were tested as fresh VMware VM guest installs with 3D accel (driver SVGA3D/vmwgfx) enabled. Thus it may be a bug specifically affecting VMware hypervisor support, I have not yet updated to reproduce on my host system (Manjaro with Nvidia proprietary drivers). VMware has since the Workstation 16 series handled 3D accel guests running on linux hosts via Vulkan host driver which may affect reproduction. --- STEPS TO REPRODUCE 1. Enable the Magic Lamp effect. 2. Minimize (or the opposite restoring the minimized window) a window with a large enough area size (eg maximized window). 3. Screen should be filled with black. 4. If not, one of the distros may need to be used with the free VMware Workstation 16 Player hypervisor to reproduce in a VM with 3D accel enabled. OBSERVED RESULT Black screen, unable to recover in a Wayland session. EXPECTED RESULT For the effect to work consistently and without the black fill. SOFTWARE/OS VERSIONS Operating System: openSUSE Tumbleweed 20220706 KDE Plasma Version: 5.25.2 KDE Frameworks Version: 5.95.0 Qt Version: 5.15.5 Kernel Version: 5.18.9 Graphics Platform: X11 Graphics Processor: SVGA3D Extra: xorg: 21.1.3, xwayland 22.1.2, mesa 22.1.2, vmwgfx 2.20.0 Operating System: EndeavourOS KDE Plasma Version: 5.25.2 KDE Frameworks Version: 5.95.0 Qt Version: 5.15.5 Kernel Version: 5.18.9 Graphics Platform: X11 Graphics Processor: SVGA3D Extra: xorg: 21.1.3, xwayland 22.1.2, mesa 22.1.2, vmwgfx 2.20.0 Operating System: Fedora 36 KDE Plasma Version: 5.25.2 KDE Frameworks Version: 5.94.0 Qt Version: 5.15.3 Kernel Version: 5.18.9 Graphics Platform: X11 Graphics Processor: SVGA3D Extra: xorg: 1.20.14, xwayland 22.1.2, mesa 22.1.2, vmwgfx 2.20.0 --- When recovering by toggling the kwin compositor via alt+shift+f12, `journalctl -b0` outputs the following (openSUSE TW): Jul 09 18:00:02 localhost.localdomain kwin_x11[1519]: OpenGL vendor string: VMware, Inc. Jul 09 18:00:02 localhost.localdomain kwin_x11[1519]: OpenGL renderer string: SVGA3D; build: RELEASE; LLVM; Jul 09 18:00:02 localhost.localdomain kwin_x11[1519]: OpenGL version string: 4.1 (Compatibility Profile) Mesa 22.1.3 Jul 09 18:00:02 localhost.localdomain kwin_x11[1519]: OpenGL shading language version string: 4.10 Jul 09 18:00:02 localhost.localdomain kwin_x11[1519]: Driver: VMware (SVGA3D) Jul 09 18:00:02 localhost.localdomain kwin_x11[1519]: GPU class: Unknown Jul 09 18:00:02 localhost.localdomain kwin_x11[1519]: OpenGL version: 4.1 Jul 09 18:00:02 localhost.localdomain kwin_x11[1519]: GLSL
[kwin] [Bug 456008] Plasma VMWare host integration broken in 5.25
https://bugs.kde.org/show_bug.cgi?id=456008 Brennan Kinney changed: What|Removed |Added CC||polarathene-signup@hotmail. ||com Ever confirmed|0 |1 Status|REPORTED|CONFIRMED --- Comment #2 from Brennan Kinney --- Upstream issue: https://github.com/vmware/open-vm-tools/issues/568 Plasma 5.25 switched to systemd startup by default, which is partly the cause. You need to either opt-out of that change, or have open-vm-tools package apply the same fix that openSUSE Tumbleweed is using. --- > Similarly, copy/pasting clipboard content worked in both directions up until > 5.24.5 and is broken now. This is due to Plasma 5.25 switching by default to [systemd startup](https://invent.kde.org/plasma/plasma-workspace/-/wikis/Plasma-and-the-systemd-boot) and the VMware autostart not completing within the 5 second timeout AFAIK. I used VMware to test KDE 5.25 on EndeavourOS (Arch based), Fedora 36 and openSUSE Tumbleweed. I found that Tumbleweed was unaffected and looked into why, they've wrapped the `vmware-user-suid-wrapper` autostart command with a script that exits early when systemd is detected from what I can tell. I don't quite understand why it fixes (or works around) the issue, but it does. You can apply it to your guest VM and it will work (_although updates may overwrite it later?_). I've detailed my findings (with the script) to the upstream issue for [`open-vm-tools`](https://github.com/vmware/open-vm-tools/issues/568#issuecomment-1178736806). I assume the maintainers must fix it there for other distro packages to pick up? Alternatively, you can choose to [opt-out of the systemd startup feature as instructed by the ArchWiki section](https://wiki.archlinux.org/title/KDE#systemd_startup): kwriteconfig5 --file startkderc --group General --key systemdBoot false --- > If I try to drag files from Plasma to Windows, it fails because the mouse > pointer can't be moved beyond the Plasma desktop borders anymore. After the above fix is applied this no longer happens. Although presently transferring from guest to host Dolphin windows, I'm getting an error about the file not existing. It is successfully transferred to the cache directory (there's also a related folder in `/tmp` with symlinks to this location): /home/my-user/.cache/vmware/drag_and_drop /tmp/VMwareDnD > From Windows to Plasma the the mouse pointer just indicates that a drop > operation into the Plasma desktop area isn't possible. Host to Guest transfers are working correctly with the fix however. --- So technically not a Plasma bug? The [systemd startup wiki entry](https://invent.kde.org/plasma/plasma-workspace/-/wikis/Plasma-and-the-systemd-boot) from David Edmundson does request including systemd in the summary: > If you find a new bug, please include "systemd" somewhere in the summary, and > report to the relevant place. I have a search set up on that title. But I don't think bugzilla allows for editing comments unfortunately to update that. -- You are receiving this mail because: You are watching all bug changes.
[plasma-systemmonitor] [Bug 452689] New: plasma-systemmonitor is missing a KInfoCenter Memory Module replacement
https://bugs.kde.org/show_bug.cgi?id=452689
Bug ID: 452689
Summary: plasma-systemmonitor is missing a KInfoCenter Memory
Module replacement
Product: plasma-systemmonitor
Version: 5.24.3
Platform: Manjaro
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: ksysguard-b...@kde.org
Reporter: polarathene-sig...@hotmail.com
CC: ahiems...@heimr.nl, plasma-b...@kde.org
Target Milestone: ---
SUMMARY
Original issue source:
https://www.reddit.com/r/kde/comments/u4rav6/kinfocenter_memory_module_replacement/
[This page from
KInfoCenter](https://forum.manjaro.org/t/why-are-htop-and-system-monitor-showing-different-memory-usages/72984/19)
appears to have been [dropped with Plasma
5.24](https://github.com/KDE/kinfocenter/commit/c529b9d4074bf4b545372ccd1d3ac9acdfdc10c8)?
The commit dropping it states System Monitor installs an "external module
service" as a replacement for that view. All I see in System Monitor is a
single "Memory" block in the "Overview" page, or the graph in "History" page.
It is unclear how to get access to such a view via System Monitor, beyond
expecting the user to re-create the page or rely on a third-party solution via
"Get New Pages".
STEPS TO REPRODUCE
1. Attempt to locate a view in System Monitor that provides the same
information breakdown as KInfoCenter Memory Module once did pre-Plasma 5.24.
2. Fail to locate an equivalent view.
OBSERVED RESULT
No equivalent view is provided/available, despite the commit implying "external
module service" in `plasma-systemmonitor` would cover the same functionality.
Unless the intention was "Tools => Launch Htop", but this does not provide the
same focused breakdown/overview specific to memory usage.
EXPECTED RESULT
Some officially maintained view either by default or enabled to provide the
same information.
Presently the "Shared Memory" and "Total Free Memory" (composite of two
sensors) is missing. As is some functionality for a compact stacked bar chart
(with text), or stacked horizontal bar.
SOFTWARE/OS VERSIONS
Linux/KDE Plasma: X11 with Kernel 5.15.28
KDE Plasma Version: 5.24.3
KDE Frameworks Version: 5.91.0
Qt Version: 5.15.3
ADDITIONAL INFORMATION
Attempting to DIY the Memory Module as a new page, I could not produce a
similar view.
- Text portion was truncating labels depending on width. Only supported
ordering, but not layout (eg single column), which further restricted label
width for "Text" widget/components.
- Stacked bar chart does not support inlining/embedding the labels+data.
- No composite sensor ("Total Free Memory" in KInfoCenter was a composite of
Total Physical and Total Swap available). Not available from sensor selection,
or any apparent way to composite multiple sensors into a single one.
- At this point I stopped trying to reproduce the view, presumably the rest is
possible with nested items.
Using "Horizontal Bars" display style with Text-Only sensors provides a
close-enough equivalent of the text section, but still truncates the full
labels of a certain length, despite ample room..? This is not an issue if using
regular sensors, which add actual bars, but these don't seem helpful.
With the horizontal bars drawn, the value shown for each sensor is the current
value, but the bar is drawn as a portion of that value to some range that is
specific to the sensor (or largest value of all sensors in the group rather?),
so it's not communicating much to a user (eg 100% full for "Total Physical
Memory" with a variable width beneath it for "Free Physical Memory", (no
"Shared Memory" sensor), and Disk Buffer/Cache likewise that could all be
stacked together as a single bar which is doable with Pie/Bar charts only, but
requires identifying a matching label by colour (no hover/interaction hinting).
--
You are receiving this mail because:
You are watching all bug changes.
[dolphin] [Bug 452637] Action "Open Terminal" ignores path context of interacted folder
https://bugs.kde.org/show_bug.cgi?id=452637 --- Comment #2 from Brennan Kinney --- (In reply to oioi555x from comment #1) > I have submitted a patch that allows you to achieve equivalent functionality > without resorting to `konsolehere.desktop`. That's great, thank you! Regarding the discussion on Gitlab, my input would be: - Don't show the option "Open Terminal Here" for multiple selection, or disable it. A separate feature request could be made should users want that functionality. It'd be unclear if it should be separate terminal instances, or single window with tabs (but that'd likely depend upon the terminal being opened). Opening as new tabs to an existing window would be undesirable though. - If you do opt to open multiple windows, I agree with the confirmation prompt to avoid mistakes, it's a very annoying UX otherwise (Get New Things has been throwing an API error dialog at times when it fetches content to load, and can spam the error excessively at times). -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 452641] [UX] "Could not read" dialog for many files during copy operation
https://bugs.kde.org/show_bug.cgi?id=452641 --- Comment #1 from Brennan Kinney --- This bug report system doesn't appear to have an ability to edit what is submitted. Ignore the first two paragraphs of SUMMARY section, they were revised with the remaining content in that section. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 452641] New: [UX] "Could not read" dialog for many files during copy operation
https://bugs.kde.org/show_bug.cgi?id=452641 Bug ID: 452641 Summary: [UX] "Could not read" dialog for many files during copy operation Product: dolphin Version: 21.12.3 Platform: Manjaro OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: dolphin-bugs-n...@kde.org Reporter: polarathene-sig...@hotmail.com CC: kfm-de...@kde.org Target Milestone: --- SUMMARY When copying a large project folder to another device, I was unaware of some nested content with root ownership that had read permission denied to my user. Unlike being ignored by Ark without warning, Dolphin correctly pointed this problem out. However the number of affected files was unclear, yet at the same time I wanted to be aware to make note of them. This is not feasible to skip each entry in order to do so if there is over 100 items. Nor is Skip All valid as that information is lost. Doing a copy operation via Dolphin, encountering a read access failure during the progress will create dialogs "Could not read" with Retry/Skip/Skip-All/Cancel options. That is a UX problem when the number of files that would raise this warning is large: - "Retry" is useful if opting to correct permissions each time prompted during the transfer, though in some contexts that's not desirable, it'd be better if that context could prompt for auth (retaining the original ownership/permissions at the destination), applying to any other content that would trigger the same failure context instead of additional prompts or skip all. - "Skip" is useful when the affected paths should be noted down to address afterwards.. but is not pleasant if there's over 100 dialogs like this for very similar paths (usually many having common parents), especially when it's spread out across a long-lived transfer requiring user attention to avoid blocking the transfer. - "Skip All" becomes the preferred action when it's frustrating to respond to an unknown amount of dialogs like this, but at the expense that you lose what those affected file paths were as a result. STEPS TO REPRODUCE 1. Copy the contents of a directory with many files or folders lacking read access to your user. 2. Skip each item to get the affected files. Careful while clicking Skip as placement can jump. OBSERVED RESULT Frustrating experience to Skip each entry to be aware of each path affected. EXPECTED RESULT Notify with a list of paths, or some option to Skip All but log them for referencing afterwards. SOFTWARE/OS VERSIONS Linux/KDE Plasma: X11 with Kernel 5.15.28 KDE Plasma Version: 5.24.3 KDE Frameworks Version: 5.91.0 Qt Version: 5.15.3 ADDITIONAL INFORMATION I realize this is possibly quite niche to resolve.. After all there is "Skip All" as an escape hatch in this situation, but then it's not obvious what the affected files were. A variant of Retry given the context of the failure might be viable by prompting for auth makes sense, otherwise a variant of Skip All that can collect a list/log of paths is better than manually skipping individual files (especially when the number of affected files is unknown, and they often share a common sibling, plus prompts spread out across a transfer as it occurs blocking the transfer progress). Presently Dolphin will block when hitting the problem unless using Skip All. Having the option to defer individual/bulk actions would seem appropriate and would not impede the transfer for unaffected files. If dialog prompts during transfer is appropriate, deferring these decisions to a prompt at the end seems just as valid? -- You are receiving this mail because: You are watching all bug changes.
[ark] [Bug 452640] New: Ark does not notify on failure to archive content due to insufficient read permissions
https://bugs.kde.org/show_bug.cgi?id=452640 Bug ID: 452640 Summary: Ark does not notify on failure to archive content due to insufficient read permissions Product: ark Version: 21.12.3 Platform: Manjaro OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: elvis.angelac...@kde.org Reporter: polarathene-sig...@hotmail.com CC: aa...@kde.org, rthoms...@gmail.com Target Milestone: --- SUMMARY When archiving some project folders into a `tar.zst` file, the process appeared to have gone smoothly with no errors raised. The content that was owned by root (Docker volume mounts) was silently skipped without informing me of the omitted or corrupt (empty but non-zero sized) data. STEPS TO REPRODUCE 1. Have some content with permissions that would prevent read access. 2. Compress that content to an archive via Ark. Note, in Dolphin context menu, "Compress" action will be disabled if lacking write permissions, use a parent directory with write permissions as a workaround. OBSERVED RESULT - Via Dolphin "Compress" right-click content menu, UI will appear successful. - Via opening Ark through a Terminal, the directory contents not readable is filtered out of the archive. No error via GUI or terminal output. - Via Ark GUI, adding a specific file explicitly instead of the parent directory will add the file of that size but is misleading as there is no actual content (blank). EXPECTED RESULT It should be raised as an error when content cannot be archived due to lack of read access permissions. Especially when adding such a file that is listed in the file picker dialog (with badge indicating lack of read-access), which presently gives the impression it was added successfully but is in fact an empty file but with the expected filename and size. I did not expect the Ark GUI to implicitly write files that were added via menu immediately to the target archive file either, but that is a separate UX concern. SOFTWARE/OS VERSIONS Linux/KDE Plasma: X11 with Kernel 5.15.28 KDE Plasma Version: 5.24.3 KDE Frameworks Version: 5.91.0 Qt Version: 5.15.3 ADDITIONAL INFORMATION In comparison, doing a copy operation via Dolphin, the read access failures will create dialogs "Could not read" with Retry/Skip/Skip-All/Cancel options. That's somewhat better but is a UX problem when the number of files that would raise this warning is large: - Retry is useful if opting to correct permissions, though in some contexts that's not desirable, it'd be better to request auth. - Skip is useful when the affected paths should be noted down to address afterwards.. but is not pleasant if there's over 100 dialogs like this for very similar paths (usually many having common parents). - Skip All becomes the preferred action when it's frustrating to respond to an unknown amount of dialogs like this, but at the expense that you lose what those paths were as a result. A better UX would be to log the path under the same error context and notify the user afterwards, perhaps with some options to handle individual files or in bulk. A tree-view list would be most helpful for context, but a sorted list of paths would work just as well for presenting that information requiring attention. At the very least, the user should be informed about omitted data or data written with expected filename + size but not the real content. -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 376111] konsolehere.desktop should open the preferred terminal emulator instead of konsole
https://bugs.kde.org/show_bug.cgi?id=376111 Brennan Kinney changed: What|Removed |Added Resolution|--- |FIXED Status|REPORTED|RESOLVED CC||polarathene-signup@hotmail. ||com --- Comment #1 from Brennan Kinney --- This was resolved since 2021. `konsolehere.desktop` was dropped in favor of an alternative solution within Dolphin that will open your preferred Terminal application. Presently, there is a regression to the functionality if you expect the folder to open at the location of an interacted folder, instead of the views location. That is tracked here: https://bugs.kde.org/show_bug.cgi?id=452637 -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 452637] New: Action "Open Terminal" ignores path context of interacted folder
https://bugs.kde.org/show_bug.cgi?id=452637 Bug ID: 452637 Summary: Action "Open Terminal" ignores path context of interacted folder Product: dolphin Version: 21.12.3 Platform: Archlinux Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: dolphin-bugs-n...@kde.org Reporter: polarathene-sig...@hotmail.com CC: kfm-de...@kde.org Target Milestone: --- SUMMARY Since 2021 releases have dropped the Konsole "Open Terminal Here" service in favor of a generic internal alternative "Open Terminal" in Dolphin. The new service opens a terminal at the views location, but ignores the context of the location for any sub-location interacted with (folder, or via details view many nested levels deep), requiring explicit navigation afterwards, or workarounds such as opening a new tab/window to use the context menu action. This seems like a regression, but may be intentional to support other terminals than Konsole. However Konsole is opening at the view location, thus it seems the UX regression is fixable. STEPS TO REPRODUCE 1. Right-click a folder and choose "Actions => Open Terminal". 2. Terminal window opens at the views set location, not the sub-directory that was interacted with. OBSERVED RESULT Terminal window opens at the views set location, not the sub-directory that was interacted with. EXPECTED RESULT Terminal window opens at the location of the interacted sub-directory. Especially useful in the "Details" view mode for a project overview, when expanding multiple levels deep I should be able to open applications such as a terminal without having to navigate or open a new view tab to perform the action (current workaround). SOFTWARE/OS VERSIONS Linux/KDE Plasma: ArchLinux, X11 with kernel 5.15.28 KDE Plasma Version: 5.24.3 KDE Frameworks Version: 5.91.0 Qt Version: 5.15.3 ADDITIONAL INFORMATION This used to be possibly prior to Konsole 20.12 from what I understand. Here is the commit that caused the regression in favor of Dolphin's internal service replacement: https://invent.kde.org/utilities/konsole/-/commit/7cfe7bb380613d37427b76cc026027e547221f9e Presently, Dolphin uses the service action `open_terminal` internally that calls the following to launch the system terminal (instead of previously hard-coded Konsole from `konsolehere.desktop` service: https://invent.kde.org/system/dolphin/-/blob/3ebe3975a65d6e81fbda260d6df1806a7f82e142/src/dolphinmainwindow.cpp#L1088 The functionality appears to have been introduced with this MR by developer Alexander Lohnau: https://invent.kde.org/system/dolphin/-/merge_requests/81 In the referenced Reddit thread for that MR, a user attempts to adapt the Konsole shipped service to their preferred Terminal app Tilix, and discovered an issue with differing options to open the terminal at the expected path: > Changing "--workdir %f" to "--working-directory %f" fixed the issue. I am not familiar with how Dolphin is launching the `open_terminal` action beyond the point I referenced earlier. I assume that calls code from another project that was difficult to search for via the Gitlab UI. Hopefully this is not a concern that would block this request from being feasible. If it would be possible to address this regression, so that the service could open at the expected location being interacted with, not the views top-level location, that would be fantastic :) WORKAROUND: The present workaround is to disable the internal Dolphin service, and restore the previous Konsole shipped service instead (altering it for alternative terminal if necessary like with Tilix above). The full issue and workaround solution was discussed recently here: https://www.reddit.com/r/kde/comments/u1mdic/how_to_restore_dolphin_action_open_terminal_here/ With the original `konsolehere.desktop` service located here: https://invent.kde.org/utilities/konsole/-/blob/release/20.12/desktop/konsolehere.desktop Place it's contents in `/usr/share/kservices5/ServiceMenus/konsolehere.desktop` and the service is restored under actions. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 398908] Dolphin uses up huge amounts of memory
https://bugs.kde.org/show_bug.cgi?id=398908 --- Comment #73 from Brennan Kinney --- This bug tracker could really do with the ability to edit comments. Sorry for the additional notification. Forgot to mention that increasing file watchers resolved the GitKraken issue(which would not resolve otherwise, had tried killing the process and starting it again which had the same symptoms until watchers were increased). -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 398908] Dolphin uses up huge amounts of memory
https://bugs.kde.org/show_bug.cgi?id=398908 --- Comment #72 from Brennan Kinney --- One thing I have been doing but still haven't configured as a default, is increase the systems file watchers. They kept running out recently when working on a larger project, and GitKraken would also complain about running out of file watchers sometimes. A recent update didn't complain when I would have expected it to, and despite being idle was constantly causing 50% CPU usage(2 cores/threads on 4 cores/threads i5-6500) as well as notably more memory usage, although it was growing from around 1.2GB to 1.6GB then falling back to 1.2GB consistently. If my system versions don't resolve the problem for you, or your distro isn't able to use those easily, perhaps try this(only changes until reboot): sudo sysctl fs.inotify.max_user_watches=262144 The number is 2^18, your distro may be using 2^13(8192) or lower by default. You can check with(use before running above command): cat /proc/sys/fs/inotify/max_user_watches -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 398908] Dolphin uses up huge amounts of memory
https://bugs.kde.org/show_bug.cgi?id=398908 --- Comment #71 from Brennan Kinney --- Seems to be resolved for me. I have the following: KDE Plasma 5.19.3 KDE Frameworks 5.72 Qt 5.15 Kernel 5.4.52-1-MANJARO Dolphin 20.04.3 Not sure when exactly, but I don't recall having major memory issues with Dolphin over the past few months. My Docker usage or other remote/external mounting activity isn't that high lately, but I have been using a Docker container(no docker-compose) recently with local directory and file volume mounts that I restart quite a few times during the day. I've also had up remote system over SFTP and browsed that a bit. Other than that, presently a single window with 7 tabs open and tree view with nested locations opened with lists of images. Only 88MB and about 4 days uptime(window has been around longer via session restore). I think I last recall the problem in April/May, I don't think 20.04 release of Dolphin fixed it, nor 5.18 of Plasma, so it might have been a newer Frameworks release that was the last piece needed? I only updated to Plasma 5.19 a few days ago, and don't recall recent memory issues before then with Dolphin either. If someone has a simple test they'd like me to run I guess I can give that a go to further verify? -- You are receiving this mail because: You are watching all bug changes.
[kdelibs] [Bug 160520] Very wide and short images cause preview mode to behave strangely
https://bugs.kde.org/show_bug.cgi?id=160520 Brennan Kinney changed: What|Removed |Added CC||polarathene-signup@hotmail. ||com --- Comment #16 from Brennan Kinney --- Still a valid bug in 2020 with Plasma 5.18. At least I think it is the same bug: https://bugs.kde.org/show_bug.cgi?id=419566 -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 419566] Folder thumbnail previews exceed their region if aspect ratio is extreme
https://bugs.kde.org/show_bug.cgi?id=419566 --- Comment #2 from Brennan Kinney --- Created attachment 127228 --> https://bugs.kde.org/attachment.cgi?id=127228=edit The problematic image, 16x1024 width/height -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 419566] Folder thumbnail previews exceed their region if aspect ratio is extreme
https://bugs.kde.org/show_bug.cgi?id=419566 --- Comment #1 from Brennan Kinney --- Created attachment 127227 --> https://bugs.kde.org/attachment.cgi?id=127227=edit Details View icon showing slightly different positioning of bugged preview -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 419566] New: Folder thumbnail previews exceed their region if aspect ratio is extreme
https://bugs.kde.org/show_bug.cgi?id=419566 Bug ID: 419566 Summary: Folder thumbnail previews exceed their region if aspect ratio is extreme Product: dolphin Version: 19.12.3 Platform: Manjaro OS: Linux Status: REPORTED Severity: minor Priority: NOR Component: general Assignee: dolphin-bugs-n...@kde.org Reporter: polarathene-sig...@hotmail.com CC: kfm-de...@kde.org Target Milestone: --- Created attachment 127226 --> https://bugs.kde.org/attachment.cgi?id=127226=edit Info Panel showing the preview breaking out of it's expected bounds SUMMARY For tall/wide images, where the aspect ratio is large, the thumbnail preview appears to exceed the intended region for display. This only affects the preview thumbnail on a thumbnail, individual icon previews per file seem to be fine. STEPS TO REPRODUCE 1. Have a folder with some images, with at least one very wide or tall image. 2. Look at the generated preview for the folder icon in details view or info panel. OBSERVED RESULT Preview breaks out of it's region/quarter on the folder preview. EXPECTED RESULT Either don't display it, scale it down to fit it's region, or fade/crop to fit. Scaling it may serve no value preview wise, other than avoiding the rendered bug. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Manjaro KDE KDE Plasma Version: 5.18.3 KDE Frameworks Version: 5.68.0 Qt Version: 5.14.1 ADDITIONAL INFORMATION Possible duplicate of this 2008 bug report that has seen no activity since 2011: https://bugs.kde.org/show_bug.cgi?id=160520 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 400286] It should be possible to paste into layer masks, filter masks and transparency masks
https://bugs.kde.org/show_bug.cgi?id=400286 Brennan Kinney changed: What|Removed |Added CC||polarathene-signup@hotmail. ||com --- Comment #1 from Brennan Kinney --- Ran into this issue. I was following the "Split Alpha" documentation here: https://docs.krita.org/en/reference_manual/layers_and_masks/split_alpha.html And wanted to copy data from another image/layer to place into the Alpha channel. This was for a game asset which the feature is promoted as being useful for catering to, but as I was wanting to merge external data rather than create/edit the Alpha channel, this doesn't seem possible? Earlier I wanted to shift color channels around too or work on those individually, and the process for doing such is also quite bad with Krita, Photoshop handles this scenario really well. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 416456] Wobbly Windows does not respect Blur effect
https://bugs.kde.org/show_bug.cgi?id=416456 --- Comment #1 from Brennan Kinney --- While filing this issue on behalf of another user that raised attention to it, a related one[1] did reveal itself(it'd be nice if the UI for the search could also toggle/query closed issues as I didn't notice those were excluded). I also came across this issue[2] via google results. It showcases videos of several effects that use transforms with before/after of enabling blur. Scaling and translation transforms were shown as fine, but ones like Wobbly Windows were revealed as to why they're not compatible. While I was going through that and related info to understand the issue, another user shared the same Wobbly Window effect video directly on reddit[3]. While the reasoning for the closing [1] is clearly explained in [2], I would like to seek feedback from a developer with knowledge of the issue. Is the Wobbly Window effect not able to scale the blur texture to fit the bounds of the Wobbly Window effect and then use the distorted window as an alpha mask with glStencil or glScissor? I tried to go over the kwin effect code, but I'm not familiar with the codebase enough(or C++ and OpenGL) to grok the flow/path of code for the effects. [1] https://bugs.kde.org/show_bug.cgi?id=397329 [2] https://bugs.kde.org/show_bug.cgi?id=391819 [3] https://www.reddit.com/r/kde/comments/equisf/why_blur_is_off_when_using_wobbly_windows/ -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 416456] New: Wobbly Windows does not respect Blur effect
https://bugs.kde.org/show_bug.cgi?id=416456 Bug ID: 416456 Summary: Wobbly Windows does not respect Blur effect Product: kwin Version: 5.17.5 Platform: Manjaro OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: effects-various Assignee: kwin-bugs-n...@kde.org Reporter: polarathene-sig...@hotmail.com Target Milestone: --- SUMMARY If the Blur effect is enabled, it is not applied on content being rendered via the Wobbly Window effect. STEPS TO REPRODUCE 1. Enable Wobbly Windows and Blur effects. 2. Trigger the Wobbly Windows effect on content that also uses Blur, such as the Konsole(Konsole profile theme enabled blur and transparency). 3. Window shows transparency without blur effect applied. OBSERVED RESULT Blur effect is not present in combination with Wobbly Window effect. EXPECTED RESULT Blur effect and Wobbly Window effect should be compatible, or otherwise a checkbox in Wobbly Window effect settings to enable Blur support if there is notable overhead when the two effects are used together. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Manjaro - Kernel 5.5 (available in About System) KDE Plasma Version: 5.17.5 KDE Frameworks Version: 5.66 Qt Version: 5.14 ADDITIONAL INFORMATION Intel Gen9 graphics(i3-10110U) with KMS modesetting driver. Translucency effect disabled(also excludes applying blur, but does not appear to contribute to the Wobbly Window effect when enabled other than increasing transparency(defaults). -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 398908] Dolphin uses up huge amounts of memory
https://bugs.kde.org/show_bug.cgi?id=398908 Brennan Kinney changed: What|Removed |Added CC||polarathene-signup@hotmail. ||com --- Comment #44 from Brennan Kinney --- Hi, was sent here to share my own experiences. Manjaro KDE, Dolphin 19.08.2. Breath theme, but Breeze is the Application style/widget. I have noticed this problem for the past year. Hardware is an Intel i5-6500 CPU with 32GB RAM and an SSD disk. nvidia proprietary drivers are in use, X11. My workaround is to copy the breadcrumb paths to a new Dolphin window, recreating my tabs and closing the old Dolphin window to free the memory(closing tabs alone does not free anything apparently). Rinse and repeat. The worse case I've experienced was up to around 4GB, may have been more I've not kept track. Usually I notice Dolphin become sluggish(single core/thread of CPU is pegged at 100%) from interactions such as scrolling through the main content pane(jittery/jumpy or low framerate paints, window only, the window itself can be moved smoothly with kwin wobbly window effect no issue). Changing tabs, closing tabs, right click context menu on the breadcrumb location for copying, all of these I recall inducing the 100% CPU core load for several seconds(length of delay depends on memory consumption, can be closer to 10 seconds). I believe with the recent 19.08 applications update, dockers overlayfs mounts began appearing again for some reason. I only mention this because someone else here asked about Docker, their visibility is probably a regression that should be raised in another bug report and unrelated to this issue. I've experienced it without running the Docker daemon. Probably the time I noticed it the most active was when I had about 5 tabs in one window open, rarely interacting with them, but doing heavy editing of some files(fontconfig specifically). At one point, I may have been actively deleting files(cache) that I believe one tab covered. The deletion iirc was via CLI, but Dolphin would visibly update to represent files being added/removed if I had that tab open. I recall this iterative approach generating 20-40-ish files each time I modified/saved my font config files, I'd clear the generated cache, and open up a web browser(firefox) which would rebuild the cache, or if the cache existed add about 9 items(1 per process I think). Must have gone through thousands of those cache files. Someone brought up Gwenview. In the past I would "disable" a display(dual monitor setup), without physically powering it off, but as it's DVI connection, it couldn't be done via software command either, so I fullscreened an solid black image with Gwenview. Usually because it was at night and I wanted to watch something on Netflix without the other display being distracting. I can't recall how long it'd take, few hours to a day perhaps, but Gwenview responsiveness at leaving the fullscreen state would be very slow(10 second or so). So the other commenter may be onto something related there as both Dolphin and Gwenview are likely to share some KDE Frameworks lib? While the active development and file tree updates example above with fontconfig might sound like it's related only to that sort of activity. I've left a Dolphin window open/idle and gone to sleep, 8 hours later 1GB more of memory was allocated to it. I've also witnessed via ksysguard Dolphin memory climbing over the course of an hour, but I don't recall it being constant or a fixed amount(not that I properly measured this). All I know is it can grow with no interaction, but file updates/refreshes may be worth looking into? As for my typical usage, I usually only use one virtual desktop, but sometimes I do use multiple, I've not done any observations if that makes any difference. I tend to have one or two windows open, especially if I use multiple virtual desktops, tabs average 3-5, rarely more than that per window. Tabs are usually project directories(developer), or downloads directory(I don't download that much, but I haven't been housekeeping(currently it states 14 folders, 97 files, 71MB). Baloo is enabled(I've also noticed high CPU activity recently when using the default search feature, no new results for some time but the CPU usage remained at 100% for a full core until I closed the search, KFind tends to work better for me and doesn't exhibit issues like that). I also use sftp in Dolphin for accessing a remote server, Kate may be open with some files from that which were opened via Dolphin(usually drag/drop from Dolphin to Kate). Current Dolphin window is at 1.2GB and has been fairly steady on that with 3 tabs. The most active tab in that window would be the sftp one. Been open for a day or so, on virtual desktop 3 atm, and most of my activity has been with Chrome and Ka
[kcharselect] [Bug 97420] [usability] optionally show only characters available in selected font, sorted by group
https://bugs.kde.org/show_bug.cgi?id=97420 --- Comment #12 from Brennan Kinney --- Perhaps a toggle button with a bundled font, if you're able to specify multiple fonts for fallback like CSS has? When enabled, this would allow for using whatever font is currently in the dropdown box as the 1st font, and then the fallback font(specified in settings if bundling isn't possible, although that makes the feature less reliable, perhaps package managers can ensure the dependency?). This would make the distinction pretty clear, and perhaps be relatively easy to support this feature, so that KCharSelect is reliable utility for inspecting glyph support in a font? You can create your own font for the fallback glyph, or use existing solutions. There is Adobe Blank(v1, v2, VF) which is intended for this type of purpose but as the name implies, is a blank fallback, so the cell would just look empty. They have an alternative called Adobe NotDef, which provides the familiar rectangle tofu glyph, another is TofuDetector, which is suggested by behdad(Pango and I think FontConfig core developer?) Adobe Blank: --- v1 --- https://github.com/adobe-fonts/adobe-blank https://blogs.adobe.com/typblography/2013/03/introducing-adobe-blank.html https://blog.typekit.com/2013/03/28/introducing-adobe-blank/ --- v2 --- https://github.com/adobe-fonts/adobe-blank-2/ https://blogs.adobe.com/CCJKType/2015/04/adobe-blank-2.html --- VF --- https://blogs.adobe.com/CCJKType/2019/05/adobe-blank-vf.html https://github.com/adobe-fonts/adobe-blank-vf Adobe NotDef: https://github.com/adobe-fonts/adobe-notdef https://blogs.adobe.com/CCJKType/2016/05/tofu-or-not-tofu.html TofuDetector: https://github.com/santhoshtr/tofudetector https://github.com/Pomax/CFF-glyphlet-fonts/issues/12 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 412483] Add a side bar panel, which contains several widgets
https://bugs.kde.org/show_bug.cgi?id=412483 Brennan Kinney changed: What|Removed |Added CC||polarathene-signup@hotmail. ||com --- Comment #1 from Brennan Kinney --- Linux Deepin is another reference, they've iterated on a side panel for a while I think? http://linux.computertechnik-fiedler.de/wp-content/uploads/2017/04/Prilozhenie-dlya-snimkov-ekrana-Deepin-20170114163849.png http://linux.computertechnik-fiedler.de/wp-content/uploads/2017/04/4.png And with some tab buttons: https://i.pinimg.com/originals/c8/bb/e2/c8bbe26a6fc4671a08d8a436de120cf9.png https://distrowatch.com/images/screenshots/deepin-15.6.png --- macOS equivalent: https://forums.macrumors.com/attachments/dark-jpg.662372/ https://developers.google.com/web/updates/images/2017/04/macos-notifications/image00.png https://discussions.apple.com/content/attachment/875445040 https://cdn.igeeksblog.com/wp-content/uploads/Best-Mac-OS-X-Yosemite-Notification-Center-Widgets.jpg -- You are receiving this mail because: You are watching all bug changes.
[kcharselect] [Bug 412271] Search field should return results for an emoji
https://bugs.kde.org/show_bug.cgi?id=412271 --- Comment #6 from Brennan Kinney --- > I doubt this is what you were after. Actually, consistency would help at least. The mixed space behaviour was confusing. > Could you clarify how the decision when to start the incremental search could > be improved? How do users tend to make use of the search field? If I want all glyphs related to "q" and I notice I get instant results with some inputs, then as a user, it'd be assumed with no obvious min input requirement, that adding spaces to fill UTF-16 values to a count of 3 is non-obvious. If I want to search a emoji such as "藍", again, copy/paste to the search field has no immediate result. I only found out the added space inputs triggered a result somehow by mistake, later learning order was not important. The minimum requirement doesn't help but make it confusing here for what I'd imagine is a common use-case, to lookup a single character/glyph(not knowing the text name or unicode value(or whatever U+1F923 is)). Getting plenty of results during input isn't an issue, it already shows everything in the current subsection for an empty search field. It's not a realistic performance concern, so as the user types multiple characters into the query, those results will filter regardless? Some indication of minimum input would otherwise be helpful. You mention the user can press "return/enter" key to avoid the spaces, but there is no UI "search" button, just immediate results after the min input is reached, thus as a user it's a less obvious action(beyond assuming enter on a field might do the expected behaviour, but this for me was dispelled as I had seen the immediate results with searching unicode values previously, it just did not occur to me to try). > KCharSelect doesn't implement the Unicode Emoji standard. It only works with > codepoints. Could you detect this like Konsole does? It notices invisible/zero-width codepoints and offers to remove them. Perhaps you could remove FE0F(although valid to search by this value, but not it's "rendered" glyph) and the zwj codepoint, such that the female spy would paste two separate glyphs(you could separate them via a space perhaps?). Alternatively, upon detection, straight-up inform the user that this type of input is not supported by KCharSelect, only single/individual codepoints(and allow the user to figure out what that means). > The word FACE is unfortunately also a hex word. A group of 4 or 5 hex digits > are treated as codepoints. Yes, I understand that. My confusion was why is that result being returned when the other part of the query has "confused" which has nothing to do with the FACE result? For example "1F601 1F923" as a query, will return only the two codepoints specified, the emoji glyph in the middle is omitted. Similarly " 藍" equates to no results. Something is wrong with the query/filtering here, unicode values are kind of treated as "OR" but the emoji glyphs are like "AND" for keywords(as in they won't return a result unless all keywords are relevant". "confused fac" is similar, the emoji glyph itself doesn't appear to have any effect at impacting the results, only by itself as " ". --- SUMMARY It'd be nice if there was some consistency in these behaviours, and if certain inputs are not supported, that they could inform the user. Of interest might be this article: https://hsivonen.fi/string-length/ It points out how various languages handle such input/strings differently and why. Perhaps the mentioned Rust crate could be used to improve the current parsing? (though being another language probably makes that a hard no?) -- You are receiving this mail because: You are watching all bug changes.
[kcharselect] [Bug 412271] Search field should return results for an emoji
https://bugs.kde.org/show_bug.cgi?id=412271
--- Comment #3 from Brennan Kinney ---
The previous comment provides glyphs I copied over but copying the contents
here won't allow for reproducing the issue. It does not appear to be something
I can copy directly here, but can be sourced from getemoji.com.
Presumably they included some other data when copied, like a skin tone. The two
glyphs/emoji from the prior comment were rendering in black/white in Chrome for
me, which I've tracked down to be from Noto Sans Symbols2(The DejaVu Sans
equivalent does not take precedence for some reason, despite being listed
earlier by fc-match query).
---
1F575 SLEUTH OR SPY + ♀ 2640 FEMALE SIGN == ️♀️
The above glyph/symbol on the right should be a single one that you can select
and input into the KCharSelect search field. In my case I see it rendered as
two glyphs that I've shared earlier, but are treated as a single glyph with
selection and arrow key navigation.
You cannot remove the 1st part of the glyph, but you can remove the 2nd part
via backspace(twice), The 1st part requires two backspaces, followed by a space
to identify as the given 1st part of the glyph in results.
(️) This seems to work with copy/paste for reproduction. It requires two
backspaces before the space.
() This one does not, and is the result after the two backspaces, just add a
space to get results(before or after the glyph).
---
The issue I'm describing might be related to code points?
https://emojipedia.org/female-sleuth/
Consists of these codepoints:
U+1F575
️ U+FE0F
U+200D
♀ U+2640
️ U+FE0F
FE0F is invisible codepoint for Variation Selector-16:
https://emojipedia.org/variation-selector-16/
200D is invisible codepoint for Zero Width Joiner:
https://emojipedia.org/zero-width-joiner/
1F615 Confused Face, single codepoint
https://emojipedia.org/rolling-on-the-floor-laughing/
☝ 261D WHITE UP POINTING INDEX
✌ 270C VICTORY HAND
Both are two codepoints(the 2nd codepoint is the invisible FE0F variation
selector-16)
https://emojipedia.org/white-up-pointing-index/
https://emojipedia.org/victory-hand/
That solves the backspace mystery :)
While some emoji with a single codepoint are happy to return results with a
single space character added, those that required two spaces, can add those in
any order(" q", " q ", "q ") and it'll work, didn't need to be strictly
before and after.
I am not sure what makes an emoji like "Confused Face" only require a single
space to trigger results.
--
You are receiving this mail because:
You are watching all bug changes.
[kcharselect] [Bug 412271] Search field should return results for an emoji
https://bugs.kde.org/show_bug.cgi?id=412271 --- Comment #2 from Brennan Kinney --- ☝ 261D WHITE UP POINTING INDEX ✌ 270C VICTORY HAND These two and others behave a little differently. Paste the glyph into the search field, then backspace once(nothing is deleted), then space two times, now a result shows. Paste and add space and no effect. Unclear what causes that, perhaps it's due to UTF-8/UTF-16 differences(inbetween values you'd get for single latin character or an emoji, latin is 1 UTF-8 char, emoji seem to be around 4 UTF-8, and these glyphs are 3 UTF-8 but only 1 UTF-16). Perhaps there will be similar issues with other glyphs/emoji like ZWJ (Zero Width Joiner), which combine multiple emoji together to form a single one. -- You are receiving this mail because: You are watching all bug changes.
[kcharselect] [Bug 412271] Search field should return results for an emoji
https://bugs.kde.org/show_bug.cgi?id=412271 Brennan Kinney changed: What|Removed |Added CC||polarathene-signup@hotmail. ||com -- You are receiving this mail because: You are watching all bug changes.
[kcharselect] [Bug 412271] Search field should return results for an emoji
https://bugs.kde.org/show_bug.cgi?id=412271 --- Comment #1 from Brennan Kinney --- Emojis do appear to work if you add a space before or after. For single characters it appears that you need a space before and after. -- You are receiving this mail because: You are watching all bug changes.
[kcharselect] [Bug 412271] New: Search field should return results for an emoji
https://bugs.kde.org/show_bug.cgi?id=412271 Bug ID: 412271 Summary: Search field should return results for an emoji Product: kcharselect Version: 19.08.0 Platform: Manjaro OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: cf...@kde.org Reporter: polarathene-sig...@hotmail.com Target Milestone: --- SUMMARY "Enter a search term or character here", try an emoji like: 1F615 Confused Face The Unicode value or assigned name "confused face", works, but not the actual emoji if you copy/paste that. This also doesn't appear to work at filtering to a single character, which might be the actual problem. STEPS TO REPRODUCE 1. Add "" to the search field. OBSERVED RESULT Nothing happens. EXPECTED RESULT Results should filter to this glyph/emoji. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Manjaro KDE (up to date), Kernel 4.19.69-1-MANJARO KDE Plasma Version: 5.16.4 KDE Frameworks Version: 5.61.0 Qt Version: 5.13.0 ADDITIONAL INFORMATION I can type "confused fac" 1 result(1F615), but "confused face" returns 2 results(U+FACE as 2nd result, which has no mention of "confused"). It appears, you can enter multiple unicode values to add that direct glyph/character to the results ignoring any other keywords, bug? You can also add any emoji, and it appears to be treated as an empty character, not impacting results, as if it was never entered.It appears to be treated similar to a blank/space. " confused", remove "confused" and results are not updated, clear the entire field and it'll reset. Search just " " and no impact either(which is fine). -- You are receiving this mail because: You are watching all bug changes.
[kcharselect] [Bug 412267] Active fonts should not render fallback glyphs if missing
https://bugs.kde.org/show_bug.cgi?id=412267 Brennan Kinney changed: What|Removed |Added CC||polarathene-signup@hotmail. ||com -- You are receiving this mail because: You are watching all bug changes.
[kcharselect] [Bug 412267] New: Active fonts should not render fallback glyphs if missing
https://bugs.kde.org/show_bug.cgi?id=412267 Bug ID: 412267 Summary: Active fonts should not render fallback glyphs if missing Product: kcharselect Version: 19.08.0 Platform: Manjaro OS: Linux Status: REPORTED Severity: wishlist Priority: NOR Component: general Assignee: cf...@kde.org Reporter: polarathene-sig...@hotmail.com Target Milestone: --- SUMMARY While troubleshooting an emoji rendering setup, I inspected fonts with KCharSelect but was mislead which fonts had which glyphs as fallbacks were being deceivingly rendered when the font did not contain the actual glyph. Installing noto-fonts-emoji Selecting DejaVu Sans or Bitstream Vera Sans fonts in the dropdown, and then the sectino/view: `Symbols -> Emoticons`. Both show mostly black/white emoji, but a few are in colour like 1F624: 1F60E - "SMILING FACE WITH SUNGLASSES" 1F624 - "FACE WITH LOOK OF TRIUMPH" When changing font to "Noto Color Emoji", all emoji are rendered in colour, including 1F60E. 1F624 is the exact same as what was shown in the earlier mentioned fonts(with my current setup at least), so it has been displayed as a fallback. Bitstream Vera fonts should not contain any emoji, so again, this is shown falling back to both DejaVu, and if not available further back to Noto Color Emoji. I have since learned how to identify this fallback order, and that Bitstream Vera didn't have the black/white emoji that KCharSelect implied it did via confirming font used with this command: fc-match serif VeraSe.ttf: "Bitstream Vera Serif" "Roman" fc-match serif:charset=1F60E DejaVuSans.ttf: "DejaVu Sans" "Book" fc-match serif:charset=1F923 NotoColorEmoji.ttf: "Noto Color Emoji" "Regular" I assume KCharSelect showed 1F60E correctly when viewing Noto Color Emoji as it renders the font glyph views with that specific font, thus, no need to render a fallback. Perhaps this is out of scope of KCharSelect and it's working as intended(character selection regardless of how it's rendered by active font), not for inspecting an actual fonts contents. I understand that the current implementation is likely rendering the glyphs in a standard way like regular text with the selected font applied. Thus it's likely more effort than it's worth to resolve this. STEPS TO REPRODUCE 1. Select "Bitstream Vera Sans" as font. 2. Enter "1F60E" in search field. 3. A result should appear, but it's not actually from the font but a fallback. OBSERVED RESULT Fallback font rendered, no indication of such. EXPECTED RESULT No result, does not exist in the selected font. Or should indicate it's rendering a fallback. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Manjaro KDE (up to date), Kernel 4.19.69-1-MANJARO KDE Plasma Version: 5.16.4 KDE Frameworks Version: 5.61.0 Qt Version: 5.13.0 -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 412145] Dolphin is not aware of unclean mount on exfat
https://bugs.kde.org/show_bug.cgi?id=412145 --- Comment #1 from Brennan Kinney --- Output for performing `sudo fsck.exfat /dev/sdc1` exfatfsck 1.3.0 Checking file system on /dev/sdc1. WARN: volume was not unmounted cleanly. ERROR: fsync failed: Input/output error. File system checking stopped. ERRORS FOUND: 1, FIXED: 0. The error appears tied to the device becoming unavailable. A physical unplug and re-plug is required as /dev/sdc1 is no longer available afterwards. The warning is the same given when performing `mount -t exfat /dev/sdc1 /mnt/usb_stick`. Windows 7 and Windows 10 systems detected the errors but both failed to repair. The repair/scan could be ignored and data could be copied off the disk, but write activity appears to cause the device to fail in Windows as well, and it becomes available until physical reconnection is made. --- When Windows 7 performed a repair/fix, I was able to mount successfully in Dolphin, although while browsing the files, Dolphin became unresponsive, and ksysguard reported 50% CPU usage(4 cores/threads system), htop revealed <5-10% CPU activity, and ksysguard processes(all) sorted by CPU column showed nothing high usage. Eventually that dropped and Dolphin became responsive again, the mounted location became unavailable and could not mount again. Possibly related to this old bug: https://bugs.kde.org/show_bug.cgi?id=347565 Although another exfat device unmounts cleanly without getting corrupted. --- Related issues: Notification Panel, incorrect error(different from Dolphin): https://bugs.kde.org/show_bug.cgi?id=412146 Partition Manager, gets stuck scanning devices after a failed mount: https://bugs.kde.org/show_bug.cgi?id=412147 -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 412146] New: Notification about a failed mount is incorrect
https://bugs.kde.org/show_bug.cgi?id=412146 Bug ID: 412146 Summary: Notification about a failed mount is incorrect Product: frameworks-knotifications Version: 5.61.0 Platform: Manjaro OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kdelibs-b...@kde.org Reporter: polarathene-sig...@hotmail.com CC: kdelibs-b...@kde.org Target Milestone: --- SUMMARY When accessing a USB stick formatted with exfat(in a dirty state) via dolphin, the mount fails with a timeout error in Dolphin error dialog/status. When mounting via terminal, the error states the filesystem was not cleanly unmounted. At the same time, a notification on the panel pops up that claims "unauthorized access", but exfat does not have permissions and this is not the actual error. That is misleading to the user. STEPS TO REPRODUCE 1. Plug in USB with exfat partition in a dirty state. 2. Access it via Dolphin. 3. Timeout triggers a notification about a lack of permissions while Dolphin's error conveys different information. OBSERVED RESULT Inconsistent errors between Dolphin and the notification panel. Notification panel also is incorrect about the cause. EXPECTED RESULT Consistency, or at least the notification not claiming it's an authorization/permissions problem. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Manjaro KDE (up to date), Kernel 4.19.69-1-MANJARO KDE Plasma Version: 5.16.4 KDE Frameworks Version: 5.61.0 Qt Version: 5.13.0 -- You are receiving this mail because: You are watching all bug changes.
[partitionmanager] [Bug 412147] Stuck scanning devices
https://bugs.kde.org/show_bug.cgi?id=412147 Brennan Kinney changed: What|Removed |Added CC||polarathene-signup@hotmail. ||com -- You are receiving this mail because: You are watching all bug changes.
[frameworks-knotifications] [Bug 412146] Notification about a failed mount is incorrect
https://bugs.kde.org/show_bug.cgi?id=412146 Brennan Kinney changed: What|Removed |Added CC||polarathene-signup@hotmail. ||com -- You are receiving this mail because: You are watching all bug changes.
[partitionmanager] [Bug 412147] New: Stuck scanning devices
https://bugs.kde.org/show_bug.cgi?id=412147 Bug ID: 412147 Summary: Stuck scanning devices Product: partitionmanager Version: 4.0.0 Platform: Manjaro OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: andr...@stikonas.eu Reporter: polarathene-sig...@hotmail.com Target Milestone: --- SUMMARY After a failed mount with Dolphin, an external USB stick(with corrupted exfat filesystem), seemed to be the cause of a device scan with PartitionManager being stuck. It remained on 50% for.. 5 mins or so, saying it was scanning /dev/sdc (the problematic device), and it was not possible to cancel this process(clicking the dialogs X button to close did nothing. I killed it via ksysguard. If a scan is performed prior to any attempt to mount the device, the scan performed fine, only after the failed mount(dirty filesystem which Windows itself cannot repair), does it cause this behaviour with scan. STEPS TO REPRODUCE 1. Fail to mount a corrupt(or possibly dirty/uncleanly mounted) exfat system. 2. Try to scan with PartitionManager(I had it open already so this was a 2nd scan) 3. Scan gets stuck when scanning the device with bad exfat filesystem. OBSERVED RESULT PartitionManager stuck scanning, unable to cancel/skip problematic device. EXPECTED RESULT Time out skip device and raise error/notification to user after, or permit cancelling the scan. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Manjaro KDE (up to date), Kernel 4.19.69-1-MANJARO KDE Plasma Version: 5.16.4 KDE Frameworks Version: 5.61.0 Qt Version: 5.13.0 -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 412145] Dolphin is not aware of unclean mount on exfat
https://bugs.kde.org/show_bug.cgi?id=412145 Brennan Kinney changed: What|Removed |Added CC||polarathene-signup@hotmail. ||com -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 412145] New: Dolphin is not aware of unclean mount on exfat
https://bugs.kde.org/show_bug.cgi?id=412145 Bug ID: 412145 Summary: Dolphin is not aware of unclean mount on exfat Product: dolphin Version: 19.08.0 Platform: Manjaro OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: bars: status Assignee: dolphin-bugs-n...@kde.org Reporter: polarathene-sig...@hotmail.com Target Milestone: --- SUMMARY When accessing a USB stick formatted with exfat(in a dirty state) via dolphin, the mount fails with a timeout error. Dolphin is unsure of what went wrong. When mounting via terminal, the error states the filesystem was not cleanly unmounted. STEPS TO REPRODUCE 1. Plug in USB with exfat partition in a dirty state. 2. Access it via Dolphin. 3. Timeout triggers a red status error where Dolphin is unsure of what went wrong. OBSERVED RESULT Unable to mount drive, Dolphin does not indicate the actual cause when that information should be available. EXPECTED RESULT The error should state that exfat filesystem was not cleanly unmounted and is in a dirty state. Then advise/link to how to repair(windows only I think, maybe 5.4 kernel will change this. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Manjaro KDE (up to date), Kernel 4.19.69-1-MANJARO KDE Plasma Version: 5.16.4 KDE Frameworks Version: 5.61.0 Qt Version: 5.13.0 -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 388854] Okular uses a very large amount of RAM for caching
https://bugs.kde.org/show_bug.cgi?id=388854 --- Comment #21 from Brennan Kinney --- (In reply to Nate Graham from comment #20) > Thanks for the additional information, Brennan. However, as previously > noted, high memory usage of the sort described by you and others in this > ticket is not considered a bug because: > 1. it's only done when there's actually unused memory available > 2. Okular should give it up when the system is under memory pressure > 3. you can change the memory caching aggressiveness in the settings if this > sort of thing unnerves you > > If you're seeing that any of the above conditions are not working properly, > please file a new bug report to track that issue. Thanks! Nate, it's not just caching, there is an obvious leak/growth, a 90kb PDF of 4 pages, 30MB on open, steadily rising memory usage by scrolling repeatedly through the pages up/down. This growth only stops once the scrolling does, and will resume again by scrolling. The cache is not being used, memory is just being allocated for the content again, and again, instead of reused or freed(until the mentioned memory pressure). I could continue that process for the same file and bring the memory usage up for the single document from the 60MB I got it to 1GB or 10GB without issue from the looks of it. That's not good behaviour, even if it is freed at a later point, the application shouldn't balloon memory like that pointlessly. If others think that is appropriate, it's a bit of a worry. Don't claim it as working as intended when it's clearly poor memory handling. It's ok to admit that this behaviour is happening and that it is not correct, but not see any value or importance in investing time to correct it, just don't pretend that it's allocating hundreds to thousands of MB in memory for small documents from scrolling pages when that growth is constant and does not stop, Okular is not using that memory in it's entirerity, it's not an optimization, it's a bug. -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 388854] Okular uses a very large amount of RAM for caching
https://bugs.kde.org/show_bug.cgi?id=388854 Brennan Kinney changed: What|Removed |Added Version|0.25.0 |1.4.2 Platform|Other |Manjaro -- You are receiving this mail because: You are watching all bug changes.
[okular] [Bug 388854] Okular uses a very large amount of RAM for caching
https://bugs.kde.org/show_bug.cgi?id=388854 Brennan Kinney changed: What|Removed |Added Ever confirmed|0 |1 Resolution|INVALID |--- CC||polarathene-signup@hotmail. ||com Status|RESOLVED|REOPENED --- Comment #19 from Brennan Kinney --- I can confirm a memory leak on Manjaro KDE with Okular 1.4.2. I've come here from the reddit discussion: https://www.reddit.com/r/kde/comments/8v4g5y/extremely_high_ram_usage_by_okular/ 4 page document(90KB in size, e-mail with few small images like logos and icons) using about 28MB RAM when opened. Repeatedly scrolling up and down this document increases memory usage, I stopped at 60MB, it's not freeing or re-using existing memory, that doesn't seem like it's caching content properly. I imagine one could continue this process until all RAM is used or something triggers a cleanup. I'm not seeing any noticeable or major memory increase while the document is idle/inactive, nor CPU usage. When scrolling rapidly (drag scrollbar top to bottom) CPU usage was initially displaying 9% up to 14% when I reached 60MB, this value was consistent at increasing steadily with the RAM. This is probably single-threaded and would cap at 25% requiring more time to process what should be linear time. Additional memory should not be allocated like this, there would be a limit if it were caching properly and utilizing that, the CPU activity is likely associated with the memory leak. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 372576] Present Windows lags when closing window
https://bugs.kde.org/show_bug.cgi?id=372576 Brennan Kinney <polarathene-sig...@hotmail.com> changed: What|Removed |Added CC||polarathene-signup@hotmail. ||com -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 384091] Add a window placement mode that remembers prior window position
https://bugs.kde.org/show_bug.cgi?id=384091 --- Comment #9 from Brennan Kinney <polarathene-sig...@hotmail.com> --- (In reply to Martin Flöser from comment #7) > (In reply to Nate Graham from comment #5) > > Would it be feasible to add a placement mode that overrides apps' own > > requested placement requests and always uses KWin to handle placement? I > > think that's basically what's desired here. > > oh and by the way: that already exists. Just create a catch-all window rule > that ignores the application specified position. Is there any harm in still supporting it as a drop down placement mode or similar for the window position behaviour? It would be more intuitive and discoverable to the user I assume if it was available as an option there with the other related window position settings than having the user know/discover that they can use a kwin rule for it? Although rather than ignoring the apps position it'd be more of a remember position. I think I could see that being useful for most apps as an available option and selectively adding a kwin window rule to apps where it's not as desirable(multiple instances like terminal or web browser, unless the rule/placement mode can be smart enough to only apply the remembered position to the first window instance and use a fallback placement mode for additional instances??) -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 384091] Add a window placement mode that remembers prior window position
https://bugs.kde.org/show_bug.cgi?id=384091 Brennan Kinney <polarathene-sig...@hotmail.com> changed: What|Removed |Added CC||polarathene-signup@hotmail. ||com --- Comment #3 from Brennan Kinney <polarathene-sig...@hotmail.com> --- (In reply to Martin Flöser from comment #2) > Implementing this in the window manager in a reliable and working way is > hardly possible as it is difficult to recognize Windows if an application is > restarted. > > Most applications on X11 Store their position and open there again. This is > good enough for most cases. You state most X11 applications will store position and open there again, but is that the case with windows being managed by kwin? Under system-settings WindowManagement -> WindowBehaviour -> Advanced tab, there is the Placement dropbox, listing options of: Smart, Maximizing, Cascade, Random, Centered, Zero-Cornered, Under Mouse. None of these seem to imply they'd respect that default X11 window position behaviour for most applications on X11 you're stating? I understand that it might not be perfect, but if it's as reliable as the kwin rule can be "Remember" perhaps making that an option instead of requiring a user to manually enforce the window rule, it could be listed with the rest of those placement options? What is the situation with Wayland? Better or worse for implementing it? This desired behaviour recently came up on r/kde. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 394152] Prompt user a mounted folder cannot be deleted
https://bugs.kde.org/show_bug.cgi?id=394152 Brennan Kinney <polarathene-sig...@hotmail.com> changed: What|Removed |Added CC||polarathene-signup@hotmail. ||com -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 394152] New: Prompt user a mounted folder cannot be deleted
https://bugs.kde.org/show_bug.cgi?id=394152 Bug ID: 394152 Summary: Prompt user a mounted folder cannot be deleted Product: dolphin Version: 18.04.0 Platform: Manjaro OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: dolphin-bugs-n...@kde.org Reporter: polarathene-sig...@hotmail.com CC: elvis.angelac...@kde.org Target Milestone: --- Had a USB drive plugged in, ended up in Dolphin at `/run/media/username/mount_name`. I wanted to shift+delete the contents, and had the folder selected(thinking for some reason this was a folder on the mounted drive, not the folder representing the mounted drive), I was confused why nothing happened. Then tried a regular delete no prompt, right click context menu, I could make a new file/folder(this confusion was due to right click selecting the mounted folder, it would create a new file/folder inside it..), but no delete, root actions menu had delete but I chose not to use it(I wanted to delete without moving to trash). Then I noticed the location I was at and realized why I was having a problem. It'd be nice UX if Dolphin would instead notify the user of error/inability to delete and why. Could delete/shift+delete instead of mapping to nothing, map to bringing up an error dialog? -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 392798] Power button actions should be handled from lock screen
https://bugs.kde.org/show_bug.cgi?id=392798 Brennan Kinney <polarathene-sig...@hotmail.com> changed: What|Removed |Added CC||polarathene-signup@hotmail. ||com --- Comment #8 from Brennan Kinney <polarathene-sig...@hotmail.com> --- Can System Settings for the lockscreen not have a UI toggle for soft buttons to allow shutdown/suspend/hibernate? Sometimes I've suspended the machine only to find it wake up again shortly after, I have to manually type out the password again just to attempt a suspend once more. It'd be nice if the user has allowed the lockscreen to display power button UI, that you could then do such actions via lockscreen without requiring an unlock. My machine isn't a laptop and it's power button isn't that accessible. Suspend shouldn't cause any harm/risk to running processes and the like? If such a setting were off by default it shouldn't cause any harm/risk to other users that is mentioned for avoiding it? -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 392663] New: Default search doesn't show results for files that are clearly there
https://bugs.kde.org/show_bug.cgi?id=392663 Bug ID: 392663 Summary: Default search doesn't show results for files that are clearly there Product: dolphin Version: 17.12.3 Platform: Manjaro OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: search Assignee: dolphin-bugs-n...@kde.org Reporter: polarathene-sig...@hotmail.com Target Milestone: --- This seems to be more of a Baloo issue rather than Dolphin I think. At least I think Dolphin defaults to Baloo on a default install. In the Downloads folder for example, where I can have files reside for months, I had many results missing files that should have shown up. KFind could find them. There is a way to go into the files properties dialog, permissions tab, advanced permissions, ok, ok to exit the properties dialog. The file will now get metadata updated, although nothing was done, this set of steps seems to trigger Baloo to index the file. The file will now show up in search results via Dolphin or KRunner. Not sure how to reproduce, if it's due to Baloo no longer actively indexing properly or ignoring files randomly, could be a bug in Baloo or something wrong with the system as the install had been running since Aug 2016. Reporting in case anyone else is affected, and that it was requested to make this a separate issue from a similar one I had with hidden files. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 392663] Default search doesn't show results for files that are clearly there
https://bugs.kde.org/show_bug.cgi?id=392663 Brennan Kinney <polarathene-sig...@hotmail.com> changed: What|Removed |Added CC||polarathene-signup@hotmail. ||com -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 308002] Information panel does not show group ownership
https://bugs.kde.org/show_bug.cgi?id=308002 Brennan Kinney <polarathene-sig...@hotmail.com> changed: What|Removed |Added Platform|Ubuntu Packages |Manjaro Version|2.1 |17.12.3 -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 308002] Information panel does not show group ownership
https://bugs.kde.org/show_bug.cgi?id=308002 Brennan Kinney <polarathene-sig...@hotmail.com> changed: What|Removed |Added CC||polarathene-signup@hotmail. ||com --- Comment #3 from Brennan Kinney <polarathene-sig...@hotmail.com> --- Over 5 years later. Still unable to select Group for info panel to go along with the Owner and Permissions fields. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 392662] Support changing permissions for root owned files via properties dialog
https://bugs.kde.org/show_bug.cgi?id=392662 --- Comment #1 from Brennan Kinney <polarathene-sig...@hotmail.com> --- Don't seem to be able to edit my original message. If it was not clear by the title, this also was about the read/write/modify and executable properties under the permissions tab which also cannot presently be adjusted for root owned files. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 392662] Support changing permissions for root owned files via properties dialog
https://bugs.kde.org/show_bug.cgi?id=392662 Brennan Kinney <polarathene-sig...@hotmail.com> changed: What|Removed |Added CC||polarathene-signup@hotmail. ||com -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 392662] New: Support changing permissions for root owned files via properties dialog
https://bugs.kde.org/show_bug.cgi?id=392662 Bug ID: 392662 Summary: Support changing permissions for root owned files via properties dialog Product: dolphin Version: 17.12.3 Platform: Manjaro OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: dolphin-bugs-n...@kde.org Reporter: polarathene-sig...@hotmail.com CC: elvis.angelac...@kde.org Target Milestone: --- Currently requires dropping to a CLI to perform via commands instead of GUI(unless using another file manager as Dolphin is forbidden to run as root). I would like to be able to easily adjust a file(s) owner or group via Dolphin context menu "Properties -> Permissions Tab". In addition to that, prompting when required for admin authorization instead of requiring Dolphin as root to adjust root owner to the session user. -- KAuth/KIO/PolKit support for supporting other actions that require root priviledges has been WIP for some time and currently a high priority item. When this is complete, I think adding support for other features requiring root as the session user can be more easily implemented? Tracking issue for dependency: https://phabricator.kde.org/T8075 -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 372979] Restored session, blank/empty windows per restored tab
https://bugs.kde.org/show_bug.cgi?id=372979 --- Comment #3 from Brennan Kinney <polarathene-sig...@hotmail.com> --- (In reply to Erik Quaeghebeur from comment #2) > Possible duplicate of Bug 360066. > > @Brennan: can you confirm this is still happening to you and whether you > think it is the same or a different bug from the one I linked? Hi @Erik yes I can confirm this still happens to me. I've recently done a fresh install of Manjaro KDE, fully updated and still experience this bug. Also experience it on another machine. Yes the linked bug describes the same issue as far as I can tell. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 391252] Baloo unable to find files in hidden folders
https://bugs.kde.org/show_bug.cgi?id=391252 --- Comment #6 from Brennan Kinney <polarathene-sig...@hotmail.com> --- (In reply to Nate Graham from comment #3) > > Another example. In the home directory... > > One issue per bug report please. See > https://community.kde.org/Get_Involved/Bug_Reporting#One_issue_per_bug_report That was an additional example to the same issue. It's not a different issue. It's not due to hidden directory that the first file was in. My 2nd message(comment #1) covers steps to make a file discoverable via Dolphin "Find" and KRunner. The OS was installed Aug 2016 with Plasma 5.7, Plasma Search is enabled but I guess something has caused Baloo to index selectively. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 391252] Baloo unable to find files in hidden folders
https://bugs.kde.org/show_bug.cgi?id=391252 --- Comment #5 from Brennan Kinney <polarathene-sig...@hotmail.com> --- (In reply to Nate Graham from comment #3) > FWIW Baloo is now maintained once more. So there is definitely the promise > of future bugfixes and new features. > > I believe KFind is basically a graphical `find`, rather than building a > whole index the way Baloo does, which is why KFind finds it. By default, I > believe Baloo doesn't index the contents of hidden folders; Sending to > frameworks-baloo to decide whether to confirm and WONTFIX, turn this on by > default, or add a switch to control it. > > > > Another example. In the home directory... > > One issue per bug report please. See > https://community.kde.org/Get_Involved/Bug_Reporting#One_issue_per_bug_report I'm seeing file locations where some files are apparently indexed while others are not. Downloads folder for example, some queries would return files, while others would be omitted that are in the same location, not hidden, should match the query etc. The files that should be in thre results but are not, when applying the steps described in "Comment 1" will immediately make these files return in the results for valid queries as well. The files aren't new, they'd been in there for some time. Why some were indexed and others not, I have no idea. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-baloo] [Bug 391252] Baloo unable to find files in hidden folders
https://bugs.kde.org/show_bug.cgi?id=391252 --- Comment #4 from Brennan Kinney <polarathene-sig...@hotmail.com> --- (In reply to XYQuadrat from comment #2) > This problem is most likely related to baloo, as you have already mentioned. > Baloo has been unmaintained for a long time, and there are quite a lot of > problems that still need to be fixed. It may be related to baloo, but why is the sequence of steps mentioned in "Comment 1" causing a file to generate a bunch of metadata? Is this due to triggering baloo to index the file and if so why is baloo being triggered when as a user I make no change beyond clicking OK instead of cancel on the properties dialogs? -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 391252] Dolphin "Find" feature unable to find files
https://bugs.kde.org/show_bug.cgi?id=391252 --- Comment #1 from Brennan Kinney <polarathene-sig...@hotmail.com> --- Right Click a file that does not show up in results. Choose properties. Permissions Tab, Advanced Permissions button. Click OK button to close the dialog, Click OK button to close the Properties dialog. Both OK buttons need to be pressed, either of them being cancel will not make the file searchable. When that sequence is done, the Info panel in Dolphin will update the metadata fields it presents, showing new ones such as "Author, Title, Document Generated By", existing metadata on the file like what URL it was downloaded from did exist prior to this. Some files do not seem to add any extra metadata(I've had images that do and images that do not). Whatever this sequence of actions does(which since no actual change was done beyond navigating dialogs and pressing only OK), it does something to cause the file to now be indexed. Simply opening the file or accessing it via Dolphin(mouse over to view data in the info panel) does not get the file indexed. --- If Dolphin fails to find results, should it not fallback to another search strategy? Shouldn't after performing it's current search from an index/database somewhere(Baloo?), Dolphin then perform a plain search so that results can be returned of files that actually are there but not always visible to the default search strategy? -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 391252] Dolphin "Find" feature unable to find files
https://bugs.kde.org/show_bug.cgi?id=391252 Brennan Kinney <polarathene-sig...@hotmail.com> changed: What|Removed |Added CC||polarathene-signup@hotmail. ||com -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 391252] New: Dolphin "Find" feature unable to find files
https://bugs.kde.org/show_bug.cgi?id=391252 Bug ID: 391252 Summary: Dolphin "Find" feature unable to find files Product: dolphin Version: 17.12.2 Platform: Manjaro OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: search Assignee: dolphin-bugs-n...@kde.org Reporter: polarathene-sig...@hotmail.com Target Milestone: --- Try to search for "plasma-org.kde.plasma.desktop-appletsrc". This file belongs in "~/.config/plasma-org.kde.plasma.desktop-appletsrc". KRunner uses the same search I think as both fail to return a result(so perhaps this isn't a Dolphin bug?) Use KFind, and it will return a result instantly. This is a recent but a query that is easy to reproduce. I have had the same experience with personal files in various locations. Another example. In the home directory, I have a "log.txt" file. I enter into the search field "log"(as well as "log.txt"), I get results but this file is not one of them. There is a "Log.txt" in a nested directory for one of my applications. I can confirm this is not due to file size differences. I've tried various searches on my downloads directory where I'll get small and large files as results but many others omitted even though I've had these files for a long time. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 389493] Collection browse dialog should be consistent with other browse dialogs on KDE
https://bugs.kde.org/show_bug.cgi?id=389493 --- Comment #4 from Brennan Kinney <polarathene-sig...@hotmail.com> --- (In reply to Maik Qualmann from comment #3) > The remote storage plugin always uses the native file dialog. For digiKam > you can activate the native file dialog under Settings Miscellaneous. > > Maik Ok thank you for clarifying that, I misunderstood Gilles when he pointed that out. I didn't seem to see this option when doing some queries in google(although Digikam docs were appeaering as results). -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 389493] Collection browse dialog should be consistent with other browse dialogs on KDE
https://bugs.kde.org/show_bug.cgi?id=389493 --- Comment #2 from Brennan Kinney <polarathene-sig...@hotmail.com> --- (In reply to caulier.gilles from comment #1) > KDE is not the finality. DK run on Windows and MAcOS too. > > We want a file dialog which do not crash DK. We want a application working > properly. The native file dialog based on GTK desktop crash violently under > Ubuntu. > > So we swith to Qt5 file dialog by default and provide an option to > Setup/Misc to switch to native File Dialog if necessary. > > Gilles Caulier Sorry, I'm confused. Despite what you say, there are two different file browse dialogs present as mentioned in my report. They may look the same on other OS/DE, but on KDE they are visually/functionally different. Can you explain why this is? Should they not both be using the same one? The import dialog is the appropriate one that I'd like to the collections dialog use as well as it's the expected native type of dialog on KDE. -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 389493] Collection browse dialog should be consistent with other browse dialogs on KDE
https://bugs.kde.org/show_bug.cgi?id=389493 Brennan Kinney <polarathene-sig...@hotmail.com> changed: What|Removed |Added CC||polarathene-signup@hotmail. ||com -- You are receiving this mail because: You are watching all bug changes.
[digikam] [Bug 389493] New: Collection browse dialog should be consistent with other browse dialogs on KDE
https://bugs.kde.org/show_bug.cgi?id=389493 Bug ID: 389493 Summary: Collection browse dialog should be consistent with other browse dialogs on KDE Product: digikam Version: 5.8.0 Platform: Manjaro OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Setup-Collections Assignee: digikam-bugs-n...@kde.org Reporter: polarathene-sig...@hotmail.com Target Milestone: --- Settings -> Configure -> Collections -> Add Collection "Choose the folder containing your collection" dialog Doesn't appear to be native KDE dialog, like the one from Import -> Remote Storage -> Load/save list buttons The available options are not the same, and the amount of places listed on the sidebar is considerably less. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 386046] Missing option "Move to Screen" for minimized window of application
https://bugs.kde.org/show_bug.cgi?id=386046 --- Comment #2 from Brennan Kinney <polarathene-sig...@hotmail.com> --- Status can be changed to confirmed? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 387722] Right click context menu - move to screen
https://bugs.kde.org/show_bug.cgi?id=387722 Brennan Kinney <polarathene-sig...@hotmail.com> changed: What|Removed |Added CC||polarathene-signup@hotmail. ||com -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 387722] New: Right click context menu - move to screen
https://bugs.kde.org/show_bug.cgi?id=387722 Bug ID: 387722 Summary: Right click context menu - move to screen Product: plasmashell Version: master Platform: Manjaro OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: Task Manager Assignee: h...@kde.org Reporter: polarathene-sig...@hotmail.com CC: plasma-b...@kde.org Target Milestone: 1.0 Like context menu for titlebar, there is `Move to Desktop`, but `Move to Screen` is not available(at least on icons-only). I have had several times where I need this as I can't see the titlebar but could use the task manager app icon to perform this. Discussion here: https://www.reddit.com/r/kde/comments/7ii2y6/send_window_to_monitor/ -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 372978] Restored session doesn't update view with new files even when refreshed
https://bugs.kde.org/show_bug.cgi?id=372978 --- Comment #2 from Brennan Kinney <polarathene-sig...@hotmail.com> --- (In reply to Nate Graham from comment #1) > Odd issue. I'm not able to reproduce with Dolphin 16.12.3. Please leave a > comment if you can still reproduce using a newer version of the software. I haven't noticed it recently. Test case if reproducible would be: 1. Open few tabs in dolphin 2. Reboot 3. Session is restored, dolphin pops up with tabs from prior session 4. Via another instance of dolphin or app that adds a file to a location the restored Dolphin window has 5. Check if the tab displays the new file(supposedly not notified of new file). -- You are receiving this mail because: You are watching all bug changes.
[ark] [Bug 384040] Support zstandard / zstd / .zst
https://bugs.kde.org/show_bug.cgi?id=384040 --- Comment #2 from Brennan Kinney <polarathene-sig...@hotmail.com> --- (In reply to Christoph Feck from comment #1) > zstd is no archive format. Do you need to decompress a *.tar.zstd file? zstd can compress input into .zst file. To compress directories I've used it with tar to get a tar.zst file, followed with tar and zstd commands to decompress.(plus split/cat if creating multi-part files). Any support would be good :) -- You are receiving this mail because: You are watching all bug changes.
[ark] [Bug 384040] New: Support zstandard / zstd / .zst
https://bugs.kde.org/show_bug.cgi?id=384040 Bug ID: 384040 Summary: Support zstandard / zstd / .zst Product: ark Version: 17.08.0 Platform: Manjaro OS: Linux Status: UNCONFIRMED Severity: wishlist Priority: NOR Component: plugins Assignee: rthoms...@gmail.com Reporter: polarathene-sig...@hotmail.com CC: elvis.angelac...@kde.org Target Milestone: --- It would be great to see support added for Facebook's zstd (aka zstandard), extension `.zst`. Repo: https://github.com/facebook/zstd -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 358957] laptop won't hybrid-suspend when Plasma is running
https://bugs.kde.org/show_bug.cgi?id=358957 Brennan Kinney <polarathene-sig...@hotmail.com> changed: What|Removed |Added CC||polarathene-signup@hotmail. ||com --- Comment #18 from Brennan Kinney <polarathene-sig...@hotmail.com> --- What is the status of this support? Is it still only discussed/tracked here? If the feature is not difficult to add/contribute, can an experienced dev familiar with the codebase point out what needs to be done where?(files to change, UI adjustments, etc) >From what I gather reading this, adding the basic functionality to the launcher leave options is trivial?(if so what files/lines? for launcher support) Followed by some UI settings modification(System Settings -> Power Management -> Advanced Settings?) and extra changes elsewhere to support laptop lid behaviour? --- I'm in agreement with getting this 5 year old request(https://bugs.kde.org/show_bug.cgi?id=302968) functional and available, tweak the UI later if there is a need. Even just having it as a launcher option would be nice(I noticed Power Management -> Energy Saving has a dropdown for the power button action supporting hybrid-sleep). While benefits are obvious for laptop users, it's also useful as a desktop user, I would prefer it. -- You are receiving this mail because: You are watching all bug changes.
[Breeze] [Bug 363147] Breeze cursors should have more sizes (patch included)
https://bugs.kde.org/show_bug.cgi?id=363147 --- Comment #17 from Brennan Kinney <polarathene-sig...@hotmail.com> --- Roman? Do you have time to review James's contribution? Especially if the custom cursor size could be integrated in future to System Settings with a slider instead of dropdown selection. I recently setup a user with 1080p display for vision impairment accessibility, similar changes that HiDPI users do to scale up elements. 48px is too small, they still have trouble spotting the cursor, I'm not sure what size it is on macOS that they also use but it was much larger. Bug report(marked as duplicate of this one): https://bugs.kde.org/show_bug.cgi?id=383146 -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 383146] Support larger cursor size
https://bugs.kde.org/show_bug.cgi?id=383146 --- Comment #2 from Brennan Kinney <polarathene-sig...@hotmail.com> --- (In reply to Christoph Feck from comment #1) > > *** This bug has been marked as a duplicate of bug 363147 *** They are similar due to request for new cursor sizes(I'll add the larger sizes as a comment on that bug), this report also addresses rendering consistency issues when applying the cursor size change. Suggested fix, a dialog warning similar to the one for Font DPI. -- You are receiving this mail because: You are watching all bug changes.
[kate] [Bug 383159] New: Polkit support for opening root owned file without read permissions
https://bugs.kde.org/show_bug.cgi?id=383159 Bug ID: 383159 Summary: Polkit support for opening root owned file without read permissions Product: kate Version: 17.04.3 Platform: Manjaro OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: application Assignee: kwrite-bugs-n...@kde.org Reporter: polarathene-sig...@hotmail.com Target Milestone: --- I've noticed and really appreciate the recent polkit support for running Kate without root permissions to open a root owned file and be prompted for password to save changes, this is great! I have opened a file from /var/log/libvirt/qemu/vmname.log that Kate refused to read due to not having read permissions, whereas /etc/default/grub I guess does. Could it be possible to also support this usecase like writing a file as root is now supported? Ideally, I could just browse to the location and select the file in Dolphin as I do now, then Kate will be able to open it with a polkit password prompt to continue. I am presently using the following command to workaround this(-n flag avoids issues caused by having an existing Kate window open, for editing grub config file and current support, using the same Kate window wasn't an issue like it is with sudoedit): EDITOR="kate -n" sudoedit /path/to/file.log -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 383157] New: Desktop Effects - Preview error makes System Settings unresponsive
https://bugs.kde.org/show_bug.cgi?id=383157 Bug ID: 383157 Summary: Desktop Effects - Preview error makes System Settings unresponsive Product: systemsettings Version: 5.10.4 Platform: Manjaro OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: polarathene-sig...@hotmail.com Target Milestone: --- The video/animated preview buttons when in System Settings -> Desktop Behaviour -> Desktop Effects. Clicking the button gets you a spinning loading indicator, and then sometimes(Looking Glass for example) it's just blank. I guess the video/preview failed to load or no long existed? Whatever the current format is, adding some GIFs here locally to avoid the loading time(5-10 seconds here) should be small on size and give an improved UX. The expanded list item doesn't seem to have an intuitive way to collapse back to how it was prior to the preview(clicking the video button again or another list item doesn't collapse). Playing with this just now actually froze up System Settings, it became unresponsive, a warning dialog to terminate the window popped up but it's buttons to take action are also unresponsive...which in turned popped up a dialog to kill the unresponsive dialog to kill system settings...also unresponsive, I sent a kill signal to system settings process to resolve. Perhaps the failed video for the effect caused the breakage. I can reproduce this with the "Looking Glass" effect. Press the video preview button, wait 10 seconds or so for the spinner to disappear, should be no preview(blank output), click the same video preview button again, it'll go grey and the window will become unresponsive. You can resolve by killing the system settings process, doing this a few times on nvidia seems to have killed compositing too.. The "Looking Glass" effect actually doesn't seem to work for me at all when I've tried it. I also haven't gone through each effect to try the preview button so others may also be affected. --- To summarize - Previews for some effects are invalid and causing errors (remote content doesn't exist or is unreachable?), unresponsive window happens when using the preview button twice for an effect, using a different effect preview button is fine. - Local animated GIFs or similar instead of remotely(I'm assuming they're remotely sourced..) sourcing the preview would be nice, 5-10 sec delay, especially for content that doesn't seem to exist is bad UX. Something might be wrong with my install, as no previews seem to be working, but they were fine on my friends fresh install as far as I can recall the other day(eg Wobbly Windows or Zoom). - The active item in the list does not collapse it's preview window(assuming it's like the info button, clicking the preview button should do this. It will collapse if scrolled far enough out of view. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 383156] New: Mouse effects
https://bugs.kde.org/show_bug.cgi?id=383156 Bug ID: 383156 Summary: Mouse effects Product: kwin Version: 5.10.4 Platform: Manjaro OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: effects-various Assignee: kwin-bugs-n...@kde.org Reporter: polarathene-sig...@hotmail.com Target Milestone: --- I recently set up a friends laptop with tweaks to assist their vision impairment. Mostly this involved scaling up elements and fonts, cursor size was not large enough, but I've filed a separate issue for that. Kwin effects for inversion and zoom were greatly appreciated by the user! We had a few problems with some mouse effects: Mouse Click Animation On both the users laptop and my desktop(both running Manjaro KDE with 5.10), this effect does not seem to work when enabled and the shortcut key toggled. I added an alternate shortcut (meta+alt+z) just incase it was a numpad issue with the default shortcut(meta+*), seems to be the case. I guess the user needs to be aware that numpad * would not work, and that they need to use their meta+shift+8 to get the equivalent(at least on keyboards here shift+8 is *). Track Mouse This one was a bit confusing at first(ctrl+meta). If the mouse is stationary and not being moved the effect doesn't toggle to reveal where the cursor is, once the cursor is moving, the effect can toggle, and if the toggle keys are released while the mouse is stationary, the effect will remain until mouse movement. This behaviour took a while to notice and felt like it sometimes was working and other times buggy. It also lacked any configuration like Mouse Click Animation(MCA) had for colour and radius/line size. An alternative effect that emitted rings like MCA does from the cursor but on shortcut toggle rather than mouse clicks could work nicely, the current effect design wasn't easy for the user to spot/recognize with their impairment(the overlap from the larger cursor size might contribute to that). macOS has an effect that if you shake/vibrate the mouse quickly it will grow/explode the cursor size briefly(crisp all the way, so maybe their cursor is a vector graphic?). Compiz has a mouse trail effect. Some sort of improvement or alternative to this effect could be really helpful(I haven't checked the KDE Store, but if the devs might be open to considering an improvement/addition for default distribution of effects to aid with this kind of accessibility that'd be nice :) ). Zoom and Inversion effects were super helpful for the user, they really appreciate that so big kudos to the devs! :) -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 383148] New: [Accessibility - Vision] Display and Monitor Scaling - Experience and issues
https://bugs.kde.org/show_bug.cgi?id=383148 Bug ID: 383148 Summary: [Accessibility - Vision] Display and Monitor Scaling - Experience and issues Product: systemsettings Version: 5.10.4 Platform: Manjaro OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: polarathene-sig...@hotmail.com Target Milestone: --- System Settings -> Display and Monitor Recently helped a friend with vision difficulties scale up their desktop elements/fonts to avoid eye strain(they had a condition that had optic nerve damage where some vision was restored but is still quite limited). While not HiDPI exactly, I think the scaling is still useful in this case for the 1080p display? Cursor size and Font DPI were also increased. In this settings window, I used the Scale Display button to try find a comfortable size for the user. If the scale value was too high(I think 1.7x-2x) some windows/dialogs were too big vertically, so while it was a more ideal scale for them I had to reduce it as a particular dialog(native KDE app I think, sorry can't recall what one) had it's apply/cancel buttons cut off, and the titlebar likewise was cropped off desktop, I couldn't seem to reposition/resize the window(I think there is a key shortcut for this but I did not know it offhand nor expect a casual user to know about such and remember it). Some applications icons had a pixelated like look instead of a crisp aesthetic. I understand scaling especially non-integer values can be responsible for this on bitmap graphics, though I think it still happened with 2x on Octopi(Qt package manager app). This also seems to affect some text, like when shutting down or rebooting, the overlay with countdown and ability to change your choice, the text here appeared pixelated. Yakuake was affected by it's bar with close/menu/pin buttons, as well the red X above that. Taskbar scaled great, as did window decorations(titlebar buttons here were crisp). I believe I noticed that this scale value was also adjusting Font DPI as when we went to tweak it was at a value I don't recall setting, that was unexpected since we started with Font DPI first, I guess that wasn't required. --- Kudos to devs as the experience was less painful than expected. I was mostly fine with google queries and exploring system settings, KDE content on accessibility for such things is a bit spread out and dated from what I gathered with findings described here: https://www.reddit.com/r/kde/comments/6rj708/accessibility_vision_and_scaling/dl5geuu/ -- You are receiving this mail because: You are watching all bug changes.
[systemsettings] [Bug 383146] New: Support larger cursor size
https://bugs.kde.org/show_bug.cgi?id=383146 Bug ID: 383146 Summary: Support larger cursor size Product: systemsettings Version: 5.10.4 Platform: Manjaro OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: general Assignee: plasma-b...@kde.org Reporter: polarathene-sig...@hotmail.com Target Milestone: --- System Settings -> Workspace Theme -> Cursor Theme Bottom right is a big dropdown button. Usually but not always with the options: "resolution dependent", 24, 48. I just checked with my machine and I also have a 36 size. I setup a laptop with KDE/Plasma for a user with vision difficulties, one of their needs was a large cursor like they had on macOS. 48 was still too small for them on their 1080p display. They usually need to use the Kwin zoom effect which gives a larger albeit pixelated cursor in addition to content around the cursor being zoomed including text. I'm not sure if cursors are bitmaps or vectors, but if the default Breeze ones could at the very least support larger sizes that would be greatly appreciated. --- In addition to the cursor size, when applied, there seems to be a mix of the prior size and the new size depending on what the cursor is interacting with. On the system settings window, the resize cursors are the smaller original size and the default pointer is small when hovering over the windows titlebar area. This may cause some confusion or seem buggy. Unlike Fonts DPI this doesn't appear to be applied to new windows(existing Dolphin window had inconsistencies, new instance had no inconsistencies but used the small original size). It's corrected with a reboot, a warning dialog like Font DPI presents could be useful to avoid user confusion. --- TL;DR: Please consider supporting larger sizes like 60 and 72, if cursors are vector based a custom size would be great. If cursors are bitmaps but use vectors as source assets, a tool that could resize and rasterize the theme could address that too for supported themes? -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 380970] Wrong bit depth per channel reported, no export option to fix
https://bugs.kde.org/show_bug.cgi?id=380970 Brennan Kinney <polarathene-sig...@hotmail.com> changed: What|Removed |Added Resolution|WORKSFORME |WAITINGFORINFO --- Comment #8 from Brennan Kinney <polarathene-sig...@hotmail.com> --- It's not an issue for me with the library anymore as it was only for understanding how the data was presented via the API ArrayFire has. I had used jpg prior with max quality settings and from memory some 0 became 1 and some 255 became 254, which I guess is expected of a lossy format. Thanks for clarifying everything :) -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 380970] Wrong bit depth per channel reported, no export option to fix
https://bugs.kde.org/show_bug.cgi?id=380970 --- Comment #6 from Brennan Kinney <polarathene-sig...@hotmail.com> --- > How are you using freeimage with these png's? A library called ArrayFire that allows you to load images onto the GPU. I wanted to work with the values of 0 and 255 but it threw an error about FreeImage not being happy with the bitdepth. I wasn't aware that was an issue with other popular image programs as well or due to a standard. In that case I guess this isn't a bug for Krita. The outcome of the export being optimized like that was just unexpected. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 380970] Wrong bit depth per channel reported, no export option to fix
https://bugs.kde.org/show_bug.cgi?id=380970 --- Comment #4 from Brennan Kinney <polarathene-sig...@hotmail.com> --- (In reply to Boudewijn Rempt from comment #1) > There is an option to save png images as indexed I've seen that option and I had it unchecked. -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 380970] Wrong bit depth per channel reported, no export option to fix
https://bugs.kde.org/show_bug.cgi?id=380970 --- Comment #3 from Brennan Kinney <polarathene-sig...@hotmail.com> --- Created attachment 105988 --> https://bugs.kde.org/attachment.cgi?id=105988=edit .png 1-bit per channel -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 380970] Wrong bit depth per channel reported, no export option to fix
https://bugs.kde.org/show_bug.cgi?id=380970 --- Comment #2 from Brennan Kinney <polarathene-sig...@hotmail.com> --- Created attachment 105987 --> https://bugs.kde.org/attachment.cgi?id=105987=edit .kra file -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 380970] New: Wrong bit depth per channel reported, no export option to fix
https://bugs.kde.org/show_bug.cgi?id=380970 Bug ID: 380970 Summary: Wrong bit depth per channel reported, no export option to fix Product: krita Version: 3.1.3 Platform: Other OS: Linux Status: UNCONFIRMED Severity: normal Priority: NOR Component: File formats Assignee: krita-bugs-n...@kde.org Reporter: polarathene-sig...@hotmail.com Target Milestone: --- Image -> Properties, Depth: 8-bit integer/channel The image consists of 3 bands of solid R, G and B. due to the 0/255 values when I export to a format such as PNG, optimization appears to happen where Krita knows it could use 1-bit channels instead to represent the image. There is no option listed in the export dialog to prevent this. While I'd like the image to retain the 0 and 255 channel values, this optimization prevents it being able to work with FreeImage(which a program I am trying to use the image with relies on) as it does not support the bit depth. Can the ability to prevent this during export be made available? ImageMagick's `identify -verbose /path/to/image.png` is what helped me realize Krita was providing false information on bit depth of the image(probably because it could be edited as 8-bit in Krita and thus wasn't locked to 1-bit per channel like the stored format?). identify output snippet: Depth: 8/1-bit Channel depth: red: 1-bit green: 1-bit blue: 1-bit alpha: 1-bit .. png:IHDR.bit-depth-orig: 8 png:IHDR.bit_depth: 8 png:IHDR.color-type-orig: 6 png:IHDR.color_type: 6 (RGBA) png:IHDR.interlace_method: 0 (Not interlaced) png:IHDR.width,height: 9, 9 -- You are receiving this mail because: You are watching all bug changes.
[krita] [Bug 379730] Krita is leaking username into exported .png files
https://bugs.kde.org/show_bug.cgi?id=379730 Brennan Kinney <polarathene-sig...@hotmail.com> changed: What|Removed |Added CC||polarathene-signup@hotmail. ||com --- Comment #1 from Brennan Kinney <polarathene-sig...@hotmail.com> --- I think it should be anonymous by default, I just ran into this myself when using ImageMagick to figure out what was wrong with my file(Krita claimed information about bit depth on the image that was incorrect). I noticed my username was included, I'm a Linux user so not platform specific. Keeping this metadata with existing filese that contain it on save I understand if it's meant to preserve that(as in it was metadata from a third party source, not always necessarily going to be by our user only). Definitely something users should be aware of due to privacy if this is not going to be switched to anonymous by default. Perhaps a first run or similar(since existing users should perhaps be notified when they update) warning about this feature being enabled, even if disabled by default in future perhaps let users know about the change and impact on all images they have created with Krita in the past? -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 379937] Sorting is slow for 'type' column
https://bugs.kde.org/show_bug.cgi?id=379937 --- Comment #2 from Brennan Kinney <polarathene-sig...@hotmail.com> --- (In reply to Christoph Feck from comment #1) > Sorting by type needs to check the MIME type, which means it needs to load > the file contents. Is there no way to cache the sorted result the next time the directory is accessed with the type column for sorting? If nothing has changed within the directory, such as navigate up/back and then to the directory again...why does the directory contents need to be sorted again? Is memoization not an option? Or in my case an extension column to sort would probably work just as well without requiring to load file contents? -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 379937] New: Sorting is slow for 'type' column
https://bugs.kde.org/show_bug.cgi?id=379937 Bug ID: 379937 Summary: Sorting is slow for 'type' column Product: dolphin Version: 17.04.0 Platform: Other OS: Linux Status: UNCONFIRMED Severity: wishlist Priority: NOR Component: view-engine: general Assignee: dolphin-bugs-n...@kde.org Reporter: polarathene-sig...@hotmail.com Target Milestone: --- 15 folders 14k files directory. Sorted by 'filename' is reasonably quick, by 'type' initial time until display is about 5 seconds, navigations to the directory without a refresh are 2 seconds delay before displaying anything. This indicates some sort of caching might be in place, yet is still much slower than a default filename sort? This is with a details view on an SSD, i5-6500 CPU, 32GB RAM, Nvidia 1070 non-free drivers. Distro is Manjaro(no idea why it's missing on the platform list considering popularity?) -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 370258] No option to bring forward multiple windows of the same program
https://bugs.kde.org/show_bug.cgi?id=370258 --- Comment #13 from Brennan Kinney <polarathene-sig...@hotmail.com> --- > how does the stacking order of a hidden window relate to shown windows as > they get raised and lowered while the window is hidden? I'm not too concerned about tracking minimized windows. If I was to have windows 1-5 with the z order 1-5 respectfully, and window 3 was minimized, it would still be tracked as 3, if 2 were raised to the top it's now above the minimized window which is still above 1. I'm probably making a mistake with that basic approach somewhere. I think for a first iteration just raising the open windows above all others while keeping their stack order in the group the same should be fine? Like mentioned, minimized windows with that sort of behaviour probably should remain minimized. > I won't accept it in review (I wrote and maintain all this stuff) No worries, something is better than nothing :) I can avoid the JS tracking arrays/logic. Are you also against tracking the last active window in a group? I don't imagine that being a problem, when a window becomes active it just stores itself into it's group, should be one line? `lastActive[app_name] = active_window`. If you're against that too, I could just take the window with the highest z index(or stack order as you're referring to it as) for the app, which presumably involves iterating with a loop through the stack order array until I find a match? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 370258] No option to bring forward multiple windows of the same program
https://bugs.kde.org/show_bug.cgi?id=370258 --- Comment #11 from Brennan Kinney <polarathene-sig...@hotmail.com> --- > You have KWindowSystem::stackingOrder() to get the stacking order for shown > windows That's the stacking order for all windows(bar minimized) right? Is there events I can use to track the stack order on the JS end? I could probably maintain my own tracking of stack order per app with arrays? Or is there something bad about that I'm not aware of? Personally if they have minimized windows you could argue they expect them to remain minimized when raising the group. For my feature, if I'm able to know when windows become active and know what group they belong to I can probably track that on the JS/QML end too. So if a window gets minimized it could still be stored as the last active window for the app raising it on click. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 370258] No option to bring forward multiple windows of the same program
https://bugs.kde.org/show_bug.cgi?id=370258 --- Comment #8 from Brennan Kinney <polarathene-sig...@hotmail.com> --- I used blame to find this commit: https://github.com/KDE/plasma-desktop/commit/2a24828eedfb14d9a5489cbb7a6a52cf1c0169e6 Is that roughly what is required to add a feature? It's missing the API call being made? Soon as I have the info I need I'll give this a shot :) -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 370258] No option to bring forward multiple windows of the same program
https://bugs.kde.org/show_bug.cgi?id=370258 --- Comment #7 from Brennan Kinney <polarathene-sig...@hotmail.com> --- (In reply to Kai Uwe Broulik from comment #6) > > Naively, I agree it seems this should be easy if not trivial to implement. > > Feel free to send a patch. I'd give this a go if I can. The majority of code to work with seems to be located here? https://github.com/KDE/plasma-desktop/tree/master/applets/taskmanager I'm trying to track how `requestToggleMinimized()` is defined and implemented. Is this calling a C++ method? If you could help me understand how the existing methods are implemented I'll try to contribute this feature along with one of my own(clicking the app icon will show the last active window in that group). Do you know if these two features have relevant API calls I can use? For Aaron's feature presumably I would be able to get an array of windows that I could iterate through and call an API to bring each to the front(possibly in an order to preserve their Z index as a whole?). The window switch(alt + tab) or another method possibly does the API call to make a given window active, would that be the way to go or is there a better way? For my feature, given the activate window API, I should just need to be able to query what was the last active window for that app icon group. How do I get this information? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 370258] No option to bring forward multiple windows of the same program
https://bugs.kde.org/show_bug.cgi?id=370258 Brennan Kinney <polarathene-sig...@hotmail.com> changed: What|Removed |Added CC||polarathene-signup@hotmail. ||com --- Comment #4 from Brennan Kinney <polarathene-sig...@hotmail.com> --- I would think this to be a rather easy feature to add? At least in the icons-only task manager settings you have the middle click action option, an action that brings all windows to the front in that drop down should be fairly easy to implement by someone familiar with KDE dev? Though from the sounds of it they want to change the behaviour of LMB instead of using MMB, which is fair enough...? Is changing the action to that binding difficult to have as an option? -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 348529] Turn off screen after lock screen
https://bugs.kde.org/show_bug.cgi?id=348529 Brennan Kinney <polarathene-sig...@hotmail.com> changed: What|Removed |Added CC||polarathene-signup@hotmail. ||com -- You are receiving this mail because: You are watching all bug changes.
[konsole] [Bug 372980] Feature request: Custom window title name
https://bugs.kde.org/show_bug.cgi?id=372980 --- Comment #2 from Brennan Kinney <polarathene-sig...@hotmail.com> --- Seeing as that duplicate appears to have been ignored for 3 years with no feedback and this is being resolved as a duplicate.. Is it likely this feature request won't see a chance of being implemented? If so any reason? Is there a more appropriate place to request a feature like this(KDE/KWin)? If there is no blocker would a PR/Patch be accepted? -- You are receiving this mail because: You are watching all bug changes.
