PS of course the first phrase should be "this is a placeholder bug ..."

Add jimmac in CC. I hope he could start draw new sexy icons.

OK, fist pass. All non GTK+ stock icons useb by Epiphany are defined in lib/ephy-stock-icons.[ch].

There are icons provided by Ephy itself:
  #define EPHY_STOCK_POPUPS	   "epiphany-popup-hidden"
  #define EPHY_STOCK_HISTORY       "epiphany-history"
  #define EPHY_STOCK_BOOKMARKS     "epiphany-bookmarks"
  #define EPHY_STOCK_ENTRY	   "epiphany-entry"
  #define EPHY_STOCK_DOWNLOAD	   "epiphany-download"

And icons grabbed from gnome-icon-theme:

  #define STOCK_NEW_TAB		   "stock_new-tab"
  #define STOCK_VIEW_SOURCE	   "stock_view-html-source"
  #define STOCK_SEND_MAIL          "stock_mail-send"
  #define STOCK_ADD_BOOKMARK	   "stock_add-bookmark"
  #define STOCK_BOOKMARK           "stock_bookmark"
  #define STOCK_PRINT_SETUP	   "stock_print-setup"
  #define STOCK_LOCK_INSECURE	   "stock_lock-open"
  #define STOCK_LOCK_SECURE	   "stock_lock"
  #define STOCK_LOCK_BROKEN	   "stock_lock-broken"
  #define STOCK_DRAG_MODE	   "stock_drag-mode"

There is also a "missing" stock icon, STOCK_NEW_WINDOW: by now the New Window menu and toolbar item is using an odd "document new" icon.

Created attachment 69407 [details] [review]
A first path to use currently available icons in gnome-icon-theme

* Add a new STOCK_NEW_WINDOW stock icon and use it for New Window item
* Use "tab-new", "bookmark-new" and "mail-forward". Those icons are available in both gnome-icon-theme and tango-icon-theme and are defined in Icon Naming Standard

Make depend on bug # 348389 ("Add document-page-setup icon")

The document-page-setup icon is the named icon as per new standard icon names spet to use in STOCK_PRINT_SETUP, replacing legacy "stock_print-setup".

Other relevant bugs outside gnome.org bugzilla:

* https://bugs.freedesktop.org/show_bug.cgi?id=5741
  This bug ask for mail-send in icon naming standard. Useful for STOCK_SEND_MAIL

* https://bugs.freedesktop.org/show_bug.cgi?id=7599
  This bug ask for security-secure, security-insercure and securiry-broken named
  icon in icon naiming standard. Useful for STOCK_LOCK*

* https://bugs.freedesktop.org/show_bug.cgi?id=7600
  The icon naming standard define "bookmark-new" named icon. Why not plain "bookmark" too?


  

And now a final note about custom Epiphany icons. We have 5 named icons to draw using new Tango style (Jakub?):

* "epiphany-history" 
  used in History menu and toolbar item. I think it should also the icon
  for History window.
* "epiphany-bookmarks"
  same as above for Bookmarks Manager
* "epiphany-download"
  Used in notification icon for download, it could/should be used alse as
  window icon for Download Manager dialog
* "epiphany-entry"
  Icon for the address entry toolbar item. Of course it's used in toolbar editor
  window
* "epiphany-popup-hidden"
  Used in epiphany status bar when there are hidden popups

history, bookmarks and download could be good candidates for inclusion in Icon Naming Standard, maybe as "history-manager", "bookmarks-manager" and "download-manager" named icons in Applications context.

By now I suggest to provide them in Epiphany, but changing their names in 
  1 "history-manager-epiphany"
  2 "bookmarks-manager-epiphany"
  3 "download-manager-epiphany"
  4 "address-entry-epiphany"
  5 "popup-hidden-epiphany"

Of course we should provide icons at 16x16, 22x22 ("scaled" to 24x24) and scalable svg. Icons should be installed under $prefix/share/hicolor/$size/$context where $context is:
  * apps for 1, 2 and 3
  * actions for 4
  * status for 5

Notes:
 - For info about context see Icon Naming Specification 
 - the -epiphany suffix should be the Good(TM) solution for custom icons. The icon naming spec says: <quote>The dash “-” character is used to separate levels of specificity in icon names[...]For instance, we use “input-mouse” as the  generic item for all mouse devices, and we use “input-mouse-usb” for a USB mouse device.</quote>

PS: using the "-epiphany" suffix we could provide named icons still not in icon naming spec, for istance all icons in comment 6.

PPS I forgot to speak about STOCK_VIEW_SOURCE and STOCK_DRAG_MODE. Do we really need them?

Add dependence on 348394 "Update stock_lock* icons to Tango style"

Waiting for new icons in Icon Naming Standard could be long.

Add dependence on

 * bug # 348399 "Tango and icon naming update for stock_fullscreen"
 * bug # 348402 "Add document-open named icon"

Add dependence on bug # 348415 "Missing list-add and list-remove"

-1 !

The Great Jimmac provided icons for view-fullscreen and view-restore (bug # 348399.

Christian, do you think I can commit patch in comment 4?

Sure. Thanks for the patch :)

Patch committed. Time to draw missing icons.

Created attachment 71664 [details]
Popup hidden icon

Here's a popup hidden icon i've done some time ago to replace the one in my installation. Perhaps you can use it

(In reply to comment #15)
> 
> Here's a popup hidden icon i've done some time ago to replace the one in my
> installation. Perhaps you can use it
> 

Yeay, the idea is good, but IMHO there should be more red on emblem. I've a new version ready, using the emblem from mark-not-junk in gnome-icon-theme.

Christian, are you Ok if I will remove stuff from data/art/ directory, moving them on new data/icons/<size> directory and using something like the icons in GNOME Panel (see http://cvs.gnome.org/viewcvs/gnome-panel/icons/).

In short, icons will be installed under ${prefix}/share/icons/hicolor/<size>/app/ directories (see http://cvs.gnome.org/viewcvs/gnome-panel/icons/24x24/Makefile.am?rev=1.1&view=markup ) at multiple sizes as per icon theme request.

Created attachment 75507 [details]
A preview of popup-hidden and download icons I'm going to commit

From left to right: 16x16, 22x22, 48x48 (SVG) and 128x128 (SVG).

A little work is needed, to use the same green in download arrow and to match the "x" shape in popup-hidden. But the point is: do you like it?

PS Of course the 24x24 will be generated using 22x22 + 1x1 transparente border, 32x32 creating it from SVG and retouching in GIMP.

Nice icons, updates about this bug?

(In reply to comment #19)
> Nice icons, updates about this bug?
> 

Download icons are on cvs, installed under $(prefix)/share/epiphany/icons/hicolor/<size>

More progress will come on this week (I hope).

Luca: The icons looks great! Nice work!

Regarding download, isn't download the same as save-as if you really think about it? I know there were talks of doing document-save and document-save-as using similar metaphors to the download icon Luca drew, but nothing commited to gnome-icon-theme yet. That means one icon less to load.

I also think we have a history icon (history-view) in the GNOME subskin of the tango-firefox theme. I'll look it up.

(In reply to comment #21)
> Luca: The icons looks great! Nice work!

Thanks :-)

> Regarding download, isn't download the same as save-as if you really think
> about it? I know there were talks of doing document-save and document-save-as
> using similar metaphors to the download icon Luca drew, but nothing commited to
> gnome-icon-theme yet. That means one icon less to load.

Dunno. Please note that Epiphany is using a "download" icon
  * as window icon for the progress dialog
  * as notification area icon for the same dialog
  * as button icon in a dialog for unknow files
  * in context menu for links

Moreover the Icon Naming Spec defines a "emblem-downloads" named icon to use as emblem for downloads directory. 'cause the download action in Epiphany directly saves the link in this directroy, could be cool to use the same icon.

Maybe we could use "emblem-downloads" and "document-save*" and remove this custom icon from ephy sources...

> I also think we have a history icon (history-view) in the GNOME subskin of the
> tango-firefox theme. I'll look it up.

Great.

Created attachment 77969 [details]
Proposed icon for bookmarks

Just a 5 minutes hack, but what about somethink like this for bookmarks.

Oh, by the way, now I think proper named icon is "web-bookmarks" (as well as "web-history")

Created attachment 78059 [details]
bookmark view in 16x16 and 22x22

Here is bookmark-view (my rough guess at what would do a proper name :)).
Matches the bookmark-new icon in gnome-icon-theme a bit better.

Created attachment 78061 [details]
history view in 16x16 and 22x22

The ones in tango-firefox was apparently cc-by-sa, so I drew some new ones. Licensed as GPL.

@Andreas:
Thanks for the icons, they look good to me!

When checking this in, please add the .xcf files directly instead of as .xcf.bz2.

@Luca:

In the Makefile.am:s you added, you have these rules:

install-data-local: install-iconsDATA
        if  test -n "$(ICONMAP)" ; then \
                (cd $(DESTDIR)$(themedir)/$(size) && $(ICONMAP) -c $(context)) ; \
        fi

uninstall-am: uninstall-iconsDATA 

What are they used for? $(ICONMAP) isn't set anywhere, what program does that refer to? And shouldn't the uninstall rule be uninstall-local, not uninstall-am?

The rule is for using icon-naming-utils, which is meant for themes to use, not apps. So yeah, that rule doesn't belong in Epiphany. As far as uninstall-am goes, if you have an icons_DATA variable, automake automatically has an uninstall rule for it that gets called, so overriding automake and making it call the same rule, is redundant and can break other things.

@Christian and Rodney
Yes, I know; I simply cut-and-pasted rules, I know that should be changed. It was just to have an up and running setup, I didn't checked the exact purpose of rules.

@Andreas
 * history -> looks good to me, just could you use another color around the clock (the blue ring, "corona" in Italian language): there is yet a lot of blue in Ephy toolbar (see bug 348407). Maybe yellow/gold?

 * bookmarks -> dunno, IMHO the current bookmark-add icon is odd. What should the paper represent here? For me something like this [1] from the Amsterdam Blue[2] theme for Camino is better. Of course, not is blue :-) So, this "bookmarks-view" icons shouldn't have the paper on background. I'll open a bug for gnome-icon-theme about it. See also Camino default theme here[3].


[1] http://pimpmycamino.com/img/themes/Amsterdam%20Blue/add_to_bookmark.png
[2] http://pimpmycamino.com/parts/amsterdam-blue
[3] http://www.caminobrowser.org/images/screenshots/bm_manager.jpg

A little update about needed icons. Currently we have:

   #define STOCK_VIEW_SOURCE        "stock_view-html-source"

IMHO we should drop this legacy icon and switch to

   #define EPHY_STOCK_VIEW_SOURCE   "view-html-source"

Of course the "view-html-source" will be a custom Ephy named icon istalled under ${prefix}/share/epiphany/icons/<size>/actions/

Also, here are any other custom named icon we could install with Ephy and possibly use in plugins? For example "feed-available" or "ads-hidden"? Or we'll let plugins to install and use their own named icons?

If stock_view-html-source is deprecated, then yes we should use a new one.

Yes, those icons in e-e should be done too, but as long as they're only used in e-e they should live there.

I'll fix the Makefile.am rules.

It should probably be view-source-html, not view-html-source. HTML is more specific than source.

Created attachment 78289 [details]
New history-view

Purple history-view, tried yellow, but it blended into the white too much.

I don't see how the view-source icon would really help you in the menu there, it rather creates clutter. I could draw it if you _really_ wanted it though, OR I could fix you some HighContrast icons. :)

(In reply to comment #32)
> Created an attachment (id=78289) [edit]
> New history-view
> 
> Purple history-view, tried yellow, but it blended into the white too much.
> 

Commited. It's great!

(In reply to comment #33)
> I don't see how the view-source icon would really help you in the menu there,
> it rather creates clutter. 

Yeah, maybe remove it is the best solution. Christian?

If we don't want to draw another icon, we could use directly "text-html" (the MIME Type icon for HTML files).

Created attachment 78292 [details]
New bookmark-view icon

Book approach similar to the one in Camino (and a bunch of other browsers)

Yes, I think we can remove the view-source icon from the menu.

Btw: were all those .png files in data/icons/*/* done as png, or derived from some other format? Because in that case, we need to add those sources to cvs and dist them. (I added the 2 .svg you added to dist already.)

(In reply to comment #37)
> Yes, I think we can remove the view-source icon from the menu.

Do we have to keep the STOCK_VIEW_SOURCE definition for API stabitily? Could be used by some extenstion?

> Btw: were all those .png files in data/icons/*/* done as png, or derived from
> some other format? Because in that case, we need to add those sources to cvs
> and dist them. (I added the 2 .svg you added to dist already.)
> 

Some sources are GIMP files (xcf.bz2), other sources are svg. All sources should be on cvs, maybe not yet in dist. I'll provide today.

(In reply to comment #36)
> New bookmark-view icon
> 
> Book approach similar to the one in Camino (and a bunch of other browsers)
> 

Commited!

Any other icons left to draw, or can we close this one?

In Epiphany: 
  * We need 32x32 and 48x48-svg for bookmark-view and history-view
    (useful for LargePring a11y theme) in Epiphany.
  * Update "location-entry" and provide it at all sizes
  * I've to track STOCK_DRAG_MODE and STOCK_BOOKMARK stock icons
    (currently using deprecated "stock_drag-mode" and "stock_bookmark")
  * The Epiphany Bookmarks launcher in Application menu issue[1]

In Gnome-Icon-Theme
  * missing security icons [2]
  * missing print setup icons [2]


[1] Rodney suggested on theme list to remome the Epiphany Bookmarks entry from
    Application -> Internet menu "They are abstract concepts explicit to the   
    browser internals. I don't see why there should be separate entries for
    them in the system programs menu." See http://mail.gnome.org/archives/gnome-themes-list/2006-December/msg00004.html
    (PS I was proposing to add "bookmarks" and "history" named icons in  
    Applications category)

[2] see depends on

STOCK_DRAG_MODE
  lib/egg/egg-editable-toolbar.c:
  { "MoveToolItem", STOCK_DRAG_MODE, N_("_Move on Toolbar"), NULL,


STOCK_BOOKMARKS
  src/bookmarks/ephy-bookmark-action.c:
  pixbuf = gtk_widget_render_icon (proxy, STOCK_BOOKMARK,

  src/bookmarks/ephy-bookmark-properties.c:
  gtk_window_set_icon_name (window, STOCK_BOOKMARK);

There are also
  * "Related" toolbar item currently using the GTK_INDEX stock icon
  * "Quick Bookmark" and "Quick Topic" entries in toolbar editor currently
     using a plain + (add) icon.

For the fist we have to add a new custom named icon ("related-bookmarks"?) and a new EPHY_STOCK_RELATED stock item.

Created attachment 78350 [details]
The usage of STOCK_DRAG_MOCE

Maybe we could remove the proxy icon and use the same layout of panel applets' context menu:

  "list-remove"  Remove from Toolbar
  NULL           Move

Created attachment 78351 [details]
New location-entry icon

A simple merge of applications-internet named icon from gnome-icon-theme and entry icon from glade3

Created attachment 78355 [details]
history-view in 32x32 and 48x48

Created attachment 78358 [details]
bookmark-view in 32x32 and 48x48

(In reply to comment #38)
> (In reply to comment #37)
> > Yes, I think we can remove the view-source icon from the menu.
> 
> Do we have to keep the STOCK_VIEW_SOURCE definition for API stabitily? Could be
> used by some extenstion?

Extensions are versioned, we don't guarantee API/ABI. And if an extension used STOCK_VIEW_SOURCE it should be fixed the same way as epiphany itself.

Forgot to mention: the "popup-hidden" is installed in Status context, so you need latest hicolor-icon-theme (0.10 - grab from here[1]). This version of hicolor provides all contexts from Icon Naming Spec at all sizes; whithout this, "status" context is unknown, so the new cool icon can't be found.

I've asked on desktop devel list to update external deps [2], but nobody replied.

Can someone "lobby" this change?


[1] http://icon-theme.freedesktop.org/wiki/HicolorTheme
[2] http://live.gnome.org/TwoPointSeventeen/ExternalDependencies

Created attachment 78439 [details]
The new themable Epiphany loves visually impaired people

So we need high-constrast, low-contrast and lc/hc inverse icons too? Is there a way to (semi)automatically generate them from the normal ones?

(In reply to comment #51)
> So we need high-constrast, low-contrast and lc/hc inverse icons too?

Could be a good addition. HIG says applications should provide those icons. But don't care: by now all the works will be performed in gnome-themes. 

I'll provide Ephy icons for HC-SVG theme, HC inverse could be simply created switching black and white. Low contrast will be created fitering normal icons in GIMP or with ImageMagick.

See [1] for all details about accessible icons. 

> Is there a way to (semi)automatically generate them from the normal ones?
> 

It's not simple: there was some ideas on latest Boston Summit [2], but
  * HighConstrast icons need a complete redesign (more "signs" then icons):
    4 pixels whide borders, no unuseful stuff, no details..
  * LowContrast icons should be renderd on-the-fly by GTK+ - by now you
    can use GIMP as suggested in [1] or ImageMagick to create new image files,
    maybe gegl will help us


[1] http://developer.gnome.org/projects/gup/hig/draft_hig_new/icons-design-accessible.html
[2] http://live.gnome.org/AwesomeArtShit

Created attachment 78455 [details]
bookmark-view for highcontrast

Here is the missing highcontrast icon for bookmark-view.

Luca: You are free to ship everything with HC-SVG, I'm afraid the situation could go out of hands when you find yourself having every icon from all the apps on the planet in that library.

Agree with you about the stuff from AweSomeArtShit. The current approach for  making HC icons let you have most control of the outcome.

Status Update:
  * commited new "location-entry" icon set (waiting for a different solution
    to list non toolbuttons items in toolbar editor)
  * removed STOCK_VIEW_SOURCE definition
  * use NULL icon for MoveToolItem action, and invert order in menu to
    match the same feature of panel applets (context menu for toolitems)
  * removed STOCK_DRAG_MODE definition

== STOCK_BOOKMARK ==

This stock icon is currently using "stock_bookmark" as target. This icon is used:

  1. In bookmark edit/properties dialog
  2. In bookmarks toolitems on toolbar[1]

Functions are src/bookmarks/ephy-bookmark-properties.c:ephy_bookmark_properties_constructor and src/bookmarks/ephy-bookmark-action.c:ephy_bookmark_action_sync_icon  

In 1. we could replace it with a generic "document-properties" named icon.

In 2. we should remove the feature and show no icons when the bookmark has no favicon. 

IMHO the best is provide a new named icon (maybe "bookmark"? which context?) to use just like in the Camino screenshot I linked in a previous comment. Note that  without this we'll have some toolitems with an icon (the favicon) and other with only the text; this is bad IMHO, don't help the used to distringuish items.

Of course this "bookmark" icon should be used only in toolitems, and in Toolbar Editor for Quick Bookmark item, not in Bookmarks menu or Bookmarks editor.


Comments? Better ideas?


[1] when the bookmark has no favicon; moreover this feature seems broken on my 
    2.16 (edgy), but works on HEAD

I'd prefer to use a special icon in [1] that says you're editing a bmk, not just some general 'document': "bookmark-properties" instead of "document-properties" maybe.

I don't remember if the bookmarks-icon-on-toolbar was a concious decision or just a side-effect of some patch; I have to say it looks a bit nicer with the icons than without.

(Btw, it seems you accidentally inverted the order of RemoveToolbar and MoveToolbar in the UI file; I fixed that.)

(In reply to comment #57)
> I'd prefer to use a special icon in [1] that says you're editing a bmk, not
> just some general 'document': "bookmark-properties" instead of
> "document-properties" maybe.
> 
> I don't remember if the bookmarks-icon-on-toolbar was a concious decision or
> just a side-effect of some patch; I have to say it looks a bit nicer with the
> icons than without.

OK, so new app-specific icon for Epiphany. I agree.

BTW, the bookmark-icon-on-toolbar seems to work only if you add the bookmark through the Bookmarks window. Dragging a "Quick Bookmark" toolitem from toolbar editor, the toolitem has no icon. I've to open another bug or it's yet known?

> (Btw, it seems you accidentally inverted the order of RemoveToolbar and
> MoveToolbar in the UI file; I fixed that.)
> 

Honestly is was  intentionally (match the Remove/Move applet on panel layout) :-|

> I've to open another bug or it's yet known?

I don't think there's a bug open for it.

> > (Btw, it seems you accidentally inverted the order of RemoveToolbar and
> > MoveToolbar in the UI file; I fixed that.)
> > 
> Honestly is was  intentionally (match the Remove/Move applet on panel layout)
> :-|

Oh.

In that case, it's ok to commit it again, sorry :)

Created attachment 78696 [details]
Proposed custom icon for bookmarks toolitems (16 and 22 pixels)

Camino-style bookmark icon to use for STOCK_BOOKMARK.

'cause the icon will be used on toolbars and in bookmark properties dialog to identify a "location", I think that Places could be a good context and "web-bookmark" a good name.

Of course the stock item will be renamed as EPHY_STOCK_BOOKMARK to match other Ephyphany custom stock items names.

If it's OK, I'll commit changes (a screenshot will come).

Created attachment 78699 [details]
Preview of new bookmark toolitems

Great stuff happening here, but I find having every single bookmark item prefixed with the same icon counter-productive. Favicons are helpful, but this is just noise.

Hot.

It appears that the 'Popup blocked' icon (shows up in the status bar when a popup is blocked) is missing in the latest epiphany release. Any thoughts?

Confirming the issue Reinout experiences.

The popup icon shows up fine with hicolor-icon-theme 0.10 (reinout has 0.9).

Just a reminder: http://www.feedicons.com/

While related to epiphany-extensions (see previous comments), I think Epiphany should use the common icon to identify feeds (common to FF end IE). 

See also
  * http://www.opmlicons.com/
  * http://shareicons.com/

That's not possible, see bug 324511 about the licence problem with those icons.

You would want the icon in the tango style anyway. You don't need to specifically use that icon, in order to have one representative of the metaphor in another style. There have been requests to put such an icon in gnome-icon-theme and/or tango-icon-theme, but it needs a reasonably good name for that to happen. Just calling it "feed" or "rss" won't do. It needs more context.

Created attachment 79539 [details]
Feed icons in 16x16, 22x22, 32x32 and 48x48

Crappy naming, but here they are, tango-style and stuff.

Pretty cool :).

Only thing I don't like is that there's some empty space in the top right corner, but it's because I'm used to the widespread feed icon I guess.

Diego: Tried to make them look as close as possible to the ones on feedicons.com, but some weirdness might have sneaked in.

what about the name feed-subscribe for the rss-icon?

** About feed icon **

I've a working patch ready, using images from Andreas. Everything is managed by "rss" extension, so:
  * the named icon will be installed in $prefix/share/epiphany-extensions/...
  * we need to add this directory to icon theme seach path only for rss ext.

The best place seems to me the ephy_rss_create_statusbar_icon() function in ephy-rss-extension.c, just before gtk_image_new_from_icon_name() call.

Also, IMHO the right Context/Name for this icon is Status/feed-presence (or feed-available?).

#### the patch ####

Index: extensions/rss/ephy-rss-extension.c
===================================================================
--- extensions/rss/ephy-rss-extension.c (revisione 1430)
+++ extensions/rss/ephy-rss-extension.c (copia locale)
@@ -69,7 +69,7 @@
        "stock_connect-to-url"          <-- Globe with a plug
        "stock_internet"                        <-- Simple globe
 */
-#define STOCK_ICON     "stock_hyperlink-toolbar"
+#define STOCK_ICON     "feed-presence"
 
 static void ephy_rss_display_cb        (GtkAction *action, 
                                         EphyWindow *window);
@@ -381,6 +381,9 @@
        data->evbox = gtk_event_box_new ();
        gtk_event_box_set_visible_window (GTK_EVENT_BOX (data->evbox), FALSE);
 
+       gtk_icon_theme_append_search_path (gtk_icon_theme_get_default (),
+                                          SHARE_DIR G_DIR_SEPARATOR_S "icons");
+
        icon = gtk_image_new_from_icon_name (STOCK_ICON, GTK_ICON_SIZE_MENU);
        gtk_container_add (GTK_CONTAINER (data->evbox), icon);
        gtk_widget_show (icon);

PS any other changes in epiphany-extensions are related to new files/directories.

Created attachment 79572 [details]
Ephy screenshot using feed icon from Andreas

Absolutely sexy.

I think we don't have to append yet another icon path; installing the e-e icons into epiphany's directory is fine, IMHO.

(In reply to comment #77)
> I think we don't have to append yet another icon path; installing the e-e icons
> into epiphany's directory is fine, IMHO.
> 

Unfortunately we have to know that (full) path in order to install icons from epiphany-extensions. We can't simply grab $prefix in epiphany-extension and trust the hand-builded $(prefix)/share/epiphany/icons as installation path: see for example the Debian based systems, where this path becomes $(prefix)/share/epiphany-browser/icons :-(

To do this, I think we have to export $(pkgdatadir) (aka SHARE_DIR in Ephy source files) through the epiphany-version.pc file, then reuse it in epiphany-extension calling `pkg-config --variable=pkgdatadir epiphany-2.17` somewhere in configure.

If you think it's OK I can prepare, test and commit needed changes.

PS the RSS extension isn't in the list of default/common extensions to build. Is this OK?

I'd say that if distros choose to move files around that's their problem. But I'm ok with introducing a "icondir" = pkgdatadir/icons variable in the .pc file.

RSS isn't part of the default set yet, yes.

(In reply to comment #79)
> I'm ok with introducing a "icondir" = pkgdatadir/icons variable in the .pc
> file.

Is seems I'm unable to do this :-(

I tried a simple

  icondir=@pkgdatadir@/icons   (in epiphany.pc.in)

and a more complex

  icondir=@SHARE_ICONDIR@  (in epiphany.pc.in)
  +
  AC_DEFINE_UNQUOTED([SHARE_ICONDIR],                   (in configure.ac)
                     ["${pkgdatadir}/icons"],
                     [path to install custom themeable icons]) 


The first one remains therefore as it is (@pkgconfig@).

The second one remains as it is in .pc file (@SHARE_ICONDIR), while value for SHARE_ICONDIR variable in config is "/icons"

Any idea? Maybe ${pkgdatadir} is used only Makefiles?

@datadir@/@PACKAGE@ should work.

feed-presence icon in now on svn trunk :-)

(next step for ephy-extensions: adblock icon)

From initial comment on #332968:

"Furthermore, if I click on an image because I want to save it, the icon used to
save the webpage and the one used to save the image are the same, which
sometimes led me to mistake and made me save a webpage when I wanted to save an
image."

Can we get a nice save-image icon or a save-webpage icon :)?

Why don't we just get rid of the save icons here? Or at least for the "Save Image As..." item. It's only in the context menu, not the toolbar. It really shouldn't have an icon. And to differentiate "image" and "web page" in a 16x16 icon, that also needs to say "save as" is a bit much for an icon.

Commited changes suggested from myself in comment 60 (EPHY_STOCK_BOOKMARKS and custom "bookmark-web" named icon). As you can see the icon name is changed, 'cause the generic part here is bookmark, not web (generic icon: "bookmark"; specific icons: "bookmark-web", "bookmark-filesystem",...)

@Jakub (comment 62): the bookmark icon will be used only if the bookmark don't provide a favicon, the posted screenshot was just a corner case. Now all bookmark buttons on toolbar have an icon: this is better, IMHO if you have "mixed" bookmarks on toolbar. Of course the new icons is not used in Bookmarks menu or window.

PS: of course due to bug 387920, sometimes the bookmark icons disappear from toolbar :-(

Are we sure that "bookmark-view" and "history-good" are proper names for icons? 

The first should at least be "bookmarks-view" (plural) and both are better in "open-*" form IMHO.

OK to change code and filenames before hard code freeze (March 5th)?

What is "history-good" anyway? Is there also a "history-bad" or "history-neutral"? That seems like a horrible name. And no, you shouldn't prepend the icon names with open-. Look at the spec for generic names. nothing is prepended with open-. And in this case, you aren't actually opening anything. You get a new view of data that's already available. You're not viewing the bookmarks either. Presumably the goal of the UI in question where the icon is used, is to manage/edit bookmarks, not view them.

Also, I would not try to specify what the bookmark is for by creating bookmark-web, etc... icons. At that point you end up just putting the "bookmark" bit on top of every type of file there is, and you dilute the metaphor. Bookmarks are bookmarks, whatever they are for, be it paperback, hardcover, or digital media.

Moving to 2.20 target due to feature and UI freeze for 2.18.

New security icons landed on gnome-icon-theme (trunk): security-medium and security-high. We could use them for secure and insecure sites, but I'm not so sure.

The trivial change is:
--- lib/ephy-stock-icons.h      (revisione 7059)
+++ lib/ephy-stock-icons.h      (copia locale)
@@ -37,8 +37,8 @@
 #define STOCK_PRINT_SETUP          "stock_print-setup" /*document-page-setup*/
-#define STOCK_LOCK_INSECURE        "stock_lock-open"
-#define STOCK_LOCK_SECURE          "stock_lock"
+#define STOCK_LOCK_INSECURE        "security-medium"
+#define STOCK_LOCK_SECURE          "security-high"
 #define STOCK_LOCK_BROKEN         "stock_lock-broken"

The result in next comment...

Created attachment 89092 [details]
Ephy screenshot using new security-* icons available in gnome-icon-theme

Please also note the Icon Naming Spec defines "security-low" (not yet available in g-i-t): are we sure that security-low will be good for broken status? Dunno.

Security-low is in practice the same as no security. 

Low is equivalent to none, but != broken, definitely.

Which versions of hicolor-icon-theme and g-i-t does this depend on, is the h-i-t version the approved external dependency version ?

So we've been telling users for years to look for the 'lock' icon, and now we're changing it to .... whatever that thing is ?

The security-high shield is not so clear at 16x16. Maybe we just make the shape typical shield in wood, silver, gold finish?

I agree with Christian. Changing the lock icon to a shield is a ridiculous idea. Even if we change our own documentation to explain it, every bank tells its customers to look for the yellow lock in the lower left, or otherwise not to trust the site they're visiting.

(In reply to comment #93)
> Low is equivalent to none, but != broken, definitely.

IMHO security-* icons should be:
  Icon             | Example
-------------------|----------------------------
  security-high    | well behaving https
  security-low     | https with outdated certs 
  security-none    | simple http
  security-broken  | recognized phishing site

or similar (for example, security-low could be named security-medium)

> Which versions of hicolor-icon-theme and g-i-t does this depend on, is the
> h-i-t version the approved external dependency version ?

h-i-t >= 0.10 for "status" category - external dep from GNOME 2.17
g-i-t trunk - it will be 2.20 

> So we've been telling users for years to look for the 'lock' icon, and now
> we're changing it to .... whatever that thing is ?

If we are going to made icons themeable we can't trust the shape and the metaphore (you should not put in the UI something like "To open your bookmarks click on the icon representing a gray book with an orange strip over it").

But, yes, I can't distinguish current security-high icon too. Jakub?

(In reply to comment #94)
> The security-high shield is not so clear at 16x16. Maybe we just make the shape
> typical shield in wood, silver, gold finish?
> 

*-low --> http://www.digital-street.com/img/tutorials/old-wooden-shield/25.png
*-medium  --> http://www3.sympatico.ca/tomkaczor/img/pics/tarst4.jpg
*-high  --> http://www.int-int.biz/acatalog/covert_vest_kevlar.jpg

:-D

(In reply to comment #95)
> I agree with Christian. Changing the lock icon to a shield is a ridiculous
> idea. Even if we change our own documentation to explain it, every bank tells
> its customers to look for the yellow lock in the lower left, or otherwise not
> to trust the site they're visiting.
> 

This could mean dump security-* icons defined in Icon Naming Spec and use new custom Ephy icons.

But we should also ask to icon themers to use the padlock metaphor for those icons, if themeable :-/

I forgot security-none: http://www.sandowmuseum.com/sandowfigleaf.gif

;-)

I like the lock icon, it's  pretty much a standard as the orange feed icon for RSS.
Also the shield doesn't say much at first sight.

In any case, redraw the lock icons in tango style but keep them as lock icons.

Apparently both safari and ie use the lock [1], so that would lean towards using that metaphor. A strange side behavior is that ephy shows a unlocked lock when I visit regular pages in the lower left corner. Why is this? 

Pro-shield argument would be that shields protects you from stuff, while locks just locks stuff up (and it is used for dialog-password already). But, familiarity  is quite important (especially for serious security related stuff like this).

1. http://mark5.co.uk/secbrowsepop.htm

Definitely lock. 

I think we need to include metaphors used for our icons, so that while it is technically possible to redo everything as small happy rubber ducks, any "freedesktop standard compliant" theme would have a commonly agreed metaphor for each icon. This should help documentation writers a lot too, as well as keeping consistency.

I copied the lock icons from g-i-t 2.16 to ephy svn.

>> Changing the lock icon to a shield is a ridiculous idea.

The lock icon is perhaps the worst metaphor for security I have ever seen. Being used by lots of other apps doesn't mean it is the right way to do.

I asked my girlfried (who is not into computer tech very much, but uses the web etc) what the lock icon meant to her. I expected her to say "I don't know what it means" but instead she said it has to be something that is blocked or disabled.

For SSL, you could argue that unwanted access to your connection is "blocked or disabled", but a shield would still be more meaningful, as it stands for protection and that is what we want to tell the user.

It's not the fact that other apps are doing it this way. It's the fact that each and every company and institution with secure webpages is telling their clients to look for a lock icon to verify security. Until Epiphany has >50% of browser market share, we're not going to change that.

FWIW, those same people also tell their clients that they need to use IE 7, Netscape, Mozilla, Firefox, or Safari. They will never mention Epiphany. Claiming that no change regarding this can happen until Epiphany has >50% market share is just insane. Apple sure isn't waiting for Safari to get >50% market share to do anything interesting with it. Nor are Netscape or Mozilla, with their products. Also, because people tell their clients to look for a lock icon, it's also one of the most prominent aspect of phishing pages these days. A lot of companies also stick lock icons in their own pages. So either way, it's really a lose-lose situation for the people that don't have the understanding to validate the URL and other aspects of what they're looking at before continuing on to enter their password.

(In reply to comment #105)
> It's not the fact that other apps are doing it this way. It's the fact that
> each and every company and institution with secure webpages is telling their
> clients to look for a lock icon to verify security. Until Epiphany has >50% of
> browser market share, we're not going to change that.
> 

*** Bug 499429 has been marked as a duplicate of this bug. ***

This is done. Please open new bug(s) for any further tango issues.