GNOME Bugzilla – Bug 167592
Open in eog when image hyperlink activated
Last modified: 2013-12-14 22:25:43 UTC
Currently we open an image in eog when the user selects 'open image' from the image context menu. If it is implementable and when it doesn't lead to unwanted scenarios, it would be good to do the same with hyperlinks to images.
Is it just me or does opening an image in eog from the context menu completely fail in 1.9.5.1?
As far as I understand, that isn't easily implementable. Epiphany decides which context menu items to show based on EPHY_EMBED_CONTEXT_* flag set received from ephy_embed_event_get_context(). The function EventContext::GetEventContext decides which context flags to set based on what element was right-clicked in the DOM tree. So if the element is <img>, Epiphany displays the context menu for images, if the element is <a>, Epiphany displays the context menu for links. But Epiphany can't know what kind of document the <a>-link is pointing to. It doesn't know it before it starts to download the link and receives its MIME-type. Then it can see that it is, for example, an application/zip document and decide that it should be opened with file-roller. Epiphany could give all links like <a href = "http://bugzilla.gnome.org/skins/custom/gnome-64.png">this</a> to eog, but then you would never be able to open image-links inside Epiphany and that wouldn't be so good I think. Epiphany could also guess what the link is pointing to by checking the extension of the link. "If the anchors link ends with .png, show the image context menu" But that would be very error-prone and Epiphany would guess wrong very often.
This definitely needs gecko support, so it goes to exthandler instead of instantiating a image document.
Does a Mozilla bug exist for this? I'd want to file it but I should first know what to ask for exactly. :-)
I haven't searched for a gecko bug yet. Also I think just filing a bug is useless, without having someone who'll implement it.
If you mean opening eog when I click on something with href="blah.jpg" then I totally disagree. I would hate to open another app just to see an image (which ephy is totally capable of doing). Having the chance to right click and selecting "open image on eog" would be a different history
That's exactly what this bug is about, yes.
Diego: right clicking an image and selecting 'open' *already* opens EOG. Using EOG to view an image is better than doing it inline in Epiphany, because EOG is much better at scaling.
A decision needs to be taken here. Either we decide it keeps opening images inside the browser window, or it calls Eye of GNOME. Adding ui-review keyword for the design team if they have thoughts on that.
Putting the ui-review keyword doesn't suddenly make it NEEDINFO.
No, but a decision needs to be taken nonetheless, and the 3.x series would be the perfect time to end this, especially by having the gnome design team review it (and that's why I put the keyword). It's not like leaving a 7 years old bug report open "because nobody has made a decision" is going to help Epiphany devs get lean. Items like these are paralysis and I would humbly suggest the devs or design team to say a final yes or no here.
The trend in the past period has been towards _less_ external viewing instead of more (case in point: view source in gedit vs. inline). I don't think image scaling quality is still a problem, however EOG still has much nicer scroll zooming, meta info, rotation buttons etc. Whatever the decision will be, please let's try to be consistent in viewing browser-supported content either all inline (including plug-in supported content) or externally, when a specialized Gnome handler is available. Personally, I would favour the latter.
I think the tentative design shows what we would want to happen (2nd row, 2nd column): https://live.gnome.org/Design/Apps/Web#Tentative_Design - Inline reading (the image is directly in the browser) - Make it easy to download and open in the default pictures application (the "Save to Photos" menu item).
That's correct. What I hope for it to view as much as possible inline and supplement or replace the "Save As" or "Open with" functionality. So, I don't think we want to do what this bug suggests.