eog refactoring



Hi,

I was going through the code, and have some ideas about refactoring eog
to make it more modular and reusable.

My basic idea is about factoring out the image viewer widget, and
possibly push it upstream to Gtk+ (see Project Ridley). Also, the image
class could be improved by more standardized metadata handling. Details
follow:

Image viewer widget
~~~~~~~~~~~~~~~~~~~
Eog's image viewer widget can be useful in other gtk apps too. There is
GtkImage, but it's more for displaying than viewing images--no zoom,
etc. One way to go is to subclass GtkImage as e.g. GtkImageView, another
is to create an "independent" GtkImageView.

Functionality:
 - Zoom/pan/rotate/flip view
 - Full screen handling
 - Animation (gifs, etc)
 - Transition effects(?)
 - Color correction (CMS)

So it's mostly what eog's viewer already can do. 

Image class
~~~~~~~~~~~
Either the viewer widget consumes the GdkPixbuf within the Image, or the
Image class could be pushed into Gdk and consumed directly.

eog-image now seems like a mixture of stuff that eog needs and that
GdkPixbuf misses. Ideally there would be something in Gdk that
represents and image. GdkImage is unfortunately something different...

Stuff that belongs in an Image class:
 - The pixbuf(s) (e.g. multilayer)
 - Metadata
 - Operations/Effects (metadata safe)
 - Thumbnail(?)

Metadata
Metadata handling should be standardized. Eog is now too EXIF specific.
I suggest a property-based get/set/enumerate style metadata access.
Property mapping to the actual metadata format would be handled
internally. E.g. the width property should be agnostic to wether it's
stored in EXIF, IPTC, XMP, PNG metadata, or the image data itself.
Getting it should return it consistently, and setting it should update
everything. CMS profile (color management) can be included here, or
handled separately.

Stuff that belongs to an Eog specific image class:
 - Uri
 - Caption
 - Undo list
 - etc
 - Thumbnail(?)

Where the thumbnail belongs exactly is up for discussion. (Ok, the rest
of course too :)

Eog itself
~~~~~~~~~~
With the image and the viewer cleanly separated, eog (the "shell")
itself is reduced to managing a list of images, and displaying them.
This can be done in C or even Python, like it was brought up earlier.

I look forward to comments.

Cheers,
Greg




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]