Titlebar/Panel display or scale custom icons badly

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Use a custom icon for gnome-mplayer or use an icon set that includes
custom icons for the application.
2. Start gnome-mplayer.
3. The Titlebar/Panel icon is scaled from a larger size, rather than simply
use a 16x16px version.

What is the expected output? What do you see instead?
When custom icons are used, gnome-mplayer should use any available 16px
icons for Titlebars, rather than scaling down a larger icon.

What version of the product are you using? On what operating system?
I'm using version 0.9.5 in Ubuntu 9.04.

Please provide any additional information below.
I've noticed this issue since the current gnome-mplayer icon was first
commited. gnome-mplayer inherits custom icons correctly, it just happens to
use a larger icon that is needed. gnome-mplayer seems to be programmed to
grab larger icons and scale them down - the only solution I've come across
is to delete all but the 16px custom icon, but then menu items and docks
don't have larger icons to work with.

I'm attaching a screenshot demonstrating current behavior and how custom
icons would normally be displayed.

Original issue reported on code.google.com by perfectska04 on 11 Jun 2009 at 7:22

Attachments:

• Screenshot.png

[GoogleCodeExporter]

We used to use a 16x16 version of the icon, but other tools like AWN which use 
bigger
icons looked exceptionally bad. 

BTW, that is not the gnome-mplayer icon that I ship... attached is the icon 
that I
provide.

If you want better looking icons, please submit a patch and I will most likely
include it.

Original comment by kdeko...@gmail.com on 11 Jun 2009 at 7:33

Attachments:

• gnome-mplayer.png

[GoogleCodeExporter]

Original comment by kdeko...@gmail.com on 11 Jun 2009 at 7:38

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Yes, I know the current icon you ship is different from the one I attached. The
reasoning was that I meant that custom icons (meaning those that are set by the 
user
or an icon-set, much like the one in the screenshot, rather than gnome-mplayer) 
do
not use 16px when it is available. This isn't a problem with the shipped icon, 
since
that is only available in one size - therefore it looks the same either way.

If this issue is related to the currently shipped icon, then how about a new
tango-based icon available in all sizes (16,22,24,32,and 48px scalable)?

I just did this real quick icon mockup, if you're interested, I could draw the
smaller sizes as well. It's attached.

Original comment by perfectska04 on 11 Jun 2009 at 7:51

Attachments:

• gnome-mplayer.svg

[GoogleCodeExporter]

I guess I am not concerned about the icon specifically, but more about how to 
specify
it so that the window manager gets the size it wants and tools like AWN get the 
size
they need. From what I can tell the icon that both use is controlled by this 
code..

   if (gtk_icon_theme_has_icon(icon_theme, "gnome-mplayer")) {
        pb_icon = gtk_icon_theme_load_icon(icon_theme, "gnome-mplayer", 64, 0, NULL);
    } else {
        pb_icon = gdk_pixbuf_new_from_xpm_data((const char **) gnome_mplayer_xpm);
    }
    gtk_window_set_icon(GTK_WINDOW(window), pb_icon);

So if I chose a smaller value of "16" over the 64, the icon looks good in the 
window
manager, but looks REALLY, much worse than the smaller icon, bad in awn.

Looks like this could be worked around with an icon list. So I'll investigate 
using
one of those.

Original comment by kdeko...@gmail.com on 11 Jun 2009 at 8:18

[GoogleCodeExporter]

Ok, thanks for looking into it!

I would say look into the code of things like Nautilus, Rhythmbox, etc... They 
have
their own icons, but they also allow for custom icons in any size... Metacity 
will
grab 16px, GNOME-Do/AWN will grab the scalable ones, etc.

If their code is somehow incompatible, then perhaps you can simply install the
current icon in /usr/share/icons/hicolor like other applications, and it will 
be used
from there or from an icon theme if an user decides to change it.

Original comment by perfectska04 on 11 Jun 2009 at 8:25

[GoogleCodeExporter]

As for the icon, would you be willing to license it to the project so that we 
could
use it? Or would you like to work on it some more?

Original comment by kdeko...@gmail.com on 11 Jun 2009 at 8:43

[GoogleCodeExporter]

Well, I quickly made it based on sources from the icon set I develop - 
gnome-colors,
so it would be GPL-2. It's the same license described in the gnome-mplayer 
homepage,
so it would be compatible and usable.

The 48px scalable file I submitted looks perfect to me, although I would have 
to draw
the 16,22,24, and 32px sizes so it is truly tango/gnome compliant.

I have to go out now, but if you wish to use the icons, I could have the rest 
of the
sizes and their sources drawn when I get back home.

Original comment by perfectska04 on 11 Jun 2009 at 8:49

[GoogleCodeExporter]

Well I posted it to the mailing list... so definitely no rush to get it done. 
So I
will probably use your icon set (once available). Unless there are any strong
oppositions.

Original comment by kdeko...@gmail.com on 11 Jun 2009 at 9:01

[GoogleCodeExporter]

Ok, I finished drawing all the sizes, just in case. I also made some 
adjustments to
the original icon (fixed some rough edges and gave it a bit of a more metallic 
look.

I'm attaching a tarball with all the icons in GNOME/Tango compliant folders and 
sizes
(16,22,24,32 and 48px scalable), the development sources to comply with GPL-2 
or for
future modification, and a preview file.

Original comment by perfectska04 on 12 Jun 2009 at 2:59

Attachments:

• gnome-mplayer-icons.tar.gz

[GoogleCodeExporter]

Never mind the previous file, I messed up on the correct directory structure for
hicolor. It should be fixed now. I also made the 48px scalable icon a bit more 
centered.

Well, I think with that it should be done. I thought a play button and a film 
reel
would be a good and simple metaphor for gnome-mplayer, but I guess it's all
subjective. Feel free to use the icons as they are GPL-2 and designed with
gnome-mplayer, or reject them (no hard feelings :P) if they don't fit your own 
vision
of the application.

Original comment by perfectska04 on 12 Jun 2009 at 4:17

Attachments:

• gnome-mplayer-icons-2.tar.gz

[GoogleCodeExporter]

New icons applied... please let me know if this fixes the original issue.

Original comment by kdeko...@gmail.com on 12 Jun 2009 at 6:36

[GoogleCodeExporter]

Perhaps it's just my setup (I haven't compiled gnome-mplayer from source in a 
while)
but I get the following error after running ./configure --prefix=/usr

config.status: error: cannot find input file: icons/Makefile.in

Other than that, there's just a really minor bug with the 48px .png icon and 
the 48px
.xpm icon - they were exported as 51x48px rather than 48x48px, so they would 
look
just a bit blurry and stretched. I'm attaching fixed versions for both, so the 
icons
always look sharp.

Original comment by perfectska04 on 12 Jun 2009 at 7:29

Attachments:

• [48px gnome-mplayer icons.tar.gz](https://storage.googleapis.com/google-code-attachments/gnome-mplayer/issue-198/comment-12/48px gnome-mplayer icons.tar.gz)

[GoogleCodeExporter]

Pull SVN now... it should allow things to compile

Original comment by kdeko...@gmail.com on 12 Jun 2009 at 7:45

[GoogleCodeExporter]

Compiled perfectly, the icons now appear correctly in panels/menus/titlebar, 
etc. I
haven't tested with GNOME-Do/Docky or AWN, but since the scalable icons are 
included,
it should look perfectly in docks with sizes up to 256x256px.

Thanks for your great work!

I'd say I much prefer the old seekbar (this one looks a bit like I'm using 
Audacity
instead of playing a video), but that's not related to this issue.

Attached is screenshot showing the new icon looking sharp and nice in the 
titlebar.

Original comment by perfectska04 on 12 Jun 2009 at 8:03

Attachments:

• Screenshot.png

[GoogleCodeExporter]

You can limit the arrows on the tracker, it is a preference in the interface.

Original comment by kdeko...@gmail.com on 12 Jun 2009 at 8:18

[GoogleCodeExporter]

Thanks for the tip, it looks much cleaner after hiding them. I think you can 
mark
this issue as fixed now, since the icons now look as expected in any 
circumstance.

Original comment by perfectska04 on 12 Jun 2009 at 8:22

[GoogleCodeExporter]

Looks nice in Avant as well... that for the hard work on the icons. How would 
you
like to be credited?

Original comment by kdeko...@gmail.com on 12 Jun 2009 at 8:24

• Changed state: Fixed

[GoogleCodeExporter]

Mmm when I did the icons for Comix, they just added "Victor Castillejo: Icon 
Design"
to their credits page. If you have a credits/contributors page, it would be 
nice, but
if not... don't worry about it. gnome-mplayer is the only video player I use, 
so just
seeing it use sharp, tango-esque icons is enough for me.

Original comment by perfectska04 on 12 Jun 2009 at 8:48

[GoogleCodeExporter]

If you would be willing, perhaps you could think of a replacement for the Arrow 
icon
on the tracker. I use the "play" icon to keep consistent with the theme and it 
looks
good in stock GTK, but on the more colorful themes, it may be a little wild. 

Original comment by kdeko...@gmail.com on 12 Jun 2009 at 8:59

[GoogleCodeExporter]

I tried making some arrow buttons in style of a traditional seeker button, but I
couldn't make it look well at all - seekers usually work best when paired with a
traditional seekbar (like Rhythmbox and Banshee). When applied to a 
progressbar, they
look too intrusive. Perhaps something more akin to a slim/smooth crosshair would
complement better this type of progressbar.

However, I personally think the old progressbar would be more intuitive and 
generate
less bugs... For example, the new design is not compatible with KDE4 or anyone 
using
the Oxygen icon theme - since their media buttons are quite different than 
stock GNOME's.

There are also other issues such as colorless progressbars when the 
selected_bg_color
is a dark gray, or completely unreadable text/ugly progressbar color when
selected_bg_color is a shade of black.

With the old progressbar, the background color would look nice regardless, due 
to 3D
shadows, borders, etc. Text was also readable under all situations, since it 
relied
on gtkprogressbar's text colors (i.e. it would become dark or white as the
progressbar passes it). Currently, it relies on input box text colors, so it 
will
break with any theme that sets that color to anything else than black or a dark
selected background.

I'm attaching a screenshot demonstrating the bugs that the new design 
encounters.

Original comment by perfectska04 on 12 Jun 2009 at 9:56

Attachments:

• Screenshot-1.png

[GoogleCodeExporter]

The old progress bar had problems, especially with animated bars (very 
distracting)

None of the problems you are mentioning seem that bad to fix, probably some 
pango
flag somewhere. 

I tried the slim/smooth crosshair and you ended up losing it... I had a box type
metaphor and it didn't look that great either. So this is what I settled on. 
All the
colors are taken from the gtk palette, so the colors should be there.  

Original comment by kdeko...@gmail.com on 12 Jun 2009 at 10:08

[GoogleCodeExporter]

In that case, then perhaps a traditional well placed seeker would look best? It
wouldn't be distracting, it would work with any gtk/icon theme, and the playing
status would be always readable. It could also mean better consistency with 
Rhythmbox
and other interfaces that users are already familiar with, without being too 
much work.

Original comment by perfectska04 on 12 Jun 2009 at 10:28

Attachments:

• seeker.png

[GoogleCodeExporter]

Perhaps that looks better in action.

Original comment by perfectska04 on 12 Jun 2009 at 10:35

Attachments:

• seeker-2.png