After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 142328 - Custom Icon 'Browse...' button opens file selector, not folder selctor
Custom Icon 'Browse...' button opens file selector, not folder selctor
Status: RESOLVED FIXED
Product: libgnomeui
Classification: Deprecated
Component: general
CVS HEAD
Other All
: Normal normal
: future
Assigned To: libgnomeui maintainers
libgnomeui maintainers
Depends on:
Blocks:
 
 
Reported: 2004-05-11 10:32 UTC by Pete Black
Modified: 2006-01-15 21:42 UTC
See Also:
GNOME target: ---
GNOME version: 2.9/2.10


Attachments
Proposed patch (against HEAD). (790 bytes, patch)
2005-05-12 08:31 UTC, Christian Neumair
none Details | Review

Description Pete Black 2004-05-11 10:32:38 UTC
Right-click on desktop icon, click 'Select Custom Icon', then click 'Browse...'
to choose a new icon folder.

File selection dialog pops up, asking you to select a specific file, which
results in the icon selector not working correctly, and the user having to
manually remove the filename in the icon selector's dialog and hitting enter.

This function should either load the contents of the folder containing the file
selected, and make the file picked by the user the selected one, or it should
pop up a folder selection dialog, and allow you to select a folder (hiding the
files inside the folder) since that is what it seems to want as input currently.

Also, the file selection dialog (which should really be a folder selection
dialog the way it is currently implemented, hence this bug report) needs a
preview, since it's helpful when selecting an icon or folder full of icons, to
see what it is you are selecting.

This is very confusing for a new user, and makes it impossible to pick an icon
that isnt in the default icon folder without manually editing the path that is
returned from the filepicker. And without a visual preview of the icons in the
folder you are choosing, the graphical 'browse' tool is of questionable value
anyway.

Ideally, the folder-browser should be integrated into the icon selection dialog,
theres simply no good reason to have a separate 'browse' interface that forces
you to select a folder of icons (without any graphical preview) when the main
select icon interface's purpose is to display a folder full of icons with a
graphical preview, for you to select one.
Comment 1 Christophe Jouny 2004-06-04 13:33:01 UTC
I totally agree, one of the most frustrating point for me in Gnome 2.6 in terms
of usability !! 

Also, because there is no text input in the new file selector, you cannot fast
navigate to that folder you look for. Default is /usr/share/pixmaps when icons
are in /usr/share/icons. Previous behavior allow you to go up one level, hit
"i", then Tab to auto-complete "icons". Now I have to scroll into /usr/share
(Huge directory!!) to find it. This point is probably more related to the new
gtk file selector, but the combination of those defects makes the icon browser
function totaly compromised.


Comment 2 Christian Neumair 2005-05-12 08:12:10 UTC
Thanks for your bug report!

You see two symptoms here:

Pete: This is an issue with libgnomeui, since that library contains the icon
selection widget. It really should only allow you to select directories in the
"Browse" icon chooser

cjouny: Press Ctrl-L, and enter "../icons". Or really switch to "/usr/share" and
enter "ic", which should autocomplete to "icons". Then press enter. Note that
these issues are in no way related to the original bug report ;).
Comment 3 Christian Neumair 2005-05-12 08:31:51 UTC
Created attachment 46357 [details] [review]
Proposed patch (against HEAD).
Comment 4 Christian Neumair 2005-05-12 08:35:13 UTC
Turns out that Nautilus doesn't use libgnomeui directly. I've filed a bug
against eel as well (bug 303887).
Comment 5 Kjartan Maraas 2006-01-15 21:42:01 UTC
This patch was already commited it seems. Closing.