Is there a way in Dolphin’s “details” view to get a column for files’ file extensions (as opposed to the existing “type” column)?
what is the difference you are looking for?
The file’s extension. Eg “Plain text document” is not an extension.
understood, but “plain text document” will all be grouped together whether they have .txt on the end or not.
so i’m just trying to understand the use case for this.
would .profile or .bashrc be considered an extension?
what about .pam_environment
or would those be considered to not have an extension like so many “plain text” documents
I’m just looking to see if there’s a way to have a column with the extensions.
If not, I’m also curious if this is something that’s possible to implement via whatever plugin system dolphin might have.
I’m not particularly concerned with the semantic nuances of it. (Although, if that’s something you’re curious about exploring, I think I remember that DLang put a good amount of thought into it when designing the relevant parts of its std lib. You could see what they did and ask around for what their reasoning was if you’re interested.)
This use case is covered by the type column.
Having types and extensions columns would be redundant, we don’t want to have features already covered elsewhere, that’s just bad app design.
It is possible to edit what the types in the column by declaring custom mime-types in the filetype kcm (kcmshell6 kcm_filetypes).
You can also try to make this file type available to anyone by default by contributing to Making sure you're not a bot!
Could you detail what is it you are trying to achieve ? Sorting by extension ?
You have some special file extensions ? like .20250415
This is why I usually avoid forums at all costs. Things are rarely allowed to be straightforward. Questions get warped into feature demands and “convince me you’re not doing it wrong”, occasional feigning of ignorance, etc.
Ugh, ok. Fine.
So summarizing so far:
-
I take it the answer to “Can I currently do this?” is “No”.
-
“Is this within the possibilities of the plugins/extensibility/etc system?” is undetermined.
-
To be clear, I have not made a feature request.
In response to other things:
It sounds like Dolphin gets all its filetype labels (ex “Plain text document”) directly from the same main MIME info project that much of the system does and doesn’t handle any of that itself? Or from some combination of that and a “kcm_filetypes” module? I’m having trouble finding information on this kcm_filetypes module.
Since I do see Dolphin list some filetypes as “Unknown”, I take it that’s what it always defaults to for anything it’s unable to determine, right? And never like, “{ext here} File” as say windows does (or used to, if memory serves, back ages ago when I was still using it regularly).
And yes, you are correct, a variety of sorting differences, and also issues with custom filetypes are both perfect examples of the differences between file extensions vs inferred file type labels. Both are great reasons why an extension column would be useful (myself included). If they were effectively the same, one could argue the type column is already redundant with displaying the extension in the filename column, and therefore one or the other should be removed. (Although personally, if I held that viewpoint, I wouldn’t be here, I’d probably be off using something like Gnome or Windows or Mac instead.)
Another difference is what they both indicate: Inferred types are more indicative of the raw data in the file. Whereas extensions are more indicative of broader context and human intent. Usually these align, but there’s a variety of situations (some intentional, some accidental) when they don’t. And when they don’t, each one gives you information the other doesn’t. At a given point, the information from either one may be more relevant to a particular task at hand, or both may be. (Personally, I find the nuances of extensions to be more relevant to most of my tasks than those of the inferred type labels, and I consistently find the using type column to be an awkward, clumbsy substitute for working with a column of extensions.)
Please understand that this type of question is likely to sound like an XY problem - there’s an exposed column in the interface that’s designed to handle a need, and you’re asking about visibility to something else that would answer that need differently. It sounds like you have a use case/workflow/etc. that isn’t enabled by the current design, so now you’re having to work around a shortcoming in the intended design, or in its implementation. Folks here are going to want to understand if there’s some other underlying problem, then - not to be intentionally difficult, but to try to save multiple future steps down the road.
Regarding a column listing the raw extension after the ., as far as I can tell that already exists, and is accessible from the column selection menu - are you seeing that available on your device?
I do still think it would be valuable to understand what types of tasks are aided by having both forms of that information, since at the very least, there might be something that you or others are using Dolphin for that hadn’t previously been considered and could inform other work in the project.
2 Likes
There it is. I realize I mistakenly overlooked it in the menu, but a simple “Yes, this is where it is, is it not doing something you were looking for?” would’ve sufficed.
But still, thank you for answering.
Welcome to Linux, where you WILL get overly long answers to things you didn’t ask for, Something I myself have never ever have done, ever 
We often try to explain things in anticipation of the next questions, usually involving “Why??”, out of both experience and habit.
I think a LOT of us missed the “other” category in there, maybe expecting to see file extensions more prominently if it were even there, then remembering that extensions are meaningless in Linux, so we…jump ahead and explain why..
Also don’t expect full 100% attention, as I am sure most of us are multi-tasking, with work or family matters as we take part here, in our spare time.
Basically, anywhere you go, forums or not, you probably will find similar reactions from people trying to help, even if that help is not exactly what you wanted.
Not bad, considering how much we get paid 
2 Likes
Some specifics off the top of my head:
For one thing, I’m just accustomed to thinking in terms of file extensions (maybe just a lasting 1990’s-brain artifact :shrug:), so when I’m using the default “Type” column I find I have to do a lot of mental translation between that and what the Type field calls them.
Also, as mentioned above, it has a big impact on sorting: Things aren’t sorted where I’d intuitively look for them because they start with a different letter. Certain extensions get grouped together as the same “type”. There might be a file that’s getting inferred based on content, but intentionally has a different extension (like how certain file types are valid zip files).
Sometimes file types simply get inferred incorrectly. This can especially happen a lot with custom, project-specific, or outdated file formats. Or when multiple file formats that aren’t inferred by content just happen to use the same extension.
It’s interesting that you mention that, as it made me realize that I actually do the same thing myself - even though I aesthetically like the more descriptive format, in my head it’s “oh, that’s a .txt file.” It’s especially bad in .../bin directories, where my “poking around DOS on an IBM XT” childhood self thinks that’s where the .com and .exe files live 
Maybe it’s a different mental approach, in some ways - finding it easier to scan and sort through slightly more abstract and compact identifiers, as opposed to doing so through written-out text?
1 Like
Didn’t realize we had it already.
1 Like
Those needs to be fixed in Making sure you're not a bot! but whatever is custom needs custom solutions.
You can learn the details in XDG MIME Applications - ArchWiki and the specification.
In my defense, I reviewed it 3 years ago: Add the ability to sort by file extension (!381) · Merge requests · System / Dolphin · GitLab
It also had a feature requests: 429579 – add the "extension" column
1 Like
Yea. And I’m sure there’s a certain amount of shorter-term familiarity too, in addition to the the longer-term ones. While I am finding it very refreshing and helpful to have an extension column again, it’s been so long that when I turned it on it was a bit visually jarring, even for me.
I guess cognitive flatulence is hitting all of us lately. 
I’ll keep that in mind. Thanks for the link.
Oooh, I was wondering if it had been a new feature within the last few years. I almost thought I was loosing my mind, or had lost it a long time ago, because I’ve been on KD…erm…Plasma for probably at least a decade and I could have sworn I’d looked very thoroughly for an option like that several times over that timeframe. I’d gotten so used to just never finding a way to do it, that when I looked again the other night, I really wasn’t expecting it to be there. So I guess that must be why I obviously wasn’t looking as closely as I thought I was.