Re: sort by extension?

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

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:
> > 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