diff options
-rw-r--r-- | AUTHORS | 3 | ||||
-rw-r--r-- | ChangeLog | 7 | ||||
-rw-r--r-- | HACKING | 40 | ||||
-rw-r--r-- | MAINTAINERS | 4 | ||||
-rw-r--r-- | TODO | 33 |
5 files changed, 27 insertions, 60 deletions
@@ -1,5 +1,6 @@ Federico Mena-Quintero (federico@gnu.org) +Jens Finke (jens@triq.net) + Arik Devens (arik@gnome.org) -Jens Finke (jens@gnome.org) Michael Meeks (michael@ximian.com) Martin Baulig (baulig@suse.de) @@ -1,3 +1,10 @@ +2004-02-19 Jens Finke <jens@triq.net> + + * MAINTAINERS, + * AUTHORS, + * TODO, + * HACKING: Updated. + 2004-02-19 Alessio Frusciante <algol@firenze.linux.it> * eog.schemas.in: Fixed some typos. @@ -3,7 +3,7 @@ Hacking on the Eye of Gnome o spec file: People from the gnome packaging project are welcome to contribute fixes for - the spec file. + the spec file. o build fixes: "build sheriff commits welcome". Please send a mail with your patch to either @@ -13,34 +13,18 @@ o build fixes: o In all other cases the following rules apply: -I have tried to write the code in the Eye of Gnome with several goals -in mind: +The code for Eye of Gnome was written with several goals in mind: - - It has to be maintainable. + - maintainable, + - extensible, + - correct, + - documented. - - It has to be extensible. +If you want to work on EOG as well, please read the GNOME Programming +Guidelines first, understand their purpose, and keep them in mind when +writing code for EOG. - - It has to be correct. +If you have a patch you would like to put into EOG, please file a bug +using http://bugzilla.gnome.org for the product EOG and attach the +patch to it. This way your submisson won't get lost. - - It has to be documented. - -Being one of the authors of the GNOME Programming Guidelines, I have -tried to apply the principles mentioned there in the code for the Eye -of Gnome. If you want to work on EOG as well, please read the GNOME -Programming Guidelines, understand their purpose, and keep them in -mind when writing code for EOG. - -If you want to put code in EOG, I would like to review it first. -Please mail me a patch to <federico@gnu.org>. If you wish to commit -to the Bonobo component please send a patch to <mmeeks@gnu.org>. This -is to ensure that the code fits well within the grand plan for EOG. -This is not fascism, it is simple and innocent paranoia. - -The reason for this is that EOG code base will grow to be -substantially big. It will be a full product for image viewing and -cataloging; it is not "yet another image viewer". I have to make sure -that the code will be able to sustain such work. - - -Federico Mena-Quintero -federico@gnu.org diff --git a/MAINTAINERS b/MAINTAINERS index 81a70df8..6de869a1 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -1,3 +1,3 @@ -Email: jens@triq.net -Email: federico@gnu.org +Jens Finke <jens@triq.net> +Federico Mena Quintero <federico@gnu.org> @@ -1,15 +1,9 @@ -If you intend to work on any of these issues, please contact -Federico Mena-Quintero (federico@gnu.org) and/or eog-list@gnome.org. -* Bugs: +Please see also bugzilla for a more accurate list of open bugs, things todo: - - Turn on window auto-sizing and create a new window with an - image in it (i.e. by turning on the "open images in a new - window" option or by specifying an image filename in the - command line). The image view comes up a little bit larger - than the right auto-fit size. This is GtkScrollFrame's - fault; for some reason it is including the (un-needed) - scrollbars' requisitions in its own space. +http://bugzilla.gnome.org/buglist.cgi?product=EOG&bug_status=NEW&bug_status=REOPENED + +================================================================ * Finish the ImageView widget: @@ -20,29 +14,10 @@ Federico Mena-Quintero (federico@gnu.org) and/or eog-list@gnome.org. - Figure out what to do with the color correction tables; we are not using them right now. -* Write a directory browser. Maybe this should be done using Nautilus - controls, or maybe we should have a simple and dumb thing of our - own. - * Write the image category mechanism. -* Write the image collection mechanism and its GUI. - -* Progressive loading. Write something like - - typedef struct { - GdkPixbufLoader *loader; - GdkPixbuf *result; - ArtUta *loaded_area; - } ImageLoadContext; - - to allow images to be loaded progressively in the idle loop. This - should be interruptible, etc. - * Animation support: - - Enhance the above structure to support animations. - - Make the ImageView widget understand animations. What to do about tearing when compositing the frames? Should we special-case animations and blast them to the screen whole |