I like dolphin very much as filemanager, but I am forced to work with more systems than Linux only. Now if I have a folder with Linux/Windows/OSX files in it it will sort a huge part of the files as "unknown" when trying to sort by type, resulting plain in a useless mess. The idea to use the mime information to sort by type is indeed very helpful sometimes, but if not being one of the lucky people being able to use Linux only this function is 100% workflow blocking and I have to rely on other filemanagers like krusader. Also the same problem when it comes to txt files, like explained in a related (but not the same) wish in https://bugs.kde.org/show_bug.cgi?id=152241. I am wondering why this has never been added though, there are plenty of sorting methods which probably most users never will touch and which require probably way more complex algorithms, so I can only assume it has been left out by purpose. Can anyone tell me why? I think it should be rather easy to implement this and I ask for adding this so that I am not forced any longer to rely on other filemanagers just because I want to sort types of "unknown" or wrongly detected mime info.
First of all, thanks for taking the time to file this report. (In reply to developer from comment #0) > I like dolphin very much as filemanager, but I am forced to work with more > systems than Linux only. Now if I have a folder with Linux/Windows/OSX files > in it it will sort a huge part of the files as "unknown" when trying to sort > by type, resulting plain in a useless mess. Then the best solution for the problem is IMHO to improve the mime type detection, which is handled by the "Shared mime info" project, http://freedesktop.org/wiki/Software/shared-mime-info/ as far as I know. > I am wondering why this has never been added though, there are plenty of > sorting methods which probably most users never will touch and which require > probably way more complex algorithms, I'm not aware of any sorting method which uses a complex algorithm. Extracting the extension is not difficult, of course, but it is actually more complex than anything we do at the moment. > so I can only assume it has been left > out by purpose. Can anyone tell me why? The question is never "Why should we not add a feature?", but rather "Why is the feature important? Will it be helpful to a large part of our user base?". Note that any new feature, in particular new options, makes the code more complex and more difficult to maintain and to test (due to the larger number of possible code paths), there will be new bugs, and it will make the user interface more complex. We get requests for new options more than once a week, and if we accepted only a part of these, then the application would quickly turn into an unusable mess. If an option is necessary for many users, then one can consider adding it, of course, but this feature has never been requested so far. And the reason for the single request that we got so far from you is that you want to work around a problem with the mime type detection. As I said, it would be much better to fix this problem directly, so I'm against implementing your feature request. Sorry about that. Please note that there is a place which is much better for discussing new features: KDE Brainstorm ( https://forum.kde.org/viewforum.php?f=83 ). bugs.kde.org is completely unsuitable for evaluating how many users would benefit from a new feature. Feel free to propose your idea there and see what other users think about it.
Hello Frank, thanks for your response. However, I disagree with a lot of things you wrote. On 07/28/2014 06:18 PM, Frank Reininghaus wrote: > https://bugs.kde.org/show_bug.cgi?id=337804 > > Frank Reininghaus <frank78ac@googlemail.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|UNCONFIRMED |RESOLVED > Resolution|--- |WONTFIX > > --- Comment #1 from Frank Reininghaus <frank78ac@googlemail.com> --- > First of all, thanks for taking the time to file this report. > > (In reply to developer from comment #0) >> I like dolphin very much as filemanager, but I am forced to work with more >> systems than Linux only. Now if I have a folder with Linux/Windows/OSX files >> in it it will sort a huge part of the files as "unknown" when trying to sort >> by type, resulting plain in a useless mess. > Then the best solution for the problem is IMHO to improve the mime type > detection, which is handled by the "Shared mime info" project, > > http://freedesktop.org/wiki/Software/shared-mime-info/ > > as far as I know. As already tried to explain, this is no fix for the problem, this "solution" is insufficient and not feasible for daily use either. Shared mime info is used to determine "common" file types, but it will never support every filetype despite any effort ever being put in. It's a great way to use files and to work with them, to edit them, but there will be always some new filetypes or "not so common types" which will be never supported or at least not until the user updated. There will be always programs, especially from windows, which will use for example "filetype text" but use a different extension nevertheless, as pointed out in https://bugs.kde.org/show_bug.cgi?id=152241 (which was accepted btw) and if you need to copy only over those files with a specific extension, the user starts to sort them out manually again from other text files. Shared mime info simply can't provide that way distinguishing those files, I thought this is obvious. I hope I was able to explain it better now. > >> I am wondering why this has never been added though, there are plenty of >> sorting methods which probably most users never will touch and which require >> probably way more complex algorithms, > I'm not aware of any sorting method which uses a complex algorithm. Extracting > the extension is not difficult, of course, but it is actually more complex than > anything we do at the moment. > What I am talking about is for example "Audio" -> sort by "Artist", "Album", "Duration", etc. This seems to be rather complex to get all the information out of the file or fileheader while getting the extension is very simple string parsing of the filename to get the latest dot as delimiter, a few lines of code at best in C++ using std::string. >> so I can only assume it has been left >> out by purpose. Can anyone tell me why? > The question is never "Why should we not add a feature?", but rather "Why is > the feature important? Will it be helpful to a large part of our user base?". > Note that any new feature, in particular new options, makes the code more > complex and more difficult to maintain and to test (due to the larger number of > possible code paths), there will be new bugs, and it will make the user > interface more complex. We get requests for new options more than once a week, > and if we accepted only a part of these, then the application would quickly > turn into an unusable mess. Sorry to be blunt, but is this the default answer to put off people? I am developing myself for years, granted, only as hobbyist, I know how annoying people can be requesting random stuff, and I am very much aware about the fact that any change and any extension bears the chance of new bugs, but still I try to listen to people at least. This missing sort of option is bothering me for years now and so far I simply used krusader instead but I thought to give it a try to add it to your wishlist. Now I only get the impression that this haven't given any serious thought, the suggested "solution" is entirely off the problem itself, its like comparing apples and oranges. I also understand that you want to keep the interface simple and clear- one of the things I very much appreciate in Dolphin, so I hope you reconsider this one line entry for sort options worth it to be added. > > If an option is necessary for many users, then one can consider adding it, of > course, but this feature has never been requested so far. And the reason for > the single request that we got so far from you is that you want to work around > a problem with the mime type detection. As I said, it would be much better to > fix this problem directly, so I'm against implementing your feature request. > Sorry about that. Again sorry, but what for is your bug systems feature "Wishlist" then? There wasn't even the slightest chance for someone to think about this feature or to vote for or against it, if every "wish" like this is being removed within 2 days I am not surprised either that it looks like I am "the only one who ever requested that". That behavior makes me mad, honestly. Then remove the wishlist and voting from your bug tracking system and place a link to the forum mentioned below, which I wouldn't have found without the link here now anyway. If you google a bit you will find out that more people than only me have been wondering why this isn't implemented, and that for years, but to have a name like the most favorite resident of the sea isn't very helpful either when it comes to google searches (and I really have nothing against the choice of this name). It is a filemanager with "focus on usability" you claim yourself, but to recommend users to improve shared mime info database or to let them sort files manually while the sort criteria is even visible on screen is way beyond my understanding- and this has nothing to do with not wanting to contribute to things like shared mime info. As said already initially, I know not everyone suffers this problem but I am definitely not the only one either. Inside a pure Linux environment this is maybe a feature which is not needed, but on the other hand I know also a couple Linux programs using file extension to distinguish files and I know no one who doesn't have the need now and then to work with windows programs based data either. > to > Please note that there is a place which is much better for discussing new > features: KDE Brainstorm ( https://forum.kde.org/viewforum.php?f=83 ). > bugs.kde.org is completely unsuitable for evaluating how many users would > benefit from a new feature. Feel free to propose your idea there and see what > other users think about it. > Again, then I strongly recommend removing the wishlist and voting feature from your system, but will do as you suggest eventually. ~Jochen
(In reply to developer from comment #2) > > Then the best solution for the problem is IMHO to improve the mime type > > detection, which is handled by the "Shared mime info" project, > > > > http://freedesktop.org/wiki/Software/shared-mime-info/ > > > > as far as I know. > As already tried to explain, this is no fix for the problem, this > "solution" is insufficient and not feasible for daily use either. Shared > mime info is used to determine "common" file types, but it will never > support every filetype despite any effort ever being put in. It's a > great way to use files and to work with them, to edit them, but there > will be always some new filetypes or "not so common types" which will be > never supported I don't see why a file type that is present on a non-negligible number of users' systems could not be added to shared-mime-info. > or at least not until the user updated. This is an issue indeed, but if all that is required on the user side is to wait for a few months for the next distro update, then I'm not sure if the suggested workaround is really needed urgently. > There will be always programs, especially from windows, which will use > for example "filetype text" but use a different extension nevertheless, > as pointed out in https://bugs.kde.org/show_bug.cgi?id=152241 (which was > accepted btw) "Accepted" in the sense that the report is open and rotting since more than 6 years, yes. I always thought that being honest if something is not going to be implemented is better, but probably I'm wrong. (Just to be clear: bug 152241 might get implemented some day, it does not require any changes in the GUI after all and looks unlikely to cause any problems. I was not aware of that report at all. We have more than 500 open reports, and it's simply impossible to know more than a small part of them, and a report with 8 votes does not even show up in any "highest voted reports" queries). > and if you need to copy only over those files with a > specific extension, the user starts to sort them out manually again from > other text files. But then bug 152241 is a far better solution for this issue IMHO. In fact, would there be *any* problem concerning file types and extensions remaining from your point of view if bug 152241 was implemented? > >> I am wondering why this has never been added though, there are plenty of > >> sorting methods which probably most users never will touch and which require > >> probably way more complex algorithms, > > I'm not aware of any sorting method which uses a complex algorithm. Extracting > > the extension is not difficult, of course, but it is actually more complex than > > anything we do at the moment. > > > What I am talking about is for example "Audio" -> sort by "Artist", > "Album", "Duration", etc. This seems to be rather complex to get all the > information out of the file or fileheader But this is all handled by libraries. No complexity whatsoever is required on the Dolphin side. We just have to compare two strings, which we already have since they show up, e.g., in columns in Details View. > while getting the extension is > very simple string parsing of the filename to get the latest dot as > delimiter, a few lines of code at best in C++ using std::string. Yes, it is simple, but you claimed that the existing sorting methods are more complex than this, and this is just wrong. > >> so I can only assume it has been left > >> out by purpose. Can anyone tell me why? > > The question is never "Why should we not add a feature?", but rather "Why is > > the feature important? Will it be helpful to a large part of our user base?". > > Note that any new feature, in particular new options, makes the code more > > complex and more difficult to maintain and to test (due to the larger number of > > possible code paths), there will be new bugs, and it will make the user > > interface more complex. We get requests for new options more than once a week, > > and if we accepted only a part of these, then the application would quickly > > turn into an unusable mess. > Sorry to be blunt, but is this the default answer to put off people? It is the default answer if the reporter provides insufficient evidence that the proposed option will make Dolphin better for a large part of our user base, AND that adding the option is the best solution for the problem. > I am developing myself for years, granted, only as hobbyist, I know how > annoying people can be requesting random stuff, and I am very much aware > about the fact that any change and any extension bears the chance of new > bugs, but still I try to listen to people at least. Sorry to be blunt, but after I provided a very quick answer in comment 1 that consists of more than a few sentences, I consider your indication that I don't "listen to people" insulting. > I also understand that you want to keep the interface simple and clear- > one of the things I very much appreciate in Dolphin, so I hope you > reconsider this one line entry for sort options worth it to be added. But then we have to also consider hundreds of other requests for one-line entries. All of these would provide some value to their reporters, but unless it is clear that adding all those options is the correct solution to the problem, this is just not right. > > If an option is necessary for many users, then one can consider adding it, of > > course, but this feature has never been requested so far. And the reason for > > the single request that we got so far from you is that you want to work around > > a problem with the mime type detection. As I said, it would be much better to > > fix this problem directly, so I'm against implementing your feature request. > > Sorry about that. > Again sorry, but what for is your bug systems feature "Wishlist" then? > There wasn't even the slightest chance for someone to think about this > feature or to vote for or against it, if every "wish" like this is being > removed within 2 days I am not surprised either that it looks like I am > "the only one who ever requested that". That behavior makes me mad, > honestly. Then remove the wishlist and voting from your bug tracking > system and place a link to the forum mentioned below, which I wouldn't > have found without the link here now anyway. I think we both agree that the entire process around reporting feature requests at bugs.kde.org (or at the bug tracker of any other free software project) is completely broken. There are 16138 open wishes at the moment, most of which will never get implemented, and many of which never got any reply. I know that most free software developers tend to simply ignore incoming feature requests (at least if it is not obvious that the feature is the correct solution to the problem, and that there are sufficient resources to write and maintain the required code) and let the reports rot forever. This is a very simple solution, of course - the only risk is that the reporter will get disappointed after a few years. Nevertheless, a small part of me still thinks that providing a quick and honest reply is the better solution, at least sometimes. Shutting down bugs.kde.org for feature requests and replacing it by KDE Brainstorm (where many more users take part in discussions, one can embed screenshots and mockups, one can not only upvote, but also downvote ideas, just to name a few obvious advantages) would be the best solution from my point of view, but this change (and moving all existing wishlist reports) will take an enormous effort. I would greatly appreciate if there was a group of people who volunteered to do this. Expecting that the small group of developers, who are already struggling to handle the incoming bug reports properly, takes care of this is simply unrealistic IMHO.
On 30.07.2014 11:22, Frank Reininghaus wrote: > https://bugs.kde.org/show_bug.cgi?id=337804 > > --- Comment #3 from Frank Reininghaus <frank78ac@googlemail.com> --- > (In reply to developer from comment #2) >>> Then the best solution for the problem is IMHO to improve the mime type >>> detection, which is handled by the "Shared mime info" project, >>> >>> http://freedesktop.org/wiki/Software/shared-mime-info/ >>> >>> as far as I know. >> As already tried to explain, this is no fix for the problem, this >> "solution" is insufficient and not feasible for daily use either. Shared >> mime info is used to determine "common" file types, but it will never >> support every filetype despite any effort ever being put in. It's a >> great way to use files and to work with them, to edit them, but there >> will be always some new filetypes or "not so common types" which will be >> never supported > I don't see why a file type that is present on a non-negligible number of > users' systems could not be added to shared-mime-info. Still it is a lot of effort for "just sorting some files" and nothing I'd like to mess with if I only want to copy over some files- it also leaves out the number of not common file types and the case if the detection is wrong. >> or at least not until the user updated. > This is an issue indeed, but if all that is required on the user side is to > wait for a few months for the next distro update, then I'm not sure if the > suggested workaround is really needed urgently. Critical? No. So could wait of course. But very annoying if having the solution right before your eyes and that in a reliable way. > >> There will be always programs, especially from windows, which will use >> for example "filetype text" but use a different extension nevertheless, >> as pointed out in https://bugs.kde.org/show_bug.cgi?id=152241 (which was >> accepted btw) > "Accepted" in the sense that the report is open and rotting since more than 6 > years, yes. I always thought that being honest if something is not going to be > implemented is better, but probably I'm wrong. > > (Just to be clear: bug 152241 might get implemented some day, it does not > require any changes in the GUI after all and looks unlikely to cause any > problems. I was not aware of that report at all. We have more than 500 open > reports, and it's simply impossible to know more than a small part of them, and > a report with 8 votes does not even show up in any "highest voted reports" > queries). > >> and if you need to copy only over those files with a >> specific extension, the user starts to sort them out manually again from >> other text files. > But then bug 152241 is a far better solution for this issue IMHO. > > In fact, would there be *any* problem concerning file types and extensions > remaining from your point of view if bug 152241 was implemented? Yes, because sometimes the detection considers files of the same extension different filetypes, maybe because they are plain unknown to it, but it leaves a considerable error margin. >>>> I am wondering why this has never been added though, there are plenty of >>>> sorting methods which probably most users never will touch and which require >>>> probably way more complex algorithms, >>> I'm not aware of any sorting method which uses a complex algorithm. Extracting >>> the extension is not difficult, of course, but it is actually more complex than >>> anything we do at the moment. >>> >> What I am talking about is for example "Audio" -> sort by "Artist", >> "Album", "Duration", etc. This seems to be rather complex to get all the >> information out of the file or fileheader > But this is all handled by libraries. No complexity whatsoever is required on > the Dolphin side. We just have to compare two strings, which we already have > since they show up, e.g., in columns in Details View. > >> while getting the extension is >> very simple string parsing of the filename to get the latest dot as >> delimiter, a few lines of code at best in C++ using std::string. > Yes, it is simple, but you claimed that the existing sorting methods are more > complex than this, and this is just wrong. Well, then you let some libs the complex stuff, still a lot of more work is done in background nevertheless- but alright, point taken. >>>> so I can only assume it has been left >>>> out by purpose. Can anyone tell me why? >>> The question is never "Why should we not add a feature?", but rather "Why is >>> the feature important? Will it be helpful to a large part of our user base?". >>> Note that any new feature, in particular new options, makes the code more >>> complex and more difficult to maintain and to test (due to the larger number of >>> possible code paths), there will be new bugs, and it will make the user >>> interface more complex. We get requests for new options more than once a week, >>> and if we accepted only a part of these, then the application would quickly >>> turn into an unusable mess. >> Sorry to be blunt, but is this the default answer to put off people? > It is the default answer if the reporter provides insufficient evidence that > the proposed option will make Dolphin better for a large part of our user base, > AND that adding the option is the best solution for the problem. > >> I am developing myself for years, granted, only as hobbyist, I know how >> annoying people can be requesting random stuff, and I am very much aware >> about the fact that any change and any extension bears the chance of new >> bugs, but still I try to listen to people at least. > Sorry to be blunt, but after I provided a very quick answer in comment 1 that > consists of more than a few sentences, I consider your indication that I don't > "listen to people" insulting. Sorry if so, but this indication was because the problem and the solution is that obvious to me that I plain got the impression that you didn't try to understand the problem and the offered solution didn't fit either. >> I also understand that you want to keep the interface simple and clear- >> one of the things I very much appreciate in Dolphin, so I hope you >> reconsider this one line entry for sort options worth it to be added. > But then we have to also consider hundreds of other requests for one-line > entries. All of these would provide some value to their reporters, but unless > it is clear that adding all those options is the correct solution to the > problem, this is just not right. Don't even disagree here. Just wondering why many other filemanagers offer this functionality then, like Krusader or even old MC. Ok, one could say that those can't take advantage of shared mime info, yet I hope I was able to show that there are some flaws using this method, while a 100% reliable method for such cases could be implemented. >>> If an option is necessary for many users, then one can consider adding it, of >>> course, but this feature has never been requested so far. And the reason for >>> the single request that we got so far from you is that you want to work around >>> a problem with the mime type detection. As I said, it would be much better to >>> fix this problem directly, so I'm against implementing your feature request. >>> Sorry about that. >> Again sorry, but what for is your bug systems feature "Wishlist" then? >> There wasn't even the slightest chance for someone to think about this >> feature or to vote for or against it, if every "wish" like this is being >> removed within 2 days I am not surprised either that it looks like I am >> "the only one who ever requested that". That behavior makes me mad, >> honestly. Then remove the wishlist and voting from your bug tracking >> system and place a link to the forum mentioned below, which I wouldn't >> have found without the link here now anyway. > I think we both agree that the entire process around reporting feature requests > at bugs.kde.org (or at the bug tracker of any other free software project) is > completely broken. There are 16138 open wishes at the moment, most of which > will never get implemented, and many of which never got any reply. I know that > most free software developers tend to simply ignore incoming feature requests > (at least if it is not obvious that the feature is the correct solution to the > problem, and that there are sufficient resources to write and maintain the > required code) and let the reports rot forever. This is a very simple solution, > of course - the only risk is that the reporter will get disappointed after a > few years. Nevertheless, a small part of me still thinks that providing a quick > and honest reply is the better solution, at least sometimes. > > Shutting down bugs.kde.org for feature requests and replacing it by KDE > Brainstorm (where many more users take part in discussions, one can embed > screenshots and mockups, one can not only upvote, but also downvote ideas, just > to name a few obvious advantages) would be the best solution from my point of > view, but this change (and moving all existing wishlist reports) will take an > enormous effort. I would greatly appreciate if there was a group of people who > volunteered to do this. Expecting that the small group of developers, who are > already struggling to handle the incoming bug reports properly, takes care of > this is simply unrealistic IMHO. > I understand. Thanks for this explanation. I really wish I would have more time. Yet a link to the forum for those who are really interested and removing the wishlist could probably help to avoid that people getting the impression being put off.