Re: sort by extension?

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

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.

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.

> | problem for many years now already at first in KDE, now in Gnome, and no
> | matter how many mime types are added in between, there are obviously
> | always more (maybe less common or new) types which are not recognized,
> | hence mixing up. It will never equal out, for obvious reasons I hope.
>
> That should be fixed in the mime types standard indeed.
Still not so sure... ;)
> | I know that this problem is originated in the windows world, but it
> | doesn't change the problem if I have to work in folders which contain
> | (also) windows files. Sorting by extension however will always reliably
> | return the expected result.
>
> Oh this has nothing to do with Windows really. Mime types are standard and should just work.
> There are no "Windows files" but rather just files that have the same issues in Windows or whatever system.
> However, it's true that Windows relies on the extension for guessing the type, but that doesn't change the 
> fact about mime types.
>
> Hope it's clearer now.
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.
> Cheers,
> Carlos Soriano
>
> |
> | Thanks,
> | Smirftsch
> |
> | On 07/08/2016 02:13 PM, Carlos Soriano Sanchez wrote:
> | > Hello,
> | >
> | > I'm unclear what the problem is. Is that there are not enough mime-types
> | > for your liking so sorting by mime type mix them?
> | > Then definitely they should be added as a standard. We don't really work
> | > with extensions (except for some specific cases).
> | >
> | > This sort by extension sounds more like a workaround for not enough mime
> | > types.
> | >
> | > Cheers,
> | > Carlos Soriano
> | >
> | > ----- Original Message -----
> | > | First off, thank you all for developing all this. I know what time and
> | > | effort this all costs and therefor I appreciate any work put into such a
> | > | project like this.
> | > |
> | > | That being said, I want to know if there is a way to enable "sort by
> | > | extension" feature for Nautilus.
> | > | If there is already an option for this, I'm sorry for my
> | > | elaborationsbelow , but after digging a while I'm pretty convinced that
> | > | I would have found it already if existing.
> | > |
> | > | Now, before starting to harass me with "we don't need another make Linux
> | > | to Windows topic", which seems to be the only obvious reason for me why
> | > | such a programming wise extremely simple feature isn't implemented yet,
> | > | let me explain why and what for this makes sense:
> | > | In a perfect Linux world one may be happy with mime type detection or
> | > | type, granted. Reality however is, if people like me, who are forced to
> | > | work in both worlds, a missing feature like this is extremely work flow
> | > | blocking and absolutely annoying. Different filetypes are mixed because
> | > | they are assumed to be the same mime type. If need to copy out files
> | > | from my Windows/Linux cross project, I have mix ups between .ini, .map
> | > | files, between .dll and .so, .ilk and .bsc and and and. I guess I could
> | > | compile a list with dozens of examples. I fully agree that Linux is not
> | > | windows and I don't want the Desktop of my choice to be "windows'ed",
> | > | but such a feature is really an essential addition if one has the
> | > | requirement to work with windows files or who needs to have interactions
> | > | between both OS.
> | > |
> | > |
> | > | Anyway, thanks for your time,
> | > | Smirftsch
> | > | --
> | > | nautilus-list mailing list
> | > | nautilus-list gnome org
> | > | https://mail.gnome.org/mailman/listinfo/nautilus-list
> | > |
> | >
> |
> | --
> | nautilus-list mailing list
> | nautilus-list gnome org
> | https://mail.gnome.org/mailman/listinfo/nautilus-list
> |