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
>
--
nautilus-list mailing list
nautilus-list gnome org
https://mail.gnome.org/mailman/listinfo/nautilus-list