Bug 404818

Created attachment 224995 [details]
Screenshot for reference

...containing new icon suggestions

For the groups thing, I think we are just using the same as yast2-qt is. If there are better ones available, we'll make use of them. Will check out your suggestions for the status icons as well.

(for curiosity, the reason why alpha transparency isn't respected as in the original ones is because we have used the XPM format in order to easily embed them in the code. If we use some already shipped with Gnome, then we aren't going to embed them in the executable.)

Ok... I just found out that the education icon is no longer part of the icon theme spec and was removed from tango :( but if you want to ship it with yast that would be possible. For office you can use the "applications-office" category icon which should be available in all themes. There's also "applications-system" which may be a better fit for the "System" category.

"Other desktops" and "XFCE" currently use the same icon which is not very nice as well... perhaps use the "user-desktop" spec icon for "Other desktops" and a special icon (like GNOME and KDE) for XFCE? And for "Unknown" "applications-other" would probably fit.

Btw it's also possible to store .png pixmaps in the executable (see GdkPixdata) but storing them separately (or using themed icons) is "better" of cause.

(In reply to comment #4 from Michael Monreal)
> Btw it's also possible to store .png pixmaps in the executable (see GdkPixdata)
> but storing them separately (or using themed icons) is "better" of cause.
> 
Sure, I did use the word "easily". One should be able to easily write some code that grabs any binary file and write those bytes into an inlined array. In the end, we would paste something like:
   const unsigned char png_data[] = { 0xff, 0x6a, .... };
A XPM, on the other hand, is already done and sliced for you. The XPM file already looks like something like:
   const char *image_data = "jkhelu3534i234wekljw ... ";

Anyway, compiling this data into the executable isn't that good of an idea. These data isn't even used for anything other than the package selector thing. But it's just four or five icons, and our executable is much smaller than the qt one already, so I didn't bother going through all the trouble to make it work for automake. (I'm only comfortable with plain old Makefile files...) However, we want to ship our icons in separated files from the executable... Maybe now will be a good time to kill a few birds at once. ;)

I fixed the XFCE group icon and a couple others as suggested. With regard to the quality of the icons on the top, I'd need someone knowledge with autoconf to check that out. Let's try to do that at a later day.

Because the LATER and REMIND resolutions have been removed, the resolution of this bug has changed from LATER to WONTFIX. If this bug needs to be reconsidered, reopen it and set a future "Target Milestone for Fix."

Michael, installing some quality PNG icons then. (At /usr/share/YaST2/gtk if you'd like to tweak something. ;))

Based the installed & available icons on the PackageKit ones. Not sure if the install and remove icons look a bit off, especially because they don't look quite the same size, but, on the other hand, I feel PackageKit ones don't contrast enough... Will append shot...

Asked for a yast2-gtk to be built to Factory.

Created attachment 248402 [details]
screenshot