80636 - Linux filepicker is not platform consistent

Status: RESOLVED FIXED

(SeaMonkey :: UI Design, defect)

Description

[Agustín Fernández]

In GTK, as in Windows and Mac, there is a common control used for selecting files.
For Windows and Mac Mozilla uses the control of each platform. However, when it
comes to Linux, it uses a different one, confusing the user at first and anoying
it later when it lacks many of the features the regular one has (creating
directories, deleting files, moving files, filtering on part of the name and
with Ximian's Gnome 1.4 GTK's modifications: going to your home directory, to
your documents directory and to your desktop). Other thing to notice is that the
current one is generally very slow to move between directories, not a case with
the native one.
There are some bugs with Mozilla's current filepicker that would vanish if this
bug is fixed.
Check bug 75838, bug 57214 and bug 57215.

Comment 1

[sairuh (rarely reading bugmail)]

->bryner.

Comment 2

[Agustín Fernández]

I think this would be the right solution to bug 72482.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Until the GTK filepicker properly handles Unicode strings, there is no way we
can use it...  The Windows/Mac controls actually support this, so we have no
need to roll our own there.

Comment 4

[Agustín Fernández]

So that means that you can't convert the strings from/to whatever GTK uses? If
not then, what would you exactly need from GTK so that I can file a bug in GTK's
bugzilla about that particular issue?

From personal experience I think that this is a very important usability bug,
since the current filepicker is used a lot and it does not work well at all.

Comment 5

[Boris Zbarsky [:bzbarsky]]

GTK uses single-byte strings.  This is acceptable for languages that can be
written in single-byte encodings.  It completely fails for ones that need a
multi-byte encoding (many Asian languages).  This issue is known to the GTK
developers, afaik -- it's just not high on their priority list.  However,
Mozilla is commited to being localizable to whatever language its users are
using.  If we want to be able to label things in the filepicker with multi-byte
strings or if we want to browse filenames which include multi-byte characters we
have to use our own filepicker.

Comment 6

[Brian Ryner (not reading)]

I guess I'll have to hold onto this bug until GTK's filepicker progresses to the
point that we can use it.

Comment 7

[Dan Mosedale (:dmosedale, :dmose)]

Hmmmm.  In principle, this sounds like a reasonable thing to do, but the last
time I checked the GTK filepicker box, the user-experience seemed just plain
bad.  So I'm not convinced this is the right thing to do even if the i18n issues
get sorted out.

Comment 8

[Aleksander Adamowski]

I've created a new bug that discusses the need for directory bookmarks and
"create new directory" features in XP filepicker. See bug 112900, which I'm
adding to this bug's dependencies (eventual resolution of bug 112900 will make
most of this bug obsolete).

Comment 9

[Boris Zbarsky [:bzbarsky]]

Bug 115981 has nothing to do with the Linux filepicker, sorry.  It's a Windows
bug.

Comment 10

[[e-mail]]

I suggest to close this bug as invalid, since there is no platform consistency
on Linux in any way. The filepickers in Gnome apps, KDE apps, and other apps
like StarOffice differ wildly and offer different features, and similar 
features in a different way. The discussion in related bugs
(eg bug 125133) are open to consider the best of any of these different
filepickers for inclusion, but I am strongly against mimicking a single 
one (and especially against  mimicking the Gnome filepicker because it
lacks several features, e.g. the KDE picker or the StarOffice picker have).

Comment 11

[Agustín Fernández]

I think this has been fixed.

Comment 12

[Jason Bassford]

No specific bug / patch mentioned as the fix.

-> WORKSFORME

Comment 13

[Boris Zbarsky [:bzbarsky]]

For what it's worth, we know exactly what fixed this -- turning on the GTK filepicker.  It's just that it's not worth my time to search for that bug number (or to correct the now-incorrect resolution on this bug).

Comment 14

[Jason Bassford]

Per comment 13.