Place For New Ideas

For Developers

Placeholder for useful discussion regarding the GNOME desktop image viewer.

• Some ideas for eog - TimGerla's post to eog-list volunteering maintainership and offering some ideas.

Blog posts discussing eog: (FIXME: summarize important and useful points and ideas here, instead of just linking to discussion)

• TimGerla

• HubertFiguiere

• J5

EoG UI Rework proposal

PaoloBorelli: This summarize where I would like EOG UI to move toward:

Overview

• Why bother with EoG, when there is GThumb, F-Spot, $PROGRAM?

• There is a place in the desktop for a really simple and lightweight image viewer. Note that I say image viewer not photo manager. The use case for EoG is display an image when double clicking on it in nautilus, not managing your photo collection, searching through it, publish it on the web, etc. This doesn't mean that EoG cannot have useful features, just that they should be almost transparent to the casual user: good examples are ICC, Exif, Zoom, etc. EoG should also be nicely integrated in the gnome desktop, for instance without overlapping functionality with nautilus.

• Some of the ideas below are inspired by Evince, why not drop EoG and use Evince for image viewing?

• Because Evince is targeted at multipage documents and the fact that it has been designed with a clear use case in mind is what makes it so good. Just because it's a really good program doesn't mean that we should shove everything into it, it means instead that we should borrow the good ideas where it makes sense so that we offer a consistent user experience.

JoachimNoreiko: but multiple images in a directory equates to multipage document. Take a look at how OS X's Preview does it.

• NguyenThaiNgocDuy: I haven't used OS X. But browsing a directory with hundreds or more of pictures is not exactly like reading a book

  • Joachim: well, you have a sequence of views, which may be pages or images. And a sidebar of thumbnails, which may be pages or images. It's quite similar. Preview on OS X shows a sidebar if you've opened several pictures simultaneously, and it shows the sidebar also for thumbnails of pages in a PDF.

Current UI problems

Currently EoG is split into two "modes", the one viewing a single image and the one displaying a directory, using a scaled down image and a thumbnail pane. This poses many problems:

• the directory mode it's hard to discover (you have to use the command line, right click on the parent dir, or use the "File > Open directory" menu)

• it's hard to switch from one mode to the other
• if the user wants to see a sequence of images in a directory (really common use case) he is forced to think in advance that he needs to open the parent directory or to select all the images he wants to see
• the directory view is pretty poor compared to what provided by F-Spot and GThumb and some of its functionality overlaps with nautilus
• the current toolbar contains items rarely used (New and Open are not common operation in an image viewer and four Zoom toolbuttons are excessive since we handle zoom with the scroll wheel)

Proposed UI

• drop the "directory" mode, only open images, but allow the user to move to the next/prev image in the current directory without closing and reopening the main window
• the toolbar would contain: Prev, Next, Rot. left, Rot Right (not 100% sure about rotation), Zoom Control similar to the one in Evince. Maybe a Start Slideshow item.

LuisMenina: Maybe a switch button in the toolbar to hide/show the thumbnails list pane ? I think it would be quite useful. JoachimNoreiko: How would you know which image next/prev goes to? I'm playing devil's advocate here, but if a user has his folder arranged by name / date / arbitrary icon arrangement, he might expect prev / next buttons to follow that order.

LucaFerretti: An alternate toolbar could be: Fit, Zoom, Real | Mirror, Rotate | Prev, Next. Where Fit and Real are buttons to set the zoom to fit window and to real image size, Zoom could be a slider (a la F-Spot), Mirror a button to flip the image, Rotate a GtkMenuToolButton providing rotate-90-deg-clockwise as main action (the button), and rotate-90-deg-counter-clock and rotate-180-deg actions in popup menu. Of course the Zoom slider is not so useful, if you have a wheel mouse... Slideshow and Fullscreen should be IMHO a single action in the UI: when the user choose View->Fullscreen, a fullscreen view of the current image will be showed, with a floating toolbar providing Previous, Next | Pause, Start | Close Fullscreen buttons. Previous and Next are used to manually browse in fullscreen mode, Pause and Start to start and pause the slideshow mode (some cute effects?).

• a thumbnail list pane could be kept showing thumbs of the current dir; such pane however should be off by default and the user should be able to show/hide it on the fly like the sidepane in evince. Such pane even if similar to evince's side pane, should however by IMHO positioned at the bottom since images are often larger than higher (the opposite of usual text documents)

LucaFerretti: agree. But I prefer at the top, just like in iPhoto in edit mode.

Slideshow and full-screen enhancement ideas

• Start slideshow from beginning
• Start slideshow from current image
• Ability to manually change image during slideshow (next / prev / home / end)
• Ability to change slideshow parameters on-the-fly (delay, wrap around, play/pause)
• No separate modes for fullscreen / slideshow. Slideshow is just fullscreen with delay, fullscreen is just a slideshow paused
• On-image info display: e.g. a tooltip-style info box appears over the image
  • Display image information (size, exif, etc)
  • Display status updates, e.g. "Slideshow paused"
  • Configurable: disappear after timeout / switch on-off / show image info for few seconds on image change

GergelyNagy

Use mouse wheel for next/previous image

I would love to see "mouse wheel down" bound to "view next image", and "mouse wheel up" bound to "view previous image". The mouse wheel currently zooms in and out, and so do the plus and minus keys. I think there are many users who have to go through a lot of pictures and this would increase useability a lot IMHO. -- ChristophFuchs

This was removed during during development of version 2.18. See bug #331645 for details. -- FelixRiemann

I see that using the mouse wheel in the collection view should scroll the collection view left and right, but I am speaking of using the mouse wheel on the image itself. Currently the mouse wheel zooms in and out. I think the user should be able to set the mouse wheel behaviour in the options. Either zoom the image, or show the next/previous image. A simple checkbox should be sufficient. -- ChristophFuchs

I think using the mouse wheel in this way is now counter-intuitive to the way people are used to. The web browser is the dominant force in UIs nowadays and the mouse wheel (or ball!) is used to scroll around the page, as opposed to zooming or navigation. This especially holds true for touch pads. My suggestion would be use the wheel for scrolling around the page, and using a combo like CTRL+wheel for zooming, just as in a web browser. -- SamLown

Just other small enhancement ideas

• I believe eog is really good but i would like that it could consume less resources because if you see eog uses about 9,5 mb of RAM which is a really big amount compared to other programs that basically do the same like GPicView 0.1.3 wich consumes about 4,5 mb I know that eog is more complete but i believe developers should not forget the basic idea of the program which is opening images in a fast and easy way.

• I find it very nasty that eog doesn't have the ability to say: "open with gimp" or something, an idea would be to offer the "open with"-entries that nautilus uses? (LucasRocha: see bug #319859 to keep track of this feature request.)

  • Suggestion: Under "Edit menu" -> "Edit Image" - this can be GIMP or something else. -- ThiloPfennig 2007-01-19 21:00:24

• I hate it using the combination of two keys to go to the next or previous image, I'd like to just press page-up or page-down to mvoe to the next image (like every other image viewer does :P ) (LucasRocha: this is already present in HEAD.)

• I wish that it would re-rasterize SVG "images" when zooming... they're vectors, let's seem 'em. I would think that this would be easy to implement via rsvg. (MattFeifarek: added bug #395280)

• I wish it would reload when the file has changed (unless its been deleted -- I guess). If this needs to be a preferences option then I guess that'd be ok, but it also seems like a sensible default. Basically I develop SVG programatically and would like to use EOG to view the result of any changes.
• I would like to be the basic function in picture viewer: loading the next image before pressing the next button

Creative Commons licenses awareness

It would be great if EOG becomes aware of Creative Commons licenses. See Gnome Integration for more info.

JaimeFrutosMorales

Replacing EogWrapList with a GtkIconView derived widget

As I've found in eog ChangeLog, Jens Finke's first image collection implementation was added to eog in February 2001 (eog 0.7 times). In that time, GTK+ (version 1.x, as GTK+ 2.0 was released in March 2002) didn't have a component like it so i made total sense to have this component implemented into eog.

Moreover, EogWrapList uses a class called EogImageList. This class was developed by Jens together with all the WrapList stuff at the same time that GTK+ 2.0 (and all the GtkTreeModel/GtkListStore stuff) was under hard unstable development. I think that this was the reason why Jens didn't use a GtkTreeModel implementation.

But since GTK+ 2.6, we have GtkIconView, a very practical grid view for data models. It is built in the same sense than GtkTreeView, and its data can be stored in any of the GtkTreeModel implementations, freeing us of the dependence on EogImageList.

But why would we want to rewrite part of eog?

First of all, we are duplicating a lot of code. Sumarizing, EogWrapList could be replaced by an extended GtkIconView (that I'd call EogThumbView) and EogImageList by a GtkListStore.

Some of the advantages I see:

• Simplify the EOG code. Less code, less bugs inside EOG, and we would increase the GTK+ user base

• Rely more on the mature GTK+ library.
• Decrease the dependence on the old GNOME Canvas.

I am cooking a patch that uses GtkIconView and GtkListStore to implement a EogThumbView widget and a EogListStore respectively, and removes the dependence in EogWrapList and EogImageList. I need a little of time to make it work because I am not too familiar with eog code as a whole. I would love to receive feedback and help from longtime eog developers and the eog community. Update: The patch has landed CVS and it is in the eog-ng branch. Please put your comments on the bug #336973 -- ClaudioSaavedra.

Would this allow the collection pane to be movable to the side? I have a widescreen laptop, so having it at the bottom eats up a lot of space. -- JamesAndrewartha

Rework on Eog Icons

• The flip/rotate icons are still low-res and ugly. I'd be better if we could employ Tango Art Libre when it's usable. For now, we could just borrow the icons from Art Libre set and use it as static icons , when Art Libre is ready to adopt, we could switch over. Reference bug #313387

• A little touch up on Eog main logo is needed, I reckon we need an icon that is more gnome-ish, something that reflects the 'eyes' and GNOME. Icon sizes will be in: 16x16, 22x22, 24x24, 32x32, 48x48 and Scalable. I might ask Jimmac or Lapo if they could design for us one.

JamesAndrewartha

Easier rotating

I would like to rotate images with easier way using R key for rotating right and L key for rotating left. (Or any user defined shortcut key). -- snek01

Ctrl+R is already available for right rotation. We could add shortcut for left rotation as well (Ctrl+L). -- LucasRocha

Is possible to use CTRL + ⇦(rotate left) and CTRL + ⇨(rotate right) -- LuigiMaselli

There is shortshut Ctrl+R for right rotation and Shift+Ctrl+R for left rotation now (Eye of GNOME 2.18.1). Do you mean that there is possible to have got more shortshuts for the same action? If it is possible so you can surely add there more simple rotation shortshut as I have written above. I will tell you why I want it: I have got mouse in my one hand and I write with other hand. (Another less important reason is that the same shortshuts are in IrfanView.) -- snek01

Ctrl+R does not work in full screen mode (F11). -- snek01

Fullscreen Ctrl+R should work in the current development version (2.19). -- FelixRiemann

Better use of screen real-estate

How about loosing the icon bar atop EOG? When you start EOG, first you will have the menu bar and then a lot of Icons in a bar. This bar with Icons really takes a lot of space. At work I use IE (yuck I know) but a very decent trick, they have when watching an image is storing the controls in a set place, hidden until the mouse hovers over it. In IE the magnify to 100% size is located right under, saving, printing is top left.

I think it would really be cool if EOG had the same features and as a result, you could show a larger picture in the same piece of pixels, because now you don't have to show the icon bar.Is there also a away of making the picture cover the whole window so you won't see the window border? -- RolandV

On the topic of screen real-estate: an opening an image of almost any size (or viewing it at Best Fit) there is invariably an empty space of approximately 125px to the left and right of the image. I would very much prefer if the border "minimized" around the image. I often find myself manually resizing the window pane along the horizontal access.

Permanent rotate and delete toolbar plugin

I have to say that I use your software mainly for browsing through digital pictures and I often have to do two simple things: permanently rotate images and delete pictures. As this is an image viewing application, it would be best perhaps if this is developed as a plugin which adds a toolbar with three buttons: rotate and save (left and right) and delete.

Interface refinements

This page proposes a number changes for EoG's interface. The idea is to streamline what is already there, to make EoG look nicer and to enhance the user experience a little.