Favicon for site being bookmarked should be used as part of the icon in the Launcher

[Tom Haddon]

The icon of the bookmark created by webfav should include the favicon for the site being bookmarked. Because this may not scale very well it might not be a good idea to just use the favicon, but if it was the current web page icon with the favicon in the bottom right corner, for instance, it would make different entries more visually distinct.

Using karmic i386 - tried to report the bug using "ubuntu-bug" but it crashed on me :(

[Neil J. Patel (njpatel)]

moving to the launcher, as that's where we process the output of webfav.

We already have methods in the launcher to grab a 'screenshot' of the website via gnome-web-photo. The current issue is:

1. We need the same behaviour for links added with webfav
2. We need gnome-web-photo in the default unr build

[Neil J. Patel (njpatel)]

To be a bit more clear, when a URI is dragged-and-dropped onto go-home-applet, if the URI begins with "http", then the launcher will add it to the favorites as usual (with a default icon) and, if gnome-web-photo exists, it will spawn gnome-web-photo async with the right args to create a thumbnail of the website and save it in the launchers cache. Once the thumbnail is ready, the launcher reads it in and replaces the temp icon with the thumbnail.

So, for each favorite, gnome-web-photo is only called once and isn't called at startup or at any other time apart from when new URL's are added.

We need the code-paths that deal with the webfav to do the same, i.e. try and make a thumbnail and only use the favicon if that fails.

[Loïc Minier (lool)]

So I guess that it's very common to be running firefox when one drags that URL to go-home-applet; I understand it means that both firefox and gnome-web-photo will be loaded at the same time. Does this raise the memory requirements for UNR significantly? I'm particularly worried because xulrunner/firefox are known to be memory hogs and we're going to run two instances at the same time.

Perhaps a good test case is:
start UNR afresh, open terminal, check free memory with free (a), launch firefox and open a site, check free memory with free (b), drag URL to go-home-applet, check free free memory with free (c)

If c - b is significantly smaller when compared to b - a I dont see any issue with the new tool; if however we're bumping the reqs from "works with 256 MB or RAM to works with 512 MB or RAM" then it might be worrying and we might want to make this feature runtime enable on higher end computers.

Concerning thumbnails, how large are they typically? Comparable to nautilus image thumbnails or much larger (higher res)? Are these cleaned up when the favorites are removed from the launcher?

I also have some questions related to the implementation of the feature, but that's not blocking inclusion:
- are the thumbnails updated afterwards? Users might not like it if their fav sites show an old screenshot and might not find it nice to have to remove/readd the favorite to get an updated screenshot
- you mention http, you mean http and https are supported in this way? Perhaps ftp / ftps would make sense for bookmarks (but not screenshots) as well, even if relatively uncommon these days

[Neil J. Patel (njpatel)]

> So I guess that it's very common to be running firefox when one drags that URL to go-home-applet; I understand it
> means that both firefox and gnome-web-photo will be loaded at the same time. Does this raise the memory
> requirements for UNR significantly? I'm particularly worried because xulrunner/firefox are known to be memory hogs
> and we're going to run two instances at the same time.

Well, as gnome-web-photo is just meant to be used as a command-line utility, it only really runs for about 3-5 seconds, creates the thumbnail, and then quits. Even though, I think that it's worth carrying out the tests for memory. I'll try and do them over the weekend.

> Concerning thumbnails, how large are they typically? Comparable to nautilus image thumbnails or much larger
> (higher res)? Are these cleaned up when the favorites are removed from the launcher?

They are 128x128, so about the same as nautilus. They aren't removed from the cache when favorites are removed at the moment, but this could easily be added.

> - are the thumbnails updated afterwards? Users might not like it if their fav sites show an old screenshot and might
> not find it nice to have to remove/readd the favorite to get an updated screenshot

Yep, this is an issue and one that I couldn't solve in time for karmic. We could have a time-stamp and update the thumbnails once a week or something. I still think the thumbnails are useful without this solved, though.

>- you mention http, you mean http and https are supported in this way? Perhaps ftp / ftps would make sense for
> bookmarks (but not screenshots) as well, even if relatively uncommon these days

Oh, ftp/sftp etc will work as normal, this is just a special case for http and https URIs. The same thing happens for file:// URIs...we try and load a thumbnail if it exists in the ~/.thumbnail directory.

[Loïc Minier (lool)]

Ok; so this is my current opinion:
- we need to check memory consumption to keep that in the final karmic release; it's probably hard to measure, you might want to add a sleep before the thing exits; not blocking progression to main for now but needs to be checked before release
- it's desirable for the thumbnails to be cleaned up since it's not excessively hard to do and they will pile up if we don't, and then we can't remove the old thumbs; not blocking anything but good target for karmic
- not updating the screenshots is IMO sad for the coolness of the feature but is not blocking anything; I remember how Apple was criticised for the date in the calendar icon on the iPhone screen which was not the current day :-)
- we need to sort out who's going to care for that package in main (UNR devs, Ubuntu UNR team, both, other people etc.) and sort blockers for main

[Loïc Minier (lool)]

I filed a MIR in bug #427833

[Loïc Minier (lool)]

Subscribing Ubuntu Release Team for FFE (NB: not motu-release since I filed a MIR for this and we want this in main or not at all).

[Martin Pitt (pitti)]

To be honest I'm not quite sure what the FFE is here -- generating preview icons for saved bookmarks? if you tested that with current gnome-web-photo, that sounds okay, and not too intrusive. About moving it to main, approved FF-wise, as long as the current package works reasonably (which I expect, since you already filed the MIR).

Please note that this now also touches UI freeze -- please contact the documentation team and tell them about the change, just in case.

[Loïc Minier (lool)]

The FFE was for the UI freeze break

[Martin Pitt (pitti)]

That's fine then. Please ping the doc team about it.

[Jason Smith (jassmith)]

I am not quite sure what the decided upon course of action is here now. Are we doing screenshots, favicons, what?

[Loïc Minier (lool)]

@Jason: ideally both would be supported but gnome-web-photo is NOT going to be included in UNR after all as the issues which need to be resolved for its inclusion in main can't be resolved in time for karmic.

So just favicons but support for gnome-web-photo when installed is nice to have.

[Loïc Minier (lool)]

So gnome-web-photo wont make it to main this cycle as it needs to be ported to use public xul ABI instead of what it's doing right now.

[Steve Langasek (vorlon)]

This UI change wasn't made for karmic, and we're not in UI freeze yet for lucid, so unsubscribing ubuntu-release.