Cannot set custom program icons in the application menu.

Bug #116443 reported by tobyadams87 on 2007-05-23
This bug affects 1 person
Affects Status Importance Assigned to Milestone
libgnomeui (Ubuntu)
Ubuntu Desktop Bugs

Bug Description

When you try to set up a custom icon for an application with alacarte, it's not possible to use a picture that is not in the default folder, it's possible to browse the different folders of the system through the file picker but the pictures/files won't be displayed.

Thank you for your bug report. How are you trying to change the icon ? What type of files did you try ?

Sorry I forgot, could you please add the version of Ubuntu you are running ?

tobyadams87 (tobyadams87) wrote :


tobyadams87 (tobyadams87) wrote :

i basically put Real VNC enterprise viewer onto my system in my home folder, and created a custom launcher in the menu's and tool bars section of the preferences menu, i tried to allocate a custom icon for the launcher, but it wouldn't pick up ANY kind of file. also when pointing the launcher at files the files dont work if they have spaces in them.

Do you only have this issue with realvnc or with all programs ?

tobyadams87 (tobyadams87) wrote :

With all programs, when you try to select a custom icon, you cannot select anything that isn't from the default location i.e. you cant select an icon from your home directory.

Ok I can confirm that with alacarte 0.11.3-0ubuntu2 and Ubuntu 7.04.

description: updated
Travis Watkins (amaranth) wrote :

You need to select the folder the icon is in, then it will show in the preview area in the icon chooser and you can select it.

Changed in alacarte:
status: Triaged → Invalid
tobyadams87 (tobyadams87) wrote :

are you serious?

Actually what we are trying to say is that the icons don't show in the icon chooser when we select a folder where the icons are.

Changed in alacarte:
status: Invalid → New
Travis Watkins (amaranth) wrote :

In that case I cannot reproduce, I can use icons from my ~/Desktop with no problems. Also, if you think this is a bad UI, etc you should file a bug against gnome-panel and/or libgnomeui.

Well I finally understood what your first comment meant, the "file chooser" is here to select the folder then when we select open the files show up in the other window. IMO this kind of "folder chooser" is really bad, it's the first time I see that and it's really weird. This is a request that should be made to gnome-panel and libgnomeui ?

I think the problem here is that the "Browse" file chooser (reached via clicking "Browse" in the "Browse Icons" dialog) violates the principle of least surprise and is badly counterintuitive.

You are expected to choose a folder, not a file. No regular files are listed at any time, so you can't see whether there are files in the folders or not. When you want to choose a file, you have to navigate to the folder one level up (i.e. closer to the root) from the folder that contains the icon you want to use, select the folder containing the icon you want to use from the list, then click "Open" to dismiss the "Browse" dialog and cause the "Browse Icons" parent dialog to MAYBE populate its main pane with thumbnails from the selected folder (IF there are any image files in it), from which an icon can be chosen.

This is not "browsing", since it expects clairvoyance on the part of the user: both in divining what the hell is going on and in knowing, presumably by osmosis, that a particular folder actually contains icons without being allowed to see its contents.

A workaround might be to relabel the button and associated dialog "Fumble Blindfold" rather than "Browse".

Sebastien Bacher (seb128) wrote :
Changed in libgnomeui:
assignee: nobody → desktop-bugs
status: New → Triaged
Changed in libgnomeui:
status: Unknown → New
hawthornso23 (hawthorn) wrote :

The behavior goes well beyond counterintuitive and into the realms of the actively deceptive. What Emmet Caulfield omitted to mention in his excellent comment is that when you first click in folder properties to change an icon, a window opens entitled "Browse icons" which has icons in it - the current icon and all icons in the same folder. And you CAN select one of these if you wish. This establishes the expectation that the name of the game is to browse to and select icons. The user does not expect that clicking the "Browse" button in this "browse icons" window will invoke ... a folder selector. If you click a button that says "Browse" you expect to actually browse. The folder switcher itself furthers this deception by opening in a window labelled "browse" and looking and behaving exactly like a file browser except that all the folders seem to be empty. I can't see how the behavior could be more deceptive. It certainly fooled me which is how I ended up here.

The behavior is not ideal. A true browser would be better. However the deception could be easily addressed without having to change anything except the appearance of the windows which is a fairly trivial fix. I suggest the following.

1. Change the title of the button in the first window to "choose folder" instead of "BROWSE".
2. Retitle the deceptive window "choose folder" instead of "browse".
3. Add the following words to the bottom of the window in the region to the left of the cancel button (which is conveniently vacant).

Thorsten Frey (thorsten-tfrey) wrote :

I can confirm that there must be a bug in alacarte also or still in Ubuntu 9.10. But I think it is not a problem of renaming things, but the dialogue does not choose a folder or a file - the dialogue asks for a folder to create. Seems to be a wrong type of dialogue?

1. e.g the icon /usr/share/icons/oxygen/48x48/apps/kde.png exists and is our candidate
2. start alacarte - choose properties for an entry
3. click "browse icons" - then click button "browse"
4. copy the path /usr/share/icons/oxygen/48x48/apps/ (not the icon name - just the path)
5. Now nothing is displayed
6. type now something in the path e.g. "whatHappensNow"
7. press button "Open" ==> Messagebox "The folder could not be created" (here: happily no write permission in this folder)

Entering the full path/filename + "open" works, but this is not very user-friendly.

I hope that this helps. Regards, Thorsten
-- End --

Changed in libgnomeui:
importance: Unknown → Low
Changed in libgnomeui:
status: New → Expired
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.