webbrowser and share-like-connect

[Marco Martin]

On Wednesday 22 June 2011, Aaron J. Seigo wrote:
> On Tuesday, June 21, 2011 10:38:11 Marco Martin wrote:
> > * an human readable name
> 
> this is absolutely required. showing the user a facebook url or a path in
> the file system instead of the web page title or the "actual" title of the
> file is not acceptable.

so in the menu itself the name of the resource will appear? (now doesn't and 
seems a bit confusing indeed)

> > * an icon/thumbnail whatever?
> 
> this was in the original proposal ... it's going to be harder to do than
> other items and in some cases likely not possible at all. so it would need
> to be optional.
> 
> for live thumbnails, it needs to generated at runtime, so we can't use the
> icon theme for that. for items that don't have a related visual (e.g. a
> tweet/dent) then an icon would work fine.
> 
> we could require that thumbnails be written out to disk and a local path be
> passed, which would make both the icon case and the thumbnail case
> equivalent in terms of passing in a path (QString). otherwise, we'll need
> two parameters, either or both of which can be empty: a QString path (to
> an image, or an icon name) and an in-memory image/pixmap.

/me senses an use for the scary the structure of the systray pixmap icons :p

> since apps are accessing this via an API, it wouldn't be hard to implement
> the "save the thumbnail to disk" inside the relevant class
> (ResourceInstance?). it's just a matter of performance (hitting disk is
> slow relative to passing things around in memory)

yeah, it would have to be done just as really needed, since doing it every 
time you switch windows or changes the open document could be costly

Cheers,
Marco Martin