[plasma-systemmonitor] [Bug 477517] "Log Files" not listed in sensor browser
https://bugs.kde.org/show_bug.cgi?id=477517 Steve Vialle changed: What|Removed |Added Resolution|WAITINGFORINFO |--- Status|NEEDSINFO |REPORTED -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 475805] Files with ending .bak are treated as if they were hidden.
https://bugs.kde.org/show_bug.cgi?id=475805 --- Comment #15 from Steve Vialle --- (In reply to Felix Ernst from comment #13) > I am currently trying to think > of a plan that makes everyone happy. The obvious answer is right there in the feature request: "it could be built-in (as suggested x-trash), like having a checkbox "[x] also hide application/x-trash files when hiding files"." Why continue to drag this out with diversions into what "application author might expect" and "user isn't supposed to interact with"? That's up to the application developer to deal with (usually using hidden "dot" files or directories), and cleaning up after programs that make a mess is none of dolphins business. If you want to please both those who want to keep the old hidden file definition and those who want x-trash (or some other list) hidden as well, what's the problem with simply adding a configuration checkbox as proposed? Worded as above, it even documents which mime type to edit if you want finer control over exactly what is hidden. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 475805] Files with ending .bak are treated as if they were hidden.
https://bugs.kde.org/show_bug.cgi?id=475805 --- Comment #12 from Steve Vialle --- (In reply to Felix Ernst from comment #8) > Which application is creating those .bak files? Are those files created in a > context in which the application author might expect users to directly > interact with the file? Is the file created in a visible path in the user's > home directory or in a path that contains hidden folders? I really don't see where any of this relevant. It's not the job of a file manager to predict the intent of other applications, but rather to provide an accurate view of the filesystem to the user. But, if you insist: * vi, diff and cp * Yes. Filenames provided from user input. * A first-level subdirectory of ~/, containing no traditional hidden files or directory elements. In the case that led me here, no application decided the names for the files I was working with, and "extensions" were arbitrary and supplied by the user... As is the norm on unix-like systems where file type is primarily determined by magic number rather than vestiges of MS-DOS "8.3" naming conventions. IOW, *I* created files with those extensions, as I have done quite happily for the last 2+ decades before this feature turned up, and having them suddenly vanish for no documented reason, contrary to the behaviour of every other file manager in existence, wasted considerable of my time. Filenames beginning with "." being treated as hidden is a well understood, well documented feature on unix-like systems, as established as the "hidden" file attribute in DOS or Windows. Files suddenly disappearing from view based on an arbitrary list of filename patterns buried in a rarely used mimetype is anything but, and leads to *surprises* for the user. Surprises are the _last_ thing I want from a tool like a file manager. -- You are receiving this mail because: You are watching all bug changes.
[plasma-systemmonitor] [Bug 477517] "Log Files" not listed in sensor browser
https://bugs.kde.org/show_bug.cgi?id=477517 --- Comment #2 from Steve Vialle --- (In reply to Arjen Hiemstra from comment #1) > What does this do? Exactly what it sounds like, allows adding a panel with a live tail of a log file to a sensor sheet. > What's the use case? For one, adding a "why" to the "what" displayed by a CPU utilisation chart or the like. e.g. Here's a periodic spike in system load, there's the cron job that's causing it, all on the same sheet. I'm sure I could think of some more, but frankly I'm a bit confused at the apparent need to justify removing existing functionality, or what is to be gained in deprecating perfectly functional software in favour of something with an obviously inferior feature set. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 475805] Files with ending .bak are treated as if they were hidden.
https://bugs.kde.org/show_bug.cgi?id=475805 --- Comment #6 from Steve Vialle --- (In reply to Felix Ernst from comment #4) > This change was done to fix a long-standing and much reported bug. Please > look at https://bugs.kde.org/show_bug.cgi?id=3212 That's not a bug, it's a 20+ year long discussion on how best to implement a *feature request*, and whether or not it's even a good idea to begin with. What we have here isn't a fix for something that was broken, it's a departure from behaviour that has been standard since KDE 1.0, and followed the example set by such truly obscure file management utilities as 'ls' and the rest of coreutils. > It seems a bit like we are in a situation in which different people want > different and conflicting behaviour. It's a situation where this was requested 23 years ago, and never implemented because nobody could agree on what beyond dotfiles, if anything, should be hidden. Even after the revival this year, nobody at all suggested x-trash be lumped in under the existing "show hidden files" functionality, the request was for *user defined* hidden files. Even Méven's initial proposal to use x-trash mentioned it having it's own toggle... Which for reasons unexplained, it didn't get. What exactly is a hidden file now anyway? Traditional *nix dotfiles? Trash files according to MIME? Backup and temporary files? Anything that doesn't have a defined MIME type? Does what is visible in dolphin depend on the phase of the moon, or just what's considered an "uncluttered view" this week? If an option to hide backup files is really considered necessary, please either provide a visible and documented option to disable it (i.e. not notes on creating random extra mime types buried in an ancient feature request), or move it to it's own "show/hide x-trash mimetype" toggle. -- You are receiving this mail because: You are watching all bug changes.
[plasma-systemmonitor] [Bug 477514] plasma-systemmonitor still missing functionality WRT ksysguard
https://bugs.kde.org/show_bug.cgi?id=477514 --- Comment #2 from Steve Vialle --- Sure. Done. Regex search is already covered by #469305 -- You are receiving this mail because: You are watching all bug changes.
[plasma-systemmonitor] [Bug 477521] New: Process table missing "Detailed Information" context-menu action and related info window
https://bugs.kde.org/show_bug.cgi?id=477521 Bug ID: 477521 Summary: Process table missing "Detailed Information" context-menu action and related info window Classification: Applications Product: plasma-systemmonitor Version: 5.27.9 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: ksysguard-b...@kde.org Reporter: stev...@runbox.com CC: ahiems...@heimr.nl, plasma-b...@kde.org Target Milestone: --- SUMMARY The right-click context-menu action "Detailed Information" (as available in ksysguard's process table view) appears to be missing from plasma-systemmonitor, along with the "Memory Map" and "Open Files" information provided by the window it opens. I don't see this detailed process information elsewhere in plasma-systemmonitor either. STEPS TO REPRODUCE 1. Explore context menu in process table view, compare to ksysguard. OBSERVED RESULT Functionality appears to be completely absent. EXPECTED RESULT New application has feature-parity with that which it is intended to replace. SOFTWARE/OS VERSIONS Gentoo Linux 2.14 KDE Plasma Version: 5.27.9 KDE Frameworks Version: 5.112.0 Qt Version: 5.15.11 -- You are receiving this mail because: You are watching all bug changes.
[plasma-systemmonitor] [Bug 477520] New: Process table missing context-menu action to jump raise application window
https://bugs.kde.org/show_bug.cgi?id=477520 Bug ID: 477520 Summary: Process table missing context-menu action to jump raise application window Classification: Applications Product: plasma-systemmonitor Version: 5.27.9 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: ksysguard-b...@kde.org Reporter: stev...@runbox.com CC: ahiems...@heimr.nl, plasma-b...@kde.org Target Milestone: --- SUMMARY The right-click context-menu action "Show Application Window" (as available in ksysguard's process table view) appears to be missing from plasma-systemmonitor. STEPS TO REPRODUCE 1. Explore context menu in process table view, compare to ksysguard. OBSERVED RESULT Functionality appears to be completely absent. EXPECTED RESULT New application has feature-parity with that which it is intended to replace. SOFTWARE/OS VERSIONS Gentoo Linux 2.14 KDE Plasma Version: 5.27.9 KDE Frameworks Version: 5.112.0 Qt Version: 5.15.11 -- You are receiving this mail because: You are watching all bug changes.
[plasma-systemmonitor] [Bug 477519] New: Process table missing context-menu action to jump from thread to parent process
https://bugs.kde.org/show_bug.cgi?id=477519 Bug ID: 477519 Summary: Process table missing context-menu action to jump from thread to parent process Classification: Applications Product: plasma-systemmonitor Version: 5.27.9 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: ksysguard-b...@kde.org Reporter: stev...@runbox.com CC: ahiems...@heimr.nl, plasma-b...@kde.org Target Milestone: --- SUMMARY The right-click context-menu action "Jump to Parent Process" (as available in ksysguard's process table view) appears to be missing from plasma-systemmonitor. STEPS TO REPRODUCE 1. Explore context menu in process table view, compare to ksysguard. OBSERVED RESULT Functionality appears to be completely absent. EXPECTED RESULT New application has feature-parity with that which it is intended to replace. SOFTWARE/OS VERSIONS Gentoo Linux 2.14 KDE Plasma Version: 5.27.9 KDE Frameworks Version: 5.112.0 Qt Version: 5.15.11 -- You are receiving this mail because: You are watching all bug changes.
[plasma-systemmonitor] [Bug 477518] New: Process table missing option to set process priority
https://bugs.kde.org/show_bug.cgi?id=477518 Bug ID: 477518 Summary: Process table missing option to set process priority Classification: Applications Product: plasma-systemmonitor Version: 5.27.9 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: ksysguard-b...@kde.org Reporter: stev...@runbox.com CC: ahiems...@heimr.nl, plasma-b...@kde.org Target Milestone: --- SUMMARY The right-click context-menu action to adjust process priority from the process tree view (as available in ksysguard) appears to be missing from plasma-systemmonitor. STEPS TO REPRODUCE 1. Try to change process priority with plasma-systemmonitor. OBSERVED RESULT Functionality appears to be completely absent. EXPECTED RESULT New application has feature-parity with that which it is intended to replace. SOFTWARE/OS VERSIONS Gentoo Linux 2.14 KDE Plasma Version: 5.27.9 KDE Frameworks Version: 5.112.0 Qt Version: 5.15.11 -- You are receiving this mail because: You are watching all bug changes.
[plasma-systemmonitor] [Bug 477517] New: "Log Files" not listed in sensor browser
https://bugs.kde.org/show_bug.cgi?id=477517 Bug ID: 477517 Summary: "Log Files" not listed in sensor browser Classification: Applications Product: plasma-systemmonitor Version: 5.27.9 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: ksysguard-b...@kde.org Reporter: stev...@runbox.com CC: ahiems...@heimr.nl, plasma-b...@kde.org Target Milestone: --- SUMMARY Ability to add a log file monitor to a sensor page (as available in ksysguard) appears to be missing from plasma-systemmonitor. STEPS TO REPRODUCE 1. Look for "Log Files" in sensor selection. 2. Look for any other way to add a log file monitor. 2. Get frustrated with horrible sensor browser, give up. OBSERVED RESULT Functionality appears to be completely absent. EXPECTED RESULT New application has feature-parity with that which it is intended to replace. SOFTWARE/OS VERSIONS Gentoo Linux 2.14 KDE Plasma Version: 5.27.9 KDE Frameworks Version: 5.112.0 Qt Version: 5.15.11 -- You are receiving this mail because: You are watching all bug changes.
[plasma-systemmonitor] [Bug 477516] New: "Monitor Remote Machine" and related ssh / ksysguardd functionality missing
https://bugs.kde.org/show_bug.cgi?id=477516 Bug ID: 477516 Summary: "Monitor Remote Machine" and related ssh / ksysguardd functionality missing Classification: Applications Product: plasma-systemmonitor Version: 5.27.9 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: ksysguard-b...@kde.org Reporter: stev...@runbox.com CC: ahiems...@heimr.nl, plasma-b...@kde.org Target Milestone: --- SUMMARY "Monitor Remote Machine" and related ssh / ksysguardd functionality from ksysguard is missing in plasma-systemmonitor. STEPS TO REPRODUCE 1. Look for "Monitor Remote Machine under "File" in menubar. 2. Look for menubar in general. 2. Search through hamburger menu, randomly placed buttons, and awful sensor browser. OBSERVED RESULT Functionality appears to be completely absent. EXPECTED RESULT New application has feature-parity with that which it is intended to replace. SOFTWARE/OS VERSIONS Gentoo Linux 2.14 KDE Plasma Version: 5.27.9 KDE Frameworks Version: 5.112.0 Qt Version: 5.15.11 -- You are receiving this mail because: You are watching all bug changes.
[plasma-systemmonitor] [Bug 477514] New: plasma-systemmonitor still missing functionality WRT ksysguard
https://bugs.kde.org/show_bug.cgi?id=477514
Bug ID: 477514
Summary: plasma-systemmonitor still missing functionality WRT
ksysguard
Classification: Applications
Product: plasma-systemmonitor
Version: 5.27.9
Platform: Other
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: ksysguard-b...@kde.org
Reporter: stev...@runbox.com
CC: ahiems...@heimr.nl, plasma-b...@kde.org
Target Milestone: ---
SUMMARY
Main application is missing:
"Monitor Remote Machine" and related ssh / ksysguardd functionality.
A usable not-mobile-centric UI, with traditional menubar and no hamburgers.
Sensor selection is missing:
"Log files" section (and the ability to add a log file view to a page in
general)
A sensible tree-based sensor browser, as opposed to whatever this *thing* is
Process table view is missing:
"Set Priority"
"Jump to Parent Process"
"Show Application Window"
"Detailed Information" ("Memory Map", "Open Files")
Regex support in the search bar
STEPS TO REPRODUCE
1. Wait a couple of years for plasma-systemmonitor to mature.
2. Try to accept it as a replacement for ksysguard.
OBSERVED RESULT
Find it's missing a bunch of very useful features, and the UI still looks and
behaves like Windows 8.
EXPECTED RESULT
New application has feature-parity with that which it is intended to replace,
UI is not out of place on a traditional mouse + keyboard desktop.
SOFTWARE/OS VERSIONS
Gentoo Linux 2.14
KDE Plasma Version: 5.27.9
KDE Frameworks Version: 5.112.0
Qt Version: 5.15.11
--
You are receiving this mail because:
You are watching all bug changes.
[dolphin] [Bug 475805] Files with ending .bak are treated as if they were hidden.
https://bugs.kde.org/show_bug.cgi?id=475805 Steve Vialle changed: What|Removed |Added CC||stev...@runbox.com --- Comment #3 from Steve Vialle --- This apparently also affects files ending in ".old" and "~", along with whatever else is now randomly considered "hidden" with complete disregard for unix/linux conventions. These are not hidden files, they are relatively standard conventions for _backup_ files. The option is not called "show backup files", now is it? Please split this from the "show/hide hidden files" functionality, this (recent) change is misleading, confusing, undocumented, and _extremely_ annoying. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 401088] "Filesystem mounted at '/' is not responding" notification on log in to Plasma 5.14.3
https://bugs.kde.org/show_bug.cgi?id=401088 --- Comment #45 from Steve Vialle --- Also see #412724, #474403, #454722, and #441077. Sigh. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 401088] "Filesystem mounted at '/' is not responding" notification on log in to Plasma 5.14.3
https://bugs.kde.org/show_bug.cgi?id=401088 --- Comment #44 from Steve Vialle --- Ed. There are symlinks pointing at the NFS mounts on 2 of the local filesystems involved (one of which is /), so #471044 may be related. Maybe. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 401088] "Filesystem mounted at '/' is not responding" notification on log in to Plasma 5.14.3
https://bugs.kde.org/show_bug.cgi?id=401088 Steve Vialle changed: What|Removed |Added CC||stev...@orcon.net.nz --- Comment #43 from Steve Vialle --- I have been seeing this for every filesystem (3 local filesystems on 2 RAID1 arrays , 5 NFS mounts), every login. Appears new(ish), as in I'm tracking current plasma releases and I've only seen it in the last couple of updates. The NFS mounts are indeed slow, as the network is firewalled until opensnitch's GUI loads (or could be down entirely) and mounts are retrying in the background (i.e. mounted with -o bg) but the messages regarding local arrays are entirely incorrect - as verified by dropping (or booting direct to) a VT. Those inaccessible NFS background mounts also completely prevent dolphin from launching (or hang it if it's already open and they go down), as well as freezing parts of plasmashell itself (including the panel and notifications). The result is an unusable desktop for a few seconds until the NFS mounts succeed, followed by a flurry of 8 "filesystem not responding" popups... which only appear once the filesystem is no longer "not responding", by which time they are completely pointless. If the network is actually down, the desktop remains unusable until the background mounts time out and fail - which could be 5 minutes, or it could be _forever_ if they are hard mounts. This is not an acceptable user experience by any stretch of the imagination, and I know of no other UI or file manager that locks up completely if a single non-essential mount is down. IOW, the behaviour of plasma/kio WRT inaccessible / unresponsive / slow filesystems is utterly broken, and has been for years. Adding popups is not addressing the root problem in the slightest, doubly so if they don't appear until _after_ the cause is resolved. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 455326] Window crash after tiling twice to the screen edge
https://bugs.kde.org/show_bug.cgi?id=455326 --- Comment #9 from Steve Vialle --- (In reply to David Edmundson from comment #6) > Is this still reproducible against newer Plasma (5.27) Apologies for the late update, I am unable to reproduce this with 5.27.6. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 470444] when compresing operation finishes, dolphin window teleports to current virtual desktop
https://bugs.kde.org/show_bug.cgi?id=470444 Steve Vialle changed: What|Removed |Added CC||stev...@orcon.net.nz --- Comment #1 from Steve Vialle --- This happens when any external application (e.g. firefox download widget -> "show in folder") asks to open a directory, and that directory is open in dolphin on another desktop. The whole dolphin window (including any other open tabs) is pulled to the current desktop. Please provide a way to disable this (and focus/select after context-menu compression in general, and focus after move/copy operation as well), all these behaviours are related, relatively new, and _extremely_ annoying. -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 316734] After waking the system, the desktop gets displayed for a moment before the lock screen appears
https://bugs.kde.org/show_bug.cgi?id=316734 Steve Vialle changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- CC||stev...@orcon.net.nz --- Comment #73 from Steve Vialle --- This is still occuring as of plasma 5.27.3 Reopening this rather than creating yet another duplicate. If you want a new bug, I can do that too. This problem has been (re)appearing for 10 years now. Was/is this ever going to be fixed properly, and permanently *on X11*? As requested some time ago: > please check dmesg after a suspend cycle for messages related to drm? Dmesg snip from suspend -> resume cycle: https://bpa.st/O5ATM ^ | grep -i drm: [drm] PCIE GART of 512M enabled (table at 0x00800030). [drm] PSP is resuming... [drm] reserve 0xa0 from 0x82fd00 for PSP TMR [drm] DMUB hardware initialized: version=0x02020017 [drm] kiq ring mec 2 pipe 1 q 0 [drm] VCN decode and encode initialized successfully(under DPG Mode). [drm] JPEG decode initialized successfully. > try whether the issue also persist on a Wayland session. No. I do not have wayland or anything related to it installed, nor do I intend to. > I would like every affected user to report: > * Distribution and version > * Mesa version > * Hardware (which CPU and GPU) Gentoo current (2.13) Mesa 23.0.0 CPU: Intel I9-10900KF GPU: AMD Radeon RX 6700 XT Anything else you need? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 442901] GTK4 apps have double scaling on hidpi
https://bugs.kde.org/show_bug.cgi?id=442901 --- Comment #46 from Steve Vialle --- (In reply to Luca Bacci from comment #45) > We fixed the issue of unscaled XWayland apps for KDE > 5.27.1, but unfortunately I had to cut out the part which properly reads > Xft.DPI due to the imminence of the 5.27.1 release. So, IOW, "We hurriedly worked around the latest GTK crazy, at the expense of breaking both manual DPI settings in X11 and our own fonts control module."? :raisedeyebrow: GTK4+HiDPI really that special, huh? WIP, got it, cool, and thanks. Guess I'll just keep my xsettingsd.conf immutable and out of plasmas meddling paws while I look forward to the _real_ fix. If we need a new bug report to track this (as it's not really about GTK4 any more), cool. I'm not convinced this one deserves a "fixed" tag when the "fix" introduces additional regressions though. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 442901] GTK4 apps have double scaling on hidpi
https://bugs.kde.org/show_bug.cgi?id=442901 --- Comment #44 from Steve Vialle --- Additional quick tests: Setting Xft.dpi to 82 in /etc/X11/Xresources -> plasma/QT/GTK all 96DPI. Setting "DPI" "82x82" in /etc/X11/xorg.conf.d/foo.conf -> plasma runs at 96DPI. Setting "Force fonts DPI to 82 in fonts KCM -> plasma runs at 96DPI. _Please_ stop overriding my settings. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 442901] GTK4 apps have double scaling on hidpi
https://bugs.kde.org/show_bug.cgi?id=442901 Steve Vialle changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #43 from Steve Vialle --- Not only is this still not fixed WRT DPI <96, the situation is now _worse_ than it was with 5.27.0. GTK3 and QT/KDE fonts are now the same DPI, so that's something... But that DPI is 96, and _everything_ is huge. It appears "force fonts DPI" is now being ignored altogether, and plasma is setting Xft.dpi to 96 unconditionally. xsettingsd.conf as of 5.27.1: Xft/DPI 98304 Gdk/UnscaledDPI 98304 Again, this is an _82_ DPI display, and that information is both readily available and manually provided in the fonts KCM. 5.27.0: ~ $ xdpyinfo | grep -B2 resolution screen #0: dimensions:1920x1080 pixels (594x334 millimeters) resolution:82x82 dots per inch ~ $ xrdb -query | grep dpi Xft.dpi:82 5.27.1: ~ $ xdpyinfo | grep -B2 resolution screen #0: dimensions:1920x1080 pixels (594x334 millimeters) resolution:82x82 dots per inch ~ $ xrdb -query | grep dpi Xft.dpi:96 No software or config changes on my end besides updating plasma. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 442901] GTK4 apps have double scaling on hidpi
https://bugs.kde.org/show_bug.cgi?id=442901 Steve Vialle changed: What|Removed |Added CC||stev...@orcon.net.nz Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #32 from Steve Vialle --- As of plasma 5.27.0, this change breaks GTK font scaling on systems where display DPI <96. This is most notable in firefox. Inspecting generated ~.config/xsettingsd/xsettingsd.conf shows: Gdk/UnscaledDPI 98304 Where 98304/1024 = 96 That's 96DPI folks, I don't know where plasma is getting it but it's flat-out wrong on this system. This is an _82DPI_ display, as reported by: X11 / GPU driver / Monitor EDID: AMDGPU(0): DPI set to (82, 82) xdpyinfo: resolution:82x82 dots per inch xrdb: Xft.dpi:82 A frickin' ruler and a calculator. On top of that, "force fonts DPI" is set to 82 in the fonts KCM. Setting 'Gdk/UnscaledDPI 83968' in xsettingsd.conf (1024x82) and marking that file immutable so plasma can't screw with it restores correct font scaling in GTK3 applications. If plasma is going to pass this setting to xsettingsd, it should _at least_ respect the setting of "force fonts DPI" in the fonts KCM. Ideally that setting should be entirely unnecessary anyway, as there is a perfectly good autodetected value available from X11. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 440663] New Dolphin window or tab opened after compression/extraction when certain default options are disabled, or when the job is canceled, or when the Dolphin window that initiated i
https://bugs.kde.org/show_bug.cgi?id=440663 --- Comment #90 from Steve Vialle --- (In reply to Andrey from comment #87) > I just fixed it so it started to work for the context menu created archives > at all (yes, it was there for them either). As far as I can see the problem began with https://invent.kde.org/utilities/ark/-/commit/ad8f47da4538d92d88900d5f86050b098f84239c, and as far as I am concerned https://invent.kde.org/utilities/ark/-/commit/28f2ef4b22f53200cb8789dbc8fe8ecdba3a377f is still the correct answer. IMO "Focus newly created archives in file manager" is just a bad idea to begin with, and if it is to stay it needs an option in ark's settings to control it. Preferrably one that is off by default. Apologies for blaming you for this, I guess you're just trying to make somebody else's "feature" work as intended. For the rest, I wholeheartedly agree with everything Christian said above. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 440663] New Dolphin window or tab opened after compression/extraction when certain default options are disabled, or when the job is canceled, or when the Dolphin window that initiated i
https://bugs.kde.org/show_bug.cgi?id=440663 --- Comment #86 from Steve Vialle --- > Checking "open new folders in tabs" does indeed prevent the spawning of new dolphin windows on extraction. s/extraction/compression/g -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 440663] New Dolphin window or tab opened after compression/extraction when certain default options are disabled, or when the job is canceled, or when the Dolphin window that initiated i
https://bugs.kde.org/show_bug.cgi?id=440663 --- Comment #85 from Steve Vialle --- (In reply to Andrey from comment #83) > What about extraction? Does it respect "open destination folder after > extraction" in ark? Checked or unchecked, nothing is opened after extraction from the dolphin context menu. It _is_ respected when extracting an archive from within ark itself, as it should and always has. IMO ark options should affect ark, and not bleed over into dolphin context menu actions anyway. They never have before AFAIK. > As I wrote above, that "open new folders in tabs" option naming in dolphin > just unfortunate and misleading. "Open new folders in tabs" does exactly what it says on the tin - it causes folders opened externally (e.g. from a desktop icon etc.) to open a new tab in an existing dolphin window, rather than opening a new window. That's what it's always done, since the introduction of dolphin as the default file manager. It's not misleading, and it has only become "unfortunate" with the introduction of this "focus archive" shenanegans. > If it UNchecked, it _guarantees_ the new Dolphin window will be opened > instead of selecting the archive in current tab/new tab. Well it does _now_. It sure didn't before all this started. > Please try to check that option and retest. Checking "open new folders in tabs" does indeed prevent the spawning of new dolphin windows on extraction. However, as above, it also causes externally opened folders to open tabs rather than new windows. For those of us used to a traditional desktop workflow, this is extremely irritating. It is also logically unrelated to background archive operations. If and when you have something in need of testing I'm happy to do so... But I also need a desktop that works properly, so for now I'm going to keep patching out your changes locally until this doesn't steal focus, raise windows, hijack existing options, or generally get in my way. I've been using KDE since 1.0 and I've never needed this, quite frankly I don't need it now either. Archiving is and always has been an unobtrusive background operation, and it has worked just fine that way for many years. If you are determined to implement this feature, please provide a clearly labelled option (a *new* option, not one with it's own well-established uses) to disable it entirely. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 440663] New Dolphin window or tab opened after compression/extraction when certain default options are disabled, or when the job is canceled, or when the Dolphin window that initiated i
https://bugs.kde.org/show_bug.cgi?id=440663 --- Comment #81 from Steve Vialle --- (In reply to Andrey from comment #80) > Are you creating archive in Ark or in Dolphin's context menu? Dolphin context menu, "Compress here". Any archive type. > Does it depend on any options, etc.? The only relevant options I can see are "open destination folder after extraction" in ark, and "open new folders in tabs" in dolphin. Both are unchecked. This is exactly the same behaviour as described in the original report, and the "workaround" revert still solves the problem. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 440663] New Dolphin window or tab opened after compression/extraction when certain default options are disabled, or when the job is canceled, or when the Dolphin window that initiated i
https://bugs.kde.org/show_bug.cgi?id=440663 --- Comment #78 from Steve Vialle --- Confirmed, again. Revert of the revert of the revert patch added back into my portage tree. Again. Can we not just kill this misfeature with fire, please? And not keep trying to put it back in, pretty please? I mean, seriously, what is the use-case here? What problem are we trying to solve with this functionality? -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 453890] Umount icon unnecessarily shown for internal drives
https://bugs.kde.org/show_bug.cgi?id=453890 Steve Vialle changed: What|Removed |Added Status|RESOLVED|REOPENED CC||stev...@orcon.net.nz Resolution|FIXED |--- --- Comment #24 from Steve Vialle --- > KIO 5.95 should have this fix. Nope, still doing silly things as of KIO 5.97.0 Presumably mdraid volumes are "hot pluggable" as well these days? If anyone can think of any reason at all I would want to unmount /dev/md127 (mounted by-label in fstab) from dolphin, I'm all ears... Suddenly it has an unmount button here. I mean, I'm never going to even unmount it, let alone "eject" it (as suggested by the icon). The latter would mean stopping the array (which can't be done from KDE / GUI anyway) and physically pulling the disks... As far as I can deduce, at least empirically, the real logic (if you can call it that) here is that *anything* mounted to /mnt or /media that is not a network mount winds up with this silly button. How's about only showing it for stuff the *user* can reasonably unmount? If it's in fstab and doesn't have the "user" mount option (yes, that means tracking by-label and by-uuid etc. as well) then it's a system mount, leave it alone. $ solid-hardware5 details '/org/freedesktop/UDisks2/block_devices/md127' udi = '/org/freedesktop/UDisks2/block_devices/md127' parent = '/' (string) vendor = '' (string) product = '' (string) description = 'rust' (string) icon = 'drive-harddisk' (string) Block.major = 9 (0x9) (int) Block.minor = 127 (0x7f) (int) Block.device = '/dev/md127' (string) StorageAccess.accessible = true (bool) StorageAccess.filePath = '/mnt/rust' (string) StorageAccess.ignored = true (bool) StorageAccess.encrypted = false (bool) StorageVolume.ignored = false (bool) StorageVolume.usage = 'FileSystem' (0x2) (enum) StorageVolume.fsType = 'ext4' (string) StorageVolume.label = 'rust' (string) StorageVolume.uuid = 'da6b28d7-799f-4667-a2cf-0021b47df500' (string) StorageVolume.size = 4000650690560 (0x3a3795d) (qulonglong) $ grep rust /etc/fstab LABEL=rust /mnt/rust ext4noatime 0 4 -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 455326] Window crash after tiling twice to the screen edge
https://bugs.kde.org/show_bug.cgi?id=455326 Steve Vialle changed: What|Removed |Added Status|REPORTED|CONFIRMED Ever confirmed|0 |1 CC||stev...@orcon.net.nz --- Comment #5 from Steve Vialle --- I can still reproduce this trivially with kwin 5.25.3, all that is required is to (drag) tile a dolphin window against the same screen edge twice. Gentoo/X11. As such, setting to confirmed. I can probably build with debug symbols and grab another backtrace if it's wanted, but frankly I'm waiting for someone to follow up with rad1an before I jump in... -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 450582] Some change between 5.24.0 and 5.24.1 broke windows shade/shutter feature
https://bugs.kde.org/show_bug.cgi?id=450582 Steve Vialle changed: What|Removed |Added CC||stev...@orcon.net.nz --- Comment #22 from Steve Vialle --- Still broken as of 5.25.3. Does anyone actually care about all these wayland/touchscreen/SNS related regressions in well-established functionality or what? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 453282] New: Adding a "shade" button to the right hand side of window titlebars causes the rightmost button to disappear when an application returns from fullscreen
https://bugs.kde.org/show_bug.cgi?id=453282 Bug ID: 453282 Summary: Adding a "shade" button to the right hand side of window titlebars causes the rightmost button to disappear when an application returns from fullscreen Product: kwin Version: 5.24.4 Platform: Gentoo Packages OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: decorations Assignee: kwin-bugs-n...@kde.org Reporter: stev...@orcon.net.nz Target Milestone: --- SUMMARY Adding the "shade" button to the right hand side of window titlebars causes the rightmost titlebar button (usually "close") to disappear when an application returns from fullscreen, as if pushed off the end of the titlebar. Titlebar is redrawn correctly if the window is later horizontally resized. Observed with smplayer, VLC and gwenview, when using breeze or oxygen decorations, but not with plastik. Removing the shade button from the titlebar or moving it to the left side restores expected behaviour. STEPS TO REPRODUCE 1. Use the "breeze" or "oxygen" window decorations. 2. Add a "shade" button anywhere on the right hand side of the titlebar. 3. Launch one of the mentioned applications, enter fullscreen, then return to windowed. OBSERVED RESULT The rightmost titlebar button is either missing entirely or only partially visible, until the titlebar forced to redraw by resizing the window. EXPECTED RESULT Window titlebars are redrawn correctly as soon as an application returns from fullscreen. SOFTWARE/OS VERSIONS Platform: Gentoo GNU/Linux, openrc, X11. KDE Plasma Version: 5.24.4 KDE Frameworks Version: 5.93.0 Qt Version: 5.15.3 ADDITIONAL INFORMATION Getting a window into this state then changing window decorations between breeze and oxygen does not redraw the titlebar correctly, instead the rightmost button reappears but the shade button itself vanishes. Horizontal resizing does not fix this condition, but entering and exiting fullscreen again returns the titlebar to the original flavor of brokenness. I'm not sure if all this is related to #450582, but it seems probable to me. IIRC it appeared around the same time too. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 440663] New Dolphin window or tab opened after compression/extraction when certain default options are disabled, or when the job is canceled, or when the Dolphin window that initiated i
https://bugs.kde.org/show_bug.cgi?id=440663 --- Comment #66 from Steve Vialle --- (In reply to Nate Graham from comment #59) > Backported; it should show up in 21.12.1. > Thanks. :) (In reply to Nate Graham from comment #61) > Ultimately here is what I think makes sense: > > Extracting within Ark: > - always respect the setting to open a filemanager or not after the job is > done > > Extracting or compressing from Dolphin's context menu item: > - open a new window after the job is done only when Ark's setting for that > is set to true and also when any of the following conditions apply: > -- Dolphin isn't running anymore > -- A Dolphin window is open but its view is not showing the > extraction/compression location > If my 2c are worth anything at all: The first bit, absolutely. As for the second... Personally I'd quite like this whole idea to just go away, i.e. return to KDE 5.22.4 behaviour and leave service-menu (de)compression as an unobtrusive background task. As an added bonus, reverting this whole can-o-worms is likely the quickest and easiest solution as well. Frankly I don't see how raising/focusing/opening file manager windows/tabs like this will be anything but an irritant to the (desktop) user, and if focus-stealing after a background job really is the goal here, I'd _very_ much like to see an option (ideally in dolphin) to turn it off. Focus stealing is, after all, evil incarnate. We already have a notification system for notifying about background jobs, why not just use that instead of all this buggering about trying to pick a window/tab/yak to raise and somewhere sane to put yet more options? As Luke suggests above, all it really needs is an "Open Containing Folder" button for compression operations. -- You are receiving this mail because: You are watching all bug changes.
[ark] [Bug 440663] Ark opens a new instance of Dolphin after compression/extraction via Dolphin
https://bugs.kde.org/show_bug.cgi?id=440663 --- Comment #27 from Steve Vialle --- (In reply to Andrey from comment #10) > This was fixed in master: > https://invent.kde.org/system/dolphin/-/merge_requests/261, > maybe need to backport to some "release" branch. While this does apply cleanly to the dolphin 21.08.3 release branch, it does _not_ fix the problem, at least not on X11. Whether or not it works on wayland I don't know, and frankly don't care, as plasma (along with pretty much everything else) on wayland is still largely unusable for people who actually want their system to do productive work. Since there appears to be little interest in fixing this regression, perhaps someone would be so kind as to point me at which particular short-sighted, untested "wayland fix" broke my desktop this time, so I can nuke it from orbit? -- You are receiving this mail because: You are watching all bug changes.
[ark] [Bug 440663] Ark opens a new instance of Dolphin after compression/extraction via Dolphin
https://bugs.kde.org/show_bug.cgi?id=440663 Steve Vialle changed: What|Removed |Added CC||stev...@orcon.net.nz --- Comment #19 from Steve Vialle --- Still present in dolphin 21.08.2, on X11. Do "extract archive here" on any archive file: New window created, process '/usr/bin/dolphin ' created. Do "compress here" on any file, (any archive type): New window created, process '/usr/bin/dolphin --new-window --select ' created. All extraneous dolphin processes terminate when their respective windows are closed, as expected. This is extremely annoying, and clearly a regression. If it's fixed in 21.12 (is this time travel, or some secret release?), why not backport it to 21.08.x? -- You are receiving this mail because: You are watching all bug changes.
[kwin] [Bug 422844] Stuttering Plasma effects after the composer's resumption
https://bugs.kde.org/show_bug.cgi?id=422844 Steve Vialle changed: What|Removed |Added CC||stev...@orcon.net.nz --- Comment #10 from Steve Vialle --- Still present in kwin 5.22.4, with Nvidia 470.63.01. Completely fixed in KwinFT, so frankly that's what I'll be using from here on out. -- You are receiving this mail because: You are watching all bug changes.
