[plasmashell] [Bug 487456] Ability to customize bottom panel
https://bugs.kde.org/show_bug.cgi?id=487456 --- Comment #3 from flan_suse --- Created attachment 169780 --> https://bugs.kde.org/attachment.cgi?id=169780=edit Mouse movements Legacy Launcher demonstrating cleaner, simpler mouse movements, without requiring "zigzagging" between panels -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 487456] Ability to customize bottom panel
https://bugs.kde.org/show_bug.cgi?id=487456 --- Comment #2 from flan_suse --- New attachment added, demonstrating clean mouse movements with easy targets. No "zigzagging" from panel to panel required. Screenshot taken from: https://store.kde.org/p/1468103/ -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 487456] Ability to customize bottom panel
https://bugs.kde.org/show_bug.cgi?id=487456 --- Comment #1 from flan_suse --- I found this from 2021: https://bugs.kde.org/show_bug.cgi?id=442981#c1 What is its status? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 487456] New: Ability to customize bottom panel
https://bugs.kde.org/show_bug.cgi?id=487456 Bug ID: 487456 Summary: Ability to customize bottom panel Classification: Plasma Product: plasmashell Version: master Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Application Launcher (Kickoff) Assignee: plasma-b...@kde.org Reporter: windows2li...@zoho.com CC: mikel5...@gmail.com, noaha...@gmail.com Target Milestone: 1.0 The Legacy Launcher allowed you to choose which "tabs" you wanted on the bottom panel. (This feature would greatly enhance the practicality of the Kickoff Launcher.) This allowed direct access to a fully breathable menu, with easy-to-click items. Example (imagine these are "vertical" mouse movements): Favorites ---> click a favorite item Applications ---> browse through and click an application item Places ---> click a bookmark / favorite place History ---> click a recent item And so on. You could choose which tabs you wanted on the bottom panel. To be able to customize the bottom panel for the new Kickoff Launcher would reduce the amount of back-and-forth zigzagging with the mouse cursor. For example, instead of doing this: Menu ---> Places ---> cut across to the opposite side panel ---> History ---> cut back across to the other panel ---> select an item You could do this: Menu ---> History ---> select an item -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 487455] New: Option to enable activate on hover for bottom panel
https://bugs.kde.org/show_bug.cgi?id=487455 Bug ID: 487455 Summary: Option to enable activate on hover for bottom panel Classification: Plasma Product: plasmashell Version: master Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Application Launcher (Kickoff) Assignee: plasma-b...@kde.org Reporter: windows2li...@zoho.com CC: mikel5...@gmail.com, noaha...@gmail.com Target Milestone: 1.0 Feature request to get an option to use "activate on hover" for the bottom panel. Kickoff defaults to "click to activate" for the bottom panel. There should be an option to toggle "hover to activate" for the bottom panel. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 487292] New: Option to enable activate on hover for bottom panel, as well as customize the bottom panel
https://bugs.kde.org/show_bug.cgi?id=487292 Bug ID: 487292 Summary: Option to enable activate on hover for bottom panel, as well as customize the bottom panel Classification: Plasma Product: plasmashell Version: master Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: Application Launcher (Kickoff) Assignee: plasma-b...@kde.org Reporter: windows2li...@zoho.com CC: mikel5...@gmail.com, noaha...@gmail.com Target Milestone: 1.0 Can we get an option to use "activate on hover" for the bottom panel, which includes "Applications" and "Places"? There's already enough clicking and flinging the cursor around to do what the Legacy Launcher could do more easily and intuitively. Now we have *fewer* options to configure our launcher? It's one of the *most used features* of the Plasma desktop. Because the Legacy Launcher no longer works with Plasma 6, I have no choice but to try and adapt to this new launcher. And why have "Places" at the bottom, which then further divides into *three more* sub-categories on the opposite side, which requires more mouse flinging to navigate to often-used items? We can no longer have this at the bottom panel (Legacy Launcher style): Applications -> quickly access an app Places -> quickly access favorite folders History -> quickly access recently opened files/folders Instead, we are forced into this: Applications -> quickly access an app Places -> must click (no option to hover) -> aim the mouse cursor over to three more sub-categories -> hover over the desired one -> fling the mouse cursor back to the opposite side to select the item There seems to be a trend of trying to "cram things into panels" and "require more side-to-side mouse movements". -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 443082] Offer option to move categories sidebar to other side of main view for better usability and faster access to Favorites
https://bugs.kde.org/show_bug.cgi?id=443082 --- Comment #45 from flan_suse --- Ohh yeah baby! =) =) =) Very awesome. Very. Awesome. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 443082] Move categories sidebar to other side of main view for better usability (like how SimpleMenu does it)
https://bugs.kde.org/show_bug.cgi?id=443082 --- Comment #39 from flan_suse --- I sent a request over Phabricator. Hopefully it gets resolved. I'll vote for your merge request as soon as I am able to login again. :) -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 443082] Move categories sidebar to other side of main view for better usability (like how SimpleMenu does it)
https://bugs.kde.org/show_bug.cgi?id=443082 --- Comment #38 from flan_suse --- (In reply to Forest from comment #36) > If that's true, I think you would have to create a new account. I have a working KDE Identity account. When I click to register a new account (for their KDE Invent GitLab), it takes me to the KDE Identity page... of which I'm already logged in with my active account. Trying to login to KDE Invent, regardless, gives me the error message: "Your account has been blocked. Please contact your GitLab administrator if you think this is an error." I have a separate GitLab account, with the same email, that works for gitlab.com. I can even login to KDE Identity with no problems. So this appears to be specific to "KDE Invent". :/ -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 443082] Move categories sidebar to other side of main view for better usability (like how SimpleMenu does it)
https://bugs.kde.org/show_bug.cgi?id=443082 --- Comment #34 from flan_suse --- (In reply to Forest from comment #33) > Strangely, a few people have given my merge request a thumbs-down, with no > valid criticism beyond having to adapt their muscle memory to a positioning > change. It seems those people think a one-time inconvenience to them > outweighs the unending frustration to others that is caused by the current > layout. > > If you want to see this fixed, I suppose it might help to add a thumbs-up > vote on the the merge request's top level comment/description. Here's the > link: > > https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1628 > > If you join the discussion there, please keep comments constructive, of > course. "Your account has been blocked. Please contact your GitLab administrator if you think this is an error." Not sure why. I can login to my KDE Identity account. But trying to use it to access the GitLab gives me the above error message. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 443082] Move categories sidebar to other side of main view for better usability (like how SimpleMenu does it)
https://bugs.kde.org/show_bug.cgi?id=443082
--- Comment #31 from flan_suse ---
(In reply to Forest from comment #29)
> > maybe also make the triangle filter toggleable? As it makes no sense with
> > categories sidebar placed on the right side.
>
> It can be reoriented such that it makes sense on either side, and the
> approach I'm using to put the sidebar on the right takes advantage of that.
There needs to be a way to disable it completely.
When it exists in any form, it affects the mouse cursor hovering over it.
Case in point: Even with your modified patch (to switch the default view), the
"Triangle Filter" still interferes with my usage of the categories that are now
on the right side. ("Am I moving my mouse too straight? At an angle? Wiggling
it ?")
The "Triangle Filter" only exists to solve a problem that this new launcher
introduced. And now it becomes a new problem in of itself.
So if your patch gets accepted (which I hope it does!), there needs to be a way
to easily disable the "Triangle Filter".
--
You are receiving this mail because:
You are watching all bug changes.
[plasmashell] [Bug 443082] Move categories sidebar to other side of main view for better usability (like how SimpleMenu does it)
https://bugs.kde.org/show_bug.cgi?id=443082 --- Comment #27 from flan_suse --- (In reply to Forest from comment #25) > Created attachment 160376 [details] > draft: Kickoff from Plasma 5.27.5 with configurable sidebar position > > I feel strongly that this should be configurable, so I decided to take on > the work of making it so. > > In case anyone wants to test it, here's a patched version of the Kickoff > plasmoid from Plasma 5.27.5, patched with a new "sidebar position" option. Just tested it, and it works as you described! CAVEAT: In my opinion, the Legacy Launcher is still preferable, since it already has a sane layout and is much snappier to use. (For reasons already discussed by myself and a few others in this thread.) Even when I move the "Favorites" to the left side, the "Application Categories" (now on the right side) still suffers from the "Triangle Filter". So let's say I want to go to my "Internet" applications. If I move my mouse too fast or at the wrong angle, I'll accidentally end up going to "Office" or "Multimedia" applications. :/ (I'm telling you, this new launcher slows down my workflow and creates more problems than solutions. I hate being "conscious" about using a menu launcher.) This is not an issue with the Legacy Launcher, since it's layout is simpler and easier to navigate. There's no need for any fancy "Triangle Filter" or "predictions", since there's no risk of collisions or overlaps. (With the new launcher, it's such a pain to quickly open up a file from the "History"; while it's very easy and effortless to do so with the Legacy Launcher.) Being able to choose which side your Favorites are displayed is definitely an improvement for this new launcher. My appreciation to you! Ironically, it feels like we're just re-inventing the Legacy Launcher. :P (I'm still going to use the Legacy Launcher. I need to get work done, and I can't feel like my desktop is creating friction or resistance. I don't want to have to "think about" every time I use the launcher.) Cluttering more things into "sub-panes" makes this new launcher feel crammed, and more prone to collisions or accidents. The Legacy Launcher has large, distinct "tabs" to effortlessly switch between modes: Favorites, Applications, Places, History, Settings, Leave, etc. (You can even enable/disable the ones you want.) No fancy mouse movements needed. Nothing's "crammed" together. The new launcher crams "History" and "Places" together, but you need to navigate a "sub-pane" to switch between them, and only after visiting the "Places" section on the bottom. The same for "Favorites" and "Applications". There's just too much going on in a crammed space with this new launcher. It must also bear repeating: It's super annoying to have to consciously move my mouse cursor vertically AS STRAIGHT AS POSSIBLE so that it registers immediately what I hover over. If there's an "angle" or "skew" to my movement, it doesn't register the item. (Luckily, this doesn't happen with the "Favorites". It only affects the sub-panes that use a "Triangle Filter".) -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 443082] Move categories sidebar to other side of main view for better usability (like how SimpleMenu does it)
https://bugs.kde.org/show_bug.cgi?id=443082 --- Comment #22 from flan_suse --- I'm telling you. As I sit here using the "Legacy Launcher" it feels much more elegant and SNAPPY. The VERY moment I hover over an item or tab it is activated. (And this is good, because everything is isolated from each other: Favorites, Applications, Places, History, Session) It doesn't matter if I move the cursor perfectly vertical... or at a slight 87-degree angle, or with a slight skew, or in a "twitchy" zig-zag. Whatever my cursor is hovering over is "active", and I can click on it or navigate through it. This is true 100% of the time. No unintended targets or "filters" that ignore my mouse position. No fancy attempts to predict my movements. No need to play games with my cursor or do little "wiggles" to make sure I'm "over the target". I click on the Legacy Launcher and move my cursor up and down, as my favorite items are IMMEDIATELY registered the MOMENT I have over them. I click on the Legacy Launcher and move my cursor sideways, as the tab I want is IMMEDIATELY activated (such as "Applications" or "History".) Now in these separate sections, I don't need to worry about any collisions or accidental triggers. EVERYTHING is intuitive and snappy. This is not so with the new launcher. It feels "fidgety". Hovering your cursor over something doesn't always activate it. It "depends" how fast you're moving your cursor and at what angle... that's ridiculous. What other software has to try to "predict" the person's mouse movements, just to use its menus and buttons? That's such a poor way to design something. Imagine if you wrote a reply in this discussion, and tried to click "Save Changes", but it doesn't register because you moved your cursor "too vertically" to reach the button? (Because it predicted you wanted to navigate to something else?) I'm pleading with the devs here. Please just give KDE users a simple, intuitive launcher with easy targets and no ambiguity on its behavior. (The Legacy Launcher was practically perfect.) -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 443082] Move categories sidebar to other side of main view for better usability (like how SimpleMenu does it)
https://bugs.kde.org/show_bug.cgi?id=443082 --- Comment #21 from flan_suse --- (In reply to Forest from comment #20) > > It was hoped that the triangle filter would alleviate complaints about > > unintended category switching, > > and so far it has done so. > > I'm afraid not. Here comes yet another complaint about unintended category > switching, this time from a Plasma 5.27.5 user. Here's another issue with this new launcher, even on the latest KDE release on vanilla Arch Linux: Even for the times you *WANT* to navigate to a category, you have to move your cursor in a way that doesn't trigger the "triangle filter", otherwise your "hover" will not be registered, and the category will not be selected! (I find I have to sometimes do a little horizontal "wiggle" with my cursor for it to select the category. I sure do love playing mind-games with my mouse cursor!) So now we're in a weird pickle: You have to be conscious about how you move your cursor to quickly reach a Favorite, or else you'll accidentally trigger a category... *BUT* ...ff you *WANT* to trigger a category, it might not work since the "triangle filter" may accidentally assume you want to reach a Favorite! Hooray! /s It's comical. The menu launcher is meant to be simple and sleek, without requiring any special consideration from the end-user, let alone an added layer of complexity with the "triangle filter". What's the solution to this? Fix the layout of the launcher? Add an option on which side to place the Favorites? Add an option on whether you should click or hover to activate a tab? Place the "Applications" tab on the bottom for more "breathable" access? (They already do this with the "Places" tab.) Nope! Let's figure out how to make the "triangle filter" even more intelligent to predict human behavior! There's no way we can concede that this new launcher's design is inferior to the Legacy Launcher. (As a side-note concern: I wouldn't be surprised if this eventually is fixed, yet it still remains frustrating to access your Favorites because there exists a "triangle filter" that will still try to predict your mouse movements and neglect to activate the item that is being hovered over). -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 452924] Dolphin not showing metadata for files on network shares, "Details" tab in File Properties missing
https://bugs.kde.org/show_bug.cgi?id=452924 flan_suse changed: What|Removed |Added CC||windows2li...@zoho.com --- Comment #25 from flan_suse --- Can confirm this bug still exists. SMB? This bug exists. NFS? This bug exists. External USB? Normal behavior. Local drive? Normal behavior. KDE Plasma Version: 5.27.4 KDE Frameworks Version: 5.105.0 Qt Version: 5.15.9 -- You are receiving this mail because: You are watching all bug changes.
[baloo-widgets] [Bug 341288] No Exif-data shown, if pictures are accessed from remote drives (NAS)
https://bugs.kde.org/show_bug.cgi?id=341288 flan_suse changed: What|Removed |Added CC||windows2li...@zoho.com --- Comment #5 from flan_suse --- (In reply to Vishesh Handa from comment #2) > Marking this as a bug (instead of wishlist) otherwise it will not get looked > at. * ... 8 years later ... * .. Wonder if it's been looked at? ;) Not only can I confirm this, but it should be noted that this bug also affects NFS shares; not just SMB. SMB? This bug exists. NFS? This bug exists. External USB? Normal behavior. Local drive? Normal behavior. KDE Plasma Version: 5.27.4 KDE Frameworks Version: 5.105.0 Qt Version: 5.15.9 -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 443806] Dolphin should allow option to cache thumbnails for separate encrypted devices / locations
https://bugs.kde.org/show_bug.cgi?id=443806 --- Comment #31 from flan_suse --- (In reply to Nate Graham from comment #27) > This isn't about home directories (which experience no issues, as you point > out) but rather other encrypted volumes, such as Plasma Vaults and encrypted > external disks. This bug report and the entire discussion has always been about external drives / locations. As was my latest comment. If the user's home is encrypted, everything else is moot: *always* store thumbnails in the standard cache directory I have to repeat this again: If the user's home is encrypted, everything else is moot: *always* store thumbnails in the standard cache directory There is no "problem to solve". The user's home is encrypted. (Currently, KDE does not behave in this way, and hence the user complaints and this bug report.) What if the user's home is *not* encrypted AND the files live on an external drive / location that *IS* encrypted? There should be an *option* to continue with the normal standard: store thumbnails in the standard cache directory It's that simple. There are many reasons why someone would want to continue to store their thumbnails locally, even if their home is not encrypted. (It is *THEIR* computer, after all. They have full access and rights. Let's not try to subject them to some out-of-scope security hand-holding if they happen to encrypt their USB drives.) The lists I include in my comments are important and have real-world consequences based on being longtime a KDE user. 1. STANDARDS: Don't randomly break from standards. Other DEs use this home cache directory 2. PERFORMANCE: The user's home almost always lives on a much faster device (NVMe, SSD) 3. PERFORMANCE: Ejecting an external USB flushes the buffers from RAM; meanwhile the home drive is still snappier with buffers in RAM 4. CONSISTENCY: KDE is not aware of encrypted network shares or SED-encrypted drives. Any "protection" for files on an external USB drive will not apply to encrypted files from a network share or SED external drive. 5. WORKFLOW: Writing and updating thumbnails to external drives will change the "last modified time" on the individual folders if the thumbnails are stored folder-by-folder. (This can ruin certain tasks and workflows.) (I understand #5 might not apply.) I humbly ask that we don't start writing and updating thumbnails to external drives. (Currently we do not, so we should offer the user an option if they understand the risks involved if their home is not encrypted.) Scenario A: Home encrypted = *Always* store thumbnails in the standard cache directory Scenario B: Home *not* encrypted = Default to *NOT* storing thumbnails from encrypted external locations, but offer the user an *OPTION* if they understand the risks. What about Plasma Vaults? Sure, since they are KDE-specific, you can have them store thumbnails within the container itself. But please don't conflate Plasma Vaults with standard universal solutions like LUKS and network shares. Done. Simple. -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 443806] Dolphin should allow option to cache thumbnails for separate encrypted devices / locations
https://bugs.kde.org/show_bug.cgi?id=443806 --- Comment #26 from flan_suse --- Because I can't create a KDE Identity account (my email gets flagged as "spam"), I'll reply in here to Nate. On the merge request Nate wrote: "Personally I think the ideal way to fix this would be to store the thumbnails for files located on an encrypted drive on that drive itself, rather than in the user's home directory." Please don't do this. 1. It breaks from standards 2. External drives are slower, especially with laptops that use NVMe and SSD internal drives 3. It's incongruent with network shares 4. It creates extra (slower) writes on an external USB If the user's home directory lives on an encrypted space, this should be a non-issue from the very beginning. Store cached thumbnails in the standard directory. If the user's home directory does not live on an encrypted space, give the user's a choice (such as a simple option of "Allow storing thumbnails of images from encrypted source in the user's cache". You can even have this option regardless... Let's not make this more complicated than it needs to be. Encrypted home? No problems. Store thumbnails like they have been for years and years. Plain home? Default to a "secure" method, but give the user the option to change this. -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 443806] Dolphin should allow option to cache thumbnails for separate encrypted devices / locations
https://bugs.kde.org/show_bug.cgi?id=443806 --- Comment #20 from flan_suse --- (In reply to Alexander Wipperfürth from comment #19) > There is actually another workaround you guys could try, symlink the > folders you want to access on a regular basis and put the link into your > ~/ Sadly, this isn't feasible for myself (and probably many users), as we have different folders all over our drive. The issue needs to be resolved by upstream KDE. :( It's a matter of waiting now? I'm not even sure if this is being worked on. It used to work on earlier versions of KDE, until it was "fixed", and now we have our thumbnails on encrypted drives constantly being regenerated every time which costs time and CPU. -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 443806] Dolphin should allow option to cache thumbnails for separate encrypted devices / locations
https://bugs.kde.org/show_bug.cgi?id=443806 --- Comment #17 from flan_suse --- Any update on this front? It's been thoroughly discussed with solutions laid out. It's getting ridiculous that on KDE my CPU has to scream and blast the fans just to browse folders with many images. Even if I re-open the folder after having just viewed it. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 464584] Add option to create hard link with drag'n'drop
https://bugs.kde.org/show_bug.cgi?id=464584 --- Comment #1 from flan_suse --- I was about to write my own feature request about this very thing. I strongly second this, as a simplified way to use "hardlinks" can greatly enhance the user experience and yield better storage efficiency, without resorting to "symlinks" which can (easily) be "broken" by simply re-organizing files an folders. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 464584] Add option to create hard link with drag'n'drop
https://bugs.kde.org/show_bug.cgi?id=464584 flan_suse changed: What|Removed |Added CC||windows2li...@zoho.com -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 358231] desktop locks up when moving lots of files
https://bugs.kde.org/show_bug.cgi?id=358231 --- Comment #40 from flan_suse --- Ohhh, just discovered something interesting while testing your method, @DarkVessel. What happens if you NAVIGATE to the folder *while* the copy operation is in progress? While the folder copy operation is running, and the system is fine, I can re-create the "freeze" by entering the folder before it finishes. It is not until the copy operation is finished will I regain control of the desktop. So this might have something to do with Dolphin/KDE/KIO/Plasma/whatever updating/refreshing the view of the current folder that is the destination of a large copy operation? -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 358231] desktop locks up when moving lots of files
https://bugs.kde.org/show_bug.cgi?id=358231 flan_suse changed: What|Removed |Added CC||windows2li...@zoho.com --- Comment #39 from flan_suse --- (In reply to DarkVessel from comment #37) > I have exactly the same problem. When copying a file, the shell freezes (but > not Dolphin), but if you copy an entire folder, plasma does not hang. LOL! Same issue here too. At first I thought it had to do with the file being *large*, yet if it involves a *FOLDER* (whether containing a single or multiple large files, doesn't matter) then it smoothly glides through the entire copy operation! I thought I was going crazy until I came across this bug report. The trick of copying a FOLDER (instead of a large FILE) magically works. Not sure why... . . . Operating System: Manjaro Linux KDE Plasma Version: 5.24.6 KDE Frameworks Version: 5.96.0 Qt Version: 5.15.5 Kernel Version: 5.19.1-3-MANJARO (64-bit) Graphics Platform: X11 Processors: 8 × 11th Gen Intel® Core™ i7-1165G7 @ 2.80GHz Memory: 15.4 GiB of RAM Graphics Processor: Mesa Intel® Xe Graphics -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 458001] KDE / KIO / Dolphin needs to support "copy_file_range" for server-side copies over a network (such as NFS)
https://bugs.kde.org/show_bug.cgi?id=458001 --- Comment #4 from flan_suse --- (In reply to Nicolas Fella from comment #3) > Okay, so this is about the file worker, not the nfs worker. My main confusion / question: Has this been addressed by the KDE developers and *should* be working as expected? Or was the feature "accepted" but never finalized? Being a layperson end-user, I cannot tell if it was actually included in the final code or not. https://invent.kde.org/frameworks/kio/-/merge_requests/602 That's why I was unsure to submit this ticket as a "bug" or a "wishlist". Because if it *was* implemented, then it's not working as intended. However, if it was not implemented, then yes, this is a *dearly* needed feature of Dolphin/KIO. Network shares (even NFS) and NAS appliances are not rare for Linux users. Besides, everything else is in place; it's just that the client (i.e, Dolphin) needs to use it. -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 458001] KDE / KIO / Dolphin needs to support "copy_file_range" for server-side copies over a network (such as NFS)
https://bugs.kde.org/show_bug.cgi?id=458001 --- Comment #2 from flan_suse --- (In reply to Nicolas Fella from comment #1) > Is this about browsing NFS directly in Dolphin (i.e. a nfs:/ URL) or a NFS > mounted to the local filesystem and accessed via Dolphin as if it was a > regular file? Mounted normally with "mount". For example: mount -t nfs 192.168.0.100:/remote/path/of/share /mnt/remote nfsstat -m reveals the client and server are both using NFS v4.2. Copying a file with cp is very fast and uses "copy_fele_range" as expected. The copy operation does *not* make a round trip over the gigabit network. It's done on the server (which is one of the major features specifically introduced with NFS v4.2) Output of nfsstat -m: Flags: rw,relatime,vers=4.2,rsize=131072,wsize=131072,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.0.2,local_lock=none,addr=192.168.0.100 Copying a large 2 GB file with cp takes only a few seconds. (Server side copy!) :) Copying a large 2 GB file with Dolphin takes over half a minute! (Round trip over the network.) :'( The 2 GB file is filled with random data. I expected this feature was already used by Dolphin since KDE Frameworks 5.88+, but it doesn't seem to be the case? Is there any activity or update on this? -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 458001] New: KDE / KIO / Dolphin needs to support "copy_file_range" for server-side copies over a network (such as NFS)
https://bugs.kde.org/show_bug.cgi?id=458001 Bug ID: 458001 Summary: KDE / KIO / Dolphin needs to support "copy_file_range" for server-side copies over a network (such as NFS) Product: frameworks-kio Version: unspecified Platform: unspecified OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: kio-bugs-n...@kde.org Reporter: windows2li...@zoho.com CC: kdelibs-b...@kde.org Target Milestone: --- When copying a large file on an NFS mount with Dolphin, it takes a very long time since it does a round trip over the network. NFS 4.2 has already supported server side copies, yet Dolphin does not take advantage of this with "copy_file_range". This means someone has to resort to the terminal with "cp" in order to copy files without sending the data on a round trip over the network. I thought this was included in KDE Frameworks 5.88? But apparently this is not the case? Has anything been done with this: https://invent.kde.org/frameworks/kio/-/merge_requests/602 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 353975] Black screen on second display (no wallpaper, can't get a context menu on right-click)
https://bugs.kde.org/show_bug.cgi?id=353975 --- Comment #214 from flan_suse --- (In reply to Fushan Wen from comment #203) > Can anyone confirm they can still reproduce this bug without any DP ports > connected? I only have HDMI port connected and currently I can't reproduce > black screen on both X11 and Wayland. HDMI here. Intel Iris Xe video. Reproducible on X11. It's not consistent, however. Sometimes there are no issues, and randomly the black screen bug will occur. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 414068] Dolphin/dialogs should cache folder contents instead of repopulating the folder view every time.
https://bugs.kde.org/show_bug.cgi?id=414068 --- Comment #3 from flan_suse --- > I think this is related: https://bugs.kde.org/show_bug.cgi?id=293888 Oops! Correction. I think THIS bug is related: https://bugs.kde.org/show_bug.cgi?id=428373 -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 414068] Dolphin/dialogs should cache folder contents instead of repopulating the folder view every time.
https://bugs.kde.org/show_bug.cgi?id=414068 flan_suse changed: What|Removed |Added CC||windows2li...@zoho.com --- Comment #2 from flan_suse --- I think this is related: https://bugs.kde.org/show_bug.cgi?id=293888 :( -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 443082] Categories sidebar is located in the wrong place for optimal usability
https://bugs.kde.org/show_bug.cgi?id=443082 --- Comment #16 from flan_suse --- (In reply to Max from comment #14) > It's not about requesting to change the launcher itself, it's about > requesting new options and settings for it. Customizability is one the main > principles behind the KDE software, so what's wrong about requesting more of > it for a specific widget? > I love the new Kickoff widget and it's design, but the sidebar placement > causes inconveniences for me It's not JUST the poor placement of the favorite applications. It's not JUST that you cannot change what view is placed on the left side (i.e, near your mouse cursor's starting position.) Where is the option to "hover" over the bottom tabs? Even to this day, you must click on the tabs to navigate to the section. No option to hover. Speaking of the bottom tabs, the Legacy Launcher requires fewer steps and less navigation to get to frequently used actions. History? Hover over the History tab. I'm there. Places? Hover over the Computer tab. I'm there. Yet with this "new and improved" launcher... History? *Click* on Places. *Then*move up to hover over History. *Then* move (yet again) towards the right to access history entries. Rather than use all the available space for easily accessible hover tabs, they try to cram in as much as possible into this new launcher, and just leave it to the end-user to do acrobatics with their mouse cursor. Sorry, but the Legacy Launcher had a cleaner and more practical design. This same phenomenon is true for Windows as well. Windows 7 introduced one of the best and most practical Start Menus. They botched it in Windows 8, 10, and 11. So much so that there's a third-party open source alternative (named OpenShell) which basically lets you use the Windows 7 launcher on Windows 10. Developers just can't leave good things alone. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 443082] Categories sidebar is located in the wrong place for optimal usability
https://bugs.kde.org/show_bug.cgi?id=443082 --- Comment #15 from flan_suse --- (In reply to Tobias Leupold from comment #13) > Instead of trying to get the new launcher's devs to change it's behavior, > layout etc. etc. (they obviously don't want to change anything about it) > simply do what I did: Install Legacy Kickoff and you're done ( > https://store.kde.org/p/1468103 ) :-P ;-) This is what I did. Back then they designed a simple, practical, sleek launcher (now referred to as "Legacy" Kickoff), which works great. I still don't understand why they needed to replace it with this new launcher. It appears to be going backwards in usability and practicality, in which they actually need to add even more complexities to try and undo some of the inferior behaviors. (Smaller targets. Poor default presentation. "Triangle" filter to try and predict if the user wants to access her favorites or browse the categories. Etc. Etc. Etc.) Seriously, just watch the video I linked to in my original post. The only problem in regards to sticking with the Legacy Launcher is that it's no longer maintained, and might break compatibility with a future KDE release. -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 443806] Dolphin should allow option to cache thumbnails for separate encrypted devices / locations
https://bugs.kde.org/show_bug.cgi?id=443806 flan_suse changed: What|Removed |Added Version|21.12.2 |22.04.2 -- You are receiving this mail because: You are watching all bug changes.
[xdg-desktop-portal-kde] [Bug 428373] "Examining (Failed)" notifications some times when trying to save in folders with many files.
https://bugs.kde.org/show_bug.cgi?id=428373 --- Comment #6 from flan_suse --- So the question is... what *is* KDialog even doing? Does it inspect / examine every file in the navigated directory? For comparison: * Dolphin loads a folder with 14,000 files very quickly * GTK file selector loads a folder with 14,000 files very quickly * Qt file selector loads a folder with 14,000 files very quickly * Windows Explorer loads a folder with 14,000 files almost instantly This is true of a network share or a local folder. I believe the error message people are seeing is inter-related to some sort of bloat of KDialog. It's doing too much. A directory listing, even of thousands of files, should simply... list the contents. That's why we experience, even on fast computers, the "loading" phenomenon when browsing large folders with KDialog. Even on repeat visits! What is KDialog doing under the hood for this long-standing issue that has never been addressed or streamlined? -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kio] [Bug 293888] Poor performance with mounted network locations
https://bugs.kde.org/show_bug.cgi?id=293888 flan_suse changed: What|Removed |Added CC||windows2li...@zoho.com --- Comment #39 from flan_suse --- (In reply to grannie from comment #38) > I just hit this bug when using VirtualBox (choosing an Iso image for a VM). > Are there any updates on this? It's only been 10 years. Quit being so impatient. ;) KDialog continues to be the slow bottleneck on my otherwise fast system. GTK file chooser runs laps around it. Generic Qt file chooser runs laps around it. KDialog is hilariously slow, even for local filesystems. (Slow for network locations *and* local. It's just more noticeable for network shares.) What is KDialog even doing in the background? Examining every single file inside the current directory or something? Listing the contents of a folder should be a smooth process, just like we experience with GTK file chooser, or heck, using the terminal. I'm not even using thumbnail previews, and it's still crawls with KDialog. One workaround I found in the meantime is to trick applications into using the GTK file chooser instead, but this doesn't work across the board. -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 443806] Dolphin should allow option to cache thumbnails for separate encrypted devices / locations
https://bugs.kde.org/show_bug.cgi?id=443806 flan_suse changed: What|Removed |Added Summary|Dolphin should allow option |Dolphin should allow option |to cache thumbnails for |to cache thumbnails for |separate encrypted devices |separate encrypted devices |/ locations (KDialog too?) |/ locations -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 443806] Dolphin should allow option to cache thumbnails for separate encrypted devices / locations (KDialog too?)
https://bugs.kde.org/show_bug.cgi?id=443806 --- Comment #16 from flan_suse --- An ideal solution! (In reply to Marcin Gurtowski) > The previous policy, in regards to encrypted $HOME was: > "If encrypted file for which thumbnail is generated is on the same drive as > ~/.cache/thumbnails, do create cache for this file.". > > Should we change it to: > "If ~/.cache/thumbnails is on encrypted device, create cache for thumbnails > of encrypted files."? This comment was taken from another bug report, but it basically solves the issue in this bug report. I'm assuming the same logic will be used across-the-board, regardless if such encrypted files live on a LUKS device or are encrypted on a network share. If the above is implemented, it solves this issue. No need for any extra toggles or options. However, implementing the above fix will not exclude the possibility for additional toggles or options in the future. It's a win-win-win! :) -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 411919] Store thumbnails for files inside an encfs or cryFS encrypted container somewhere inside the encrypted container itself, not ~/.cache/thumbnails, or generate them but don't
https://bugs.kde.org/show_bug.cgi?id=411919 --- Comment #46 from flan_suse --- (In reply to Nate Graham from comment #45) > Your issue is valid too, but it's off-topic for this bug report, which is > purely about the issue with thumbnails for an encfs/cryfs (etc) encrypted > volume. It's not about thumbnails for network mounts or external disks. > > If your issue doesn't fall under Bug 451408, can you please file a new bug > report for it? Thanks! If my issue is off-topic, then why'd you mark my other bug report as a "duplicate" of this one? And no, the issue does not fall under Bug 451408 -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 411919] Store thumbnails for files inside an encfs or cryFS encrypted container somewhere inside the encrypted container itself, not ~/.cache/thumbnails, or generate them but don't
https://bugs.kde.org/show_bug.cgi?id=411919 --- Comment #44 from flan_suse --- (In reply to Nate Graham from comment #42) > Let's try to focus on one thing at a time rather than generalizing, > increasing the scope of the issue, and writing walls of text. :) The last part of my post was the "non wall of text" summary. ;) > What I can say confidently for now this is: > > *** The immediate resolution for users with encrypted $HOME is to remove any > such spillover protection. *** > > Using our computers is becoming a bottleneck when it involves browsing many > images and videos. (In reply to Nate Graham from comment #42) > Hopefully we can agree that this specific narrow use case/issue is valid. For Plasma Vaults? Sure, I agree. But the reason this is getting "out of scope" is because trying to resolve the issue around a KDE-specific technology (Plasma Vaults) affects users *without* Plasma Vaults. We use LUKS on external media and/or secondary drives. (LUKS is desktop-agnostic.) So I circle back around to this point, which I believe will *immediately* resolve one of the most impactful regressions from these recent changes to KDE: > *** The immediate resolution for users with encrypted $HOME is to remove any > such spillover protection. *** -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 411919] Store thumbnails for files inside an encfs or cryFS encrypted container somewhere inside the encrypted container itself, not ~/.cache/thumbnails, or generate them but don't
https://bugs.kde.org/show_bug.cgi?id=411919 flan_suse changed: What|Removed |Added CC||contijn.bu...@hotmail.com, ||wpprf...@posteo.de -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 411919] Store thumbnails for files inside an encfs or cryFS encrypted container somewhere inside the encrypted container itself, not ~/.cache/thumbnails, or generate them but don't
https://bugs.kde.org/show_bug.cgi?id=411919 --- Comment #41 from flan_suse --- (In reply to Nate Graham from comment #40) > Maybe we could only do it for encrypted volumes, and for everything else, > the thumbnails could live in the normal location. Nate, from the other bug report I created, all the commenters, as well as myself, are using an encrypted $HOME (which is very common for users who go out of there way to use encryption on external USB, network shares, and secondary drives.) This comes off as a "solution in search of a problem" for such users. We get hit with a performance penalty, sluggish browsing, and overworked CPUs (not an exaggeration, I hear my laptop fans spin up every time I browse a folder with many WEBP images.) Our $HOME is encrypted. There is no risk of spillover. But once again, I must re-emphasize, your philosophy about reducing or eliminating spillover sounds good, but it's not even feasible when you consider network shares. With ubiquitous home solutions of NAS (TrueNAS, Synology, QNAP, etc), and even just SMB / NFS shares in general, KDE generates and *stores* thumbnails from *encrypted* sources. (They are encrypted on the NAS / server.) This is *spillover* if the user's $HOME is not encrypted. The solution should NOT be to read and write thumbnails to a network share. That would be a hard block for me, and I would have to jump to another desktop environment if that ever happens. (Too many reasons to list in here.) -- So for users that have an encrypted $HOME, there's zero reason to use any sort of sophistication of attempting spillover prevention. No reason to check whether or not the source images and videos live in an encrypted space. No reason to determine the "speed" of the device. Just let thumbnails be cache'd under $HOME/.cache/thumbnails/, like normal. We're using encrypted $HOME for a reason, after all. -- For those with plain $HOME, you've got an entirely different problem. Try to prevent spillover by forcing the writing and reading of thumbnails to the source folder? But... What happens if there are permission issues? What if the device is read-only (to view, but not modify the images / videos)? Save the thumbnails in each separate folder? Or save them under the root directory? What if the root directory does not have sufficient permissions? (The common r-xr-x--- for root:wheel) Should we try to write and read thumbnail files over a network share? (That's a can of worms...) -- What I can say confidently for now this is: *** The immediate resolution for users with encrypted $HOME is to remove any such spillover protection. *** Using our computers is becoming a bottleneck when it involves browsing many images and videos. -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 411919] Store thumbnails for files inside an encfs or cryFS encrypted container somewhere inside the encrypted container itself, not ~/.cache/thumbnails, or generate them but don't
https://bugs.kde.org/show_bug.cgi?id=411919 --- Comment #39 from flan_suse --- (In reply to Nate Graham from comment #38) > I still think each mounted volume's thumbnails should be stored *on* that > mounted volume. It solves basically all the problems. I think it might lead into new issues down the line. I listed the reasons why. And I absolutely don't want thumbnails being cache'd on a network share / volume. Not to mention some people might mount an external drive as read-only, or not have sufficient permissions. Not to mention that external media is usually slower than where someone's $HOME resides. And finally, it means that KDE will stand out as the odd-ball desktop environment, straying for other standards. If one switches between desktops (Xfce, GNOME, Mate, KDE), then with only KDE will it try to write and read thumbnails from each separate volume, while on the others they will write and read thumbnails directly from $HOME. We've been using KDE with no problems until this "fix" was implemented, and now we don't have thumbnails being cached. And now thumbnails might in fact attempt to write outside of home? What does that mean for network shares? That would be a step backwards. -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 411919] Store thumbnails for files inside an encfs or cryFS encrypted container somewhere inside the encrypted container itself, not ~/.cache/thumbnails, or generate them but don't
https://bugs.kde.org/show_bug.cgi?id=411919 --- Comment #37 from flan_suse --- (In reply to Nate Graham from comment #35) Slow or not, *displaying* previews are one thing. But what about the over-arching issue of *caching* thumbnails? -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 411919] Store thumbnails for files inside an encfs or cryFS encrypted container somewhere inside the encrypted container itself, not ~/.cache/thumbnails, or generate them but don't
https://bugs.kde.org/show_bug.cgi?id=411919 --- Comment #32 from flan_suse --- (In reply to Nate Graham from comment #31) > As I understand it, it's a part of the general problem of certain filesystem > types being detected as "non-local" and that being assumed to be slow, and > thumbnails not being shown for slow locations. > > I think think we need much more discussion here; someone just needs to sit > down and fix it. Trying to solve a dilemma in KDE (whereas "Plasma Vaults" are unique to KDE) actually introduced more issues for KDE users who *don't* even use this particular feature of "Plasma Vaults". This is a wide-sweep that is causing headaches for LUKS users, with no means of bypassing it. There's no option, no toggle. Hence, why I think the toggle option is the best short-term (and possibly long-term) approach. No one will be forced into one way or the other, and this is not a minor issue. This directly involves security and performance. *Notable* performance impacts. --- As for Plasma Vaults, specifically? Sure, cache the thumbnails directly into the vault itself. Any user who goes out of there way to specifically use Plasma Vaults understands its benefits and implications. However, users of LUKS, SMB, and NFS were caught in the "crossfire" as uninvolved bystanders, and now we're hoping to have our thumbnails cache once again in $HOME/.cache/thumbnails/ (Many reasons listed above in and the other bug report.) -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 411919] Store thumbnails for files inside an encfs or cryFS encrypted container somewhere inside the encrypted container itself, not ~/.cache/thumbnails, or generate them but don't
https://bugs.kde.org/show_bug.cgi?id=411919 --- Comment #30 from flan_suse --- (In reply to flan_suse from comment #29) > (In reply to Nate Graham from comment #28) > This affects user of LUKS (internal and external drives), as well as SMB and > NFS shares. No Plasma Vaults involved, and yet thumbnails are not being > cached inside $HOME/.cache/thumbnails To clarify: Thumbnails are not being cached inside $HOME/.cache/thumbnails if the files live on an external or internal LUKS partition. Yet, thumbnails will be saved in the cache if the files are accessed via an SMB or NFS share (even though they are encrypted on the server itself.) That's the reason I made the other bug report. There are no Plasma Vaults involved, whatsoever. -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 411919] Store thumbnails for files inside an encfs or cryFS encrypted container somewhere inside the encrypted container itself, not ~/.cache/thumbnails, or generate them but don't
https://bugs.kde.org/show_bug.cgi?id=411919 --- Comment #29 from flan_suse --- (In reply to Nate Graham from comment #28) > Choice is good, but it's even more important that we solve the common use > cases by default. I don't object, as long as we make sure that people get > their thumbnails in Plasma vaults shown again without having to configure > anything. If this is about Plasma Vaults, then how come it inadvertently bled into non-KDE storage? This affects user of LUKS (internal and external drives), as well as SMB and NFS shares. No Plasma Vaults involved, and yet thumbnails are not being cached inside $HOME/.cache/thumbnails -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 411919] Store thumbnails for files inside an encfs or cryFS encrypted container somewhere inside the encrypted container itself, not ~/.cache/thumbnails, or generate them but don't
https://bugs.kde.org/show_bug.cgi?id=411919 --- Comment #27 from flan_suse --- (In reply to Marcin Gurtowski from comment #26) > > 2) The user's $HOME is where we expect cache to be consolidated, and it's > > the main "driver" of daily work. I'd assume most users that utilize > > encrypted volumes use them nearly exclusively on their *own* system, rather > > than on someone else's system. It can complicate things if KDE is an outlier > > in that it caches thumbnails on the folder/volume itself (where the media > > resides), while other desktop environments continue to use $HOME/.cache > > consistently. > > If someone uses both unencrypted $HOME and some encrypted devices, it > implies they don't care as much about data from $HOME being leaked as they > do about from encrypted media. Catching data from encrypted drive gives > access to data that shouldn't be given. But that once again stresses the importance of user-choice. If KDE *hard-locks* a user to one method or the other, based on the encryption (or lack thereof) of their $HOME, then the user is stuck with the developer's decisions and has to either (1) "live with it", or (2) find a hacky workaround, or (3) file bug reports and wait for the changes to be reverted/fixed upstream. Some user's *without* encrypted $HOME may prefer performance over spillover prevention. While some might not even care. While yet some still might want zero spillover. Guess what solves all of the above? An option that can be toggled. ;) As for users *with* encrypted $HOME? Providing the same toggles does no harm, and it still gives them a choice if they so desire. "Oh, but what about network shares and NAS servers?" Since KDE is unaware of whether or not the files are encrypted on the server, there should be no fancy workarounds or guessing. Once again, an option that can be toggled resolves this issue. No one needs to ask "How can we determine if the files are encrypted on the server? Maybe we should assume they are or are not?" A simple toggle solves this. No one is hard-locked into anything. As for the "default" setting? Err on the side of caution. Have the toggles default to *DISABLED*, and let the user decide if they want to enable them. No need to deviate from the other desktop environments and OSes by writing thumbnails to external media and network shares. For the record, I would *NOT* want KDE to store thumbnails on my external drives and *DEFINITELY NOT* try to store them on my network shares. If KDE tries to go the route of "We'll just save thumbnails on the filesystem from where the images/videos reside", it can really open up a can of worms down the line... I listed out *four* independent issues of concern if pursuing this approach. (I even thought of *more* reasons off the top of my head just now.) > I'll try to look into the problem and fix previous solution (create > thumbnails, but don't save them), but if you want to add extra options to > this, is sounds fine to me. I truly, truly believe the two toggles mentioned above would resolve nearly all user scenarios. -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 411919] Store thumbnails for files inside an encfs or cryFS encrypted container somewhere inside the encrypted container itself, not ~/.cache/thumbnails, or generate them but don't
https://bugs.kde.org/show_bug.cgi?id=411919
--- Comment #25 from flan_suse ---
(In reply to Nate Graham from comment #22)
> Flan, Would you be able to submit a merge request to implement your idea?
How and where do I submit a merge request? I'm just an end-user that believes
in practicality and usability. :) I'll do it, just need to know the proper
method.
--
> Caching thumbnails in $HOME when $HOME is encrypted is reasonable.
This makes a lot of sense, but see below where I will try to break down this
"problem". This is not so much a technical issue (though it requires a
technical solution in the future), but rather this is a practical issue, with
some psychological and use-case elements involved.
--
>However I'm still
> in favor of one of the original ideas which is to cache the thumbnails
> inside the encrypted volume itself. I think that solves all potential
> problems, if it's technically feasible.
This might not be ideal, and I would argue against it, for four reasons:
1) The user's $HOME is almost always going to be on the faster media (SSD,
NVMe, Optane, etc), whereas an encrypted volume is commonly on a slower media
(secondary HDD, external USB drive, USB stick, etc).
2) The user's $HOME is where we expect cache to be consolidated, and it's the
main "driver" of daily work. I'd assume most users that utilize encrypted
volumes use them nearly exclusively on their *own* system, rather than on
someone else's system. It can complicate things if KDE is an outlier in that it
caches thumbnails on the folder/volume itself (where the media resides), while
other desktop environments continue to use $HOME/.cache consistently.
3) This can be bad for those who use NAS servers or network shares. Not only is
KDE *unaware* of whether or not the photos/videos live on an encrypted volume
("Is the SMB / NFS share residing on an encrypted location on the server? No
idea!"), but if it were to assume it does, it's now storing cache'd thumbnails
on a network share? We're now losing performance and I advise against trying to
write on a network share or NAS server "under-the-hood" like that, especially
for media archives, etc.
4) It's expected that $HOME/.cache will always have read-write access for the
user account. However, offloading the caching of thumbnails to an *external
location* gets even more complicated if it is: write-protected; or mounted
read-only; or does not have write permissions; etc.
I'm not trying to poo-poo any idea nor come off as a pessimist. I'm just trying
to cut off user experience pitfalls *ahead of time*. If it sounds like the
above reasons make it seem like there are too many complexities involved,
that's because there *are*. Once again, pursuing such a workaround might risk
more problems than solutions.
--
Here is the original problem: "As a user, I want to safeguard against sensitive
photos/videos dumping their thumbnails from an encrypted storage onto a
non-encrypted storage."
This should not be confused with a friend or adversary in possession of the
device. Once it is in their hands, none of this stuff about caching thumbnails
matters.
This should not be confused with using the encrypted device on *someone else's*
computer. Why? Because the friend/stranger could be using *any* OS, distro, or
desktop environment on their own computer.
This really only applies to the *owner's computer* running KDE; in which they
do not want "spillover" of encrypted data onto a non-encrypted volume.
There are three common places where encrypted photos/videos reside that are
under the owner's control: secondary volumes; external drives; network shares
(encrypted on the server).
KDE is only aware of the encryption state of secondary volumes and external
drives. KDE is *not* aware of the encryption state on network shares (on a
server / NAS).
Therefor, to treat this as "How should KDE handle thumbnail caching of
encrypted volumes?" falls short of its *own goal*.
It should be split into *two* approaches:
1) "How should KDE handle thumbnail caching of encrypted volumes?"
2) "How should KDE handle thumbnail caching of network shares / remote
locations?"
In my opinion, you can simplify this by yielding control to the end-user with
*two different toggles*. Plain and simple:
* Cache thumbnail previews for multimedia from encrypted volumes? Yes/No
* Cache thumbnail previews for multimedia from network shares? Yes/No
Simple as that.
Here is the expected behavior, which is very clean and unambiguous, and let's
the user choose:
Cache thumbnail previews for multimedia from encrypted volumes? YES!
- Regardless of the external storage or secondary volume using encryption,
thumbnails will be cache'd to $HOME/.cache/thumbnails
Cache thumbnail previews for multimedia from encrypted volumes? NO!
- Previews will be generated for multimedia from external storage o
[kio-extras] [Bug 411919] Store thumbnails for files inside an encfs or cryFS encrypted container somewhere inside the encrypted container itself, not ~/.cache/thumbnails, or generate them but don't
https://bugs.kde.org/show_bug.cgi?id=411919 flan_suse changed: What|Removed |Added CC||windows2li...@zoho.com --- Comment #20 from flan_suse --- This "fix" is creating more problems than solutions. Please see my bug report for a more sensible way to approach this. As others have confirmed (and as it is clearly evident), this was NOT the right approach. https://bugs.kde.org/show_bug.cgi?id=443806 It's getting really bad. Outright disabling the caching of thumbnails from an encrypted container makes no sense. I lay out the reasons why in my bug report. I highly encourage others to read it and vote on the issue. There are better ways to approach this than the nuclear option. -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 443806] Dolphin should allow option to cache thumbnails for separate encrypted devices / locations (KDialog too?)
https://bugs.kde.org/show_bug.cgi?id=443806 --- Comment #12 from flan_suse --- Is this bug report just not reaching the right people? Should I change the component or CC a developer in particular? -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 260266] Allow assigning keyboard shortcuts to service menu actions
https://bugs.kde.org/show_bug.cgi?id=260266 flan_suse changed: What|Removed |Added CC||windows2li...@zoho.com --- Comment #12 from flan_suse --- And over 12 years later... -- You are receiving this mail because: You are watching all bug changes.
[xdg-desktop-portal-kde] [Bug 428373] "Examining (Failed)" notifications some times when trying to save in folders with many files.
https://bugs.kde.org/show_bug.cgi?id=428373 --- Comment #3 from flan_suse --- This is still an issue with folders containing many files, even today with KDialog (i.e, saving a file or downloading an image from a website). Even today, with updated specs: Operating System: Manjaro Linux KDE Plasma Version: 5.24.3 KDE Frameworks Version: 5.91.0 Qt Version: 5.15.3 Kernel Version: 5.15.28-1-MANJARO (64-bit) Graphics Platform: X11 Processors: 8 × 11th Gen Intel® Core™ i7-1165G7 @ 2.80GHz Memory: 15.4 GiB of RAM Graphics Processor: Mesa Intel® Xe Graphics -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kservice] [Bug 442721] kf.service.services: KApplicationTrader: mimeType "x-scheme-handler/file" not found
https://bugs.kde.org/show_bug.cgi?id=442721 --- Comment #11 from flan_suse --- (In reply to pridoorok from comment #10) > a workaround has been found - you need to: Wow! That worked perfectly! Thank you so much. :) I wonder why this is even needed for KDE? Why doesn't it "just work" as expected by default? -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 443806] Dolphin should allow option to cache thumbnails for separate encrypted devices / locations (KDialog too?)
https://bugs.kde.org/show_bug.cgi?id=443806 --- Comment #9 from flan_suse --- (In reply to Alexander Wipperfürth from comment #8) > I can confirm this is the same problem I encounter every day with the same > setup, also having luks encrypted drives connected, also my linux drive is > fully encrypted and I have to agree it doesn't make sense to me either, > please can this be considered Imagine having folders with lots of WEBP images. It's bad enough with JPEG and PNG, having to re-generate the thumbnails every single time, but it REALLY cooks the CPU when it's WEBP images. I laid out the case. I even created a mock screenshot of what such an option could look like in Dolphin. (see the attachment) Not sure what else we can do at this point. Out of desperation, I'm trying to figure out how to forcefully cache thumbnails in a folder manually, if I knew what command to issue. :( -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 450980] KDE 5.24 breaks suspend to RAM (really badly); reverting to 5.23 resolves it
https://bugs.kde.org/show_bug.cgi?id=450980 flan_suse changed: What|Removed |Added Resolution|WAITINGFORINFO |NOT A BUG Status|NEEDSINFO |RESOLVED --- Comment #9 from flan_suse --- Upstream upower and kernel, after all. (Fixed in kernel 5.17) -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 450980] KDE 5.24 breaks suspend to RAM (really badly); reverting to 5.23 resolves it
https://bugs.kde.org/show_bug.cgi?id=450980 --- Comment #8 from flan_suse --- This might be upower after all. I'll keep on eye on things, and see what happens with upstream upower. (However, I did try with an earlier version of upower, and the same issue persisted.) https://bbs.archlinux.org/viewtopic.php?id=274292 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 353975] Black screen on second display (no wallpaper, can't get a context menu on right-click)
https://bugs.kde.org/show_bug.cgi?id=353975 flan_suse changed: What|Removed |Added CC||windows2li...@zoho.com --- Comment #125 from flan_suse --- Here's what "fixed" the issue for me, at least for now: * Log out of KDE * Switch to TTY2 * sudo systemctl stop sddm * rm -rfv ~/.local/share/kscreen * kbuildsycoca5 --noincremental * sudo systemctl restart sddm * Log back in and redo configuration under Settings -> Display and Monitor Something's going on with systems that were installed with earlier versions of KDE (e.g, 5.23 or previous), and then updated their software to KDE 5.24, in which current configurations (such as those saved under the folder ~/.local/share/kscreen) causes issues with multiple displays / laptop lid actions. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 450980] KDE 5.24 breaks suspend to RAM (really badly); reverting to 5.23 resolves it
https://bugs.kde.org/show_bug.cgi?id=450980 --- Comment #7 from flan_suse --- (In reply to flan_suse from comment #6) > Notice there's a 3-minute gap in the log? To emphasize this point, for all intents and purposes the system *did* in fact "suspend". No activity logged for 3 minutes, until I forced it to "wake up" again. During this 3-minute period, using the USB mouse and keyboard would *NOT* wake up the laptop, even though it's *supposed* to (as it does in KDE 5.23) During this 3-minute period (of no logged activity, remember), the laptop's fans are completely off. Yet the CPU quickly gets hotter and hotter! (I can feel it almost hurt my finger when I touch the surface.) None of the above issue happens if with KDE 5.24: 1) I log out 2) I switch to TTY2 3) I stop the SDDM service 4) I issue "systemctl suspend" Then it will behave *properly*, as if I was using KDE 5.23. This is why I think it's related to KDE (and notably, the transition from 5.23 -> 5.24). I believe it has something to do with local user settings (configured during 5.23 and earlier), which cause a conflict with KDE 5.24's changes in handling external displays, settings, and power management. Reverting back to KDE 5.23 (regardless of kernel), always, 100%, resolves the issue. -- You are receiving this mail because: You are watching all bug changes.
[Powerdevil] [Bug 438716] Lid close leads to suspend even when external monitor is attached
https://bugs.kde.org/show_bug.cgi?id=438716 flan_suse changed: What|Removed |Added CC||windows2li...@zoho.com --- Comment #25 from flan_suse --- (In reply to ita84 from comment #22) > Just updated to Plasma 5.24 and the issue has been fixed for me: now closing > the laptop lid in a Wayland session doesn't trigger suspend anymore, and > selecting Shutdown shuts the laptop down correctly instead of suspending it. > Thanks! (In reply to Matej Mrenica from comment #23) > Same here. (In reply to Nate Graham from comment #24) > Oh good! Is there any chance that 5.24 "fixing" this issue caused a new issue? Here's why I mention that: https://bugs.kde.org/show_bug.cgi?id=450980 -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 450980] KDE 5.24 breaks suspend to RAM (really badly); reverting to 5.23 resolves it
https://bugs.kde.org/show_bug.cgi?id=450980 --- Comment #6 from flan_suse --- Created attachment 147231 --> https://bugs.kde.org/attachment.cgi?id=147231=edit journalctl when suspending with KDE 5.24 Notice there's a 3-minute gap in the log? That's how long I waited while the system was "suspended". I couldn't wake it up until I used the laptop's keyboard to "wake up" the system. (USB mouse and keyboard did not work.) Yes, during that 3-minute period, the laptop got REALLY HOT, since the fans stopped, but apparently the CPU was still cooking. This doesn't happen with KDE 5.23 (doesn't matter which kernel, nor which version of upower.) -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 450980] KDE 5.24 breaks suspend to RAM (really badly); reverting to 5.23 resolves it
https://bugs.kde.org/show_bug.cgi?id=450980 --- Comment #5 from flan_suse --- Keep in mind when this bug occurs, my fans STOP. Monitor shut off (no signal). However, for some reason my CPU is heating up rapidly, since it's somehow still running, but without the cooling of the fans. I can attach a journalctl as well, but it appears to believe the suspend was successful. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 450980] KDE 5.24 breaks suspend to RAM (really badly); reverting to 5.23 resolves it
https://bugs.kde.org/show_bug.cgi?id=450980 --- Comment #4 from flan_suse --- Created attachment 147217 --> https://bugs.kde.org/attachment.cgi?id=147217=edit Output of "systemd-inhibit --list" when KDE and SDDM are *NOT* running. Output of "systemd-inhibit --list" when KDE and SDDM are *NOT* running. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 450980] KDE 5.24 breaks suspend to RAM (really badly); reverting to 5.23 resolves it
https://bugs.kde.org/show_bug.cgi?id=450980 --- Comment #3 from flan_suse --- Created attachment 147216 --> https://bugs.kde.org/attachment.cgi?id=147216=edit Output of "systemd-inhibit --list" when KDE and SDDM are running. Output of "systemd-inhibit --list" when KDE and SDDM are running. -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 450980] KDE 5.24 breaks suspend to RAM (really badly); reverting to 5.23 resolves it
https://bugs.kde.org/show_bug.cgi?id=450980
--- Comment #2 from flan_suse ---
(In reply to David Edmundson from comment #1)
> Please test with "systemctl suspend"
>
> If that behaves the same, the issue isn't our side.
>
> systemd-inhibit --list might also be useful
It gets more interesting.
* While I am logged into a KDE session, even using "systemctl suspend" causes
the same issue.
AND...
* If I logout of KDE (leaving only the SDDM login screen), then switch to TTY2
and issue "systemctl suspend", it's still affected by the same issue
HOWEVER...
* If I log out of KDE and stop the SDDM display manager ("systemctl stop
sddm"), then switch to TTY2 and issue "systemctl suspend", the issue no longer
exists: CPU is not running hot, and using my wireless keyboard or mouse
properly wakes up from suspend
So *without* KDE nor SSDM running, it behaves correctly again (regardless of
which kernel I'm using). If KDE or SDDM is running, then even using "systemctl
suspend" reproduces the same issue. Only when I stop SDDM and suspend, it will
work correctly
I will attach the outputs from "systemd-inhibit --list".
The first text file is the output when logged into KDE.
The second text file is the output when I stop SDDM.
(I must also note that when I force the laptop to wake up when the bug is
occurring, my wallpaper doesn't "stick" anymore. If I switch workspaces, the
wallpaper will flicker and disappear.)
--
You are receiving this mail because:
You are watching all bug changes.
[kdemultimedia] [Bug 444064] ffmpegthumbs causes Dolphin to "hang" when viewing properties / details of video file on network share (CIFS/SMB)
https://bugs.kde.org/show_bug.cgi?id=444064 flan_suse changed: What|Removed |Added Component|ffmpegthumbs|general -- You are receiving this mail because: You are watching all bug changes.
[plasmashell] [Bug 450980] KDE 5.24 breaks suspend to RAM (really badly); reverting to 5.23 resolves it
https://bugs.kde.org/show_bug.cgi?id=450980 flan_suse changed: What|Removed |Added Assignee|unassigned-b...@kde.org |plasma-b...@kde.org Component|general |general Product|kde |plasmashell Version|unspecified |5.24.2 Target Milestone|--- |1.0 CC||k...@davidedmundson.co.uk -- You are receiving this mail because: You are watching all bug changes.
[kde] [Bug 450980] New: KDE 5.24 breaks suspend to RAM (really badly); reverting to 5.23 resolves it
https://bugs.kde.org/show_bug.cgi?id=450980 Bug ID: 450980 Summary: KDE 5.24 breaks suspend to RAM (really badly); reverting to 5.23 resolves it Product: kde Version: unspecified Platform: Manjaro OS: Linux Status: REPORTED Severity: major Priority: NOR Component: general Assignee: unassigned-b...@kde.org Reporter: windows2li...@zoho.com Target Milestone: --- Starting with KDE 5.24, when I tell my laptop to suspend to RAM, the following occurs: * It "appears" to suspend. (Fans stop, external monitor turns off) * But the CPU is COOKING at maximum heat, without any running fans! * Pressing keys on my wireless keyboard or mouse does NOT wake up it (as it always has before) * I need to "wake up" the laptop by pressing on the actual laptop keyboard * When it "wakes up", the entire laptop feels like it's COOKING. Apparently, the CPU was still running, but no fans were running to keep it cooled. With 5.23 and earlier: * The laptop correctly suspends to RAM * Everything stays cool (CPU is not running) * Pressing a key on my wireless keyboard or mouse wakes up the laptop * No issues at all, laptop feels cool I have an external monitor attached to the laptop, which works properly. I had to revert back to KDE 5.23, since this bug was literally FRYING my laptop to ungodly levels of heat. (Had I not noticed earlier and reproduced it consistently, I could have risked damaging my components.) Was there a change done to the "power" side of things from 5.23 -> 5.24? To reiterate: It's specifically KDE 5.24. Trying a different kernel makes no difference. SYSTEM INFO: Operating System: Manjaro Linux KDE Plasma Version: 5.24.2 KDE Frameworks Version: 5.91.0 Qt Version: 5.15.2 Kernel Version: 5.16.7-1-MANJARO (64-bit) Graphics Platform: X11 Processors: 8 × 11th Gen Intel® Core™ i7-1165G7 @ 2.80GHz Memory: 15.4 GiB of RAM Graphics Processor: Mesa Intel® Xe Graphics I have a desktop PC with the same software, however, it uses a discrete GPU (Nvidia), which does not have this issue with KDE 5.24. What other information would be useful? Thank you. -- You are receiving this mail because: You are watching all bug changes.
[kdemultimedia] [Bug 444064] ffmpegthumbs causes Dolphin to "hang" when viewing properties / details of video file on network share (CIFS/SMB)
https://bugs.kde.org/show_bug.cgi?id=444064 flan_suse changed: What|Removed |Added Ever confirmed|0 |1 Status|REPORTED|CONFIRMED -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 448302] Dolphin file previews are being regenerated on non OS drive everytime directory is being reopened
https://bugs.kde.org/show_bug.cgi?id=448302 flan_suse changed: What|Removed |Added CC||windows2li...@zoho.com --- Comment #1 from flan_suse --- Hi, Alexander Wipperfürth. Please see my bug report (linked below). Can you please vote for it and comment on it? This was a decision made by the KDE developers, which causes more problems than solutions. https://bugs.kde.org/show_bug.cgi?id=443806 -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 443806] Dolphin should allow option to cache thumbnails for separate encrypted devices / locations (KDialog too?)
https://bugs.kde.org/show_bug.cgi?id=443806 flan_suse changed: What|Removed |Added Version|21.12.0 |21.12.2 --- Comment #7 from flan_suse --- Pretty please, can this be considered? KDE is slamming my CPU every time I browse a directory with many images, as it has to re-generate the thumbnails Every. Single. Time. And they are never cached. See my attachment of how this option could easily be toggled on or off. This decision to outright disable caching of thumbnails (without a means to re-enable them) from an encrypted source, causes more issues than solutions. Please, I humbly beg of you. The current implementation makes NO SENSE. If the user's home folder is encrypted, it makes no sense. If the user is view images on a network share, it makes no sense. If the user prefers cache'd thumbnails, speed, and cooler CPU's, and doesn't care it's from an encrypted source, it makes no sense. Please, I'm begging. I don't understand why this change was abruptly made with Dolphin / KIO without considering the most common real-world scenarios. -- You are receiving this mail because: You are watching all bug changes.
[kdemultimedia] [Bug 444064] ffmpegthumbs causes Dolphin to "hang" when viewing properties / details of video file on network share (CIFS/SMB)
https://bugs.kde.org/show_bug.cgi?id=444064 flan_suse changed: What|Removed |Added Version|unspecified |21.12.2 -- You are receiving this mail because: You are watching all bug changes.
[kdemultimedia] [Bug 444064] ffmpegthumbs causes Dolphin to "hang" when viewing properties / details of video file on network share (CIFS/SMB)
https://bugs.kde.org/show_bug.cgi?id=444064 --- Comment #3 from flan_suse --- UPDATE: Removing the package "ffmpegthumbs" fixes the issue, but I don't consider this "resolved", since it means I lose out on video thumbnail previews in Dolphin. This is why I believe the underlying cause has to do with ffmpegthumbs + network folder. -- You are receiving this mail because: You are watching all bug changes.
[kdemultimedia] [Bug 444064] ffmpegthumbs causes Dolphin to "hang" when viewing properties / details of video file on network share (CIFS/SMB)
https://bugs.kde.org/show_bug.cgi?id=444064 --- Comment #2 from flan_suse --- This continues to happen with an updated system: Operating System: Manjaro Linux KDE Plasma Version: 5.23.5 KDE Frameworks Version: 5.90.0 Qt Version: 5.15.2 Kernel Version: 5.16.5-1-MANJARO (64-bit) Graphics Platform: X11 Processors: 8 × 11th Gen Intel® Core™ i7-1165G7 @ 2.80GHz Memory: 15.4 GiB of RAM Graphics Processor: Mesa Intel® Xe Graphics The issue is as described in the bug report. :( -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 443806] Dolphin should allow option to cache thumbnails for separate encrypted devices / locations (KDialog too?)
https://bugs.kde.org/show_bug.cgi?id=443806 flan_suse changed: What|Removed |Added Version|21.12.0 |21.12.1 -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 443806] Dolphin should allow option to cache thumbnails for separate encrypted devices / locations (KDialog too?)
https://bugs.kde.org/show_bug.cgi?id=443806
--- Comment #6 from flan_suse ---
Created attachment 146051
--> https://bugs.kde.org/attachment.cgi?id=146051=edit
Toggle to enable/disable thumbnail caching of media that lives on encrypted
source
Is there anyone looking into this?
Folders with many image files can really make the CPU crank up the heat,
especially when they are WEBP images. And this happens *every time* I open the
folder, since nothing is ever cached. :'(
My $HOME is encrypted, as are many other users' setups. Which means preventing
thumbnails from being cached only slows down the workflow without any added
security benefits.
A simple "bypass" option or toggle would suffice, that allows thumbnail caching
from any folder: remote, encrypted, plain, doesn't matter
The option could look something like so:
Prevent thumbnail caching of media from encrypted sources[X]
It can be enabled by default, but at least the user has an option to completely
disable ("uncheck") this feature. I implore the devs to seriously consider
this. While the original intentions were good, it is causes more issues than
benefits for users who either have encrypted $HOME and/or don't want to
sacrifice performance for security (not even a security issue for them.) What's
more, it's not even implemented correctly, since as I explain above, network
shares (SMB, NFS) in which the media is stored encrypted on a server, KDE
treats it like it's non-encrypted and will cache the thumbnails *anyways*.
Please see my attachment of a mock idea of how this could look in the GUI.
--
You are receiving this mail because:
You are watching all bug changes.
[dolphin] [Bug 442774] Dolphin crashed after click on stop button of notification indicating the progress of compression to 7zip archive
https://bugs.kde.org/show_bug.cgi?id=442774 flan_suse changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #13 from flan_suse --- (In reply to Lyubomir from comment #12) > What I was doing when the application crashed: > I clicked stop button while compressing to .7z Even without clicking the "Stop" button in the notification, one of a few things might happen: 1) Dolphin crashes immediately, and no archive was ever created Or... 2) Dolphin crashes at the end of the compression task, but the archive was created (and passes verification) Or... 3) The notification hangs indefinitely, until I click "Stop" in which it will then hang for a bit and then segfault None of the above ever happens if I open Ark first, and then create a new archive. It only happens if you create a new archive from Dolphin's context menu. --- This happens when I go to Right-click -> Compress -> Compress to -> select 7z --- Distro: Manjaro Linux KDE Plasma: 5.23.4 KDE Frameworks: 5.88.0 Qt: 5.15.2 Kernel: 5.15.7 Dolphin: 21.12.0 Ark: 21.12.0 p7zip: 17.04 -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 443806] Dolphin should allow option to cache thumbnails for separate encrypted devices / locations (KDialog too?)
https://bugs.kde.org/show_bug.cgi?id=443806 flan_suse changed: What|Removed |Added Status|REPORTED|CONFIRMED Ever confirmed|0 |1 -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 443806] Dolphin should allow option to cache thumbnails for separate encrypted devices / locations (KDialog too?)
https://bugs.kde.org/show_bug.cgi?id=443806 --- Comment #5 from flan_suse --- Can't this be implemented in one of two simple ways? 1) Simply give the user the option to "Allow caching thumbnails from encrypted and remote locations" Enabling this option would disable/ignore the "safety check" on whether or not caching thumbnails is allowed. Or... 2) If the user's $HOME is located in an encrypted location (such as LUKS), then the "safety check" should be disabled/ignored. --- As it currently stands, KDE currently has implemented a "halfway" safety measure, since it *does not consider*... * ...the user's preference * ...if the user's $HOME is encrypted anyways * ...if the remote network share (e.g., SMB, NFS) is encrypted on the server itself -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 443806] Dolphin should allow option to cache thumbnails for separate encrypted devices / locations (KDialog too?)
https://bugs.kde.org/show_bug.cgi?id=443806 flan_suse changed: What|Removed |Added Version|21.08.1 |21.12.0 -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 446926] Dolphin crashed after click on stop button of notification indicating the progress of compression to zip archive
https://bugs.kde.org/show_bug.cgi?id=446926 --- Comment #2 from flan_suse --- (In reply to Tony from comment #1) > *** Bug 446927 has been marked as a duplicate of this bug. *** For what it's worth, I experience the same thing with Ark/Dolphin 21.12, but with 7z (not just zip). -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 446926] Dolphin crashed after click on stop button of notification indicating the progress of compression to zip archive
https://bugs.kde.org/show_bug.cgi?id=446926 flan_suse changed: What|Removed |Added CC||windows2li...@zoho.com -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 442774] Dolphin crashed after click on stop button of notification indicating the progress of compression to 7zip archive
https://bugs.kde.org/show_bug.cgi?id=442774 --- Comment #10 from flan_suse --- Can someone confirm this was fixed? I'm still experiencing it on 21.12, on two different computers. -- 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 #67 from flan_suse --- (In reply to Steve Vialle from comment #66) > 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? Fully agree with this opinion. It worked smoothly prior to this, and was non-complex, and straight forwards. It's like one step forwards and two steps back, for something that worked fine without "improvement". I might have to file a *separate* bug report, for even in 21.12 there still exists a bug with the notification tray that freezes up the entire session when trying to compress file via Dolphin's context menu. :( It was interrelated with this bug, from what I recall. It's unclear if the process crashed or if the compression was successful. -- You are receiving this mail because: You are watching all bug changes.
[Smb4k] [Bug 442187] Smb4K 3.1.0 still has frustrating, old usability glitches and bugs (explained in description). Kills usability.
https://bugs.kde.org/show_bug.cgi?id=442187 --- Comment #20 from flan_suse --- (In reply to Alexander Reinholdt from comment #19) Could it be due to something upstream (Qt / KDE)? However, I have never noticed this behaviour anywhere else except for Smb4K, so it might not be upstream. -- You are receiving this mail because: You are watching all bug changes.
[Smb4k] [Bug 442187] Smb4K 3.1.0 still has frustrating, old usability glitches and bugs (explained in description). Kills usability.
https://bugs.kde.org/show_bug.cgi?id=442187 --- Comment #18 from flan_suse --- (In reply to Alexander Reinholdt from comment #17) > Is that also your experience? Not always. I'm trying to find a clear pattern, but it's more random than I first assumed. :( It can happen when the Main Window is minimized (or hidden to tray), but sometimes it will not happen. At first I thought it was unique to non-bookmarked shares, but it can happen to any share. I'm going to try some more tests on my end. If you discover a pattern or hint, I can try to re-produce it on my end as well. (I'm using two different PCs, one with Intel Iris Xe GPU and the other with Nvidia GPU, and Smb4K behaves the same way on both computers.) -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 443806] Dolphin should allow option to cache thumbnails for separate encrypted devices / locations (KDialog too?)
https://bugs.kde.org/show_bug.cgi?id=443806 --- Comment #4 from flan_suse --- (In reply to Lemuel Simon from comment #3) > If you don't mind me asking, what is your partition scheme? Gladly. I'll keep it simple and laid out, so as to make it easier to follow and compare. Just FYI, I do not use LVM whatsoever. The following sources have multimedia (picture and video) that support thumbnail previews. SRC1, Single local partition (entire system, /boot, /, and /home) | encrypted (LUKS) SRC2, Single local partition (external USB) | encrypted (LUKS) SRC3, Single local partition (external USB) | plain SRC4, Network share (CIFS) | encrypted (ZFS) --- When using Dolphin to browse images/videos in SRC1, SRC3, and SRC4, thumbnails are generated and CACHED under ~/.cache/thumbnails With subsequent re-visits of these folders, the thumbnails are QUICKLY displayed (because they're loaded from cache) Examples including ~/Pictures, ~/Videos, a CIFS share mounted via "cifs" from a server, a USB stick with pictures, et al. Because /home resides within an encrypted partition, there is no risk of "spillover" of sensitive thumbnails jumping from an encrypted source to a plain (non-encrypted) ~/.cache However, if my /home actually lived in a plain (non-encrypted) partition, SRC4 is an example of "spillover" of sensitive thumbnails being cached to a non-encrypted ~/.cache (yikes!), whereas the original photos are stored encrypted (on the server). --- When using Dolphin to browse images/videos in SRC2, thumbnails are NOT cached under ~/.cache/thumbnails With subsequent re-visits of these folders, the thumbnails must be re-generated all over again... every... single... time... --- This bug report (feature request) is to give users, like you and me, an option to toggle this behavior. Keep the default as it is, but give us the option to allow thumbnail caching ALWAYS (regardless if the source multimedia lives in an encrypted space.) * It would be much faster (rather than always re-generating the thumbnails from scratch) * Very important when dealing with numerous files in large folders * It's not necessary to protect from "spillover" if your /home lives in its own encrypted space anyways (such as /home in LUKS) * It's not even implemented properly anyways, as seen with the example of SRC4 above -- You are receiving this mail because: You are watching all bug changes.
[kdemultimedia] [Bug 444064] ffmpegthumbs causes Dolphin to "hang" when viewing properties / details of video file on network share (CIFS/SMB)
https://bugs.kde.org/show_bug.cgi?id=444064 --- Comment #1 from flan_suse --- Upon further experimenting, it appears the problem is mostly consistent with my Intel Iris Xe GPU (specs in first post.) With my other computer using proprietary Nvidia drivers (GeForce 1650) it doesn't seem to have this issue. --- I notice that I cannot even play the mini video preview in Dolphin with my Intel GPU system (even on local files.) However, I can play them just fine with my Nvidia GPU, even on network shares. (There's a small 1-2 second delay, but it works.) --- I mention this because it might be inter-related with the GPU / ffmpegthumbs / Dolphin / CIFS. -- 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 #21 from flan_suse --- CORRECTION: I meant to write "Confirmed on 21.08.1 for THIS bug, and on 21.08.2 on the OTHER possibly related bug." -- 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 flan_suse changed: What|Removed |Added CC||windows2li...@zoho.com --- Comment #20 from flan_suse --- Confirmed on 21.08.2 Might be related to this issue: https://forum.manjaro.org/t/ark-7zip-and-zip-compression-not-working-properly-and-crashing-dolphin/87123/39?u=winnie And this bug: https://bugs.kde.org/show_bug.cgi?id=442774 --- With Dolphin at 21.08.2 and Frameworks at 5.87.0, but with Ark at 21.08.1, it reveals this bug. If Ark is at 21.08.2 with the above combination, it reveals a different bug (ID: 442774), URL pasted above. -- You are receiving this mail because: You are watching all bug changes.
[Smb4k] [Bug 442187] Smb4K 3.1.0 still has frustrating, old usability glitches and bugs (explained in description). Kills usability.
https://bugs.kde.org/show_bug.cgi?id=442187 --- Comment #15 from flan_suse --- Created attachment 142640 --> https://bugs.kde.org/attachment.cgi?id=142640=edit greyed-out-mounted-shares-tray-icon >These glitches involves "Unmount All" and "Unmount" being greyed out in the >tray context menu, yet working normally from the main window. Since this bug is less predictable compared to the others, it's tricky to catch in real-time. However, this is what it looks like. (I will also attach the screenshot to the bug report.) --- The test share is not in my Bookmarks. I manually go to the Tray -> right-click -> Open Mount Dialog It mounts correctly. Browseable with Dolphin. Works from the Smb4K Main Window. However, you will notice "Mounted Shares" from the Tray icon is "greyed out" as if nothing is currently mounted. This screenshot was taken with Smb4K version 3.1.1. -- You are receiving this mail because: You are watching all bug changes.
[kdemultimedia] [Bug 444064] New: ffmpegthumbs causes Dolphin to "hang" when viewing properties / details of video file on network share (CIFS/SMB)
https://bugs.kde.org/show_bug.cgi?id=444064
Bug ID: 444064
Summary: ffmpegthumbs causes Dolphin to "hang" when viewing
properties / details of video file on network share
(CIFS/SMB)
Product: kdemultimedia
Version: unspecified
Platform: Manjaro
OS: Linux
Status: REPORTED
Severity: crash
Priority: NOR
Component: ffmpegthumbs
Assignee: unassigned-b...@kde.org
Reporter: windows2li...@zoho.com
Target Milestone: ---
VERSION INFO:
ffmpegthumbs: 21.08.2
Operating System: Manjaro Linux
KDE Plasma Version: 5.22.5
KDE Frameworks Version: 5.87.0
Qt Version: 5.15.2
Kernel Version: 5.14.10-1-MANJARO (64-bit)
Graphics Platform: X11
Processors: 8 × 11th Gen Intel® Core™ i7-1165G7 @ 2.80GHz
Memory: 15.4 GiB of RAM
Graphics Processor: Mesa Intel Xe Graphics
---
All scenarios assume CIFS network share, SMB protocol version 3; mounted either
via manual mount, fstab, systemd unit, or Smb4K.
The following scenarios are *very likely* to make Dolphin "hang":
* Prerequisite: ffmpegthumbs is installed
* Prerequisite: Previews are enabled in Dolphin (video previews are enabled)
1. With Dolphin, browse to a CIFS network share
1a. Right-click a video file -> Properties
Result: Dolphin hangs for several seconds or more (unresponsive)
2. In Dolphin Browse to CIFS network share
2a. Enable the "Details" pane
2b. Click on a video file
Result: Dolphin hangs for several seconds or more (unresponsive)
---
The following scenarios will *NOT* make Dolphin hang:
3. Repeat any of the above, however, use a LOCAL folder (rather than a network
share)
4. Repeat any of the above, however, use a READ-ONLY mounted network share
("ro")
5. Repeat any of the above, however DISABLE "Video File" previews (or uninstall
ffmpegthumbs)
---
FURTHER NOTES:
This isn't 100% a consistent hang. Sometimes it will "just work", but I noticed
the majority of the time it hangs Dolphin.
Scenario #4 above is very peculiar. For some reason using the "ro" (read-only)
mount option on the CIFS network share alleviates the problem entirely!
In all the above scenarios, video thumbnails generate properly. The hang only
occurs when trying to view the file's properties (either via right-click ->
Properties, or by enabling the Details pane and clicking on the file.)
---
I am going to prepare a video capture to show exactly what happens.
Any more information needed? Let me know what would be most useful.
--
You are receiving this mail because:
You are watching all bug changes.
[dolphin] [Bug 442774] Dolphin crashed after click on stop button of notification indicating the progress of compression to 7zip archive
https://bugs.kde.org/show_bug.cgi?id=442774 flan_suse changed: What|Removed |Added Status|REPORTED|CONFIRMED Ever confirmed|0 |1 -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 442774] Dolphin crashed after click on stop button of notification indicating the progress of compression to 7zip archive
https://bugs.kde.org/show_bug.cgi?id=442774 flan_suse changed: What|Removed |Added CC||windows2li...@zoho.com --- Comment #1 from flan_suse --- Sounds exactly like this issue: https://forum.manjaro.org/t/ark-7zip-and-zip-compression-not-working-properly-and-crashing-dolphin/87123/19 -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 441123] Dolphin does not create, save thumbnails
https://bugs.kde.org/show_bug.cgi?id=441123 --- Comment #4 from flan_suse --- (In reply to flan_suse from comment #3) > Are you using encryption on the locations / subvolumes in question? > > > It seems like thumbnails in ~/.cache/thumbnails only get written when the > > thumbnailed data is on the same filesystem as the ~/.cache directory. > > This doesn't explain why I am able to cache thumbnails from remote > locations, such as CIFS (SMB) network shares. > > It might have something to do with the following bug reports, the second one > I filed recently to suggest the users be given an "option" to override this > default behaviour: > > https://bugs.kde.org/show_bug.cgi?id=411919 > > https://bugs.kde.org/show_bug.cgi?id=443806 Also to mention, non-encrypted USB drives also have their thumbnails cached: https://bugs.kde.org/show_bug.cgi?id=443806#c2 -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 443806] Dolphin should allow option to cache thumbnails for separate encrypted devices / locations (KDialog too?)
https://bugs.kde.org/show_bug.cgi?id=443806 --- Comment #2 from flan_suse --- For any users or developers reading this, here is a summarized version of how things stand now, as of version 21.08.1 default behaviour: * Local folder on same filesystem, no encryption Cached thumbnails? Yes! * Local folder on same filesystem, LUKS encryption Cached thumbnails? Yes! * External USB drive, no encryption Cached thumbnails? Yes! * Remote location (CIFS/SMB) Cached thumbnails? Yes! * External USB drive, LUKS encryption Cached thumbnails? NO! It is the very last example in which an option to override the default behaviour is important. -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 441123] Dolphin does not create, save thumbnails
https://bugs.kde.org/show_bug.cgi?id=441123 flan_suse changed: What|Removed |Added CC||windows2li...@zoho.com --- Comment #3 from flan_suse --- Are you using encryption on the locations / subvolumes in question? > It seems like thumbnails in ~/.cache/thumbnails only get written when the > thumbnailed data is on the same filesystem as the ~/.cache directory. This doesn't explain why I am able to cache thumbnails from remote locations, such as CIFS (SMB) network shares. It might have something to do with the following bug reports, the second one I filed recently to suggest the users be given an "option" to override this default behaviour: https://bugs.kde.org/show_bug.cgi?id=411919 https://bugs.kde.org/show_bug.cgi?id=443806 -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 443806] Dolphin should allow option to cache thumbnails for separate encrypted devices / locations (KDialog too?)
https://bugs.kde.org/show_bug.cgi?id=443806 --- Comment #1 from flan_suse --- For clarity, my examples use LUKS on external drives. I haven't yet tested with other encryption alternatives, but from what I've read, it's the same concept / rules with forgoing caching thumbnails in KDE. -- You are receiving this mail because: You are watching all bug changes.
[kio-extras] [Bug 443806] Dolphin should allow option to cache thumbnails for separate encrypted devices / locations (KDialog too?)
https://bugs.kde.org/show_bug.cgi?id=443806 flan_suse changed: What|Removed |Added Assignee|dolphin-bugs-n...@kde.org |plasma-b...@kde.org Component|general |Thumbnails and previews Product|dolphin |kio-extras -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 443806] New: Dolphin should allow option to cache thumbnails for separate encrypted devices / locations (KDialog too?)
https://bugs.kde.org/show_bug.cgi?id=443806 Bug ID: 443806 Summary: Dolphin should allow option to cache thumbnails for separate encrypted devices / locations (KDialog too?) Product: dolphin Version: 21.08.1 Platform: unspecified OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: dolphin-bugs-n...@kde.org Reporter: windows2li...@zoho.com CC: kfm-de...@kde.org Target Milestone: --- For (understandable) security and privacy reasons, Dolphin will not cache thumbnails for files that are located on a separate encrypted container. While I support this as a default behavior, and feel it is a responsible decision, there are two reasons why I suggest there should be an option that a user can override to allow thumbnail caching from separate encrypted containers: 1. The user's $HOME directory is already located on a encrypted container, and thus an external drive that is also using encryption needn't worry about "spillover" to a non-encrypted device. 2. Performance. External and/or separate devices need to re-generate their thumbnails every time the user browses to this folder. This causes extra reads and CPU cycles, and usually on slower devices in comparison to their primary drive. Not to mention the fact that reading thumbnails from cache is insanely faster than re-generating them every time. Thus, while the default should remain as is (which errs on the side of security and privacy) there should definitely be an option to allow thumbnail caching on separate encrypted devices. I suppose this also applies to KDialog, and not just Dolphin? --- Just for fun, here is a third reason: 3. The current implementation is inconsistent from a security and privacy standpoint. Network shares accessed via CIFS (SMB) have their thumbnails cached, even though (unknown to KDE) they are encrypted on the server. This is a case of "spillover" of potentially sensitive thumbnails, where KDE does not know whether or not the separate location is "encrypted", and thus whether or not to forgo thumbnail caching. --- For reference, here is a bug report that addresses the previous problem: https://bugs.kde.org/show_bug.cgi?id=411919 I'm not suggesting a reversal; only an *option* to override this for the reasons explained above. In certain cases, the drawbacks outweigh the benefits, which is why an option for the user makes the most sense. -- You are receiving this mail because: You are watching all bug changes.
[xdg-desktop-portal-kde] [Bug 428373] "Examining (Failed)" notifications some times when trying to save in folders with many files.
https://bugs.kde.org/show_bug.cgi?id=428373 flan_suse changed: What|Removed |Added CC||windows2li...@zoho.com --- Comment #2 from flan_suse --- Issue still exists, on the latest versions: Operating System: Manjaro Linux KDE Plasma Version: 5.22.5 KDE Frameworks Version: 5.86.0 Qt Version: 5.15.2 Kernel Version: 5.14.10-1-MANJARO (64-bit) Graphics Platform: X11 Processors: 8 × 11th Gen Intel® Core™ i7-1165G7 @ 2.80GHz Memory: 15.4 GiB of RAM Graphics Processor: Mesa Intel® Xe Graphics Notable slowdown if folder contains many files. Previews are disable (in KDailog). Every time I go to save a file to the directory, there's a delay as it "generates" the listing of folders/files. The location in question has 8,800+ files. Always abruptly notified with: > xdg-desktop-portal-kde > Examining (Failed) -- You are receiving this mail because: You are watching all bug changes.
