I know there was an issue not too long ago regarding Animated GIFs, but this is more about simple support for Animated GIFs. I don't necessarily care about having the ability to edit the animated GIFs, just viewing them is good enough for me.
Up: I still keep this feature actual for myself ( https://github.com/HoverHell/mcomix ). I've merged the svn trunk there, which means this feature (and couple others) can be merged rather easily (by whomever has the write access to the svn).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am sorry for the late reply. I am posting this mainly because another request for this just came in (see [bugs:#107]). Obviously, it seems that this is an often-requested feature. Unfortunately, I do not have much spare time left for MComix development, and there is also a workaround for this (see below). Therefore, I am currently not motivated to do much about this issue. I am sorry, again. I wish that I had more time for this. Are you (and by "you", I also mean Momoe), by any chance, interested in supporting me? I cannot promise anything, and, based on what things look like now, it will take a long time until this will be implemented. That is, I could really use your help.
As I said, there is a workaround: Use File → Open with → Edit commands and add a line there to run a player such as mpv, e.g.
The patch I'm using gives minimal support for animated gifs, and it still
works. It's quite too experimental,which is why it is hidden under a
non-GUI setting. But it works. At the very least you can apply that patch
(wih the hidden documented setting) to the main codebase.
I am sorry for the late reply. I am posting this mainly because another
request for this just came in (see [bugs:#107] https://sourceforge.net/p/mcomix/bugs/107/). Obviously, it seems that
this is an often-requested feature. Unfortunately, I do not have much spare
time left for MComix development, and there is also a workaround for this
(see below). Therefore, I am currently not motivated to do much about this
issue. I am sorry, again. I wish that I had more time for this. Are you
(and by "you", I also mean Momoe), by any chance, interested in supporting
me? I cannot promise anything, and, based on what things look like now, it
will take a long time until this will be implemented. That is, I could
really use your help.
As I said, there is a workaround: Use File → Open with → Edit commands
and add a line there to run a player such as mpv, e.g.
Status: open Group: SVN Created: Sun Mar 01, 2015 11:24 PM UTC by Xylemon Last Updated: Sat Feb 27, 2016 12:38 PM UTC Owner: nobody
I know there was an issue not too long ago regarding Animated GIFs, but
this is more about simple support for Animated GIFs. I don't necessarily
care about having the ability to edit the animated GIFs, just viewing them
is good enough for me.
I further improved the animation branch and already merged an (unfortunately buggy) version to master. Few things to note:
If animation is enabled, certain calculations in zoom.py assume that animations can be scaled just like normal images while they actually remain unchanged. This breaks things like "Fit to width" in double page mode if one image is animated and the other one is not. (In this case, downscaling will be performed on the scalable image but not necessarily enough to make the double page actually fit.) While this is unsolvable in principle (for example, if the animation is wider than the viewport, there is no way to make it fit), the current approach does not degenerate the scalable image to a one-pixel wide line.
If all visible images are animations, the user will not get any feedback if, for example, he or she changes the zoom factor. If the user accidentally changes the zoom factor to the maximum due to this, flipping to the next scalable image will result in a possibly huge rendered image (which might result in huge memory consumption) and he or she might be confused. A possible workaround would be forcing animations to be always single-sided and ignore any user input events that will not be reflected by the animation. This, however, is quite complicated and would be obsolete as soon as animations do respect all the settings.
The lens is buggy, see the commit message of [3b103d27a5871f0324fc7ce0506d742372c28ccf] for details. Instead of making the code even more complicated (to work around those issues), we should just leave it this way and hope that animations will eventually work just like normal images in the future.
There is a pref "animation mode" for whether this feature should be enabled or not but there is no way to control it using the GUI. Since the current implementation for animation support is more or less experimental, I propose setting the default value of "animation_mode" to constants.ANIMATION_DISABLED and adding a checkbox in the "Preferences/Advanced" tab (instead of "Preferences/Display").
There are new commits on branch "animation". Feel free to comment. Note that the lens is as buggy as before. If there are no complains, I will merge it into master.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I just opted for a different workaround: Do not render animations in the magnifying lens at all. While this is still far from perfect, it feels way less buggy than before.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
For the record: I merged animation into master. The animation ignores any image manipulation settings (including zoom) and does not work with the magnifying lens. I still consider this feature somewhat experimental, which is why it will be turned off by default.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'd like to say that I'd love this too. I don't even need them scaled, necessarily - just viewing them would be fantastic.
Up: I still keep this feature actual for myself ( https://github.com/HoverHell/mcomix ). I've merged the svn trunk there, which means this feature (and couple others) can be merged rather easily (by whomever has the write access to the svn).
I am sorry for the late reply. I am posting this mainly because another request for this just came in (see [bugs:#107]). Obviously, it seems that this is an often-requested feature. Unfortunately, I do not have much spare time left for MComix development, and there is also a workaround for this (see below). Therefore, I am currently not motivated to do much about this issue. I am sorry, again. I wish that I had more time for this. Are you (and by "you", I also mean Momoe), by any chance, interested in supporting me? I cannot promise anything, and, based on what things look like now, it will take a long time until this will be implemented. That is, I could really use your help.
As I said, there is a workaround: Use File → Open with → Edit commands and add a line there to run a player such as mpv, e.g.
See https://sourceforge.net/p/mcomix/wiki/External_Commands/ for details.
Related
Bugs:
#107The patch I'm using gives minimal support for animated gifs, and it still
works. It's quite too experimental,which is why it is hidden under a
non-GUI setting. But it works. At the very least you can apply that patch
(wih the hidden documented setting) to the main codebase.
On Fri, Aug 19, 2016 at 7:54 PM, Ark aaku@users.sf.net wrote:
Related
Bugs:
#107Feature Requests:
#93Good news: A first implementation on the new branch "animation" is available for testing: [0e9c10] Feedback is welcome!
@HoverHell: Thank you very much for your groundwork. Also, thank you for your positive reply, it certainly boosted my motivation.
Related
Commit: [0e9c10]
I further improved the
animationbranch and already merged an (unfortunately buggy) version tomaster. Few things to note:zoom.pyassume that animations can be scaled just like normal images while they actually remain unchanged. This breaks things like "Fit to width" in double page mode if one image is animated and the other one is not. (In this case, downscaling will be performed on the scalable image but not necessarily enough to make the double page actually fit.) While this is unsolvable in principle (for example, if the animation is wider than the viewport, there is no way to make it fit), the current approach does not degenerate the scalable image to a one-pixel wide line."animation_mode"toconstants.ANIMATION_DISABLEDand adding a checkbox in the "Preferences/Advanced" tab (instead of "Preferences/Display").Feel free to comment.
Related
Commit: [3b103d]
There are new commits on branch "animation". Feel free to comment. Note that the lens is as buggy as before. If there are no complains, I will merge it into master.
I just opted for a different workaround: Do not render animations in the magnifying lens at all. While this is still far from perfect, it feels way less buggy than before.
For the record: I merged
animationintomaster. The animation ignores any image manipulation settings (including zoom) and does not work with the magnifying lens. I still consider this feature somewhat experimental, which is why it will be turned off by default.