Claiming ownership.

Enhancement, will be forwarded to upstream maintainer ASAP.

Feature request has been forwarded to upstream maintainer.

This problem is still present in the the latest N800/OS2007.

https://garage.maemo.org/tracker/index.php?func=detail&aid=1404&group_id=164&atid=681

Comment 6 Andre Klapper 2008-11-14 20:43:38 UTC

From the current Fremantle File management UI Specification:
"File extensions are hidden. The exception to this is unknown file types,
which, if they have file extensions, will show them as an aide to
identification."

> When I have a file that I have downloaded onto the 770 that has a potentially
> bad file extension,

Any example for this? Please provide an exact usecase, otherwise it can be
quite hard to convince the people that decided this.

> 1) (prefered) Expose the option to unhide known file extentions in the UI
> somewhere.

Michael, would a gconf key work for this, as I consider this request an
advanced user option?

Anyway, this is the only report in all those years, and it has 0 votes. Hence
it's probably a WONTFIX.

Admittedly this is not a common issue but it is an irreversible one with the
standard GUI.

I've been in several situations where I've had to rename a file extension just
to get it past a brain-dead email filter and if the tablet recognized the new
faked extension, there would be no GUI way to change it back.

The hidden extension UI design choice is a silly MSWindows one (but at least
you can turn it off easily there) that was not inherited by the GNOME desktop
(or KDE or XFCE AFAIK) so I am surprised that it was included in Maemo. Linux
doesn't entirely depend on the file extension to define the mime-type so
treating it like a super special immutable part of the filename like it is in
MSWindows is a mistake.

A gconf hack would be sufficient for my purposes but I can already correct
mistakes on the command line.

If the Maemo designers insist on hiding information from the user, I would be
happy if the extension showed up and was editable in the file properties
dialog. At least the user wouldn't have to resort to the command line if a
fat-finger edit of the extension did mistakenly happen on file save.

Comment 8 Quim Gil 2008-12-09 11:01:28 UTC

Roope, any ideas on this one?

Comment 9 Quim Gil 2008-12-23 15:13:18 UTC

Changing summary since easy editing of filename extensions is also requested.

Comment 10 Roope Rainisto 2008-12-23 15:18:29 UTC

Well. At least from the UI side we do not expect/want to show filename
extensions normally in the UI also anytime in the near future. 

The main problem is about mime types and selecting and supporting multiple
applications for a given filetype at the same time. That is an important issue,
and it is being actively discussed, also for Harmattan. 

But whatever the solution is, I don't think it should be left up to the user to
have to a) care b) see or c) have to edit file type extensions, in relation to
seeing the file name. 

So I'd say wontfix to this. (Although yes, we are certainly trying to improve
filetype handling by itself.)

Hum ... 

Example : 

I'm the author of PyGTKEditor, since fremantle, we can't use anymore
gtk.FileChooserDialog due to the theme with his enormous Open button.

But as an source code editor, i want to open one file of my project in which
contain the following files :

- pygtkeditor.py
- pygtkeditor.pyo
- pygtkeditor.service
- pygtkeditor.desktop

But there is no differences visible between this file in the
hildon.FileChooserDialog ... extension is really nedded ...

But it s seems you assume seeing extension isn't for end user ? But here it s
difficult without ...

same thing for image editor ... how does i select the png  version of an image
which exist also in jpg ... random choose ...

Comment 12 Andre Klapper 2009-11-30 15:04:40 UTC

*** Bug 6451 has been marked as a duplicate of this bug. ***

Is this confirmed as a won't fix?

Cannot consider N900 as a mobile 'computer' anymore if it doesn't show or let
us do anything with file extension.

Comment 14 Andre Klapper 2009-12-14 11:12:18 UTC

(In reply to comment #13)
> Is this confirmed as a won't fix?

Confirmed by what?!
Re-read comment 10? :-)

(In reply to comment #14)

> Confirmed by what?!
> Re-read comment 10? :-)
> 

Cool seems like this will have to be install as a plugin for advanced users
similar to Petrovich.

"But whatever the solution is, I don't think it should be left up to the user
to
have to a) care b) see or c) have to edit file type extensions, in relation to
seeing the file name. "

This is where we don't have the same point of view ...
I think i should be left up to the user !

And wontfix is not acceptable ... again !!!

Hello

Is this still "won't fix"?

If so, is there any way (plugins, hacks, a replacement File Manager and file
dialog, whatever) to get this functionality? 

I know that it is not easy to argue that the Fremantle specification of hiding
file extensions is flawed, just as Windows implementations are, so I'm not
going to do this here. I just want to have a fully functional File Manager,
even if the default configuration is to hide the file extension and parts of
the file system.



(In reply to comment #16)
> "But whatever the solution is, I don't think it should be left up to the user
> to
> have to a) care b) see or c) have to edit file type extensions, in relation to
> seeing the file name. "
> 
> This is where we don't have the same point of view ...
> I think i should be left up to the user !
> 
> And wontfix is not acceptable ... again !!!

Comment 18 Andre Klapper 2010-01-18 14:32:53 UTC

Please don't fullquote the entire previous comment without a reason, and please
don't answer above the quote. Yes, this is WONTFIX currently, still.

> If so, is there any way (plugins, hacks, a replacement File Manager and file
> dialog, whatever) to get this functionality? 

I don't know any except rewriting a dialog from scratch.

*** Bug 9525 has been marked as a duplicate of this bug. ***

(In reply to comment #19)
> > If so, is there any way (plugins, hacks, a replacement File Manager and file
> > dialog, whatever) to get this functionality? 
> 
> I don't know any except rewriting a dialog from scratch.

Umm, what do you mean, from scratch? The source is available.
Check
<http://repository.maemo.org/pool/maemo5.0/free/libh/libhildonfm/libhildonfm_2.28.18+0m5.tar.gz>
file "hildon-file-chooser-dialog.c" and "hildon-file-selection.c" (the latter
being the list).

Indeed ... but a bit useless for python dev.

Created an attachment (id=2870) [details]
patch to enable viewing of filename extensions

Made a patch that enables filename extensions to be seen in hildon file manager
and file chooser dialog.

First it simply bypass the few lines that strips the extension from known
filetypes.
Second it rearranges the audio file listing from the current

track
author

to

title
author / track

so that the filename becomes visible.
used libhildonfm_2.28.18+0m5.tar.gz as source for this patch

do any of these related bugs have internal versions?
it makes sense to track patches and assess viability of integration.

Comment 25 Andre Klapper 2010-06-14 16:23:59 UTC

(In reply to comment #23)
> Made a patch that enables filename extensions to be seen in hildon file manager
> and file chooser dialog.

Does the patch make the new behavior optional, e.g. by setting a gconf flag?

(In reply to comment #25)
> (In reply to comment #23)
> > Made a patch that enables filename extensions to be seen in hildon file manager
> > and file chooser dialog.
> 
> Does the patch make the new behavior optional, e.g. by setting a gconf flag?
> 

i don't see any in the patch and think we should.
the functionality improvement is nice, but it changes the default behaviour at
present.
if we had it on a gconf flag, the default behaviour could remain and those who
wish to opt out and use alternative setting should be able to.

The default behaviour is equivalent to having a set of unlabelled buttons where
the user has to guess which one to press. If someone wants to delete a file,
and can't tell them apart without the extension, they can either not delete
either file (which amounts to a bug "file manager cannot manage files"), or
they have to guess which one to delete (which amounts to a bug "file manager
sometimes deletes wrong file"). Neither option is acceptible for a File
Manager. As far as i understand, the patch effectively puts labels on the
buttons, making the file manager actually useful. 

I really can't understand the resistance to actually admitting that there may
be problems with the original philosophy of hiding all extensions. There are
simply cases where the file extension is the *only* way to distinguish files. 




> 
> i don't see any in the patch and think we should.
> the functionality improvement is nice, but it changes the default behaviour at
> present.
> if we had it on a gconf flag, the default behaviour could remain and those who
> wish to opt out and use alternative setting should be able to.
>

Comment 28 Andre Klapper 2010-06-15 10:32:25 UTC

(Please do not answer above the quoted comment and please strip unneeded
quoting)

(In reply to comment #27)
> The default behaviour is equivalent to having a set of unlabelled buttons where
> the user has to guess which one to press. If someone wants to delete a file,
> and can't tell them apart without the extension, they can either not delete
> either file (which amounts to a bug "file manager cannot manage files"), or
> they have to guess which one to delete (which amounts to a bug "file manager
> sometimes deletes wrong file"). Neither option is acceptible for a File
> Manager. As far as i understand, the patch effectively puts labels on the
> buttons, making the file manager actually useful. 
> 
> I really can't understand the resistance to actually admitting that there may
> be problems with the original philosophy of hiding all extensions. There are
> simply cases where the file extension is the *only* way to distinguish files. 
> 
> 

i know for a fact the default behaviour will not be modified, so lets skip the
theoretical discourse and try to find a path where those who want the different
behaviour can have it?
we all know there are people who prefer showing file extensions, its exactly
the same as in windows.
:)