hugin::Images

[Kai-Uwe Behrmann]

Am 11.06.03, 22:53 +0200 schrieb Pablo d'Angelo:
> Hmm, I haven't decided wether to split the changed messages into smaller
> parts yet. We have 3 ways:
>
> 1. leave it like it is, notifies about any change.

This is from a programmers view very easy ending to adjust some gui things
twice or more after an small change. Namely if adding an image while
working in the CPEditorPanel. With this method we would later go to
remember many of the gui state and try to recover from saved values. This
would be very complicated - scroll positions of windows, selected tabs
..(?)

> 2. create special functions for different changes (like you
>    suggest).

I hope to avoid the problems mentioned above alltogether. These functions
can be called through the Panorama class.

> 3. One function with an argument (enum) that indicates what
>    has changed.

With option 2 and 3 we have to grow up some funtionality in the gui
related part. With option 1 it would be a real gui thing. This could let
the Panorama class still simple an blow up the gui. For 1 I would need to
know the state of the gui/pano befor and after a change to know what is to
be updated.

> I see that it is tempting to specialize the change messages a lot, but
> sometimes it can be counterproductive, when clients assume to much about
> the Panorama. I had this in the first version in QT hugin. the code to
> handle the changes was more complicated than the one for the global
> panoramaChanged() version.

agree, all grows from now

> which operations do we need?
> panoramaImageAdded(int imgNr);
> panoramaImageRemoved(int imgNr);
> panoramaImageChanged(int imgNr);
>   this then should be called for many images when one in the middle is
>   removed. or when images are swapped.

What do You think about an update signal to Panorama after all changes
from the gui, to let Panorama decide wich parts have to recieve further
commands.

> > You added an class ImageChache. Isnt it the same like wxImageList?
>
> Nope, wxImageList only stores wxBitmap, not wxImage (wonderful naming,
> isn't it). But I need wxImage's to do image processing on them, wxBitmap
> is a platform dependant format, for fast display, not image processing.
> We also might need to be able to unload some images from memory, when
> projects consist of many images, and only store some small thumbnails.

The naming is funny, beautiful pitfall I was walking through ;-)

> And one can ask ImageCache automatically loads images if its not already
> there.

> ciao
>   Pablo

Kai-Uwe