Hi, On Fri, Nov 1, 2013 at 3:01 AM, Daniel P. Berrange <d...@berrange.com> wrote: > On Wed, Oct 30, 2013 at 07:02:58PM -0200, Manuel Quiñones wrote: >> Hi, >> >> I wonder how finished are the GObject introspection bindings for >> Entangle. I would like to use its backend to create a free software >> stopmotion app. Or do you think it would be better to use libgphoto2 >> directly? >> >> I saw this stopmotion app http://sourceforge.net/projects/smcapture/ >> but couldn't compile it in a recent Fedora 19. Its development seems >> stalled. > > As mentioned elsewhere in response to another msg, I've done some > work to add onion skining, and other things requested by people > interested in stopmotion work.
I just saw this, and that's an awesome feature. Exactly what I wanted, and what I would have proposed as new feature if that was not already there. :-) Now I have a question though. When I enable image overlay and activate preview, the preview image does not display anymore in the whole Image Display area (over previous image(s)), but as a small scalled image on top left (while the previous layered images only takes the whole area). Is that on purpose? One of the whole point of onion skinning for stopmotion would be to preview what would be the next image layered over the previous ones. For instance to ensure the background has not moved, or placing some objects relative to their old position *before* shooting, etc. Is there a way currently to have the preview over the previous image(s) instead of in a small box by itself? If not, would you mind if I patch entangle to allow this? Note that I may understand if other people may prefer a small box instead of layered preview (other usage, etc.). If so, I can do it an optional view in the preferences. :-) Thanks! Jehan P.S.: unrelated, but while I am at it, I made my first patch to entangle yesterday, fixing the flickering operation progress bar during preview mode: https://gna.org/bugs/?21246 I hope you'll like it and apply it upstream. :-) > > I don't really consider the backend APIs to be stable, so wouldn't > want to expose it as a formally supported library. > > At this point in time, I'd like to think we can get one UI that is > good for all capture use cases, including stop motion. Some of it > might be done as plugins rather than being present by default. If > you have specific features you'd like to see please do file bugs > about them, and mention them on list. > > Daniel > -- > |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| > |: http://libvirt.org -o- http://virt-manager.org :| > |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| > |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| > > _______________________________________________ > Entangle-devel mailing list > Entangle-devel@gna.org > https://mail.gna.org/listinfo/entangle-devel _______________________________________________ Entangle-devel mailing list Entangle-devel@gna.org https://mail.gna.org/listinfo/entangle-devel
