Should the file name include the suffix?

[WildPenquin]

Hi,

I like to know the file name of the file playing. There can be various reasons and I can see I can enable it in the playlist - which is neat! But it doesn't include the suffix. This is important information since I play many different kinds of files, and sometimes I want to know it. I can find it in in the file information context menu, but why is it hidden in the first place?!??

I can get people may have different opinions / stances, hence a poll =)

(OT: Don't get me started on how much I hate Windowses for dumbing down their UI - hiding the suffix was never a good idea! I get it maybe in the case of "important system folders" as the user does not ususally want to work with them etc...).

If I were to add the suffix, what would be the correct way to do it? Bare in mind I'm only superficially familiar with cpp, and just started browsing the source code. I can see something in tuple, tuple-compiler; song-window-qt?

[radioactiveman]

Where do you want the file extension to be displayed? Do you add a separate "File Name" column to the playlist?

Audacious tracks the file extension separately from the file name or path. You can configure a custom format at "Settings -> Playlist -> Song Display -> Custom string". With ${file-name}.${file-ext} you can at least include the file extension in the window title. Does this help?

[WildPenquin]

Where do you want the file extension to be displayed? Do you add a separate "File Name" column to the playlist?

Yes, that's right (maybe I should have included a screenshot).

Audacious tracks the file extension separately from the file name or path.

Yes, this seems to be the case, but only for the UI elements - obviously it needs to track the whole filename somewhere (whatever "track" means) as it's impossible to do any file operations without.

My argument (I'm re-iterating here) is I don't see any reason to do so. The file ending / suffix is just a part of the file name, and maybe it should be parsed only when needed instead, be that by a human or the program (code).

(I made the poll specifically since I can see some users can see the suffix as clutter, which could be an argument, so I'd like to know if other people have opinions. Probably not any strong ones but still :-P )

You can configure a custom format at "Settings -> Playlist -> Song Display -> Custom string". With ${file-name}.${file-ext} you can at least include the file extension in the window title. Does this help?

Not really, it creates more problems than it solves. I now need to change to a file just to see end part of the file name. The file name is also in an awkward position in the UI this way. It's much easier to right click on the playlist and see the whole file name (any file on the playlist, even those I'm not playing) via the information dialog (also: ALT+I). It will also always show the ${file-name}.${file-ext} in the window title, which is something I do not want to see in most cases, as it's more useful to see the metadata (if available) here.

[radioactiveman]

@jlindgren90: What is your view on this? Personally I am also in favor of including the extension in the file name/path tuple. But I assume we should not change the behavior, at least not shortly before the 4.5 release. Would it be acceptable in the early 4.6 development phase? Or would you prefer new tuple entries like Tuple::FullBasename and Tuple::FullPath and make them available in the UI?

[jlindgren90]

The file extension is already available in the tuple API. I do not see any need to change that. It's also available in the info window, audtool, etc.

What is the actual request here? Is it just to have a file name + extension column in the playlist? I am okay with that, but it can be implemented without API changes.

[radioactiveman]

@jlindgren90: Exactly, the request is including the extension in the playlist column. I have prepared a pull request, please review it.