Re: sort by extension?

Don't mean to bother anyone, but I don't want to have this topic forgotten again either, since I still think it is a valid and important request, not only for me. :)

On 14.07.2016 13:51, developer oldunreal com wrote:
On 07/13/2016 07:38 PM, Carlos Soriano Sanchez wrote:

----- Original Message -----
| On 07/12/2016 10:10 AM, Carlos Soriano Sanchez wrote:
| >
| > ----- Original Message -----
| > | Hello ;)
| > |
| > | As I was trying to explain already, there is always cases in which mime | > | type fails and mixes up different filetypes. I am messing with this
| >
| > Oh that's a bug, please file it on glib with the mime types that are mixed
| > and we will take a look which component has an issue with it.
| Thanks for discussing this out with me, it's not that easy it seems! And | please don't take this as complain, it's not my intention to make anyone
| upset here, I'm only interested in getting understood and finding a
| solution.

As long as we discuss technically and with respect, I cannot see why someone should be upset :) That's what the mailing list are for!
I'm happy about this.
| So, if it is a bug in glib, where to report that exactly? I'm not that
| deep anymore in that matters nowadays.
| However, I am not sure if we are not still comparing apples and oranges
| here. I found some time to make more tests today, if sorting by mime
| type I get the following mix ups when sorting my workspace files:
| identified as "application/octet-stream"
| .bsc
| .u
| .int
| .mhr
| .ilk
| .itt
| .pgd
| .bin
| identified as "application/x-sharedlib" (problem if I only want to copy
| dll's f.e.)
| .so
| .so.whatever
| .dll
| identified as "text/plain"
| .map
| .int
| .itt
| .ini
| Now, needless to say that many of these filetypes are entirely unrelated
| and should be separated then if I want to copy/delete a specific
| filetype like .bin or .u , it's also troublesome for example for .int
| files, identified as both octed-stream and plaintext but which are
| always textfiles containing just localization information.
| I'm sure I can easily find more of these, but it's already an exemplary
| list I think.
| And when sorting by "type" instead of mime type it's even worse.

Hm okay, I'm not sure anymore I know enough to discuss it, so I will probably let other more experts than me to answer. In any case, what I see is that, for example video of type ogg is marked as mime type video/ogg. I would expect the same to all other types. I don't see a reason to not provide a good mimetype standard list so we can be sure about the type and not rely on the extension. I want my videos that are type of .ogg or .ogv to be ordered in the same level, not differently. Or I am wrong here?
Sort of I think, because while it makes perfectly sense in your example with video files, such an aggregation is absolutely unwanted if its only about to make file operations with files of a specific type.
| Well, somehow it makes it even more questionable to me if the solution
| is really in the mime types and if it is a bug in there, while on the
| other hand a suitable solution could be directly available. I hope the
| problem is clearer now too.

To me it feels like a workaround rather than a solution. On the other hand, this might be enough difficult to move forward that a workaround would worth it. But I would like to put that as the last option.

In any case as I said, I'm not sure I know enough, so hope someone that knows more jumps into this.
I think the example with the video files above is great to show the the different usage/purpose for both methods of sorting, so neither of these seems to be a workaround to me, but each has it's advantages/disadvantages depending on needs.
Carlos Soriano


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]