| 1 | If you intend to work on any of these issues, please contact |
|---|
| 2 | Federico Mena-Quintero (federico@gnu.org) and/or eog-list@gnome.org. |
|---|
| 3 | |
|---|
| 4 | * Bugs: |
|---|
| 5 | |
|---|
| 6 | - Turn on window auto-sizing and create a new window with an |
|---|
| 7 | image in it (i.e. by turning on the "open images in a new |
|---|
| 8 | window" option or by specifying an image filename in the |
|---|
| 9 | command line). The image view comes up a little bit larger |
|---|
| 10 | than the right auto-fit size. This is GtkScrollFrame's |
|---|
| 11 | fault; for some reason it is including the (un-needed) |
|---|
| 12 | scrollbars' requisitions in its own space. |
|---|
| 13 | |
|---|
| 14 | * Finish the ImageView widget: |
|---|
| 15 | |
|---|
| 16 | - Write a "fast" version of uta.c:uta_find_first_glom_rect(). |
|---|
| 17 | Right now we just have a hacked version of libart's |
|---|
| 18 | function. |
|---|
| 19 | |
|---|
| 20 | - Figure out what to do with the color correction tables; we |
|---|
| 21 | are not using them right now. |
|---|
| 22 | |
|---|
| 23 | * Write a directory browser. Maybe this should be done using Nautilus |
|---|
| 24 | controls, or maybe we should have a simple and dumb thing of our |
|---|
| 25 | own. |
|---|
| 26 | |
|---|
| 27 | * Write the image category mechanism. |
|---|
| 28 | |
|---|
| 29 | * Write the image collection mechanism and its GUI. |
|---|
| 30 | |
|---|
| 31 | * Progressive loading. Write something like |
|---|
| 32 | |
|---|
| 33 | typedef struct { |
|---|
| 34 | GdkPixbufLoader *loader; |
|---|
| 35 | GdkPixbuf *result; |
|---|
| 36 | ArtUta *loaded_area; |
|---|
| 37 | } ImageLoadContext; |
|---|
| 38 | |
|---|
| 39 | to allow images to be loaded progressively in the idle loop. This |
|---|
| 40 | should be interruptible, etc. |
|---|
| 41 | |
|---|
| 42 | * Animation support: |
|---|
| 43 | |
|---|
| 44 | - Enhance the above structure to support animations. |
|---|
| 45 | |
|---|
| 46 | - Make the ImageView widget understand animations. What to do |
|---|
| 47 | about tearing when compositing the frames? Should we |
|---|
| 48 | special-case animations and blast them to the screen whole |
|---|
| 49 | without tearing? |
|---|
| 50 | |
|---|
| 51 | Maybe we can blast each frame at the proper time without |
|---|
| 52 | tearing, and only use the normal tearing method when the |
|---|
| 53 | user changes the zoom/scroll. |
|---|
| 54 | |
|---|
| 55 | * Write the programmer's and API reference manuals. |
|---|
