[ark] [Bug 358304] Ark does not open ISO files with UDF filesystem.
https://bugs.kde.org/show_bug.cgi?id=358304 ttrovo changed: What|Removed |Added CC||vle...@yandex.ru --- Comment #20 from ttrovo --- I still cannot open ISO files with Ark (version 23.08.3). It says: "The archive is empty or Ark could not open its content." and shows nothing in the file list. Please reopen the problem, not fixed. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 467216] Cannot search hidden files and folders with built-in search; have to use Baloo file search
https://bugs.kde.org/show_bug.cgi?id=467216 --- Comment #12 from ttrovo --- (In reply to tagwerk19 from comment #11) > (In reply to ttrovo from comment #9) > > ... I have `baloo` completely disabled ... and Show Hidden Files set to > > always-on ... > It's an issue then with Dolphin's "There and Then" search, as per: > https://bugs.kde.org/show_bug.cgi?id=463830#c3 Thank you for the link. But #463830 has quite a different problem, related but different, has it not? Because it is about the difference of results with or without baloo. People do not care about baloo and consistency with its results. What they care about is the fact that **search does not find files that exist in the directory**. The main point is that the only correct way to search files is to find those files, especially when Show Hidden Files is ON. Because all other search apps and file manager do it, so, it is what people expect. Otherwise it is an actual bug, not a feature. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 467216] Cannot search hidden files and folders with built-in search; have to use Baloo file search
https://bugs.kde.org/show_bug.cgi?id=467216 --- Comment #10 from ttrovo --- Oh, I forgot to add my use-case of having DATA LOSS due to this search problem. I eventually forget that search is not working reliably in Dolphin and this happens: 1. I open directory and check there it has no valuable files based by names. To do that I search for some sub-string like "important" using Dolphin search. 2. I delete the directory expecting it to lack valuable files. 3. The files where really there, like: `subdir/.local/important`. Dolphin failed to find them but successfully removed them. I had these situation multiple times myself in real life, so it is not far-fetched at all. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 467216] Cannot search hidden files and folders with built-in search; have to use Baloo file search
https://bugs.kde.org/show_bug.cgi?id=467216 ttrovo changed: What|Removed |Added CC||vle...@yandex.ru --- Comment #9 from ttrovo --- Thank you Nate Graham for you work on the best file manager for GNU/Linux, I really appreciate your afford on fixing other issues I was complaining about or following. Related to this topic: a lot of other people and I have `baloo` completely disabled (maybe not even installed) and Show Hidden Files set to always-on. Can somehow we make search in Dolphin work as expected, more reliably? I mean as Dolphin is great, it is more convenient to search in it compared to open kfind in a separate window or use krusader manager. But **currently Dolphin does not find files that are there**. Like imagine, I have this in the current directory directory: ``` ./.something/foobar.txt ./.foobar.txt ``` I see both items because I have always-on Show Hidden Files on all systems I have ever used, including Windows. But if I search in Dolphin for "foobar" it find nothing! Note that `Krusader`, `KFind` and `mc` work differently, well, almost ANY file manager is able to find this files. It would be great if this issue will be possible to address, because people are really waiting for it for a long time. E.g.: here is a link to a popular reddit topic where people discuss search in Dolphin and consider it to be "broken". https://www.reddit.com/r/kde/comments/smlevb/dolphin_search_doesnt_work_well_any_way_to_make/ Maybe the the issue should be considered a bug, as a lot of people really do consider it that way. Almost nobody will say that it is not a bug not to find files when they exist. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 416087] Optionally find hidden files using Dolphin's standard search
https://bugs.kde.org/show_bug.cgi?id=416087 --- Comment #14 from ttrovo --- Additional link to a popular reddit topic where people discuss search in Dolphin and consider it to be "broken". https://www.reddit.com/r/kde/comments/smlevb/dolphin_search_doesnt_work_well_any_way_to_make/ Maybe the the issue should be marked as a bug, as a lot of people really consider it a bug. Almost nobody will say that it is not a bug not to find files when they exist. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 416087] Optionally find hidden files using Dolphin's standard search
https://bugs.kde.org/show_bug.cgi?id=416087 ttrovo changed: What|Removed |Added CC||vle...@yandex.ru --- Comment #13 from ttrovo --- Please, reconsider and address this issue. A lot of people are not expecting current behavior and many of them consider it to be a bug. Important bug. The behavior of search in Krusader and ANY other file manager is different and better. Please also take into account, that it can easily lead to user DATA LOSS. I had these situations multiple times myself in real life, so it is not far-fetched at all: 1. User opens directory and check there it has no valuable files with sub-string "foobar" using dolphin search. 2. User deletes directory expecting it to lack valuable files. 3. The files where in path like: `subdir/.local/foobar`. Dolphin removes them. Why would dolphin remove files that it kind of does not see them? Obviously ignoring "hidden" files during removal would be not a good idea, why would anyone consider ignoring them during search to be a good idea in the first place? Especially when Show hidden files is on. Awesome Nate Graham and other guys, please, reconsider, address this issue and make Dolphin even better and once again reliable (currently search is not reliable). Maybe search provider that does not search properly should be opt-in instead of being irreplaceable opt-nothing. Thanks a lot! -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 439864] Dolphin resets to "Home" and forgets paths of all tabs that are not available on start [regression]
https://bugs.kde.org/show_bug.cgi?id=439864 --- Comment #19 from ttrovo --- Can somebody please find the commit that cause this issue again? Maybe this commit should be reverted until its author fix the introduced regression in their commit? -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 439864] Dolphin resets to "Home" and forgets paths of all tabs that are not available on start [regression]
https://bugs.kde.org/show_bug.cgi?id=439864 --- Comment #14 from ttrovo --- (In reply to Thomas from comment #13) > It is again with Dolphin Version 23.04.1 on update to Fedora 38. Thanks for reporting! When this issue with loss of users information (paths of tabs) happened the last time Nate Graham made it work again and it was very appreciated! I really hope this time Nate again or somebody else will be able to once again fix this issue before I get to this version of Dolphin. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 454650] New: Dolphin does not find any Hidden Files even when "Show Hidden Files" is on
https://bugs.kde.org/show_bug.cgi?id=454650 Bug ID: 454650 Summary: Dolphin does not find any Hidden Files even when "Show Hidden Files" is on Product: dolphin Version: 21.12.2 Platform: Other OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: search Assignee: dolphin-bugs-n...@kde.org Reporter: vle...@yandex.ru CC: kfm-de...@kde.org Target Milestone: --- SUMMARY *** Dolphin does not find any Hidden Files even when "Show Hidden Files" is on. No results for filename search, nor for content search. => There is no way to use search in Dolphin reliably. *** STEPS TO REPRODUCE 1. Open Dolphin in the home directory. The directory has hidden file, e.g. ".bashrc". 2. Check that "Show Hidden Files" option is set on and ".bashrc" is visible in the directory. 3. Try to search for "bash" using Search panel in Dolphin. OBSERVED RESULT No ".bashrc" found in the results, Dolphin states there is no such file after showing it before search. EXPECTED RESULT The ".bashrc" file found and is shown in the search results. ADDITIONAL INFORMATION The issue affects Content search too. One can search for something but hidden files will be skipped and the search result will be wrong (without actual expected file). SUMMARY Please make search not to ignore hidden files. Because: 1) Other software does not behave like that and provide reliable search results (e.g. mc) 2) It's completely unexpected by the user who has Show Hidden Files ALWAYS ON and does not care if the file starts with dot at all. 3) The current search method is not reliable. Dolphin states there is not file with the provided name but actually there is one. Dolphin states there is no file with provided content and it's false also. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 439864] Dolphin resets to "Home" and forgets paths of all tabs that are not available on start [regression]
https://bugs.kde.org/show_bug.cgi?id=439864 --- Comment #9 from ttrovo --- Great, that's really appreciated! I really loved reliable save-session feature and use tabs to remember what I have to do (path of tab means a lot). I have this ideas you may find useful: 1) Maybe the redirect to home should not happen on session restore, only it the path because unavailable in progress 2) And maybe only the current tab should be affected because it is more explicit? 3) Maybe the redirect to home should always be reversible by Back function. E.g. not change the path, but save current path to history and only then "go to home", so Back button will allow the come back to unavailable place. I hope for any solutions that would preserve my use case. Thanks again. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 439864] Dolphin resets to "Home" and forgets paths of all tabs that are not available on start [regression]
https://bugs.kde.org/show_bug.cgi?id=439864 --- Comment #7 from ttrovo --- Thanks for reply, have a great vacation. I do have limited expectations, but this feature already was implemented and is kind of crucial in my user-case. With the whole save-session feature of Dolphin I could have relied on - just close Dolphin and continue from the last place. Even if place is not mounted - I could have just remount and F5 tab - I have my progress saved. Now if I open Dolphin when I forgot to mount disk - I have 7-10 tabs Home. OK, maybe there are some people who prefer saving session but loosing unavailable locations on startup. How about adding a checkbox in settings: "On startup close tabs with unavailable location"? It would allow these people and people like me who used reliable sessions to coexist happily. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 439864] Dolphin resets to "Home" and forgets paths of all tabs that are not available on start [regression]
https://bugs.kde.org/show_bug.cgi?id=439864 --- Comment #5 from ttrovo --- Nate Graham, can you response? I love Dolphin and want it to be better. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 439864] Dolphin resets to "Home" and forgets paths of all tabs that are not available on start [regression]
https://bugs.kde.org/show_bug.cgi?id=439864 --- Comment #4 from ttrovo --- I uses the feature that tab keeps it path and do not reset it. I could have remount location and continue to work with it. So closing Dolphin was not a problem at any point. And now it's a disaster. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 439864] Dolphin resets to "Home" and forgets paths of all tabs that are not available on start [regression]
https://bugs.kde.org/show_bug.cgi?id=439864 --- Comment #3 from ttrovo --- Furthermore, tabs exist not only in the Dolphin, but other applications too, like browsers. And NO browser closes/resets user tab's URL because it is not currently accessible. It will be strange and awful behavior, when you have disappearing tabs and have no information available what was there. Please reconsider. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 439864] Dolphin resets to "Home" and forgets paths of all tabs that are not available on start [regression]
https://bugs.kde.org/show_bug.cgi?id=439864 --- Comment #2 from ttrovo --- > we had many complaints about Dolphin showing annoying "this path cannot be > found" messages on launch when attempting to restore tabs for inaccessible > locations. Please revert this regression. The reasons: 1) The message was not annoying, it was banner at the top, not some modal messagebox. This message still exist if you delete the directory that is opened in tab. And that's fine, perfect. 2) If there are really people who were annoyed with "not found" message, then are using some unmounted directories and and now they should be pleased having 7 empty tabs of "Home"? Makes no sense. 3) And the most important - the session is lost! It's a loss of information, it is not acceptable, it's like deleting user files. Because location can be very important - those can be some directories that user was working in and will FORGET about it after this information is discarded. Nate Graham, can something be done to revert the current behavior? I will be wokring against this wrong decision. If you need someone the be convinced about this decision being wrong - please tell me. Who are those people who like to loose their information and have empty tabs anyway? -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 439864] Dolphin resets to "Home" and forgets paths of all tabs that are not available on start [regression]
https://bugs.kde.org/show_bug.cgi?id=439864 ttrovo changed: What|Removed |Added CC||vle...@yandex.ru -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 439864] New: Dolphin resets to "Home" and forgets paths of all tabs that are not available on start [regression]
https://bugs.kde.org/show_bug.cgi?id=439864 Bug ID: 439864 Summary: Dolphin resets to "Home" and forgets paths of all tabs that are not available on start [regression] Product: dolphin Version: 20.12.2 Platform: Fedora RPMs OS: Linux Status: REPORTED Severity: normal Priority: NOR Component: general Assignee: dolphin-bugs-n...@kde.org Reporter: vle...@yandex.ru CC: kfm-de...@kde.org Target Milestone: --- SUMMARY Dolphin resets to "Home" and forgets paths of all tabs that are not available on start. The session gets completely lost and even making places available again do not help to restore information what were the locations of tabs. STEPS TO REPRODUCE 1. Set "Show on starup" setting to "Folders, tabs, and window state from the last time" in "Startup" settings of Dolphin. 2. Mount something to some directory, e.g. to /home/user/my/ 3. Open several tabs with sub-directories of this mounted place. 4. Close Dolphin 5. Unmount the directory 6. Open Dolphin OBSERVED RESULT Dolphin shows several tabs but all of them have "Home" name and no saved path. Information about previous session is lost. User has several useless "Home" tabs instead and that's all. EXPECTED RESULT All tabs should keep the paths even if those are not currently available (it can be remounted and session won't be lost). It always worked like that in previous versions of Dolphin. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Fedora 33. Dolphin: 20.12.2 KDE Frameworks Version: 5.79.0 Qt Version: 5.15.2 ADDITIONAL INFORMATION It's a regression, because on older versions of Dolphin I had a red banner that location is not available with ability to make it available and refresh the tab. -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kconfig] [Bug 430521] Dolphin doesn't restore to original size after resuming from maximized.
https://bugs.kde.org/show_bug.cgi?id=430521 --- Comment #23 from ttrovo --- The bug description says: "Version Fixed In: 5.79". It must be wrong, because I have Dolphin 20.12.2 with KDE Frameworks 5.79.0 and it's not fixed for me. Also the version should be Dolphin-related, should not it? -- You are receiving this mail because: You are watching all bug changes.
[frameworks-kconfig] [Bug 430521] Dolphin doesn't restore to original size after resuming from maximized.
https://bugs.kde.org/show_bug.cgi?id=430521 ttrovo changed: What|Removed |Added CC||vle...@yandex.ru --- Comment #22 from ttrovo --- I also suffer from this regression. How come this regressions go to major releases? Developers do not use dolphin or do not use maximize or don't use Places panel? No idea. Very disturbing issue, please avoid regressions like that (breaking basic things) as it eliminates all awe of new things in new versions, when you have something broken each major release. P.S. I see a possible fix was made by Nate Graham. Thanks a lot! Can someone tell what exact Dolphin version should have fixes of this regression and #434825? -- 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 ttrovo changed: What|Removed |Added CC||vle...@yandex.ru --- Comment #11 from ttrovo --- Any news when will it be possible to make shortcuts for services in Dolphin? If it's at least half-done, we can wait for another half (in year 2032). -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 426341] Dolphin doesn't show number of items in symlinked folder
https://bugs.kde.org/show_bug.cgi?id=426341 --- Comment #4 from ttrovo --- Added Méven Car to CC list (not sure how to tag/mention someone here, sorry if doing it wrong) as they mentioned possibly-related issue #421831 that is related to the the new content-size feature that can be affecting Number of items mode. Maybe you, Méven Car, can help us with current issue? Thanks. -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 426341] Dolphin doesn't show number of items in symlinked folder
https://bugs.kde.org/show_bug.cgi?id=426341 ttrovo changed: What|Removed |Added CC||meve...@gmail.com -- You are receiving this mail because: You are watching all bug changes.
[dolphin] [Bug 426341] Dolphin doesn't show number of items in symlinked folder
https://bugs.kde.org/show_bug.cgi?id=426341 ttrovo changed: What|Removed |Added CC||vle...@yandex.ru --- Comment #3 from ttrovo --- I confirm this BUG on Fedora 32. Even worse - the number of items is not shown for several directories in ~user: Documents, Videos, Desktop, Downloads, Public, Templates and for some reason ".gnome2". It makes it so easy to REPRODUCE and find the reason of the bug. It's a REGRESSION as Fedora 30 had Dolphin that worked fine, it showed number of items for all directories, including symlinks with no issue. I believe, it's a "new feature" (calculate files' size instead of number of items) broke this. Maybe recursive calculation of files inside symlink or something is risky (can take long), so someone removed count of number of files non-recursive (just one level) with it by accident. By the way, size of contents also does not work for symlinks and this directories, the same bug? -- You are receiving this mail because: You are watching all bug changes.
[kxkb] [Bug 295438] Keyboard layout switcher stops working
https://bugs.kde.org/show_bug.cgi?id=295438 --- Comment #59 from ttrovo <vle...@yandex.ru> --- Are there any plans to fix this ANNOYING bug? A lot of people hate KDE5 because of such things. -- You are receiving this mail because: You are watching all bug changes.
