[Digikam-devel] Moving of preview rectangle in digikamimageplugins

[Caulier Gilles]

Le Jeudi 7 Juillet 2005 11:14, Mikolaj Machowski a écrit :
> Dnia czwartek 07 lipiec 2005 07:58, Gilles Caulier napisał:
> > Le Mercredi 06 Juillet 2005 11:29 PM, Mikolaj Machowski a écrit :
> > > Dnia środa 06 lipiec 2005 16:30, Gilles Caulier napisał:
> > > > > Such moving of rectangle should not be possible.
> > > >
> > > > Done in SVN !!! Please try again and report !
> > >
> > > Thanks, works for me.
> >
> > OK. Thanks.
> >
> > > I noticed just one minute ago. The same situation
> > > is with Aspect Ratio Crop.
> >
> > Yes, i will correct it...
> >
> > > BTW - few days ago someone mentioned about moving of splitting line in
> > > parallel view. This would be useful in border/corner cases. Not very
> > > much important feature but there is reason behind it.
> >
> > splitting line in parallel view from Aspect Ratio Crop ? Perhaps i need
> > a big coffee (bresilian, i love (:=))), but i don't understand what you
> > mean. Sorry...
>
> Sorry, "Separate view" in plugins like Emboss.
>
> Also - preview rectangle goes weird on smaller images. Try 480x360
> pixels or smaller (or narrow ones) and maximize dialog window as much as
> possible. There are numerous symptoms from preview not working at all to
> not synced preview area and "thumbnail".
>
> > > Digikam still causes enormous memory usage for me. But this is not
> > > digiKam itself - X goes wild. Something in digiKam is causing X is
> > > eating memory as locust.
> >
> > Where/When digiKam use memory ? in image editor ? In main interface ?
> >
> > If you have a doubt about memory leak, try to run digikam with valgrind
> > like this :
>
> This rather not mem leak in digiKam itself but something which is
> confusing X-Window very, very much.
>
> > # valgrind --tool=memcheck 0.8-experimental/digikam/digikam
> >
> > ... from your build directory. Don't try to start the main digiKam
> > binary from your install directory (me : /usr/bin/) because its will be
> > very slow to test.
>
> I will try that later.
>
> m.

Fixed in SVN, in trunk, not 0.8.0 branch (obsolete now).

Gilles