Re: sort by extension?

["developer oldunreal com" <developer oldunreal com>]

On 07/13/2016 07:38 PM, Carlos Soriano Sanchez wrote:
> Hey,
>
> ----- 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.
> Cheers,
> Carlos Soriano
~Smirftsch